aboutsummaryrefslogtreecommitdiff
path: root/libjava/testsuite/libjava.lang/invokethrow.java
blob: 8cf3ca0a51ba5ad3f0263b5213e0349d80a166f0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// Test a `throw' across a libffi call.

import java.lang.reflect.*;

public class invokethrow
{
  public static void doit () throws Throwable
  {
    throw new Throwable ("hi!");
  }

  public static void main (String[] args)
  {
    Class k = invokethrow.class;
    try
      {
	Class[] noargs = new Class[0];
	Method m = k.getMethod ("doit", noargs);
	m.invoke (null, null);
      }
    catch (InvocationTargetException x1)
      {
	System.out.println (x1.getTargetException ().getMessage ());
      }
    catch (UnsupportedOperationException _)
      {
	// Some systems don't support invocation, in which case we
	// will fake a passing result.
	System.out.println ("hi!");
      }
    catch (Throwable _)
      {
      }
  }
}
e22a004d4921b7dee6ddb'>dependencies/Gemfile17
-rw-r--r--dependencies/README.md2
-rw-r--r--dependencies/apt_packages.txt22
-rw-r--r--dependencies/package.json8
m---------docs-resources0
-rw-r--r--marchid.md55
-rw-r--r--normative_rule_defs/README.md22
-rw-r--r--normative_rule_defs/m-st-ext.yaml38
-rw-r--r--normative_rule_defs/machine.yaml94
-rw-r--r--normative_rule_defs/rv-32-64g.yaml346
-rw-r--r--normative_rule_defs/rv32.yaml153
-rw-r--r--normative_rule_defs/rv64.yaml70
-rw-r--r--normative_rule_defs/zilsd.yaml41
-rw-r--r--release/riscv-privileged-v1.10.pdfbin536816 -> 0 bytes-rw-r--r--release/riscv-privileged-v1.7.pdfbin380597 -> 0 bytes-rw-r--r--release/riscv-privileged-v1.9.1.pdfbin625668 -> 0 bytes-rw-r--r--release/riscv-privileged-v1.9.pdfbin514566 -> 0 bytes-rw-r--r--release/riscv-spec-v2.1.pdfbin611902 -> 0 bytes-rw-r--r--release/riscv-spec-v2.2.pdfbin615016 -> 0 bytes-rw-r--r--src/a-st-ext.adoc485
-rw-r--r--src/a.tex404
-rw-r--r--src/assembly.tex163
-rw-r--r--src/b-st-ext.adoc3865
-rw-r--r--src/b.tex19
-rw-r--r--src/bfloat16.adoc780
-rw-r--r--src/bibliography.adoc4
-rw-r--r--src/c-st-ext.adoc918
-rw-r--r--src/c.tex1225
-rw-r--r--src/calling-convention.adoc29
-rw-r--r--src/cfgstr.tex63
-rw-r--r--src/cmo.adoc1126
-rw-r--r--src/colophon.adoc464
-rw-r--r--src/counters.adoc236
-rw-r--r--src/counters.tex205
-rw-r--r--src/csr.tex156
-rw-r--r--src/d-st-ext.adoc230
-rw-r--r--src/d.tex439
-rw-r--r--src/dep-table.tex456
-rw-r--r--src/example/memcpy.s17
-rw-r--r--src/example/saxpy.s29
-rw-r--r--src/example/sgemm.S221
-rw-r--r--src/example/strcmp.s32
-rw-r--r--src/example/strcpy.s20
-rw-r--r--src/example/strlen.s22
-rw-r--r--src/example/strncpy.s36
-rw-r--r--src/example/vvaddint32.s22
-rw-r--r--src/extensions.tex381
-rw-r--r--src/f-st-ext.adoc499
-rw-r--r--src/f.tex801
-rw-r--r--src/figs/PLIC-block-diagram.pdfbin13826 -> 0 bytes-rw-r--r--src/figs/PLIC-interrupt-flow.pdfbin15941 -> 0 bytes-rw-r--r--src/figs/halimps.pdfbin10187 -> 0 bytes-rw-r--r--src/figs/halmode.pdfbin11179 -> 0 bytes-rw-r--r--src/figs/litmus_addrpo.pdfbin4481 -> 0 bytes-rw-r--r--src/figs/litmus_addrpo.pdf_t49
-rw-r--r--src/figs/litmus_datacoirfi.pdfbin4081 -> 0 bytes-rw-r--r--src/figs/litmus_datacoirfi.pdf_t61
-rw-r--r--src/figs/litmus_datarfi.pdfbin4668 -> 0 bytes-rw-r--r--src/figs/litmus_datarfi.pdf_t56
-rw-r--r--src/figs/litmus_lb_lrsc.pdfbin4988 -> 0 bytes-rw-r--r--src/figs/litmus_lb_lrsc.pdf_t50
-rw-r--r--src/figs/litmus_mp_fenceww_fri_rfi_addr.pdfbin4081 -> 0 bytes-rw-r--r--src/figs/litmus_mp_fenceww_fri_rfi_addr.pdf_t56
-rw-r--r--src/figs/litmus_ppoca.pdfbin5280 -> 0 bytes-rw-r--r--src/figs/litmus_ppoca.pdf_t58
-rw-r--r--src/figs/litmus_rsw.pdfbin4308 -> 0 bytes-rw-r--r--src/figs/litmus_rsw.pdf_t61
-rw-r--r--src/figs/litmus_sample.pdfbin5320 -> 0 bytes-rw-r--r--src/figs/litmus_sample.pdf_t52
-rw-r--r--src/figs/litmus_sb_fwd.pdfbin3886 -> 0 bytes-rw-r--r--src/figs/litmus_sb_fwd.pdf_t52
-rw-r--r--src/figs/litmus_subsumption.pdfbin3620 -> 0 bytes-rw-r--r--src/figs/litmus_subsumption.pdf_t49
-rw-r--r--src/figs/privimps.pdfbin9537 -> 0 bytes-rw-r--r--src/figs/virtimps.pdfbin11644 -> 0 bytes-rw-r--r--src/fraclmul.adoc175
-rw-r--r--src/gmaps.tex75
-rw-r--r--src/history.tex403
-rw-r--r--src/hypervisor.adoc2599
-rw-r--r--src/hypervisor.tex1474
-rw-r--r--src/images/.gitignore1
-rw-r--r--src/images/backpage.pngbin0 -> 142162 bytes-rw-r--r--src/images/base-unpriv-reg-state.pngbin0 -> 49614 bytes-rw-r--r--src/images/bytefield/counteren.edn30
-rw-r--r--src/images/bytefield/counterinh.edn30
-rw-r--r--src/images/bytefield/cust-sys-instr.edn80
-rw-r--r--src/images/bytefield/epcreg.edn16
-rw-r--r--src/images/bytefield/hcounterenreg.edn43
-rw-r--r--src/images/bytefield/hedelegreg.edn17
-rw-r--r--src/images/bytefield/hgeiereg.edn16
-rw-r--r--src/images/bytefield/hgeipreg.edn15
-rw-r--r--src/images/bytefield/hidelegreg.edn17
-rw-r--r--src/images/bytefield/hiereg-standard.edn43
-rw-r--r--src/images/bytefield/hiereg.edn17
-rw-r--r--src/images/bytefield/hipreg-standard.edn43
-rw-r--r--src/images/bytefield/hipreg.edn17
-rw-r--r--src/images/bytefield/hpmevents.edn47
-rw-r--r--src/images/bytefield/htimedelta.edn16
-rw-r--r--src/images/bytefield/htimedeltah.edn17
-rw-r--r--src/images/bytefield/htinstreg.edn16
-rw-r--r--src/images/bytefield/htvalreg.edn16
-rw-r--r--src/images/bytefield/hvipreg-standard.edn37
-rw-r--r--src/images/bytefield/hvipreg.edn17
-rw-r--r--src/images/bytefield/hypv-miereg-standard.edn58
-rw-r--r--src/images/bytefield/hypv-mipreg-standard.edn58
-rw-r--r--src/images/bytefield/hypv-mstatus.edn129
-rw-r--r--src/images/bytefield/hypv-mstatush.edn32
-rw-r--r--src/images/bytefield/marchid.edn14
-rw-r--r--src/images/bytefield/mcausereg.edn20
-rw-r--r--src/images/bytefield/mconfigptrreg.edn13
-rw-r--r--src/images/bytefield/medeleg.edn17
-rw-r--r--src/images/bytefield/mepcreg.edn15
-rw-r--r--src/images/bytefield/mhartid.edn14
-rw-r--r--src/images/bytefield/mideleg.edn17
-rw-r--r--src/images/bytefield/miereg-standard.edn42
-rw-r--r--src/images/bytefield/mimpid.edn14
-rw-r--r--src/images/bytefield/mipreg-standard.edn42
-rw-r--r--src/images/bytefield/misareg.edn27
-rw-r--r--src/images/bytefield/mncause.edn16
-rw-r--r--src/images/bytefield/mnepc.edn14
-rw-r--r--src/images/bytefield/mnscratch.edn13
-rw-r--r--src/images/bytefield/mnstatus.edn33
-rw-r--r--src/images/bytefield/mscratch.edn16
-rw-r--r--src/images/bytefield/mtime.edn13
-rw-r--r--src/images/bytefield/mtimecmp.edn13
-rw-r--r--src/images/bytefield/mtinstreg.edn14
-rw-r--r--src/images/bytefield/mtval2reg.edn14
-rw-r--r--src/images/bytefield/mtvalreg.edn13
-rw-r--r--src/images/bytefield/mtvec.edn18
-rw-r--r--src/images/bytefield/mvendorid.edn15
-rw-r--r--src/images/bytefield/pmp-rv32.edn79
-rw-r--r--src/images/bytefield/pmp-rv64.edn131
-rw-r--r--src/images/bytefield/pmpaddr-rv32.edn15
-rw-r--r--src/images/bytefield/pmpaddr-rv64.edn18
-rw-r--r--src/images/bytefield/pmpcfg.edn32
-rw-r--r--src/images/bytefield/priv-instr-set.edn279
-rw-r--r--src/images/bytefield/rv32hgatp.edn30
-rw-r--r--src/images/bytefield/rv32satp.edn26
-rw-r--r--src/images/bytefield/rv32vsatpreg.edn26
-rw-r--r--src/images/bytefield/rv64hgatp.edn32
-rw-r--r--src/images/bytefield/rv64satp.edn27
-rw-r--r--src/images/bytefield/rv64vsatpreg.edn27
-rw-r--r--src/images/bytefield/rvc-instr-quad0.edn90
-rw-r--r--src/images/bytefield/rvc-instr-quad1.edn173
-rw-r--r--src/images/bytefield/rvc-instr-quad2.edn105
-rw-r--r--src/images/bytefield/scausereg.edn21
-rw-r--r--src/images/bytefield/scounteren.edn43
-rw-r--r--src/images/bytefield/sie.edn17
-rw-r--r--src/images/bytefield/siereg-standard.edn49
-rw-r--r--src/images/bytefield/sip.edn17
-rw-r--r--src/images/bytefield/sipreg-standard.edn49
-rw-r--r--src/images/bytefield/sscratch.edn16
-rw-r--r--src/images/bytefield/stvalreg.edn16
-rw-r--r--src/images/bytefield/stvec.edn28
-rw-r--r--src/images/bytefield/sv32pa.edn24
-rw-r--r--src/images/bytefield/sv32pte.edn48
-rw-r--r--src/images/bytefield/sv32va.edn24
-rw-r--r--src/images/bytefield/sv32x4va.edn30
-rw-r--r--src/images/bytefield/sv39pa.edn28
-rw-r--r--src/images/bytefield/sv39pte.edn64
-rw-r--r--src/images/bytefield/sv39va.edn28
-rw-r--r--src/images/bytefield/sv39x4va.edn34
-rw-r--r--src/images/bytefield/sv48pa.edn32
-rw-r--r--src/images/bytefield/sv48pte.edn68
-rw-r--r--src/images/bytefield/sv48va.edn38
-rw-r--r--src/images/bytefield/sv48x4va.edn38
-rw-r--r--src/images/bytefield/sv57pa.edn36
-rw-r--r--src/images/bytefield/sv57pte.edn87
-rw-r--r--src/images/bytefield/sv57va.edn36
-rw-r--r--src/images/bytefield/sv57x4va.edn42
-rw-r--r--src/images/bytefield/vscausereg.edn18
-rw-r--r--src/images/bytefield/vsepcreg.edn14
-rw-r--r--src/images/bytefield/vsiereg-standard.edn51
-rw-r--r--src/images/bytefield/vsiereg.edn17
-rw-r--r--src/images/bytefield/vsipreg-standard.edn51
-rw-r--r--src/images/bytefield/vsipreg.edn17
-rw-r--r--src/images/bytefield/vsscratchreg.edn14
-rw-r--r--src/images/bytefield/vsstatusreg-rv32.edn86
-rw-r--r--src/images/bytefield/vsstatusreg.edn90
-rw-r--r--src/images/bytefield/vstvalreg.edn14
-rw-r--r--src/images/bytefield/vstvecreg.edn22
-rw-r--r--src/images/draft.pngbin0 -> 24563 bytes-rw-r--r--src/images/es_dataflow.svg181
-rw-r--r--src/images/es_noisetest.svg122
-rw-r--r--src/images/es_state.svg71
-rw-r--r--src/images/graphviz/litmus_addrpo.pngbin0 -> 32841 bytes-rw-r--r--src/images/graphviz/litmus_addrpo.txt (renamed from src/graphviz/litmus_addrpo.dot)2
-rw-r--r--src/images/graphviz/litmus_datacoirfi.pngbin0 -> 43027 bytes-rw-r--r--src/images/graphviz/litmus_datacoirfi.txt (renamed from src/graphviz/litmus_datacoirfi.dot)0
-rw-r--r--src/images/graphviz/litmus_datarfi.pngbin0 -> 41219 bytes-rw-r--r--src/images/graphviz/litmus_datarfi.txt (renamed from src/graphviz/litmus_datarfi.dot)0
-rw-r--r--src/images/graphviz/litmus_lb_lrsc.pngbin0 -> 43281 bytes-rw-r--r--src/images/graphviz/litmus_lb_lrsc.txt (renamed from src/graphviz/litmus_lb_lrsc.dot)2
-rw-r--r--src/images/graphviz/litmus_mp_fenceww_fri_rfi_addr.pngbin0 -> 35420 bytes-rw-r--r--src/images/graphviz/litmus_mp_fenceww_fri_rfi_addr.txt (renamed from src/graphviz/litmus_mp_fenceww_fri_rfi_addr.dot)2
-rw-r--r--src/images/graphviz/litmus_ppoca.pngbin0 -> 43783 bytes-rw-r--r--src/images/graphviz/litmus_ppoca.txt (renamed from src/graphviz/litmus_ppoca.dot)3
-rw-r--r--src/images/graphviz/litmus_rsw.pngbin0 -> 36051 bytes-rw-r--r--src/images/graphviz/litmus_rsw.txt (renamed from src/graphviz/litmus_rsw.dot)2
-rw-r--r--src/images/graphviz/litmus_sample.adoc (renamed from src/graphviz/litmus_sample.dot)5
-rw-r--r--src/images/graphviz/litmus_sample.pngbin0 -> 32792 bytes-rw-r--r--src/images/graphviz/litmus_sample.txt37
-rw-r--r--src/images/graphviz/litmus_sb_fwd.pngbin0 -> 31689 bytes-rw-r--r--src/images/graphviz/litmus_sb_fwd.txt (renamed from src/graphviz/litmus_sb_fwd.dot)3
-rw-r--r--src/images/graphviz/litmus_subsumption.pngbin0 -> 28760 bytes-rw-r--r--src/images/graphviz/litmus_subsumption.txt (renamed from src/graphviz/litmus_subsumption.dot)0
-rw-r--r--src/images/image_placeholder.pngbin0 -> 3996 bytes-rw-r--r--src/images/png/misareg.pngbin0 -> 9337 bytes-rw-r--r--src/images/png/mvendorid.pngbin0 -> 3223 bytes-rw-r--r--src/images/png/privimps.pngbin0 -> 17660 bytes-rw-r--r--src/images/risc-v_logo.pngbin0 -> 11962 bytes-rw-r--r--src/images/riscv-horizontal-color.svg36
-rw-r--r--src/images/smepmp-visual-representation.pngbin0 -> 89113 bytes-rw-r--r--src/images/wavedrom/atomic-mem.edn15
-rw-r--r--src/images/wavedrom/b-immediate.edn12
-rw-r--r--src/images/wavedrom/c-andi.edn13
-rw-r--r--src/images/wavedrom/c-breakpoint-instr.edn11
-rw-r--r--src/images/wavedrom/c-cb-format-ls.edn12
-rw-r--r--src/images/wavedrom/c-ci.edn12
-rw-r--r--src/images/wavedrom/c-ciw.edn11
-rw-r--r--src/images/wavedrom/c-cj-format-ls.edn20
-rw-r--r--src/images/wavedrom/c-cr-format-ls.edn11
-rw-r--r--src/images/wavedrom/c-cs-format-ls.edn14
-rw-r--r--src/images/wavedrom/c-def-illegal-inst.edn13
-rw-r--r--src/images/wavedrom/c-int-reg-immed.edn12
-rw-r--r--src/images/wavedrom/c-int-reg-to-reg-ca-format.edn13
-rw-r--r--src/images/wavedrom/c-int-reg-to-reg-cr-format.edn12
-rw-r--r--src/images/wavedrom/c-integer-const-gen.edn12
-rw-r--r--src/images/wavedrom/c-mop.edn12
-rw-r--r--src/images/wavedrom/c-nop-instr.edn13
-rw-r--r--src/images/wavedrom/c-sp-load-store-css.edn11
-rw-r--r--src/images/wavedrom/c-sp-load-store.edn13
-rw-r--r--src/images/wavedrom/c-srli-srai.edn13
-rw-r--r--src/images/wavedrom/counters-diag.edn13
-rw-r--r--src/images/wavedrom/cr-register.edn109
-rw-r--r--src/images/wavedrom/csr-instr.edn24
-rw-r--r--src/images/wavedrom/ct-conditional.edn13
-rw-r--r--src/images/wavedrom/ct-unconditional-2.edn12
-rw-r--r--src/images/wavedrom/ct-unconditional.edn14
-rw-r--r--src/images/wavedrom/d-xwwx.edn14
-rw-r--r--src/images/wavedrom/division-op.edn25
-rw-r--r--src/images/wavedrom/double-fl-class.edn14
-rw-r--r--src/images/wavedrom/double-fl-compare.edn14
-rw-r--r--src/images/wavedrom/double-fl-compute.edn53
-rw-r--r--src/images/wavedrom/double-fl-convert-mv.edn15
-rw-r--r--src/images/wavedrom/double-ls.edn25
-rw-r--r--src/images/wavedrom/env-call-breakpoint.edn12
-rw-r--r--src/images/wavedrom/fcvt-sd-ds.edn14
-rw-r--r--src/images/wavedrom/float-csr.edn16
-rw-r--r--src/images/wavedrom/flt-pt-to-int-move.edn14
-rw-r--r--src/images/wavedrom/flt-to-flt-sgn-inj-instr.edn14
-rw-r--r--src/images/wavedrom/fsjgnjnx-d.edn14
-rw-r--r--src/images/wavedrom/half-ls.edn13
-rw-r--r--src/images/wavedrom/half-pr-flt-pt-class.edn14
-rw-r--r--src/images/wavedrom/half-pr-flt-pt-compare.edn14
-rw-r--r--src/images/wavedrom/half-prec-conv-and-mv.edn15
-rw-r--r--src/images/wavedrom/half-prec-flpt-to-flpt-conv.edn14
-rw-r--r--src/images/wavedrom/hinvalgvma.edn11
-rw-r--r--src/images/wavedrom/hinvalvvma.edn11
-rw-r--r--src/images/wavedrom/hypv-mm-fence.edn13
-rw-r--r--src/images/wavedrom/hypv-virt-load-and-store.edn13
-rw-r--r--src/images/wavedrom/i-immediate.edn13
-rw-r--r--src/images/wavedrom/immediate-variants.edn73
-rw-r--r--src/images/wavedrom/immediate.edn13
-rw-r--r--src/images/wavedrom/instruction-formats.edn47
-rw-r--r--src/images/wavedrom/int-comp-lui-aiupc.edn12
-rw-r--r--src/images/wavedrom/int-comp-slli-srli-srai.edn15
-rw-r--r--src/images/wavedrom/int-reg-reg.edn13
-rw-r--r--src/images/wavedrom/integer-computational.edn15
-rw-r--r--src/images/wavedrom/j-immediate.edn13
-rw-r--r--src/images/wavedrom/load-reserve-st-conditional.edn17
-rw-r--r--src/images/wavedrom/load-store.edn24
-rw-r--r--src/images/wavedrom/m-st-ext-for-int-mult.edn26
-rw-r--r--src/images/wavedrom/mem-order.edn20
-rw-r--r--src/images/wavedrom/menvcfgreg.edn21
-rw-r--r--src/images/wavedrom/mm-env-call.edn13
-rw-r--r--src/images/wavedrom/mop-r.edn15
-rw-r--r--src/images/wavedrom/mop-rr.edn15
-rw-r--r--src/images/wavedrom/mseccfg.edn16
-rw-r--r--src/images/wavedrom/mstatushreg.edn15
-rw-r--r--src/images/wavedrom/mstatusreg-rv321.edn29
-rw-r--r--src/images/wavedrom/mstatusreg.edn39
-rw-r--r--src/images/wavedrom/nop.edn11
-rw-r--r--src/images/wavedrom/quad-cnvrt-intch-xqqx.edn14
-rw-r--r--src/images/wavedrom/quad-cnvrt-mv.edn27
-rw-r--r--src/images/wavedrom/quad-cnvt-interchange.edn14
-rw-r--r--src/images/wavedrom/quad-compute.edn54
-rw-r--r--src/images/wavedrom/quad-float-clssfy.edn14
-rw-r--r--src/images/wavedrom/quad-float-compare.edn14
-rw-r--r--src/images/wavedrom/quad-ls.edn24
-rw-r--r--src/images/wavedrom/reg-based-ldnstr.edn14
-rw-r--r--src/images/wavedrom/rv64-lui-auipc.edn10
-rw-r--r--src/images/wavedrom/rv64i-base-int.edn14
-rw-r--r--src/images/wavedrom/rv64i-int-reg-reg.edn27
-rw-r--r--src/images/wavedrom/rv64i-slli.edn11
-rw-r--r--src/images/wavedrom/rv64i-slliw.edn12
-rw-r--r--src/images/wavedrom/s-immediate.edn11
-rw-r--r--src/images/wavedrom/sfenceinvalir.edn11
-rw-r--r--src/images/wavedrom/sfencevma.edn11
-rw-r--r--src/images/wavedrom/sfencewinval.edn11
-rw-r--r--src/images/wavedrom/sinvalvma.edn11
-rw-r--r--src/images/wavedrom/sp-load-store-2.edn24
-rw-r--r--src/images/wavedrom/sp-load-store.edn24
-rw-r--r--src/images/wavedrom/spfloat-classify.edn14
-rw-r--r--src/images/wavedrom/spfloat-cn-cmp.edn14
-rw-r--r--src/images/wavedrom/spfloat-comp.edn14
-rw-r--r--src/images/wavedrom/spfloat-mv.edn14
-rw-r--r--src/images/wavedrom/spfloat-sign-inj.edn14
-rw-r--r--src/images/wavedrom/spfloat-zfh.edn14
-rw-r--r--src/images/wavedrom/spfloat.edn14
-rw-r--r--src/images/wavedrom/spfloat2-zfh.edn12
-rw-r--r--src/images/wavedrom/spfloat2.edn12
-rw-r--r--src/images/wavedrom/transformedatomicinst.edn13
-rw-r--r--src/images/wavedrom/transformedloadinst.edn11
-rw-r--r--src/images/wavedrom/transformedstoreinst.edn11
-rw-r--r--src/images/wavedrom/transformedvmaccessinst.edn11
-rw-r--r--src/images/wavedrom/trap-return.edn13
-rw-r--r--src/images/wavedrom/u-immediate.edn11
-rw-r--r--src/images/wavedrom/v-inst-table.edn208
-rw-r--r--src/images/wavedrom/valu-format.edn104
-rw-r--r--src/images/wavedrom/vcfg-format.edn47
-rw-r--r--src/images/wavedrom/vfrec7.edn136
-rw-r--r--src/images/wavedrom/vfrsqrt7.edn137
-rw-r--r--src/images/wavedrom/vmem-format.edn108
-rw-r--r--src/images/wavedrom/vtype-format.edn28
-rw-r--r--src/images/wavedrom/wfi.edn13
-rw-r--r--src/images/wavedrom/zifencei-ff.edn12
-rw-r--r--src/images/wavedrom/zihintpause-hint.edn20
-rw-r--r--src/index.adoc2
-rw-r--r--src/indirect-csr.adoc333
-rw-r--r--src/inkscape/PLIC-block-diagram.svg3309
-rw-r--r--src/inkscape/PLIC-interrupt-flow.svg775
-rw-r--r--src/inkscape/halimps.svg994
-rw-r--r--src/inkscape/halmode.svg799
-rw-r--r--src/inkscape/htif.svg626
-rw-r--r--src/inkscape/privimps.svg820
-rw-r--r--src/inkscape/proxy.svg635
-rw-r--r--src/inkscape/virtimps.svg730
-rw-r--r--src/instr-table.tex2004
-rw-r--r--src/intro.adoc696
-rw-r--r--src/intro.tex701
-rw-r--r--src/j.tex13
-rw-r--r--src/l.tex20
-rw-r--r--src/m-st-ext.adoc157
-rw-r--r--src/m.tex162
-rw-r--r--src/machine.adoc3341
-rw-r--r--src/machine.tex3098
-rw-r--r--src/memory-model-operational.tex659
-rw-r--r--src/memory.tex1422
-rw-r--r--src/mm-alloy.adoc (renamed from src/memory-model-alloy.tex)92
-rw-r--r--src/mm-eplan.adoc1851
-rw-r--r--src/mm-formal.adoc1425
-rw-r--r--src/mm-herd.adoc (renamed from src/memory-model-herd.tex)75
-rw-r--r--src/n.tex124
-rw-r--r--src/naming.adoc222
-rw-r--r--src/naming.tex161
-rw-r--r--src/opcode-map.tex22
-rw-r--r--src/p.tex101
-rw-r--r--src/plic.tex427
-rw-r--r--src/preamble.tex139
-rw-r--r--src/preface.tex291
-rw-r--r--src/priv-cfi.adoc365
-rw-r--r--src/priv-csrs.adoc1267
-rw-r--r--src/priv-csrs.tex457
-rw-r--r--src/priv-history.adoc22
-rw-r--r--src/priv-history.tex29
-rw-r--r--src/priv-insns.adoc12
-rw-r--r--src/priv-insns.tex9
-rw-r--r--src/priv-instr-table.tex118
-rw-r--r--src/priv-intro.adoc216
-rw-r--r--src/priv-intro.tex224
-rw-r--r--src/priv-preface.adoc597
-rw-r--r--src/priv-preface.tex126
-rw-r--r--src/q-st-ext.adoc113
-rw-r--r--src/q.tex307
-rw-r--r--src/rationale.adoc62
-rw-r--r--src/resources/riscv-spec.bib1804
-rw-r--r--src/riscv-privileged.adoc141
-rw-r--r--src/riscv-privileged.tex88
-rw-r--r--src/riscv-spec.bib491
-rw-r--r--src/riscv-spec.tex108
-rw-r--r--src/riscv-unprivileged.adoc210
-rw-r--r--src/rnmi.adoc166
-rw-r--r--src/rv-32-64g.adoc462
-rw-r--r--src/rv128.tex71
-rw-r--r--src/rv32.adoc1103
-rw-r--r--src/rv32.tex1370
-rw-r--r--src/rv32e.adoc46
-rw-r--r--src/rv32e.tex49
-rw-r--r--src/rv64.adoc260
-rw-r--r--src/rv64.tex303
-rw-r--r--src/rvc-instr-table.tex537
-rw-r--r--src/rvc-opcode-map.tex27
-rw-r--r--src/rvwmo.adoc815
-rw-r--r--src/rvwmo.tex217
-rw-r--r--src/scalar-crypto.adoc5659
-rw-r--r--src/smcdeleg.adoc147
-rw-r--r--src/smcntrpmf.adoc69
-rw-r--r--src/smctr.adoc760
-rw-r--r--src/smdbltrp.adoc17
-rw-r--r--src/smepmp.adoc176
-rw-r--r--src/smstateen.adoc373
-rw-r--r--src/sscofpmf.adoc126
-rw-r--r--src/ssdbltrp.adoc15
-rw-r--r--src/sstc.adoc187
-rw-r--r--src/supervisor.adoc2457
-rw-r--r--src/supervisor.tex1571
-rw-r--r--src/svgnam.def10
-rw-r--r--src/t.tex16
-rw-r--r--src/unpriv-cfi.adoc877
-rw-r--r--src/v-instr-table.tex733
-rw-r--r--src/v-st-ext.adoc5322
-rw-r--r--src/v.tex1402
-rw-r--r--src/vector-crypto.adoc4965
-rw-r--r--src/vector-examples.adoc125
-rw-r--r--src/xcolor.sty1449
-rw-r--r--src/zabha.adoc68
-rw-r--r--src/zacas.adoc259
-rw-r--r--src/zam.tex26
-rw-r--r--src/zawrs.adoc103
-rw-r--r--src/zc.adoc2589
-rw-r--r--src/zfa.adoc239
-rw-r--r--src/zfh.adoc176
-rw-r--r--src/zfinx.adoc148
-rw-r--r--src/zicond.adoc183
-rw-r--r--src/zicsr.adoc237
-rw-r--r--src/zifencei.adoc127
-rw-r--r--src/zifencei.tex111
-rw-r--r--src/zihintntl.adoc188
-rw-r--r--src/zihintpause.adoc56
-rw-r--r--src/zilsd.adoc316
-rw-r--r--src/zimop.adoc110
-rw-r--r--src/zpm.adoc302
-rw-r--r--src/ztso-st-ext.adoc47
-rw-r--r--src/ztso.tex29
-rw-r--r--tagging_normative_rules.adoc134
450 files changed, 62315 insertions, 34940 deletions
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
new file mode 100644
index 0000000..2a02267
--- /dev/null
+++ b/.github/dependabot.yml
@@ -0,0 +1,12 @@
+---
+# https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#package-ecosystem
+version: 2
+updates:
+ - package-ecosystem: gitsubmodule
+ directory: /
+ schedule:
+ interval: daily
+ - package-ecosystem: github-actions
+ directory: /
+ schedule:
+ interval: daily
diff --git a/.github/workflows/check-ready-to-merge.yml b/.github/workflows/check-ready-to-merge.yml
new file mode 100644
index 0000000..bdd5393
--- /dev/null
+++ b/.github/workflows/check-ready-to-merge.yml
@@ -0,0 +1,22 @@
+---
+name: Check Mergeable by Label
+
+on:
+ pull_request:
+ types:
+ - opened
+ - reopened
+ - synchronize
+ - edited
+ - labeled
+ - unlabeled
+
+jobs:
+ fail-by-label:
+ if: contains(github.event.pull_request.labels.*.name, 'Pending Ratification')
+ runs-on: ubuntu-latest
+ steps:
+ - name: Fail if PR is labeled "Pending Ratification"
+ run: |
+ echo "Error: This PR is labeled as 'Pending Ratification' and cannot be merged."
+ exit 1
diff --git a/.github/workflows/isa-build.yml b/.github/workflows/isa-build.yml
new file mode 100644
index 0000000..6aa3804
--- /dev/null
+++ b/.github/workflows/isa-build.yml
@@ -0,0 +1,156 @@
+---
+name: RISC-V ISA Build
+
+on:
+ workflow_dispatch:
+ inputs:
+ create_release:
+ description: Create a new RISC-V ISA release if set to true
+ required: false
+ default: 'false'
+ target_branch:
+ description: Target Branch
+ required: true
+ default: main
+ release_notes:
+ description: Release Notes
+ required: false
+ push:
+ branches:
+ - main
+ pull_request:
+ branches:
+ - main
+
+jobs:
+ build:
+ runs-on: ubuntu-latest
+
+ steps:
+ # Checkout the repository
+ - name: Checkout repository
+ uses: actions/checkout@v5
+ with:
+ submodules: recursive
+
+ # Set the short SHA for use in artifact names
+ - name: Set short SHA
+ run: echo "SHORT_SHA=$(echo ${GITHUB_SHA::7})" >> $GITHUB_ENV
+
+ # Get the current date
+ - name: Get current date
+ run: echo "CURRENT_DATE=$(date +'%Y-%m-%d')" >> $GITHUB_ENV
+
+ # Build PDF and HTML files using the container
+ - name: Build Files
+ id: build_files
+ run: make -j$(nproc)
+
+ # Upload the riscv-privileged PDF file
+ - name: Upload riscv-privileged.pdf
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-privileged-${{ env.SHORT_SHA }}.pdf
+ path: ${{ github.workspace }}/build/riscv-privileged.pdf
+ retention-days: 7
+
+ # Upload the riscv-privileged HTML file
+ - name: Upload riscv-privileged.html
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-privileged-${{ env.SHORT_SHA }}.html
+ path: ${{ github.workspace }}/build/riscv-privileged.html
+ retention-days: 7
+
+ # Upload the riscv-privileged EPUB file
+ - name: Upload riscv-privileged.epub
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-privileged-${{ env.SHORT_SHA }}.epub
+ path: ${{ github.workspace }}/build/riscv-privileged.epub
+ retention-days: 7
+
+ # Upload the riscv-unprivileged PDF file
+ - name: Upload riscv-unprivileged.pdf
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-unprivileged-${{ env.SHORT_SHA }}.pdf
+ path: ${{ github.workspace }}/build/riscv-unprivileged.pdf
+ retention-days: 7
+
+ # Upload the riscv-unprivileged HTML file
+ - name: Upload riscv-unprivileged.html
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-unprivileged-${{ env.SHORT_SHA }}.html
+ path: ${{ github.workspace }}/build/riscv-unprivileged.html
+ retention-days: 7
+
+ # Upload the riscv-unprivileged EPUB file
+ - name: Upload riscv-unprivileged.epub
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-unprivileged-${{ env.SHORT_SHA }}.epub
+ path: ${{ github.workspace }}/build/riscv-unprivileged.epub
+ retention-days: 7
+
+ - name: Create Release
+ if: steps.build_files.outcome == 'success' && github.event_name == 'workflow_dispatch' && github.event.inputs.create_release == 'true'
+ #uses: softprops/action-gh-release@v2.2.2
+ uses: softprops/action-gh-release@6da8fa9354ddfdc4aeace5fc48d7f679b5214090
+ with:
+ draft: false
+ tag_name: riscv-isa-release-${{ env.SHORT_SHA }}-${{ env.CURRENT_DATE }}
+ name: ${{ env.CURRENT_DATE }}
+ body: |
+ This release was created by: ${{ github.event.sender.login }}
+ Release Notes: ${{ github.event.inputs.release_notes }}
+ files: |
+ ${{ github.workspace }}/build/riscv-privileged.pdf
+ ${{ github.workspace }}/build/riscv-privileged.html
+ ${{ github.workspace }}/build/riscv-privileged.epub
+ ${{ github.workspace }}/build/riscv-unprivileged.pdf
+ ${{ github.workspace }}/build/riscv-unprivileged.html
+ ${{ github.workspace }}/build/riscv-unprivileged.epub
+ env:
+ GITHUB_TOKEN: ${{ secrets.GHTOKEN }}
+
+ # Create directory structure pages sites for privileged and unprivileged specs.
+ - name: Make GitHub pages directory
+ run: |
+ mkdir -p dist/snapshot/unprivileged dist/snapshot/privileged
+ cp build/riscv-unprivileged.html dist/snapshot/unprivileged/index.html
+ cp build/riscv-privileged.html dist/snapshot/privileged/index.html
+ if: github.event_name == 'workflow_dispatch' || (github.event_name == 'push' && github.ref == 'refs/heads/main')
+
+ - name: Upload pages artifact
+ uses: actions/upload-pages-artifact@v3
+ with:
+ path: dist
+ if: github.event_name == 'workflow_dispatch' || (github.event_name == 'push' && github.ref == 'refs/heads/main')
+
+ # Deploy HTML to GitHub pages.
+ deploy:
+ if: github.event_name == 'push' && github.ref == 'refs/heads/main'
+
+ needs: build
+
+ permissions:
+ pages: write
+ id-token: write
+
+ environment:
+ name: github-pages
+ url: ${{ steps.deployment.outputs.page_url }}
+
+ runs-on: ubuntu-latest
+ steps:
+ - name: Deploy to GitHub Pages
+ id: deployment
+ uses: actions/deploy-pages@v4
diff --git a/.github/workflows/merge-and-release.yml b/.github/workflows/merge-and-release.yml
new file mode 100644
index 0000000..0fe06d9
--- /dev/null
+++ b/.github/workflows/merge-and-release.yml
@@ -0,0 +1,102 @@
+---
+name: Release New ISA When Merging a PR
+
+on:
+ workflow_run:
+ workflows: [RISC-V ISA Build]
+ branches:
+ - main
+ types:
+ - completed
+
+jobs:
+ on-success:
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v5
+ with:
+ submodules: recursive
+
+ - run: |
+ echo The PR was successfully merged.
+
+ - name: Set short SHA
+ run: echo "SHORT_SHA=$(echo ${GITHUB_SHA::7})" >> $GITHUB_ENV
+
+ - name: Get current date
+ run: echo "CURRENT_DATE=$(date +'%Y-%m-%d')" >> $GITHUB_ENV
+
+ - name: Build Files
+ id: build_files
+ run: make -j$(nproc) RELEASE_TYPE=intermediate
+
+ # Upload the riscv-privileged PDF file
+ - name: Upload riscv-privileged.pdf
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-privileged-${{ env.SHORT_SHA }}.pdf
+ path: ${{ github.workspace }}/build/riscv-privileged.pdf
+
+ # Upload the riscv-privileged HTML file
+ - name: Upload riscv-privileged.html
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-privileged-${{ env.SHORT_SHA }}.html
+ path: ${{ github.workspace }}/build/riscv-privileged.html
+
+ # Upload the riscv-privileged EPUB file
+ - name: Upload riscv-privileged.epub
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-privileged-${{ env.SHORT_SHA }}.epub
+ path: ${{ github.workspace }}/build/riscv-privileged.epub
+
+ # Upload the riscv-unprivileged PDF file
+ - name: Upload riscv-unprivileged.pdf
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-unprivileged-${{ env.SHORT_SHA }}.pdf
+ path: ${{ github.workspace }}/build/riscv-unprivileged.pdf
+
+ # Upload the riscv-unprivileged HTML file
+ - name: Upload riscv-unprivileged.html
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-unprivileged-${{ env.SHORT_SHA }}.html
+ path: ${{ github.workspace }}/build/riscv-unprivileged.html
+
+ # Upload the riscv-unprivileged EPUB file
+ - name: Upload riscv-unprivileged.epub
+ if: steps.build_files.outcome == 'success'
+ uses: actions/upload-artifact@v4
+ with:
+ name: riscv-unprivileged-${{ env.SHORT_SHA }}.epub
+ path: ${{ github.workspace }}/build/riscv-unprivileged.epub
+
+ - name: Create Release
+ uses: softprops/action-gh-release@v2.4.1
+ env:
+ GITHUB_TOKEN: ${{ secrets.GHTOKEN }}
+ with:
+ tag_name: riscv-isa-release-${{ env.SHORT_SHA }}-${{ env.CURRENT_DATE }}
+ name: Release riscv-isa-release-${{ env.SHORT_SHA }}-${{ env.CURRENT_DATE }}
+ draft: false
+ prerelease: false
+ make_latest: true
+ generate_release_notes: true
+ body: |
+ This release was created by: ${{ github.event.sender.login }}
+ Release of RISC-V ISA, built from commit ${{ env.SHORT_SHA }}, is now available.
+ files: |
+ ${{ github.workspace }}/build/riscv-privileged.pdf
+ ${{ github.workspace }}/build/riscv-privileged.html
+ ${{ github.workspace }}/build/riscv-privileged.epub
+ ${{ github.workspace }}/build/riscv-unprivileged.pdf
+ ${{ github.workspace }}/build/riscv-unprivileged.html
+ ${{ github.workspace }}/build/riscv-unprivileged.epub
diff --git a/.github/workflows/pre-commit.yml b/.github/workflows/pre-commit.yml
new file mode 100644
index 0000000..1b3b824
--- /dev/null
+++ b/.github/workflows/pre-commit.yml
@@ -0,0 +1,15 @@
+---
+name: pre-commit
+
+on:
+ pull_request:
+ push:
+ branches: [main]
+
+jobs:
+ pre-commit:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v5
+ - uses: actions/setup-python@v5
+ - uses: pre-commit/action@v3.0.0
diff --git a/.gitignore b/.gitignore
index e61db2e..c3a9cba 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,5 @@
.DS_Store
.*.swp
+.vscode
+/build/*
+/images/*
diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000..78a8f9c
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "docs-resources"]
+ path = docs-resources
+ url = https://github.com/riscv/docs-resources
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
new file mode 100644
index 0000000..3bb7e4b
--- /dev/null
+++ b/.pre-commit-config.yaml
@@ -0,0 +1,35 @@
+---
+repos:
+ - repo: https://github.com/pre-commit/pre-commit-hooks
+ rev: v5.0.0
+ hooks:
+ - id: check-json
+ - id: check-symlinks
+ - id: check-yaml
+ - id: end-of-file-fixer
+ - id: trailing-whitespace
+ args: [--markdown-linebreak-ext=md]
+ - id: check-merge-conflict
+ args: [--assume-in-merge]
+
+ - repo: local
+ hooks:
+ - id: forbidden-file-extensions
+ name: forbidden-file-extensions
+ entry: disallow these file extensions
+ language: fail
+ # Disallow other asciidoc extensions except .adoc
+ files: .*\.(asciidoc|asc)$
+
+ - repo: https://github.com/jumanjihouse/pre-commit-hook-yamlfmt
+ rev: 0.2.3
+ hooks:
+ - id: yamlfmt
+ args: [--mapping, '2', --sequence, '4', --offset, '2', --preserve-quotes]
+
+ - repo: https://github.com/Lucas-C/pre-commit-hooks
+ rev: v1.5.5
+ hooks:
+ - id: forbid-tabs
+ exclude_types:
+ - makefile
diff --git a/.travis.yml b/.travis.yml
deleted file mode 100644
index 9f7f99e..0000000
--- a/.travis.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-sudo: required
-dist: trusty
-before_install:
- - sudo apt-get -qq update && sudo apt-get install -y --no-install-recommends texlive-fonts-recommended texlive-latex-extra texlive-fonts-extra dvipng texlive-latex-recommended
-script:
- - make -C build
-before_deploy:
- - git tag "draft-$(date +'%Y%m%d')-$(git log --format=%h -1)"
-deploy:
- provider: releases
- api_key:
- secure: h6v0vndWyTsljlYwwyqVrtW155NJ/CAE1xl+15JJ7Uf8PVZXY3NfeNqSuGVot5Em3m4qzksHLqtJWCwi17GJxGvxex0dPjrJDPOki13PPNChbwbMT5ij2fQ5IDD5lHoXlDoP7+QZLgSJ+tQk+k0ctOKZ8Pt6JnVA13/WcRDGW1Ol1buVJU9OZoczplI1/aszEOWXXRznrbgQBXqRy1lQWAItLrC+3UWgn2GwSKg/1XirN3q9twgPFwirLkHkpCr1ZhflnJ0JBoWgsdJvA2p9ITJM+ked8WnBJ9YNDbMR7FsG0iV2C0+DF4hisLlaVmu4/+yBfNHVM8m6jFWvQPMJDjsRGwss9Ax9tLj3dr6W0FhkB99qZaAWwb25vq/nVis2MCSZlYdiOBEclgmmua0s52RonAXzyqptKNBE2IlZKVs0GrDLK7OIebhIUaW0MtlZlf98cfiSM5kH1PpSyn9ePoa29uh2KZH908zzPHukt9vSivlvgQxy1NBu+6m1hYGe4jk3rDUDnT9CBiGEi3fny9pZd9/Q3voVxC4gKd1/QC8PuEMDDPb46qQdU09yGF2xQkFHYemu9emtfIryCy0+8YSiXRZwxGN8u2CGrGwcYMA1ityMQY9aUHBWTVVOoArVR0UN94U8ZKT9SDP0y/gnyph13BQ2p1M6gO7aoUUlIlM=
- file_glob: true
- file: build/*.pdf
- skip_cleanup: true
- on:
- repo: riscv/riscv-isa-manual
- branch: master
diff --git a/LICENSE b/LICENSE
index 53883b1..2d19653 100644
--- a/LICENSE
+++ b/LICENSE
@@ -33,7 +33,7 @@ exhaustive, and do not form part of our licenses.
material not subject to the license. This includes other CC-
licensed material, or material used under an exception or
limitation to copyright. More considerations for licensors:
- wiki.creativecommons.org/Considerations_for_licensors
+ wiki.creativecommons.org/Considerations_for_licensors
Considerations for the public: By using one of our public
licenses, a licensor grants the public permission to use the
@@ -49,8 +49,8 @@ exhaustive, and do not form part of our licenses.
such as asking that all changes be marked or described.
Although not required by our licenses, you are encouraged to
respect those requests where reasonable. More_considerations
- for the public:
- wiki.creativecommons.org/Considerations_for_licensees
+ for the public:
+ creativecommons.org/Considerations_for_licensees
=======================================================================
@@ -393,4 +393,3 @@ the avoidance of doubt, this paragraph does not form part of the
public licenses.
Creative Commons may be contacted at creativecommons.org.
-
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..1b5a9a3
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,197 @@
+# Makefile for RISC-V ISA Manuals
+#
+# This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
+# International License. To view a copy of this license, visit
+# http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to
+# Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
+#
+# SPDX-License-Identifier: CC-BY-SA-4.0
+#
+# Description:
+#
+# This Makefile is designed to automate the process of building and packaging
+# the documentation for RISC-V ISA Manuals. It supports multiple build targets
+# for generating documentation in various formats (PDF, HTML, EPUB).
+#
+# Building with a preinstalled docker container is recommended.
+# Install by running:
+#
+# docker pull riscvintl/riscv-docs-base-container-image:latest
+#
+
+DOCS := riscv-privileged riscv-unprivileged
+
+RELEASE_TYPE ?= draft
+
+ifeq ($(RELEASE_TYPE), draft)
+ WATERMARK_OPT := -a draft-watermark
+ RELEASE_DESCRIPTION := DRAFT---NOT AN OFFICIAL RELEASE
+else ifeq ($(RELEASE_TYPE), intermediate)
+ WATERMARK_OPT :=
+ RELEASE_DESCRIPTION := Intermediate Release
+else ifeq ($(RELEASE_TYPE), official)
+ WATERMARK_OPT :=
+ RELEASE_DESCRIPTION := Official Release
+else
+ $(error Unknown build type; use RELEASE_TYPE={draft, intermediate, official})
+endif
+
+DATE ?= $(shell date +%Y%m%d)
+DOCKER_BIN ?= docker
+SKIP_DOCKER ?= $(shell if command -v ${DOCKER_BIN} >/dev/null 2>&1 ; then echo false; else echo true; fi)
+DOCKER_IMG := riscvintl/riscv-docs-base-container-image:latest
+ifneq ($(SKIP_DOCKER),true)
+ DOCKER_IS_PODMAN = \
+ $(shell ! ${DOCKER_BIN} -v | grep podman >/dev/null ; echo $$?)
+ ifeq "$(DOCKER_IS_PODMAN)" "1"
+ # Modify the SELinux label for the host directory to indicate
+ # that it can be shared with multiple containers. This is apparently
+ # only required for Podman, though it is also supported by Docker.
+ DOCKER_VOL_SUFFIX = :z
+ DOCKER_EXTRA_VOL_SUFFIX = ,z
+ else
+ DOCKER_IS_ROOTLESS = \
+ $(shell ! ${DOCKER_BIN} info -f '{{println .SecurityOptions}}' | grep rootless >/dev/null ; echo $$?)
+ ifneq "$(DOCKER_IS_ROOTLESS)" "1"
+ # Rooted Docker requires this flag so that the files it creates are
+ # owned by the current user instead of root. Rootless docker does not
+ # require it, and Podman doesn't either since it is always rootless.
+ DOCKER_USER_ARG := --user $(shell id -u)
+ endif
+ endif
+
+ DOCKER_CMD = \
+ ${DOCKER_BIN} run --rm \
+ -v ${PWD}/$@.workdir:/build${DOCKER_VOL_SUFFIX} \
+ -v ${PWD}/src:/src:ro${DOCKER_EXTRA_VOL_SUFFIX} \
+ -v ${PWD}/normative_rule_defs:/normative_rule_defs:ro${DOCKER_EXTRA_VOL_SUFFIX} \
+ -v ${PWD}/docs-resources:/docs-resources:ro${DOCKER_EXTRA_VOL_SUFFIX} \
+ -w /build \
+ $(DOCKER_USER_ARG) \
+ ${DOCKER_IMG} \
+ /bin/sh -c
+ DOCKER_QUOTE := "
+else
+ DOCKER_CMD = \
+ cd $@.workdir &&
+endif
+
+ifdef UNRELIABLE_BUT_FASTER_INCREMENTAL_BUILDS
+WORKDIR_SETUP = mkdir -p $@.workdir && ln -sfn ../../src ../../normative_rule_defs ../../docs-resources $@.workdir/
+WORKDIR_TEARDOWN = mv $@.workdir/$@ $@
+else
+WORKDIR_SETUP = \
+ rm -rf $@.workdir && \
+ mkdir -p $@.workdir && \
+ ln -sfn ../../src ../../normative_rule_defs ../../docs-resources $@.workdir/
+
+WORKDIR_TEARDOWN = \
+ mv $@.workdir/$@ $@ && \
+ rm -rf $@.workdir
+endif
+
+SRC_DIR := src
+BUILD_DIR := build
+NORM_RULE_DEF_DIR := normative_rule_defs
+DOC_NORM_TAG_SUFFIX := -norm-tags.json
+
+DOCS_PDF := $(addprefix $(BUILD_DIR)/, $(addsuffix .pdf, $(DOCS)))
+DOCS_HTML := $(addprefix $(BUILD_DIR)/, $(addsuffix .html, $(DOCS)))
+DOCS_EPUB := $(addprefix $(BUILD_DIR)/, $(addsuffix .epub, $(DOCS)))
+DOCS_NORM_TAGS := $(addprefix $(BUILD_DIR)/, $(addsuffix $(DOC_NORM_TAG_SUFFIX), $(DOCS)))
+NORM_RULES := $(BUILD_DIR)/norm-rules.json
+
+ENV := LANG=C.utf8
+XTRA_ADOC_OPTS :=
+
+ASCIIDOCTOR_PDF := $(ENV) asciidoctor-pdf
+ASCIIDOCTOR_HTML := $(ENV) asciidoctor
+ASCIIDOCTOR_EPUB := $(ENV) asciidoctor-epub3
+ASCIIDOCTOR_TAGS := $(ENV) asciidoctor --backend tags --require=./docs-resources/converters/tags.rb
+CREATE_NORM_RULE_TOOL := ruby docs-resources/tools/create_normative_rules.rb
+
+OPTIONS := --trace \
+ -a compress \
+ -a mathematical-format=svg \
+ -a pdf-fontsdir=docs-resources/fonts \
+ -a pdf-theme=docs-resources/themes/riscv-pdf.yml \
+ $(WATERMARK_OPT) \
+ -a revnumber='$(DATE)' \
+ -a revremark='$(RELEASE_DESCRIPTION)' \
+ -a docinfo=shared \
+ $(XTRA_ADOC_OPTS) \
+ -D build \
+ --failure-level=WARN
+REQUIRES := --require=asciidoctor-bibtex \
+ --require=asciidoctor-diagram \
+ --require=asciidoctor-lists \
+ --require=asciidoctor-mathematical \
+ --require=asciidoctor-sail
+
+.PHONY: all build clean build-container build-no-container build-docs build-pdf build-html build-epub build-tags build-norm-rules submodule-check
+
+all: build
+
+# Check if the docs-resources/global-config.adoc file exists. If not, the user forgot to check out submodules.
+ifeq ("$(wildcard docs-resources/global-config.adoc)","")
+ $(warning You must clone with --recurse-submodules to automatically populate the submodule 'docs-resources'.")
+ $(warning Checking out submodules for you via 'git submodule update --init --recursive'...)
+ $(shell git submodule update --init --recursive)
+endif
+
+build-pdf: $(DOCS_PDF)
+build-html: $(DOCS_HTML)
+build-epub: $(DOCS_EPUB)
+build-tags: $(DOCS_NORM_TAGS)
+build-norm-rules: $(NORM_RULES)
+build: build-pdf build-html build-epub build-tags build-norm-rules
+
+ALL_SRCS := $(shell git ls-files $(SRC_DIR))
+
+# All normative rule definition input YAML files tracked under Git (ensure you at least stage new files).
+NORM_RULE_DEF_FILES := $(shell git ls-files '$(NORM_RULE_DEF_DIR)/*.yaml')
+
+# Add -t to each normative tag input filename and add prefix of "/" to make into absolute pathname.
+NORM_TAG_FILE_ARGS := $(foreach relative_pname,$(DOCS_NORM_TAGS),-t /$(relative_pname))
+
+# Add -d to each normative rule definition filename
+NORM_RULE_DEF_ARGS := $(foreach relative_pname,$(NORM_RULE_DEF_FILES),-d $(relative_pname))
+
+$(BUILD_DIR)/%.pdf: $(SRC_DIR)/%.adoc $(ALL_SRCS)
+ $(WORKDIR_SETUP)
+ $(DOCKER_CMD) $(DOCKER_QUOTE) $(ASCIIDOCTOR_PDF) $(OPTIONS) $(REQUIRES) $< $(DOCKER_QUOTE)
+ $(WORKDIR_TEARDOWN)
+ @echo -e '\n Built \e]8;;file://$(abspath $@)\e\\$@\e]8;;\e\\\n'
+
+$(BUILD_DIR)/%.html: $(SRC_DIR)/%.adoc $(ALL_SRCS)
+ $(WORKDIR_SETUP)
+ $(DOCKER_CMD) $(DOCKER_QUOTE) $(ASCIIDOCTOR_HTML) $(OPTIONS) $(REQUIRES) $< $(DOCKER_QUOTE)
+ $(WORKDIR_TEARDOWN)
+ @echo -e '\n Built \e]8;;file://$(abspath $@)\e\\$@\e]8;;\e\\\n'
+
+$(BUILD_DIR)/%.epub: $(SRC_DIR)/%.adoc $(ALL_SRCS)
+ $(WORKDIR_SETUP)
+ $(DOCKER_CMD) $(DOCKER_QUOTE) $(ASCIIDOCTOR_EPUB) $(OPTIONS) $(REQUIRES) $< $(DOCKER_QUOTE)
+ $(WORKDIR_TEARDOWN)
+ @echo -e '\n Built \e]8;;file://$(abspath $@)\e\\$@\e]8;;\e\\\n'
+
+$(BUILD_DIR)/%-norm-tags.json: $(SRC_DIR)/%.adoc $(ALL_SRCS) docs-resources/converters/tags.rb
+ $(WORKDIR_SETUP)
+ $(DOCKER_CMD) $(DOCKER_QUOTE) $(ASCIIDOCTOR_TAGS) $(OPTIONS) -a tags-match-prefix='norm:' -a tags-output-suffix='-norm-tags.json' $(REQUIRES) $< $(DOCKER_QUOTE)
+ $(WORKDIR_TEARDOWN)
+
+$(NORM_RULES): $(DOCS_NORM_TAGS) $(NORM_RULE_DEF_FILES)
+ $(WORKDIR_SETUP)
+ cp -f $(DOCS_NORM_TAGS) $@.workdir
+ mkdir -p $@.workdir/build
+ $(DOCKER_CMD) $(DOCKER_QUOTE) $(CREATE_NORM_RULE_TOOL) $(NORM_TAG_FILE_ARGS) $(NORM_RULE_DEF_ARGS) $@ $(DOCKER_QUOTE)
+ $(WORKDIR_TEARDOWN)
+
+# Update docker image to latest
+docker-pull-latest:
+ ${DOCKER_BIN} pull ${DOCKER_IMG}
+
+clean:
+ @echo "Cleaning up generated files..."
+ rm -rf $(BUILD_DIR)
+ @echo "Cleanup completed."
diff --git a/README.md b/README.md
index ad70a00..f94c2e5 100644
--- a/README.md
+++ b/README.md
@@ -1,22 +1,43 @@
-RISC-V Instruction Set Manual [![Build Status](https://travis-ci.org/riscv/riscv-isa-manual.svg?branch=master)](https://travis-ci.org/riscv/riscv-isa-manual)
-=============================
+# RISC-V Instruction Set Manual
-This repository contains the LaTeX source for the draft RISC-V Instruction Set
-Manual. At the time of this writing, none of these specifications have been
-formally adopted by the RISC-V Foundation.
+[![RISC-V ISA Build](https://github.com/riscv/riscv-isa-manual/actions/workflows/isa-build.yml/badge.svg)](https://github.com/riscv/riscv-isa-manual/actions/workflows/isa-build.yml)
-This work is licensed under a Creative Commons Attribution 4.0 International
-License. See the LICENSE file for details.
+This repository contains the source files for the RISC-V Instruction Set Manual, which consists of the Unprivileged and Privileged volumes. The preface of each document indicates the version of each standard that has been formally ratified by RISC-V International.
-The Manual is split up into the following volumes:
-- Volume I: User-Level ISA
+This work is licensed under a [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/). See the [LICENSE](LICENSE) file for details.
+
+The RISC-V Instruction Set Manual is organized into the following volumes:
+
+- Volume I: Unprivileged Architecture
- Volume II: Privileged Architecture
-Official versions of the specifications are available at
-https://riscv.org/specifications/
+## Official and Draft Versions
+
+- **Official versions** of the specifications are available at the [RISC-V International website](https://riscv.org/specifications/).
+- **Compiled versions of the most recent drafts** of the specifications can be found on the [GitHub releases page](https://github.com/riscv/riscv-isa-manual/releases/latest).
+- **HTML snapshots of the latest commit** can be viewed at the following locations:
+ - [Unprivileged spec](https://riscv.github.io/riscv-isa-manual/snapshot/unprivileged/)
+ - [Privileged spec](https://riscv.github.io/riscv-isa-manual/snapshot/privileged/)
+- **Older official versions** of the specifications are archived at the [GitHub releases archive](https://github.com/riscv/riscv-isa-manual/releases/tag/archive).
+
+The canonical list of **open-source RISC-V implementations' marchid CSR values** is available in the [marchid.md file](https://github.com/riscv/riscv-isa-manual/blob/main/marchid.md).
+
+## Contributing
+
+If you would like to contribute to this documentation, please refer to the [Documentation Developer's Guide](https://github.com/riscv/docs-dev-guide).
+
+The recommended method for building the PDF files is to use the Docker Image, as described in the [RISC-V Docs Base Container Image repository](https://github.com/riscv/riscv-docs-base-container-image).
+
+Alternative build methods, such as local builds and GitHub Action builds, are also available and described in the Documentation Developer's Guide.
+
+## Images not rendered for EPUB files
+
+If the eBook reader does not support embedded images, uncomment `:data-uri:` lines in `src/riscv-privileged.adoc` and `src/riscv-unprivileged.adoc`.
+
+### Known devices that cannot handle embedded images
+
+- PocketBook InkPad 3
-Compiled versions of the most recent drafts of the specifications are available at
-https://github.com/riscv/riscv-isa-manual/releases/latest
+## Repo Activity
-The canonical list of open-source RISC-V implementations' marchid CSR values
-is available at https://github.com/riscv/riscv-isa-manual/blob/master/marchid.md
+![Alt](https://repobeats.axiom.co/api/embed/ccec87dc4502f2ed7c216b670b5ed8efc33a1d4c.svg "Repobeats analytics image")
diff --git a/build/.gitignore b/build/.gitignore
deleted file mode 100644
index dba8159..0000000
--- a/build/.gitignore
+++ /dev/null
@@ -1,7 +0,0 @@
-*.aux
-*.bbl
-*.blg
-*.log
-*.out
-*.pdf
-*.toc
diff --git a/build/Makefile b/build/Makefile
deleted file mode 100644
index 8b895f2..0000000
--- a/build/Makefile
+++ /dev/null
@@ -1,68 +0,0 @@
-#=======================================================================
-# Makefile for generating LaTeX documents
-#-----------------------------------------------------------------------
-#
-# This is a simple makefile for generating LaTeX documents. It will
-# run bibtex, generate eps from xfig figures, and make pdfs. The
-# makefile supports builds in non-source directories: just make a
-# build directory, copy the makefile there, and change the srcdir
-# variable accordingly.
-#
-# Note that the makefile assumes that the default dvips/ps2pdfwr
-# commands "do the right thing" for fonts in pdfs. This is true on
-# Athena/Linux and Fedora Core but is not true for older redhat installs ...
-#
-# At a minimum you should just change the main variable to be
-# the basename of your toplevel tex file. If you use a bibliography
-# then you should set the bibfile variable to be the name of your
-# .bib file (assumed to be in the source directory).
-#
-
-srcdir = ../src
-
-docs_with_bib = riscv-spec riscv-privileged
-docs_without_bib =
-
-srcs = $(wildcard $(srcdir)/*.tex)
-figs = $(wildcard $(srcdir)/figs/*)
-bibs = $(srcdir)/riscv-spec.bib
-
-#=======================================================================
-# You shouldn't need to change anything below this
-#=======================================================================
-
-PDFLATEX := TEXINPUTS=$(srcdir): pdflatex -interaction=nonstopmode -halt-on-error
-BIBTEX := BIBINPUTS=$(srcdir): bibtex
-
-default : pdf
-
-#------------------------------------------------------------
-# PDF
-
-pdfs_with_bib = $(addsuffix .pdf, $(docs_with_bib))
-pdfs_without_bib = $(addsuffix .pdf, $(docs_without_bib))
-pdfs = $(pdfs_with_bib) $(pdfs_without_bib)
-
-pdf : $(pdfs)
-.PHONY: pdf open
-
-open: $(pdfs)
- open $(pdfs)
-
-$(pdfs_with_bib): %.pdf: $(srcdir)/%.tex $(srcs) $(figs) $(bibs)
- $(PDFLATEX) $*
- $(BIBTEX) $*
- $(PDFLATEX) $*
- $(PDFLATEX) $*
-
-$(pdfs_without_bib): %.pdf: $(srcdir)/%.tex $(srcs) $(figs)
- $(PDFLATEX) $*
- $(PDFLATEX) $*
-
-junk += $(pdfs) *.aux *.log *.bbl *.blg *.toc *.out
-
-#------------------------------------------------------------
-# Other Targets
-
-clean :
- rm -rf $(junk) *~ \#*
diff --git a/dependencies/Gemfile b/dependencies/Gemfile
new file mode 100644
index 0000000..fb9958a
--- /dev/null
+++ b/dependencies/Gemfile
@@ -0,0 +1,17 @@
+source 'https://rubygems.org'
+gem 'asciidoctor'
+gem 'asciidoctor-bibtex'
+gem 'asciidoctor-diagram'
+gem 'asciidoctor-lists'
+gem 'mathematical'
+gem 'asciidoctor-mathematical'
+gem 'asciidoctor-pdf'
+gem 'asciidoctor-epub3'
+gem 'citeproc-ruby'
+gem 'coderay'
+gem 'csl-styles'
+gem 'json'
+gem 'pygments.rb'
+gem 'rghost'
+gem 'rouge'
+gem 'ruby_dev'
diff --git a/dependencies/README.md b/dependencies/README.md
new file mode 100644
index 0000000..f64a366
--- /dev/null
+++ b/dependencies/README.md
@@ -0,0 +1,2 @@
+Dependencies for the build environment for various package managers. Used in
+`.github/workflows/`.
diff --git a/dependencies/apt_packages.txt b/dependencies/apt_packages.txt
new file mode 100644
index 0000000..9ec7080
--- /dev/null
+++ b/dependencies/apt_packages.txt
@@ -0,0 +1,22 @@
+bison
+build-essential
+cmake
+curl
+flex
+fonts-lyx
+git
+graphviz
+# For wavedrom
+default-jre
+libcairo2-dev
+libffi-dev
+libgdk-pixbuf2.0-dev
+libglib2.0-dev
+libpango1.0-dev
+libxml2-dev
+make
+pkg-config
+ruby
+ruby-dev
+libwebp-dev
+libzstd-dev
diff --git a/dependencies/package.json b/dependencies/package.json
new file mode 100644
index 0000000..6291f07
--- /dev/null
+++ b/dependencies/package.json
@@ -0,0 +1,8 @@
+{
+ "name": "local",
+ "version": "0.0.1",
+ "dependencies": {
+ "wavedrom-cli": "^2.6.8",
+ "bytefield-svg": "^1.8.0"
+ }
+}
diff --git a/docs-resources b/docs-resources
new file mode 160000
+Subproject 1fb9a748079d93a8aa7d0e9e2f4fdbb1c0e3807
diff --git a/marchid.md b/marchid.md
index 23bb457..ec31440 100644
--- a/marchid.md
+++ b/marchid.md
@@ -16,14 +16,53 @@ requests against this repository to request the allocation of an architecture
ID.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-Project Name | Maintainers | Point of Contact | Architecture ID | Project URL
-------------- | ------------------------------- | ----------------------------------------------------------- | ----------------- | ---------------------------------------------------
-Rocket | SiFive, UC Berkeley | [Andrew Waterman](mailto:andrew@sifive.com), SiFive | 1 | https://github.com/freechipsproject/rocket-chip
-BOOM | UC Berkeley | [Christopher Celio](mailto:celio@berkeley.edu) | 2 | https://github.com/ucb-bar/riscv-boom
-Ariane | PULP Platform | [Florian Zaruba](mailto:zarubaf@iis.ee.ethz.ch), ETH Zurich | 3 | https://github.com/pulp-platform/ariane
-RI5CY | PULP Platform | [Frank K. Gürkaynak](mailto:kgf@iis.ee.ethz.ch), ETH Zurich | 4 | https://github.com/pulp-platform/riscv
-Spike | SiFive, UC Berkeley | [Andrew Waterman](mailto:andrew@sifive.com), SiFive | 5 | https://github.com/riscv/riscv-isa-sim
+Project Name | Maintainers | Point of Contact | Architecture ID | Project URL
+------------- | ------------------------------- | ----------------------------------------------------------- | ----------------- | ---------------------------------------------------
+Rocket | SiFive, UC Berkeley | [Andrew Waterman](mailto:andrew@sifive.com), SiFive | 1 | https://github.com/chipsalliance/rocket-chip
+BOOM | UC Berkeley | [Christopher Celio](mailto:celio@berkeley.edu) | 2 | https://github.com/riscv-boom/riscv-boom
+CVA6 | OpenHW Group | [Florian Zaruba](mailto:florian@openhwgroup.org), OpenHW Group | 3 | https://github.com/openhwgroup/cva6
+CV32E40P | OpenHW Group | [Davide Schiavone](mailto:davide@openhwgroup.org), OpenHW Group | 4 | https://github.com/openhwgroup/cv32e40p
+Spike | SiFive, UC Berkeley | [Andrew Waterman](mailto:andrew@sifive.com), SiFive | 5 | https://github.com/riscv/riscv-isa-sim
E-Class | IIT Madras | [Neel Gala](mailto:neelgala@gmail.com) | 6 | https://gitlab.com/shaktiproject/cores/e-class
ORCA | VectorBlox | [Joel Vandergriendt](mailto:joel@vectorblox.com) | 7 | https://github.com/vectorblox/orca
SCR1 | Syntacore | [Dmitri Pavlov](mailto:dmitri.pavlov@syntacore.com), Syntacore| 8 | https://github.com/syntacore/scr1
-YARVI | Tommy Thorn's Priceless Services| [Tommy Thorn](mailto:tommy-github2@thorn.ws) | 9 | https://github.com/tommythorn/yarvi \ No newline at end of file
+YARVI | Tommy Thorn's Priceless Services| [Tommy Thorn](mailto:tommy-github2@thorn.ws) | 9 | https://github.com/tommythorn/yarvi
+RVBS | Alexandre Joannou, University of Cambridge| [Alexandre Joannou](mailto:aj443@cl.cam.ac.uk) | 10 | https://github.com/CTSRD-CHERI/RVBS
+SweRV EH1 | Western Digital Corporation | [Thomas Wicki](mailto:Thomas.Wicki@wdc.com) | 11 | https://github.com/chipsalliance/Cores-SweRV
+MSCC | Rongcui Dong | [Rongcui Dong](mailto:rongcuid@outlook.com) | 12 | https://github.com/rongcuid/MSCC
+BlackParrot | The World | [Michael B. Taylor](mailto:prof.taylor@gmail.com), U. Washington | 13 | https://github.com/black-parrot
+BaseJump Manycore | U. Washington | [Michael B. Taylor](mailto:prof.taylor@gmail.com), U. Washington | 14 | https://github.com/bespoke-silicon-group/bsg_manycore
+C-Class | IIT Madras | [Neel Gala](mailto:neelgala@gmail.com) | 15 | https://gitlab.com/shaktiproject/cores/c-class
+SweRV EL2 | Western Digital Corporation | [Thomas Wicki](mailto:Thomas.Wicki@wdc.com) | 16 | https://github.com/chipsalliance/Cores-SweRV-EL2
+SweRV EH2 | Western Digital Corporation | [Thomas Wicki](mailto:Thomas.Wicki@wdc.com) | 17 | https://github.com/chipsalliance/Cores-SweRV-EH2
+SERV | Olof Kindgren Enterprises | [Olof Kindgren](mailto:olof.kindgren@gmail.com) | 18 | https://github.com/olofk/serv
+NEORV32 | Stephan Nolting | [Stephan Nolting](mailto:stnolting@gmail.com) | 19 | https://github.com/stnolting/neorv32
+CV32E40X | OpenHW Group | [Arjan Bink](mailto:arjan.bink@silabs.com), Silicon Laboratories | 20 | https://github.com/openhwgroup/cv32e40x
+CV32E40S | OpenHW Group | [Arjan Bink](mailto:arjan.bink@silabs.com), Silicon Laboratories | 21 | https://github.com/openhwgroup/cv32e40s
+Ibex | lowRISC | [lowRISC Hardware Team](mailto:hardware@lowrisc.org) | 22 | https://github.com/lowRISC/ibex
+RudolV | Jörg Mische | [Jörg Mische](mailto:bobbl@gmx.de) | 23 | https://github.com/bobbl/rudolv
+Steel Core | Rafael Calcada | [Rafael Calcada](mailto:rafaelcalcada@gmail.com) | 24 | https://github.com/rafaelcalcada/steel-core
+XiangShan | ICT, CAS | [XiangShan Team](mailto:xiangshan-all@ict.ac.cn) | 25 | https://github.com/OpenXiangShan/XiangShan
+Hummingbirdv2 E203 | Nuclei System Technology | [Can Hu](mailto:canhu@nucleisys.com), Nuclei System Technology | 26 | https://github.com/riscv-mcu/e203_hbirdv2
+Hazard3 | Luke Wren | [Luke Wren](mailto:wren6991@gmail.com) | 27 | https://github.com/wren6991/hazard3
+CV32E41P | OpenHW Group | [Mark Hill](mailto:mark.hill@huawei.com), OpenHW Group | 28 | https://github.com/openhwgroup/cv32e41p
+Rift | Jianhu Lab, WUT | [Ruige Lee](mailto:295054118@whut.edu.cn) | 29 | [RiftCore](https://github.com/whutddk/RiftCore), [Rift2Core](https://github.com/whutddk/Rift2Core)
+RISu064 | Wenting Zhang | [Wenting Zhang](mailto:zephray@outlook.com) | 30 | https://github.com/zephray/RISu064
+AIRISC | Fraunhofer IMS | [AIRISC Support](mailto:airisc@ims.fraunhofer.de) | 31 | https://github.com/Fraunhofer-IMS/airisc_core_complex
+Proteus | imec-DistriNet, KU Leuven | [Marton Bognar](mailto:marton.bognar@kuleuven.be) | 32 | https://github.com/proteus-core/proteus
+VexRiscv | SpinalHDL | [Charles Papon](mailto:charles.papon.90@gmail.com) | 33 | https://github.com/SpinalHDL/VexRiscv
+Shuttle | UC Berkeley | [Jerry Zhao](mailto:jerryz123@berkeley.edu) | 34 | https://github.com/ucb-bar/shuttle
+CV32E2 | OpenHW Group | [Davide Schiavone](mailto:davide@openhwgroup.org), OpenHW Group | 35 | https://github.com/openhwgroup/cve2
+Wally | OpenHW Group | [James Stine](mailto:james.stine@okstate.edu), OpenHW Group | 36 | https://github.com/openhwgroup/cvw
+Boa32 | Julian Scheffers | [Julian Scheffers](mailto:julian@scheffers.net) | 37 | https://github.com/robotman2412/boa-risc-v
+WIV64 | Jesús Sanz del Rey | [Jesús Sanz del Rey](mailto:jesussanz2003@gmail.com) | 38 | https://github.com/StartForKiller/WivCPU
+RV6 | Nikola Lukić | [Nikola Lukić](mailto:lukicn@protonmail.com) | 39 | https://github.com/kiclu/rv6
+ApogeoRV | Gabriele Tripi | [Gabriele Tripi](mailto:tripi.gabriele2002@gmail.com) | 40 | https://github.com/GabbedT/ApogeoRV
+MicroRV32 | AGRA, Group of Computer Architecture, University of Bremen | [RISC-V @ AGRA](mailto:riscv@informatik.uni-bremen.de) | 41 | https://github.com/agra-uni-bremen/microrv32
+QEMU | qemu.org | [QEMU Mailing List](mailto:qemu-riscv@nongnu.org) | 42 | https://qemu.org
+KianV | Hirosh Dabui | [Hirosh Dabui](mailto:hirosh@dabui.de) | 43 | https://github.com/splinedrive/kianRiscV
+Coreblocks | Kuźnia Rdzeni, University of Wrocław | [Coreblocks Team](mailto:coreblocks@cs.uni.wroc.pl) | 44 | https://github.com/kuznia-rdzeni/coreblocks
+rrv32 | Solra Bizna | [Solra Bizna](mailto:solra@bizna.name) | 45 | https://github.com/SolraBizna/rrv32
+VexiiRiscv | SpinalHDL | [Charles Papon](mailto:charles.papon.90@gmail.com) | 46 | https://github.com/SpinalHDL/VexiiRiscv
+Wildcat | Technical University of Denmark | [Martin Schoeberl](mailto:masca@dtu.dk) | 47 | https://github.com/schoeberl/wildcat
+CVA5 | OpenHW Group | [Lesley Shannon](mailto:lesley_shannon@sfu.ca) | 48 | https://github.com/openhwgroup/cva5
diff --git a/normative_rule_defs/README.md b/normative_rule_defs/README.md
new file mode 100644
index 0000000..318ae52
--- /dev/null
+++ b/normative_rule_defs/README.md
@@ -0,0 +1,22 @@
+# Normative Rule Definition Files
+
+This directory contains one normative rule definition file per adoc chapter file.
+Each definition file has the same name as its corresponding adoc file with the extension changed from .adoc to .yaml.
+See rv32.yaml for a good example of a definition file that includes additional informative comments.
+
+Each definition file provides the information required to create the normative rules for
+its corresponding adoc file. The adoc file contains tags (AKA AsciiDoc anchors with names with a "norm:" prefix) of text associated with normative rules.
+
+In many cases there is a 1:1 mapping between normative rules and tags but not always (1:many, many:1, and many:many also exist). The definition files provide the mapping information to create normative rules from the tags.
+The definition files also contain additional meta-data added to the normative rule definitions.
+
+The Ruby script in docs-resources/tools/create_normative_rules.rb consumes these definition files along with
+the extracted normative tags from the ISA manual chapters to create a file containing all normative rules
+for all ISA manuals (priv & unpriv).
+
+See the schemas in docs-resources/schemas for a machine-readable definition of the input and output file formats:
+* File defs-schema.json is the format of the definition input file format (YAML).
+* File norm-rules-schema.json is the format of the normative rule output file format (JSON).
+
+Using Visual Studio Code to edit the definition YAML files is encouraged since it provides
+live schema feedback.
diff --git a/normative_rule_defs/m-st-ext.yaml b/normative_rule_defs/m-st-ext.yaml
new file mode 100644
index 0000000..0c71b72
--- /dev/null
+++ b/normative_rule_defs/m-st-ext.yaml
@@ -0,0 +1,38 @@
+---
+# yaml-language-server: $schema=../docs-resources/schemas/defs-schema.json
+
+$schema: "../docs-resources/schemas/defs-schema.json#"
+
+# Used to create normative rules for m-st-ext.adoc file.
+# Tags refer to anchors in any adoc file for any ISA manual.
+
+normative_rule_definitions:
+ - name: mul_op
+ tags: ["norm:mul_op"]
+ - names: [mulh_op, mulhu_op, mulhsu_op]
+ tags: ["norm:mulh_mulhu_mulhsu_op"]
+ - names: [div_op, divu_op]
+ tags: ["norm:div_divu_op"]
+ - names: [divw_op, divuw_op]
+ tags: ["norm:divw_divuw_op"]
+ - names: [rem_op, remu_op]
+ tags: ["norm:rem_remu_op"]
+ - names: [remw_op, remuw_op]
+ tags: ["norm:remw_remuw_op"]
+ - name: div_by_zero
+ tags: ["norm:div_by_zero"]
+ - name: rem_by_zero
+ tags: ["norm:rem_by_zero"]
+ - name: signed_div_overflow
+ tags: ["norm:signed_div_overflow"]
+ - name: rem_result_sign
+ tags: ["norm:rem_result_sign"]
+ - names: [remw_result_sign, remuw_result_sign]
+ tags: ["norm:remw_remuw_result_sign"]
+ - name: mulw_op
+ tags: ["norm:mulw_op"]
+ - name: mul_misa_M_dis
+ description: |
+ An illegal instruction exception is raised when the instruction is executed
+ and `misa.M` is 0.
+ tags: ["norm:misa_extensions_disabling"]
diff --git a/normative_rule_defs/machine.yaml b/normative_rule_defs/machine.yaml
new file mode 100644
index 0000000..b293446
--- /dev/null
+++ b/normative_rule_defs/machine.yaml
@@ -0,0 +1,94 @@
+---
+# yaml-language-server: $schema=../docs-resources/schemas/defs-schema.json
+
+$schema: "../docs-resources/schemas/defs-schema.json#"
+
+# Used to create normative rules for rv32.adoc file.
+# Tags refer to anchors in any adoc file for any ISA manual.
+
+normative_rule_definitions:
+ - name: M_highest_priv_mode
+ tags: ["norm:M_highest_priv_mode"]
+ - name: M_mode_at_reset
+ tags: ["norm:M_mode_at_reset"]
+ - name: M_access_all_lower_priv_CSRs
+ tags: ["norm:M_access_all_lower_priv_CSRs"]
+ - name: misa_acc
+ tags: ["norm:misa_acc"]
+ - name: misa_always_rd
+ tags: ["norm:misa_always_rd"]
+ - name: MISA_CSR_IMPLEMENTED
+ tags: ["norm:MISA_CSR_IMPLEMENTED"]
+ - name: misa_mxl_op
+ tags:
+ - "norm:misa_mxl_op_isa"
+ - "norm:misa_mxl_op_nz"
+ - name: misa_mxl_acc
+ tags: ["norm:misa_mxl_acc"]
+ - name: misa_sz
+ tags: ["norm:misa_sz"]
+ - name: misa_extensions_enc
+ tags: ["norm:misa_extensions_enc"]
+ - name: misa_extensions_op
+ tags: ["norm:misa_extensions_op"]
+ - name: misa_extensions_rst
+ tags: ["norm:misa_extensions_rst"]
+ - name: misa_extensions_disabling
+ description: what happens when you turn off bits
+ tags: ["norm:misa_extensions_disabling"]
+ - name: misa_extensions_impl_def
+ tags: ["norm:misa_extensions_impl_def"]
+ - name: misa_extensions_disabling_def
+ tags: ["norm:misa_extensions_disabling_def"]
+ - name: misa_extensions_rsv_ret_0
+ tags: ["norm:misa_extensions_rsv_ret_0"]
+ - name: misa_i_op
+ tags: ["norm:misa_i_op"]
+ - name: misa_e_op
+ tags: ["norm:misa_e_op"]
+ - name: misa_x_op
+ tags: ["norm:misa_x_op"]
+ - name: misa_b_op
+ tags: ["norm:misa_b_op"]
+ - name: misa_m_op
+ tags: ["norm:misa_m_op"]
+ - name: misa_s_op
+ tags: ["norm:misa_s_op"]
+ - name: misa_u_op
+ tags: ["norm:misa_u_op"]
+ - name: misa_e_not_i
+ tags: ["norm:misa_e_not_i"]
+ - name: Zmmul_misa_m
+ tags: ["norm:Zmmul_misa_m"]
+ - name: misa_e_acc
+ tags: ["norm:misa_e_acc"]
+ - name: misa_extensions_dependencies
+ tags: ["norm:misa_extensions_dependencies"]
+ - name: misa_inc_ialign
+ tags: ["norm:misa_inc_ialign"]
+ - names: [mvendorid_sz, mvendorid_acc, mvendorid_op]
+ tags: ["norm:mvendorid_sz_acc_op"]
+ - name: mvendorid_always_rd
+ tags: ["norm:mvendorid_always_rd"]
+ - name: mvendorid_enc
+ tags: ["norm:mvendorid_enc"]
+ - name: mvendorid_bank_1_less_than_JEDEC
+ tags: ["norm:mvendorid_bank_1_less_than_JEDEC"]
+ - names: [marchid_sz, marchid_acc, marchid_op]
+ tags: ["norm:marchid_sz_acc_op"]
+ - name: marchid_always_rd
+ tags: ["norm:marchid_always_rd"]
+ - name: mimpid_op
+ tags: ["norm:mimpid_op"]
+ - name: mimpid_always_rd
+ tags: ["norm:mimpid_always_rd"]
+ - names: [mhartid_sz, mhartid_acc, mhartid_op]
+ tags: ["norm:mhartid_sz_acc_op"]
+ - name: mhartid_always_rd
+ tags: ["norm:mhartid_always_rd"]
+ - names: [mstatus_sz, mstatus_acc]
+ tags: ["norm:mstatus_sz_acc"]
+ - names: [mstatush_sz, mstatush_acc]
+ tags: ["norm:mstatush_sz_acc"]
+ - name: mstatush_enc
+ tags: ["norm:mstatush_enc"]
diff --git a/normative_rule_defs/rv-32-64g.yaml b/normative_rule_defs/rv-32-64g.yaml
new file mode 100644
index 0000000..5de9c67
--- /dev/null
+++ b/normative_rule_defs/rv-32-64g.yaml
@@ -0,0 +1,346 @@
+---
+# yaml-language-server: $schema=../docs-resources/schemas/defs-schema.json
+
+$schema: "../docs-resources/schemas/defs-schema.json#"
+
+# All of these normative rule definitions are to table cells in the ISA manual instruction
+# encoding tables and so there isn't any associated text with the normative rule.
+# These definitions are still useful since there is still an AsciiDoc anchor in the table cell
+# and so it can be used as a hyperlink target in PDF/HTML files.
+
+normative_rule_definitions:
+ - name: lui_enc
+ tags_without_text:
+ - name: "norm:lui_enc"
+ kind: instruction
+ instances: [lui]
+ - name: auipc_enc
+ tags_without_text:
+ - name: "norm:auipc_enc"
+ kind: instruction
+ instances: [auipc]
+ - name: jal_enc
+ tags_without_text:
+ - name: "norm:jal_enc"
+ kind: instruction
+ instances: [jal]
+ - name: jalr_enc
+ tags_without_text:
+ - name: "norm:jalr_enc"
+ kind: instruction
+ instances: [jalr]
+ - name: beq_enc
+ tags_without_text:
+ - name: "norm:beq_enc"
+ kind: instruction
+ instances: [beq]
+ - name: bne_enc
+ tags_without_text:
+ - name: "norm:bne_enc"
+ kind: instruction
+ instances: [bne]
+ - name: blt_enc
+ tags_without_text:
+ - name: "norm:blt_enc"
+ kind: instruction
+ instances: [blt]
+ - name: bge_enc
+ tags_without_text:
+ - name: "norm:bge_enc"
+ kind: instruction
+ instances: [bge]
+ - name: bltu_enc
+ tags_without_text:
+ - name: "norm:bltu_enc"
+ kind: instruction
+ instances: [bltu]
+ - name: bgeu_enc
+ tags_without_text:
+ - name: "norm:bgeu_enc"
+ kind: instruction
+ instances: [bgeu]
+ - name: lb_enc
+ tags_without_text:
+ - name: "norm:lb_enc"
+ kind: instruction
+ instances: [lb]
+ - name: lh_enc
+ tags_without_text:
+ - name: "norm:lh_enc"
+ kind: instruction
+ instances: [lh]
+ - name: lw_enc
+ tags_without_text:
+ - name: "norm:lw_enc"
+ kind: instruction
+ instances: [lw]
+ - name: lbu_enc
+ tags_without_text:
+ - name: "norm:lbu_enc"
+ kind: instruction
+ instances: [lbu]
+ - name: lhu_enc
+ tags_without_text:
+ - name: "norm:lhu_enc"
+ kind: instruction
+ instances: [lhu]
+ - name: sb_enc
+ tags_without_text:
+ - name: "norm:sb_enc"
+ kind: instruction
+ instances: [sb]
+ - name: sh_enc
+ tags_without_text:
+ - name: "norm:sh_enc"
+ kind: instruction
+ instances: [sh]
+ - name: sw_enc
+ tags_without_text:
+ - name: "norm:sw_enc"
+ kind: instruction
+ instances: [sw]
+ - name: addi_enc
+ tags_without_text:
+ - name: "norm:addi_enc"
+ kind: instruction
+ instances: [addi]
+ - name: slti_enc
+ tags_without_text:
+ - name: "norm:slti_enc"
+ kind: instruction
+ instances: [slti]
+ - name: sltiu_enc
+ tags_without_text:
+ - name: "norm:sltiu_enc"
+ kind: instruction
+ instances: [sltiu]
+ - name: xori_enc
+ tags_without_text:
+ - name: "norm:xori_enc"
+ kind: instruction
+ instances: [xori]
+ - name: ori_enc
+ tags_without_text:
+ - name: "norm:ori_enc"
+ kind: instruction
+ instances: [ori]
+ - name: andi_enc
+ tags_without_text:
+ - name: "norm:andi_enc"
+ kind: instruction
+ instances: [auipc]
+ - name: slli_enc
+ tags_without_text:
+ - name: "norm:slli_enc"
+ kind: instruction
+ instances: [slli]
+ - name: srli_enc
+ tags_without_text:
+ - name: "norm:srli_enc"
+ kind: instruction
+ instances: [srli]
+ - name: srai_enc
+ tags_without_text:
+ - name: "norm:srai_enc"
+ kind: instruction
+ instances: [srai]
+ - name: add_enc
+ tags_without_text:
+ - name: "norm:add_enc"
+ kind: instruction
+ instances: [add]
+ - name: sub_enc
+ tags_without_text:
+ - name: "norm:sub_enc"
+ kind: instruction
+ instances: [sub]
+ - name: sll_enc
+ tags_without_text:
+ - name: "norm:sll_enc"
+ kind: instruction
+ instances: [sll]
+ - name: slt_enc
+ tags_without_text:
+ - name: "norm:slt_enc"
+ kind: instruction
+ instances: [slt]
+ - name: sltu_enc
+ tags_without_text:
+ - name: "norm:sltu_enc"
+ kind: instruction
+ instances: [sltu]
+ - name: xor_enc
+ tags_without_text:
+ - name: "norm:xor_enc"
+ kind: instruction
+ instances: [xor]
+ - name: srl_enc
+ tags_without_text:
+ - name: "norm:srl_enc"
+ kind: instruction
+ instances: [srl]
+ - name: sra_enc
+ tags_without_text:
+ - name: "norm:sra_enc"
+ kind: instruction
+ instances: [sra]
+ - name: or_enc
+ tags_without_text:
+ - name: "norm:or_enc"
+ kind: instruction
+ instances: [or]
+ - name: and_enc
+ tags_without_text:
+ - name: "norm:and_enc"
+ kind: instruction
+ instances: [and]
+ - name: fence_enc
+ tags_without_text:
+ - name: "norm:fence_enc"
+ kind: instruction
+ instances: [fence]
+ - name: fence-tso_enc
+ tags_without_text:
+ - name: "norm:fence-tso_enc"
+ kind: instruction
+ instances: [fence-tso]
+ - name: pause_enc
+ tags_without_text:
+ - name: "norm:pause_enc"
+ kind: instruction
+ instances: [pause]
+ - name: ecall_enc
+ tags_without_text:
+ - name: "norm:ecall_enc"
+ kind: instruction
+ instances: [ecall]
+ - name: ebreak_enc
+ tags_without_text:
+ - name: "norm:ebreak_enc"
+ kind: instruction
+ instances: [ebreak]
+ - name: lwu_enc
+ tags_without_text:
+ - name: "norm:lwu_enc"
+ kind: instruction
+ instances: [lwu]
+ - name: ld_enc
+ tags_without_text:
+ - name: "norm:ld_enc"
+ kind: instruction
+ instances: [ld]
+ - name: sd_enc
+ tags_without_text:
+ - name: "norm:sd_enc"
+ kind: instruction
+ instances: [sd]
+ - name: addiw_enc
+ tags_without_text:
+ - name: "norm:addiw_enc"
+ kind: instruction
+ instances: [addiw]
+ - name: slliw_enc
+ tags_without_text:
+ - name: "norm:slliw_enc"
+ kind: instruction
+ instances: [slliw]
+ - name: srliw_enc
+ tags_without_text:
+ - name: "norm:srliw_enc"
+ kind: instruction
+ instances: [srliw]
+ - name: sraiw_enc
+ tags_without_text:
+ - name: "norm:sraiw_enc"
+ kind: instruction
+ instances: [sraiw]
+ - name: addw_enc
+ tags_without_text:
+ - name: "norm:addw_enc"
+ kind: instruction
+ instances: [addw]
+ - name: subw_enc
+ tags_without_text:
+ - name: "norm:subw_enc"
+ kind: instruction
+ instances: [subw]
+ - name: sllw_enc
+ tags_without_text:
+ - name: "norm:sllw_enc"
+ kind: instruction
+ instances: [sllw]
+ - name: srlw_enc
+ tags_without_text:
+ - name: "norm:srlw_enc"
+ kind: instruction
+ instances: [srlw]
+ - name: sraw_enc
+ tags_without_text:
+ - name: "norm:sraw_enc"
+ kind: instruction
+ instances: [sraw]
+ - name: mul_enc
+ tags_without_text:
+ - name: "norm:mul_enc"
+ kind: instruction
+ instances: [mul]
+ - name: mulh_enc
+ tags_without_text:
+ - name: "norm:mulh_enc"
+ kind: instruction
+ instances: [mulh]
+ - name: mulhsu_enc
+ tags_without_text:
+ - name: "norm:mulhsu_enc"
+ kind: instruction
+ instances: [mulhsu]
+ - name: mulhu_enc
+ tags_without_text:
+ - name: "norm:mulhu_enc"
+ kind: instruction
+ instances: [mulhu]
+ - name: div_enc
+ tags_without_text:
+ - name: "norm:div_enc"
+ kind: instruction
+ instances: [div]
+ - name: divu_enc
+ tags_without_text:
+ - name: "norm:divu_enc"
+ kind: instruction
+ instances: [divu]
+ - name: rem_enc
+ tags_without_text:
+ - name: "norm:rem_enc"
+ kind: instruction
+ instances: [rem]
+ - name: remu_enc
+ tags_without_text:
+ - name: "norm:remu_enc"
+ kind: instruction
+ instances: [remu]
+ - name: mulw_enc
+ tags_without_text:
+ - name: "norm:mulw_enc"
+ kind: instruction
+ instances: [mulw]
+ - name: divw_enc
+ tags_without_text:
+ - name: "norm:divw_enc"
+ kind: instruction
+ instances: [divw]
+ - name: divuw_enc
+ tags_without_text:
+ - name: "norm:divuw_enc"
+ kind: instruction
+ instances: [divuw]
+ - name: remw_enc
+ tags_without_text:
+ - name: "norm:remw_enc"
+ kind: instruction
+ instances: [remw]
+ - name: remuw_enc
+ tags_without_text:
+ - name: "norm:remuw_enc"
+ kind: instruction
+ instances: [remuw]
diff --git a/normative_rule_defs/rv32.yaml b/normative_rule_defs/rv32.yaml
new file mode 100644
index 0000000..58ed236
--- /dev/null
+++ b/normative_rule_defs/rv32.yaml
@@ -0,0 +1,153 @@
+---
+# yaml-language-server: $schema=../docs-resources/schemas/defs-schema.json
+
+$schema: "../docs-resources/schemas/defs-schema.json#"
+
+# Used to create normative rules for rv32.adoc file.
+# Tags refer to anchors in any adoc file for any ISA manual.
+
+normative_rule_definitions:
+ - name: rv32i_xreg_sz # Normative rule names are typically more compact than tag names since they appear in table cells
+ summary: RV32I XLEN # Few word summary of normative rule.
+ tags: ["norm:rv32i_xreg_sz"]
+ - name: rv32i_other_xregs
+ summary: Registers x1 to x31
+ tags: ["norm:rv32i_rv64i_other_xregs"] # Same tag used in rv64.yaml (that chapter is written as deltas from this chapter)
+ - name: pcreg_op
+ description: | # Example where augmenting information in tags helps better define a normative rule
+ The `pc` contains a byte address so is incremented by 4 for 32-bit instructions and
+ 2 for 16-bit instructions.
+ tags: ["norm:pcreg_op"]
+ - names: [slti_op, sltiu_op] # Example of multiple normative rules using the same tag
+ tags: ["norm:slti_sltiu_op"]
+ - name: x0eq0
+ summary: Register x0 always zero
+ tags: ["norm:x0eq0"]
+ - name: taken_cti_misaligned_exc
+ summary: CTI misaligned execution
+ tags: ["norm:taken_cti_misaligned_exc"]
+ - name: cond_br_no_ia_misaligned_exc_not_taken
+ summary: No IA misaligned exc on not taken
+ tags: ["norm:cond_br_no_ia_misaligned_exc_not_taken"]
+ - name: imm_always_sex
+ summary: Immediates always sign-extended
+ tags: ["norm:imm_always_sex"]
+ - name: addi_op
+ tags: ["norm:addi_op"]
+ - name: addi_overflow
+ summary: Treatment of overflow
+ tags: ["norm:addi_overflow"]
+ - names: [andi_op, ori_op, xori_op]
+ tags: ["norm:andi_ori_xori_op"]
+ - name: slli_op
+ tags: ["norm:slli_op"]
+ - name: srli_op
+ tags: ["norm:srli_op"]
+ - name: srai_op
+ tags: ["norm:srai_op"]
+ - name: lui_op
+ tags: ["norm:lui_op"]
+ - name: auipc_op
+ tags: ["norm:auipc_op"]
+ - name: R-type_operands
+ tags: ["norm:R-type_operands"]
+ - name: add_op
+ tags: ["norm:add_op"]
+ - name: sub_op
+ tags: ["norm:sub_op"]
+ - names: [add_overflow, sub_overflow]
+ tags: ["norm:add_sub_overflow"]
+ - names: [slt_op, sltu_op]
+ tags: ["norm:slt_sltu_op"]
+ - names: [and_op, or_op, xor_op]
+ tags: ["norm:and_or_xor_op"]
+ - names: [sll_op, srl_op, sra_op]
+ tags: ["norm:sll_srl_sra_op"]
+ - name: no_cti_delay_slots
+ tags: ["norm:no_cti_delay_slots"]
+ - name: ia_fault_exc_on_target
+ tags: ["norm:ia_fault_exc_on_target"]
+ - name: jal_target
+ tags: ["norm:jal_target"]
+ - name: jal_op
+ tags: ["norm:jal_op"]
+ - name: jalr_target
+ tags: ["norm:jalr_target"]
+ - name: jalr_op
+ tags: ["norm:jalr_op"]
+ - name: br_target
+ tags: ["norm:br_target"]
+ - names: [beq_op, bne_op]
+ tags: ["norm:beq_bne_op"]
+ - names: [blt_op, bltu_op]
+ tags: ["norm:blt_bltu_op"]
+ - names: [bge_op, bgeu_op]
+ tags: ["norm:bge_bgeu_op"]
+ - name: load_exc_x0
+ tags: ["norm:load_exc_x0"]
+ - name: ENDIANNESS_LITTLE_OR_BIG
+ tags: ["norm:ENDIANNESS_LITTLE_OR_BIG"]
+ - name: ldst_endian_byte_invariant
+ tags: ["norm:ldst_endian_byte_invariant"]
+ - name: ldst_endian_byte_op
+ tags: ["norm:ldst_endian_byte_op"]
+ - name: ldst_little_endian_op
+ tags: ["norm:ldst_little_endian_op"]
+ - name: ldst_big_endian_op
+ tags: ["norm:ldst_big_endian_op"]
+ - name: ldst_ea
+ tags: ["norm:ldst_ea"]
+ - name: ldst_no_exc_aligned
+ tags: ["norm:ldst_no_exc_aligned"]
+ - name: load_op
+ tags: ["norm:load_op"]
+ - name: store_op
+ tags: ["norm:store_op"]
+ - name: lw_op
+ tags: ["norm:lw_op"]
+ - name: lh_op
+ tags: ["norm:lh_op"]
+ - name: lhu_op
+ tags: ["norm:lhu_op"]
+ - names: [lb_op]
+ tags:
+ - "norm:lb_lbu_op"
+ - "norm:lh_op"
+ - names: [lbu_op]
+ tags:
+ - "norm:lb_lbu_op"
+ - "norm:lhu_op"
+ - names: [sw_op, sh_op, sb_op]
+ tags: ["norm:sw_sh_sb_op"]
+ - name: MISALIGNED_LDST_EEI_DEPENDENT_BEHAVIOR
+ tags: ["norm:MISALIGNED_LDST_EEI_DEPENDENT_BEHAVIOR"]
+ - name: MISALIGNED_LDST_FULLY_HW_SUPPORTED
+ tags: ["norm:MISALIGNED_LDST_FULLY_HW_SUPPORTED"]
+ - name: MISALIGNED_LDST_INVISIBLE_TRAP
+ tags: ["norm:MISALIGNED_LDST_INVISIBLE_TRAP"]
+ - name: MISALIGNED_LDST_HW_OR_INVISIBLE_TRAP_FUNC_OF_ADDR
+ tags: ["norm:MISALIGNED_LDST_HW_OR_INVISIBLE_TRAP_FUNC_OF_ADDR"]
+ - name: MISALIGNED_LDST_FULLY_HW_SUPPORTED_OR_VISIBLE_TRAP
+ tags: ["norm:MISALIGNED_LDST_FULLY_HW_SUPPORTED_OR_VISIBLE_TRAP"]
+ - name: MISALIGNED_LDST_CONTAINED_OR_FATAL_TRAP
+ tags: ["norm:MISALIGNED_LDST_CONTAINED_OR_FATAL_TRAP"]
+ - name: ldst_addr_misaligned_or_access_fault_exc
+ tags: ["norm:ldst_addr_misaligned_or_access_fault_exc"]
+ - name: ldst_atomicity_for_aligned
+ tags: ["norm:ldst_atomicity_for_aligned"]
+ - name: fence_op
+ tags: ["norm:fence_op"]
+ - name: fence-tso_op
+ tags: ["norm:fence-tso_op"]
+ - name: fence-tso_ordering_rw_rw_ok
+ tags: ["norm:fence-tso_ordering_rw_rw_ok"]
+ - name: fence_unused_flds_rsv
+ tags: ["norm:fence_unused_flds_rsv"]
+ - name: fence_cons_ok
+ tags: ["norm:fence_cons_ok"]
+ - name: ecall_op
+ tags: ["norm:ecall_op"]
+ - name: ebreak_op
+ tags: ["norm:ebreak_op"]
+ - name: fence_null_pred_succ_inter
+ tags: ["norm:fence_null_pred_succ_inter"]
diff --git a/normative_rule_defs/rv64.yaml b/normative_rule_defs/rv64.yaml
new file mode 100644
index 0000000..0b1fd02
--- /dev/null
+++ b/normative_rule_defs/rv64.yaml
@@ -0,0 +1,70 @@
+---
+# yaml-language-server: $schema=../docs-resources/schemas/defs-schema.json
+
+$schema: "../docs-resources/schemas/defs-schema.json#"
+
+# Used to create normative rules for rv64.adoc file.
+# Tags refer to anchors in any adoc file for any ISA manual.
+
+normative_rule_definitions:
+ - name: rv64i_xreg_sz
+ summary: RV64I XLEN
+ tags: ["norm:rv64i_xreg_sz"]
+ - name: rv64_w_sex
+ tags: ["norm:rv64_w_sex"]
+ - name: rv64i_other_xregs
+ summary: Registers x1 to x31
+ tags: ["norm:rv32i_rv64i_other_xregs"]
+ - name: addiw_op
+ tags: ["norm:addiw_op"]
+ - names: [slliw_op, srliw_op, sraiw_op]
+ tags: ["norm:slliw_srliw_sraiw_op"]
+ - names: [slliw_imm5_rsv, srliw_imm5_rsv, sraiw_imm5_rsv]
+ summary: Bit 5 of imm reserved
+ tags: ["norm:slliw_srliw_sraiw_imm5_rsv"]
+ - name: lui_op_rv64i
+ tags: ["norm:lui_op_rv64i"]
+ - name: auipc_op_rv64i
+ tags: ["norm:auipc_op_rv64i"]
+ - names: [addw_op, subw_op]
+ tags: ["norm:addw_subw_op"]
+ - names: [addw_overflow, subw_overflow]
+ tags: ["norm:addw_subw_overflow"]
+ - name: addiw_overflow
+ tags: ["norm:addiw_overflow"]
+ - names: [sll_sh_amt_rv64i, srl_sh_amt_rv64i, sra_sh_amt_rv64i]
+ tags: ["norm:sll_srl_sra_sh_amt_rv64i"]
+ - names: [sllw_op, srlw_op, sraw_op]
+ tags: ["norm:sllw_srlw_sraw_op"]
+ - name: ld_op_rv64i
+ tags: ["norm:ld_op_rv64i"]
+ - name: lw_op_rv64i
+ tags: ["norm:lw_op_rv64i"]
+ - name: lwu_op
+ tags: ["norm:lwu_op"]
+ - name: lh_op_rv64i
+ summary: "lh RV64I operation"
+ tags:
+ - "norm:ld_op_rv64i" # Example where multiple tags required to create a complete self-contained rule
+ - "norm:lw_op_rv64i"
+ - "norm:lh_lhu_lb_lbu_op_rv64i"
+ - name: lhu_rv64i_op
+ summary: "lhu RV64I operation"
+ tags:
+ - "norm:ld_op_rv64i" # Example where multiple tags required to create a complete self-contained rule
+ - "norm:lw_op_rv64i"
+ - "norm:lh_lhu_lb_lbu_op_rv64i"
+ - name: lb_rv64i_op
+ summary: "lb RV64I operation"
+ tags:
+ - "norm:ld_op_rv64i" # Example where multiple tags required to create a complete self-contained rule
+ - "norm:lw_op_rv64i"
+ - "norm:lh_lhu_lb_lbu_op_rv64i"
+ - name: lbu_rv64i_op
+ summary: "lbu RV64I operation"
+ tags:
+ - "norm:ld_op_rv64i" # Example where multiple tags required to create a complete self-contained rule
+ - "norm:lw_op_rv64i"
+ - "norm:lh_lhu_lb_lbu_op_rv64i"
+ - names: [sd_op_rv64i, sw_op_rv64i, sh_op_rv64i, sb_op_rv64i]
+ tags: ["norm:sd_sw_sh_sb_op_rv64i"]
diff --git a/normative_rule_defs/zilsd.yaml b/normative_rule_defs/zilsd.yaml
new file mode 100644
index 0000000..5cde09a
--- /dev/null
+++ b/normative_rule_defs/zilsd.yaml
@@ -0,0 +1,41 @@
+---
+# yaml-language-server: $schema=../docs-resources/schemas/defs-schema.json
+
+$schema: "../docs-resources/schemas/defs-schema.json#"
+
+# Used to create normative rules for zilsd.adoc file.
+# Tags refer to anchors in any adoc file for any ISA manual.
+
+normative_rule_definitions:
+ - name: Zilsd_reg_pairs
+ tags: ["norm:Zilsd_reg_pairs"]
+ - name: Zilsd_bits_to_pair
+ tags: ["norm:Zilsd_bits_to_pair"]
+ - name: Zilsd_align8_no_exc
+ tags: ["norm:Zilsd_align8_no_exc"]
+ - name: Zilsd_align8_atomic_unknown
+ tags: ["norm:Zilsd_align8_atomic_unknown"]
+ - name: Zilsd_align4_atomic
+ tags: ["norm:Zilsd_align4_atomic"]
+ - name: Zilsd_ld_resume_trap
+ tags: ["norm:Zilsd_ld_resume_trap"]
+ - name: Zilsd_ld_x0
+ tags: ["norm:Zilsd_ld_x0"]
+ - name: Zilsd_sd_x0
+ tags: ["norm:Zilsd_sd_x0"]
+ - name: Zilsd_RVWMO_exc_misaligned
+ tags: ["norm:Zilsd_RVWMO_exc_misaligned"]
+ - name: Zilsd_align4_two_4byte
+ tags: ["norm:Zilsd_align4_two_4byte"]
+ - name: Zilsd_ld_op
+ tags: ["norm:Zilsd_ld_op"]
+ - name: Zilsd_sd_op
+ tags: ["norm:Zilsd_sd_op"]
+ - name: c-ldsp_op
+ tags: ["norm:c-ldsp_op"]
+ - name: c-sdsp_op
+ tags: ["norm:c-sdsp_op"]
+ - name: c-ld_op
+ tags: ["norm:c-ld_op"]
+ - name: c-sd_op
+ tags: ["norm:c-sd_op"]
diff --git a/release/riscv-privileged-v1.10.pdf b/release/riscv-privileged-v1.10.pdf
deleted file mode 100644
index 6942fe7..0000000
--- a/release/riscv-privileged-v1.10.pdf
+++ /dev/null
Binary files differ
diff --git a/release/riscv-privileged-v1.7.pdf b/release/riscv-privileged-v1.7.pdf
deleted file mode 100644
index 70ee638..0000000
--- a/release/riscv-privileged-v1.7.pdf
+++ /dev/null
Binary files differ
diff --git a/release/riscv-privileged-v1.9.1.pdf b/release/riscv-privileged-v1.9.1.pdf
deleted file mode 100644
index df17e4d..0000000
--- a/release/riscv-privileged-v1.9.1.pdf
+++ /dev/null
Binary files differ
diff --git a/release/riscv-privileged-v1.9.pdf b/release/riscv-privileged-v1.9.pdf
deleted file mode 100644
index 709e1f4..0000000
--- a/release/riscv-privileged-v1.9.pdf
+++ /dev/null
Binary files differ
diff --git a/release/riscv-spec-v2.1.pdf b/release/riscv-spec-v2.1.pdf
deleted file mode 100644
index 1f8ce6a..0000000
--- a/release/riscv-spec-v2.1.pdf
+++ /dev/null
Binary files differ
diff --git a/release/riscv-spec-v2.2.pdf b/release/riscv-spec-v2.2.pdf
deleted file mode 100644
index e4a4634..0000000
--- a/release/riscv-spec-v2.2.pdf
+++ /dev/null
Binary files differ
diff --git a/src/a-st-ext.adoc b/src/a-st-ext.adoc
new file mode 100644
index 0000000..100f004
--- /dev/null
+++ b/src/a-st-ext.adoc
@@ -0,0 +1,485 @@
+[[atomics]]
+== "A" Extension for Atomic Instructions, Version 2.1
+
+The atomic-instruction extension, named "A", contains
+instructions that atomically read-modify-write memory to support
+synchronization between multiple RISC-V harts running in the same memory
+space. The two forms of atomic instruction provided are
+load-reserved/store-conditional instructions and atomic fetch-and-op
+memory instructions. Both types of atomic instruction support various
+memory consistency orderings including unordered, acquire, release, and
+sequentially consistent semantics. These instructions allow RISC-V to
+support the RCsc memory consistency model. cite:[Gharachorloo90memoryconsistency]
+
+[NOTE]
+====
+After much debate, the language community and architecture community
+appear to have finally settled on release consistency as the standard
+memory consistency model and so the RISC-V atomic support is built
+around this model.
+====
+
+The A extension comprises instructions provided by the Zaamo and Zalrsc
+extensions.
+
+=== Specifying Ordering of Atomic Instructions
+
+The base RISC-V ISA has a relaxed memory model, with the FENCE
+instruction used to impose additional ordering constraints. The address
+space is divided by the execution environment into memory and I/O
+domains, and the FENCE instruction provides options to order accesses to
+one or both of these two address domains.
+
+To provide more efficient support for release consistency cite:[Gharachorloo90memoryconsistency], each atomic
+instruction has two bits, _aq_ and _rl_, used to specify additional
+memory ordering constraints as viewed by other RISC-V harts. The bits
+order accesses to one of the two address domains, memory or I/O,
+depending on which address domain the atomic instruction is accessing.
+No ordering constraint is implied to accesses to the other domain, and a
+FENCE instruction should be used to order across both domains.
+
+If both bits are clear, no additional ordering constraints are imposed
+on the atomic memory operation. If only the _aq_ bit is set, the atomic
+memory operation is treated as an _acquire_ access, i.e., no following
+memory operations on this RISC-V hart can be observed to take place
+before the acquire memory operation. If only the _rl_ bit is set, the
+atomic memory operation is treated as a _release_ access, i.e., the
+release memory operation cannot be observed to take place before any
+earlier memory operations on this RISC-V hart. If both the _aq_ and _rl_
+bits are set, the atomic memory operation is _sequentially consistent_
+and cannot be observed to happen before any earlier memory operations or
+after any later memory operations in the same RISC-V hart and to the
+same address domain.
+
+[[sec:lrsc]]
+=== "Zalrsc" Extension for Load-Reserved/Store-Conditional Instructions
+
+include::images/wavedrom/load-reserve-st-conditional.edn[]
+
+Complex atomic memory operations on a single memory word or doubleword
+are performed with the load-reserved (LR) and store-conditional (SC)
+instructions. LR.W loads a word from the address in _rs1_, places the
+sign-extended value in _rd_, and registers a _reservation set_—a set of
+bytes that subsumes the bytes in the addressed word. SC.W conditionally
+writes a word in _rs2_ to the address in _rs1_: the SC.W succeeds only
+if the reservation is still valid and the reservation set contains the
+bytes being written. If the SC.W succeeds, the instruction writes the
+word in _rs2_ to memory, and it writes zero to _rd_. If the SC.W fails,
+the instruction does not write to memory, and it writes a nonzero value
+to _rd_.
+No SC.W instruction shall retire unless it passes memory permission checks,
+but it is UNSPECIFIED whether any side effects of implicit address translation
+and protection memory accesses (such as setting a page-table entry D bit)
+occur on a failed SC.W.
+For the purposes of memory protection, a failed SC.W may be
+treated like a store.
+Regardless of success or failure, executing an
+SC.W instruction invalidates any reservation held by this hart. LR.D and
+SC.D act analogously on doublewords and are only available on RV64. For
+RV64, LR.W and SC.W sign-extend the value placed in _rd_.
+
+[NOTE]
+====
+Both compare-and-swap (CAS) and LR/SC can be used to build lock-free
+data structures. After extensive discussion, we opted for LR/SC for
+several reasons: 1) CAS suffers from the ABA problem, which LR/SC avoids
+because it monitors all writes to the address rather than only checking
+for changes in the data value; 2) CAS would also require a new integer
+instruction format to support three source operands (address, compare
+value, swap value) as well as a different memory system message format,
+which would complicate microarchitectures; 3) Furthermore, to avoid the
+ABA problem, other systems provide a double-wide CAS (DW-CAS) to allow a
+counter to be tested and incremented along with a data word. This
+requires reading five registers and writing two in one instruction, and
+also a new larger memory system message type, further complicating
+implementations; 4) LR/SC provides a more efficient implementation of
+many primitives as it only requires one load as opposed to two with CAS
+(one load before the CAS instruction to obtain a value for speculative
+computation, then a second load as part of the CAS instruction to check
+if value is unchanged before updating).
+
+The main disadvantage of LR/SC over CAS is livelock, which we avoid,
+under certain circumstances, with an architected guarantee of eventual
+forward progress as described below. Another concern is whether the
+influence of the current x86 architecture, with its DW-CAS, will
+complicate porting of synchronization libraries and other software that
+assumes DW-CAS is the basic machine primitive. A possible mitigating
+factor is the recent addition of transactional memory instructions to
+x86, which might cause a move away from DW-CAS.
+
+More generally, a multi-word atomic primitive is desirable, but there is
+still considerable debate about what form this should take, and
+guaranteeing forward progress adds complexity to a system.
+====
+
+The failure code with value 1 encodes an unspecified failure. Other
+failure codes are reserved at this time. Portable software should only
+assume the failure code will be non-zero.
+
+[NOTE]
+====
+We reserve a failure code of 1 to mean ''unspecified'' so that simple
+implementations may return this value using the existing multiplexer required
+for the SLT/SLTU instructions. More specific failure codes might be
+defined in future versions or extensions to the ISA.
+====
+
+For LR and SC, the Zalrsc extension requires that the address held in _rs1_
+be naturally aligned to the size of the operand (i.e., eight-byte
+aligned for _doublewords_ and four-byte aligned for _words_). If the
+address is not naturally aligned, an address-misaligned exception or an
+access-fault exception will be generated. The access-fault exception can
+be generated for a memory access that would otherwise be able to
+complete except for the misalignment, if the misaligned access should
+not be emulated.
+[NOTE]
+====
+Emulating misaligned LR/SC sequences is impractical in most systems.
+
+Misaligned LR/SC sequences also raise the possibility of accessing
+multiple reservation sets at once, which present definitions do not
+provide for.
+====
+
+An implementation can register an arbitrarily large reservation set on
+each LR, provided the reservation set includes all bytes of the
+addressed data word or doubleword. An SC can only pair with the most
+recent LR in program order. An SC may succeed only if no store from
+another hart to the reservation set can be observed to have occurred
+between the LR and the SC, and if there is no other SC between the LR
+and itself in program order. An SC may succeed only if no write from a
+device other than a hart to the bytes accessed by the LR instruction can
+be observed to have occurred between the LR and SC. Note this LR might
+have had a different effective address and data size, but reserved the
+SC's address as part of the reservation set.
+
+[NOTE]
+====
+Following this model, in systems with memory translation, an SC is
+allowed to succeed if the earlier LR reserved the same location using an
+alias with a different virtual address, but is also allowed to fail if
+the virtual address is different.
+
+To accommodate legacy devices and buses, writes from devices other than
+RISC-V harts are only required to invalidate reservations when they
+overlap the bytes accessed by the LR. These writes are not required to
+invalidate the reservation when they access other bytes in the
+reservation set.
+====
+
+The SC must fail if the address is not within the reservation set of the
+most recent LR in program order. The SC must fail if a store to the
+reservation set from another hart can be observed to occur between the
+LR and SC. The SC must fail if a write from some other device to the
+bytes accessed by the LR can be observed to occur between the LR and SC.
+(If such a device writes the reservation set but does not write the
+bytes accessed by the LR, the SC may or may not fail.) An SC must fail
+if there is another SC (to any address) between the LR and the SC in
+program order. The precise statement of the atomicity requirements for
+successful LR/SC sequences is defined by the Atomicity Axiom in
+<<rvwmo>>.
+
+[NOTE]
+====
+The platform should provide a means to determine the size and shape of
+the reservation set.
+
+A platform specification may constrain the size and shape of the
+reservation set.
+
+A store-conditional instruction to a scratch word of memory should be
+used to forcibly invalidate any existing load reservation:
+
+* during a preemptive context switch, and
+* if necessary when changing virtual to physical address mappings, such
+as when migrating pages that might contain an active reservation.
+
+The invalidation of a hart's reservation when it executes an LR or SC
+imply that a hart can only hold one reservation at a time, and that an
+SC can only pair with the most recent LR, and LR with the next following
+SC, in program order. This is a restriction to the Atomicity Axiom in
+<<rvwmo>> that ensures software runs correctly on
+expected common implementations that operate in this manner.
+====
+
+An SC instruction can never be observed by another RISC-V hart before
+the LR instruction that established the reservation.
+
+[NOTE]
+====
+The LR/SC sequence
+can be given acquire semantics by setting the _aq_ bit on the LR
+instruction. The LR/SC sequence can be given release semantics by
+by setting the _rl_ bit on the SC instruction. Assuming
+suitable mappings for other atomic operations, setting the
+_aq_ bit on the LR instruction, and setting the
+_rl_ bit on the SC instruction makes the LR/SC
+sequence sequentially consistent in the C\++ `memory_order_seq_cst`
+sense. Such a sequence does not act as a fence for ordering ordinary
+load and store instructions before and after the sequence. Specific
+instruction mappings for other C++ atomic operations,
+or stronger notions of "sequential consistency", may require both
+bits to be set on either or both of the LR or SC instruction.
+
+If neither bit is set on either LR or SC, the LR/SC sequence can be
+observed to occur before or after surrounding memory operations from the
+same RISC-V hart. This can be appropriate when the LR/SC sequence is
+used to implement a parallel reduction operation.
+====
+
+Software should not set the _rl_ bit on an LR instruction unless the
+_aq_ bit is also set, nor should software set the _aq_ bit on an SC
+instruction unless the _rl_ bit is also set. LR._rl_ and SC._aq_
+instructions are not guaranteed to provide any stronger ordering than
+those with both bits clear, but may result in lower performance.
+
+[NOTE]
+====
+[[cas]]
+[source,asm]
+.Sample code for compare-and-swap function using LR/SC.
+ # a0 holds address of memory location
+ # a1 holds expected value
+ # a2 holds desired value
+ # a0 holds return value, 0 if successful, !0 otherwise
+ cas:
+ lr.w t0, (a0) # Load original value.
+ bne t0, a1, fail # Doesn't match, so fail.
+ sc.w t0, a2, (a0) # Try to update.
+ bnez t0, cas # Retry if store-conditional failed.
+ li a0, 0 # Set return to success.
+ jr ra # Return.
+ fail:
+ li a0, 1 # Set return to failure.
+ jr ra # Return.
+
+LR/SC can be used to construct lock-free data structures. An example
+using LR/SC to implement a compare-and-swap function is shown in
+<<cas>>. If inlined, compare-and-swap functionality need only take four instructions.
+====
+
+[[sec:lrscseq]]
+=== Eventual Success of Store-Conditional Instructions
+
+The Zalrsc extension defines _constrained LR/SC loops_, which have
+the following properties:
+
+* The loop comprises only an LR/SC sequence and code to retry the
+sequence in the case of failure, and must comprise at most 16
+instructions placed sequentially in memory.
+* An LR/SC sequence begins with an LR instruction and ends with an SC
+instruction. The dynamic code executed between the LR and SC
+instructions can only contain instructions from the base ''I''
+instruction set, excluding loads, stores, backward jumps, taken backward
+branches, JALR, FENCE, and SYSTEM instructions.
+Compressed forms of the aforementioned ''I'' instructions in the
+C (hence Zca) and Zcb extensions are also permitted.
+* The code to retry a failing LR/SC sequence can contain backwards jumps
+and/or branches to repeat the LR/SC sequence, but otherwise has the same
+constraint as the code between the LR and SC.
+* The LR and SC addresses must lie within a memory region with the
+_LR/SC eventuality_ property. The execution environment is responsible
+for communicating which regions have this property.
+* The SC must be to the same effective address and of the same data size
+as the latest LR executed by the same hart.
+
+LR/SC sequences that do not lie within constrained LR/SC loops are
+_unconstrained_. Unconstrained LR/SC sequences might succeed on some
+attempts on some implementations, but might never succeed on other
+implementations.
+
+[NOTE]
+====
+We restricted the length of LR/SC loops to fit within 64 contiguous
+instruction bytes in the base ISA to avoid undue restrictions on
+instruction cache and TLB size and associativity. Similarly, we
+disallowed other loads and stores within the loops to avoid restrictions
+on data-cache associativity in simple implementations that track the
+reservation within a private cache. The restrictions on branches and
+jumps limit the time that can be spent in the sequence. Floating-point
+operations and integer multiply/divide were disallowed to simplify the
+operating system's emulation of these instructions on implementations
+lacking appropriate hardware support.
+
+Software is not forbidden from using unconstrained LR/SC sequences, but
+portable software must detect the case that the sequence repeatedly
+fails, then fall back to an alternate code sequence that does not rely
+on an unconstrained LR/SC sequence. Implementations are permitted to
+unconditionally fail any unconstrained LR/SC sequence.
+====
+
+If a hart _H_ enters a constrained LR/SC loop, the execution environment
+must guarantee that one of the following events eventually occurs:
+
+* _H_ or some other hart executes a successful SC to the reservation set
+of the LR instruction in _H_'s constrained LR/SC loops.
+* Some other hart executes an unconditional store or AMO instruction to
+the reservation set of the LR instruction in _H_'s constrained LR/SC
+loop, or some other device in the system writes to that reservation set.
+* _H_ executes a branch or jump that exits the constrained LR/SC loop.
+* _H_ traps.
+
+[NOTE]
+====
+Note that these definitions permit an implementation to fail an SC
+instruction occasionally for any reason, provided the aforementioned
+guarantee is not violated.
+
+As a consequence of the eventuality guarantee, if some harts in an
+execution environment are executing constrained LR/SC loops, and no
+other harts or devices in the execution environment execute an
+unconditional store or AMO to that reservation set, then at least one
+hart will eventually exit its constrained LR/SC loop. By contrast, if
+other harts or devices continue to write to that reservation set, it is
+not guaranteed that any hart will exit its LR/SC loop.
+
+Loads and load-reserved instructions do not by themselves impede the
+progress of other harts' LR/SC sequences. We note this constraint
+implies, among other things, that loads and load-reserved instructions
+executed by other harts (possibly within the same core) cannot impede
+LR/SC progress indefinitely. For example, cache evictions caused by
+another hart sharing the cache cannot impede LR/SC progress
+indefinitely. Typically, this implies reservations are tracked
+independently of evictions from any shared cache. Similarly, cache
+misses caused by speculative execution within a hart cannot impede LR/SC
+progress indefinitely.
+
+These definitions admit the possibility that SC instructions may
+spuriously fail for implementation reasons, provided progress is
+eventually made.
+
+One advantage of CAS is that it guarantees that some hart eventually
+makes progress, whereas an LR/SC atomic sequence could livelock
+indefinitely on some systems. To avoid this concern, we added an
+architectural guarantee of livelock freedom for certain LR/SC sequences.
+
+Earlier versions of this specification imposed a stronger
+starvation-freedom guarantee. However, the weaker livelock-freedom
+guarantee is sufficient to implement the C11 and C++11 languages, and is
+substantially easier to provide in some microarchitectural styles.
+====
+
+[[sec:amo]]
+=== "Zaamo" Extension for Atomic Memory Operations
+
+include::images/wavedrom/atomic-mem.edn[]
+
+The atomic memory operation (AMO) instructions perform read-modify-write
+operations for multiprocessor synchronization and are encoded with an
+R-type instruction format. These AMO instructions atomically load a data
+value from the address in _rs1_, place the value into register _rd_,
+apply a binary operator to the loaded value and the original value in
+_rs2_, then store the result back to the original address in _rs1_. AMOs
+can either operate on _doublewords_ (RV64 only) or _words_ in memory. For
+RV64, 32-bit AMOs always sign-extend the value placed in _rd_, and
+ignore the upper 32 bits of the original value of _rs2_.
+
+For AMOs, the Zaamo extension requires that the address held in _rs1_ be
+naturally aligned to the size of the operand (i.e., eight-byte aligned
+for _doublewords_ and four-byte aligned for _words_). If the address
+is not naturally aligned, an address-misaligned exception or an
+access-fault exception will be generated. The access-fault exception can
+be generated for a memory access that would otherwise be able to
+complete except for the misalignment, if the misaligned access should
+not be emulated.
+
+The misaligned atomicity granule PMA, defined in Volume II of this manual,
+optionally relaxes this alignment requirement.
+If present, the misaligned atomicity granule PMA specifies the size
+of a misaligned atomicity granule, a power-of-two number of bytes.
+The misaligned atomicity granule PMA applies only to AMOs, loads and stores
+defined in the base ISAs, and loads and stores of no more than XLEN bits
+defined in the F, D, and Q extensions.
+For an instruction in that set, if all accessed bytes lie within the same
+misaligned atomicity granule, the instruction will not raise an exception for
+reasons of address alignment, and the instruction will give rise to only one
+memory operation for the purposes of RVWMO--i.e., it will execute atomically.
+
+The operations supported are swap, integer add, bitwise AND, bitwise OR,
+bitwise XOR, and signed and unsigned integer maximum and minimum.
+Without ordering constraints, these AMOs can be used to implement
+parallel reduction operations, where typically the return value would be
+discarded by writing to `x0`.
+
+[NOTE]
+====
+We provided fetch-and-op style atomic primitives as they scale to highly
+parallel systems better than LR/SC or CAS. A simple microarchitecture
+can implement AMOs using the LR/SC primitives, provided the
+implementation can guarantee the AMO eventually completes. More complex
+implementations might also implement AMOs at memory controllers, and can
+optimize away fetching the original value when the destination is `x0`.
+
+The set of AMOs was chosen to support the C11/C++11 atomic memory
+operations efficiently, and also to support parallel reductions in
+memory. Another use of AMOs is to provide atomic updates to
+memory-mapped device registers (e.g., setting, clearing, or toggling
+bits) in the I/O space.
+
+The Zaamo extension enables microcontroller class implementations to utilize
+atomic primitives from the AMO subset of the A extension. Typically such
+implementations do not have caches and thus may not be able to naturally support
+the LR/SC instructions provided by the Zalrsc extension.
+====
+
+To help implement multiprocessor synchronization, the AMOs optionally
+provide release consistency semantics. If the _aq_ bit is set, then no
+later memory operations in this RISC-V hart can be observed to take
+place before the AMO. Conversely, if the _rl_ bit is set, then other
+RISC-V harts will not observe the AMO before memory accesses preceding
+the AMO in this RISC-V hart. Setting both the _aq_ and the _rl_ bit on
+an AMO makes the sequence sequentially consistent, meaning that it
+cannot be reordered with earlier or later memory operations from the
+same hart.
+
+[NOTE]
+====
+The AMOs were designed to implement the C11 and C++11 memory models
+efficiently. Although the FENCE R, RW instruction suffices to implement
+the _acquire_ operation and FENCE RW, W suffices to implement _release_,
+both imply additional unnecessary ordering as compared to AMOs with the
+corresponding _aq_ or _rl_ bit set.
+====
+
+[NOTE]
+====
+An example code sequence for a critical section guarded by a
+test-and-test-and-set spinlock is shown in
+Example <<critical>>. Note the first AMO is marked _aq_ to
+order the lock acquisition before the critical section, and the second
+AMO is marked _rl_ to order the critical section before the lock
+relinquishment.
+
+[[critical]]
+[source,asm]
+.Sample code for mutual exclusion. `a0` contains the address of the lock.
+ li t0, 1 # Initialize swap value.
+ again:
+ lw t1, (a0) # Check if lock is held.
+ bnez t1, again # Retry if held.
+ amoswap.w.aq t1, t0, (a0) # Attempt to acquire lock.
+ bnez t1, again # Retry if held.
+ # ...
+ # Critical section.
+ # ...
+ amoswap.w.rl x0, x0, (a0) # Release lock by storing 0.
+
+We recommend the use of the AMO Swap idiom shown in <<critical>> for both lock
+acquire and release to simplify the implementation of speculative lock
+elision. cite:[Rajwar:2001:SLE]
+====
+
+[NOTE]
+====
+The instructions in the "A" extension can be used to provide sequentially
+consistent loads and stores, but this constrains hardware
+reordering of memory accesses more than necessary.
+A C++ sequentially consistent load can be implemented as
+an LR with _aq_ set. However, the LR/SC eventual
+success guarantee may slow down concurrent loads from the same effective
+address. A sequentially consistent store can be implemented as an AMOSWAP
+that writes the old value to `x0` and has _rl_ set. However the superfluous
+load may impose ordering constraints that are unnecessary for this use case.
+Specific compilation conventions may require both the _aq_ and _rl_
+bits to be set in either or both the LR and AMOSWAP instructions.
+====
diff --git a/src/a.tex b/src/a.tex
deleted file mode 100644
index 163c52f..0000000
--- a/src/a.tex
+++ /dev/null
@@ -1,404 +0,0 @@
-\chapter{``A'' Standard Extension for Atomic Instructions, Version 2.0}
-\label{atomics}
-
-The standard atomic instruction extension is denoted by instruction
-subset name ``A'', and contains instructions that atomically
-read-modify-write memory to support synchronization between multiple
-RISC-V harts running in the same memory space. The two forms of
-atomic instruction provided are load-reserved/store-conditional
-instructions and atomic fetch-and-op memory instructions. Both types
-of atomic instruction support various memory consistency orderings
-including unordered, acquire, release, and sequentially consistent
-semantics. These instructions allow RISC-V to support the RCsc memory
-consistency model~\cite{Gharachorloo90memoryconsistency}.
-
-\begin{commentary}
-After much debate, the language community and architecture community
-appear to have finally settled on release consistency as the standard
-memory consistency model and so the RISC-V atomic support is built
-around this model.
-\end{commentary}
-
-\section{Specifying Ordering of Atomic Instructions}
-
-The base RISC-V ISA has a relaxed memory model, with the FENCE
-instruction used to impose additional ordering constraints. The
-address space is divided by the execution environment into memory and
-I/O domains, and the FENCE instruction provides options to order
-accesses to one or both of these two address domains.
-
-To provide more efficient support for release
-consistency~\cite{Gharachorloo90memoryconsistency}, each atomic
-instruction has two bits, {\em aq} and {\em rl}, used to specify
-additional memory ordering constraints as viewed by other RISC-V
-harts. The bits order accesses to one of the two address domains,
-memory or I/O, depending on which address domain the atomic
-instruction is accessing. No ordering constraint is implied to
-accesses to the other domain, and a FENCE instruction should be used
-to order across both domains.
-
-If both bits are clear, no additional ordering constraints are imposed
-on the atomic memory operation. If only the {\em aq} bit is set, the
-atomic memory operation is treated as an {\em acquire} access, i.e.,
-no following memory operations on this RISC-V hart can be observed
-to take place before the acquire memory operation. If only the {\em
- rl} bit is set, the atomic memory operation is treated as a {\em
- release} access, i.e., the release memory operation cannot be
-observed to take place before any earlier memory operations on this
-RISC-V hart. If both the {\em aq} and {\em rl} bits are set, the
-atomic memory operation is {\em sequentially consistent} and cannot be
-observed to happen before any earlier memory operations or after any
-later memory operations in the same RISC-V hart and to the same
-address domain.
-
-\section{Load-Reserved/Store-Conditional Instructions}
-\label{sec:lrsc}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}W@{}W@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbit{26} &
-\instbit{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 1 & 1 & 5 & 5 & 3 & 5 & 7 \\
-LR & \multicolumn{2}{c}{ordering} & 0 & addr & width & dest & AMO \\
-SC & \multicolumn{2}{c}{ordering} & src & addr & width & dest & AMO \\
-\end{tabular}
-\end{center}
-
-Complex atomic memory operations on a single memory word are performed
-with the load-reserved (LR) and store-conditional (SC) instructions.
-LR loads a word from the address in {\em rs1}, places the
-sign-extended value in {\em rd}, and registers a reservation on the
-memory address and a range of bytes including at least all bytes of
-the addressed word. SC writes a word in {\em rs2} to the address in
-{\em rs1}, provided a valid reservation still exists on that address.
-SC writes zero to {\em rd} on success or a nonzero code on failure.
-
-\begin{commentary}
-Both compare-and-swap (CAS) and LR/SC can be used to build lock-free
-data structures. After extensive discussion, we opted for LR/SC for
-several reasons: 1) CAS suffers from the ABA problem, which LR/SC
-avoids because it monitors all accesses to the address rather than
-only checking for changes in the data value; 2) CAS would also require
-a new integer instruction format to support three source operands
-(address, compare value, swap value) as well as a different memory
-system message format, which would complicate microarchitectures; 3)
-Furthermore, to avoid the ABA problem, other systems provide a
-double-wide CAS (DW-CAS) to allow a counter to be tested and
-incremented along with a data word. This requires reading five
-registers and writing two in one instruction, and also a new larger
-memory system message type, further complicating implementations; 4)
-LR/SC provides a more efficient implementation of many primitives as
-it only requires one load as opposed to two with CAS (one load before
-the CAS instruction to obtain a value for speculative computation,
-then a second load as part of the CAS instruction to check if value is
-unchanged before updating).
-
-The main disadvantage of LR/SC over CAS is livelock, which we avoid
-with an architected guarantee of eventual forward progress as
-described below. Another concern is whether the influence of the
-current x86 architecture, with its DW-CAS, will complicate porting of
-synchronization libraries and other software that assumes DW-CAS is
-the basic machine primitive. A possible mitigating factor is the
-recent addition of transactional memory instructions to x86, which
-might cause a move away from DW-CAS.
-\end{commentary}
-
-The failure code with value 1 is reserved to encode an unspecified
-failure. Other failure codes are reserved at this time, and portable
-software should only assume the failure code will be non-zero.
-
-\begin{commentary}
-We reserve a failure code of 1 to mean ``unspecified'' so that simple
-implementations may return this value using the existing mux required
-for the SLT/SLTU instructions. More specific failure codes might be
-defined in future versions or extensions to the ISA.
-\end{commentary}
-
-For LR and SC, the A extension requires that the address held in {\em
- rs1} be naturally aligned to the size of the operand (i.e.,
-eight-byte aligned for 64-bit words and four-byte aligned for 32-bit
-words). If the address is not naturally aligned, a misaligned address
-exception or an access exception will be generated. The access
-exception can be generated for a memory access that would otherwise be
-able to complete except for the misalignment, if the misaligned access
-should not be emulated.
-
-\label{lrscseq}
-
-In the standard A extension, certain constrained LR/SC sequences are
-guaranteed to succeed eventually. The static code for the LR/SC
-sequence plus the code to retry the sequence in case of failure must
-comprise at most 16 integer instructions placed sequentially in
-memory. For the sequence to be guaranteed to eventually succeed, the
-dynamic code executed between the LR and SC instructions can only
-contain other instructions from the base ``I'' subset, excluding
-loads, stores, backward jumps or taken backward branches, FENCE,
-FENCE.I, and SYSTEM instructions. The code to retry a failing LR/SC
-sequence can contain backward jumps and/or branches to repeat the
-LR/SC sequence, but otherwise has the same constraints. The SC must
-be to the same address and of the same data size as the latest LR
-executed. The execution environment can limit the instruction and
-data memory regions within which forward progress is guaranteed.
-LR/SC sequences that do not meet all these constraints might complete on
-some attempts on some implementations, but there is no guarantee of
-eventual success.
-
-\begin{commentary}
-One advantage of CAS is that it guarantees that some hart eventually
-makes progress, whereas an LR/SC atomic sequence could livelock
-indefinitely on some systems. To avoid this concern, we added an
-architectural guarantee of forward progress to LR/SC atomic sequences.
-The restrictions on LR/SC sequence contents allows an implementation
-to capture a cache line on the LR and complete the LR/SC sequence by
-holding off remote cache interventions for a bounded short
-time. Interrupts and TLB misses might cause the reservation to be
-lost, but eventually the atomic sequence can complete. We restricted
-the length of LR/SC sequences to fit within 64 contiguous instruction
-bytes in the base ISA to avoid undue restrictions on instruction cache
-and TLB size and associativity. Similarly, we disallowed other loads
-and stores within the sequences to avoid restrictions on data-cache
-associativity. The restrictions on branches and jumps limits the time
-that can be spent in the sequence. Floating-point operations and
-integer multiply/divide were disallowed to simplify the operating
-system's emulation of these instructions on implementations lacking
-appropriate hardware support.
-
-Although software is not forbidden from using LR/SC sequences that do not meet
-the forward-progress constraints, portable software must detect the case that
-the sequence repeatedly fails, then fall back to an alternate code sequence
-that does not run afoul of the forward-progress constraints.
-Implementations are permitted to simply always fail any LR/SC sequence that does
-not meet the forward-progress guarantee.
-\end{commentary}
-
-An implementation can reserve an arbitrarily large subset of the
-address space on each LR, provided the memory range includes all bytes
-of the addressed data word.
-An SC can only pair with the most recent LR in program order. An SC
-may succeed if no store from another hart to the address range
-reserved by the LR can be observed to have occurred between the LR and
-the SC, and if there is no other SC between the LR and itself in
-program order. Note this LR might have had a different address
-argument, but reserved the SC's address as part of the memory subset.
-Following this model, in systems with memory translation, an SC is
-allowed to succeed if the earlier LR reserved the same location using
-an alias with a different virtual address, but is also allowed to fail
-if the virtual address is different. The SC must fail if a store from
-another hart to the address range reserved by the LR can be observed
-to occur between the LR and the SC. An SC must fail if there is
-another SC (to any address) between the LR and the SC in program
-order. The precise statement of the atomicity requirements for
-successful LR/SC sequences is defined by the Atomicity Axiom in
-Section~\ref{sec:rvwmo}.
-
-\begin{commentary}
-A store-conditional instruction to a scratch word of memory should be used
-during a preemptive context switch to forcibly yield any existing load
-reservation.
-\end{commentary}
-
-LR/SC can be used to construct lock-free data structures. An example
-using LR/SC to implement a compare-and-swap function is shown in
-Figure~\ref{cas}. If inlined, compare-and-swap functionality need
-only take four instructions.
-
-\begin{figure}[h!]
-\begin{center}
-\begin{verbatim}
- # a0 holds address of memory location
- # a1 holds expected value
- # a2 holds desired value
- # a0 holds return value, 0 if successful, !0 otherwise
- cas:
- lr.w t0, (a0) # Load original value.
- bne t0, a1, fail # Doesn't match, so fail.
- sc.w a0, a2, (a0) # Try to update.
- bnez a0, cas # Retry if store-conditional failed.
- jr ra # Return.
- fail:
- li a0, 1 # Set return to failure.
- jr ra # Return.
-\end{verbatim}
-\end{center}
-\caption{Sample code for compare-and-swap function using LR/SC.}
-\label{cas}
-\end{figure}
-
-An SC instruction can never be observed by another RISC-V hart
-before the immediately preceding LR. Due to the atomic nature of the
-LR/SC sequence, no memory operations from another hart can be observed
-to have occurred between the LR and a successful SC. The LR/SC
-sequence can be given acquire semantics by setting the {\em aq} bit on
-the LR instruction. The LR/SC sequence can be given release semantics
-by setting the {\em rl} bit on the SC instruction. Setting the {\em
- aq} bit on the LR instruction, and setting both the {\em aq} and the {\em
- rl} bit on the SC instruction makes the LR/SC sequence sequentially
-consistent, meaning that it cannot be reordered with earlier or
-later memory operations from the same hart.
-
-The {\em rl} bit on an LR instruction must not be set unless the {\em aq} bit is also set.
-The {\em aq} bit on an SC instruction must not be set unless the {\em rl} bit is also set.
-
-If neither bit is set on both LR and SC, the LR/SC sequence can be
-observed to occur before or after surrounding memory operations from
-the same RISC-V hart. This can be appropriate when the LR/SC
-sequence is used to implement a parallel reduction operation.
-
-\begin{commentary}
-In general, a multi-word atomic primitive is desirable but there is
-still considerable debate about what form this should take, and
-guaranteeing forward progress adds complexity to a system. Our
-current thoughts are to include a small limited-capacity transactional
-memory buffer along the lines of the original transactional memory
-proposals as an optional standard extension ``T''.
-\end{commentary}
-
-\section{Atomic Memory Operations}
-\label{sec:amo}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{O@{}W@{}W@{}R@{}R@{}F@{}R@{}R}
-\\
-\instbitrange{31}{27} &
-\instbit{26} &
-\instbit{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 1 & 1 & 5 & 5 & 3 & 5 & 7 \\
-AMOSWAP.W/D & \multicolumn{2}{c}{ordering} & src & addr & width & dest & AMO \\
-AMOADD.W/D & \multicolumn{2}{c}{ordering} & src & addr & width & dest & AMO \\
-AMOAND.W/D & \multicolumn{2}{c}{ordering} & src & addr & width & dest & AMO \\
-AMOOR.W/D & \multicolumn{2}{c}{ordering} & src & addr & width & dest & AMO \\
-AMOXOR.W/D & \multicolumn{2}{c}{ordering} & src & addr & width & dest & AMO \\
-AMOMAX[U].W/D & \multicolumn{2}{c}{ordering} & src & addr & width & dest & AMO \\
-AMOMIN[U].W/D & \multicolumn{2}{c}{ordering} & src & addr & width & dest & AMO \\
-\end{tabular}
-\end{center}
-
-\vspace{-0.1in} The atomic memory operation (AMO) instructions perform
-read-modify-write operations for multiprocessor synchronization and
-are encoded with an R-type instruction format. These AMO instructions
-atomically load a data value from the address in {\em rs1}, place the
-value into register {\em rd}, apply a binary operator to the loaded
-value and the original value in {\em rs2}, then store the result back
-to the address in {\em rs1}. AMOs can either operate on 64-bit (RV64
-only) or 32-bit words in memory. For RV64, 32-bit AMOs always
-sign-extend the value placed in {\em rd}.
-
-For AMOs, the A extension requires that the address held in {\em rs1}
-be naturally aligned to the size of the operand (i.e., eight-byte
-aligned for 64-bit words and four-byte aligned for 32-bit words). If
-the address is not naturally aligned, a misaligned address exception
-or an access exception will be generated. The access exception can be
-generated for a memory access that would otherwise be able to complete
-except for the misalignment, if the misaligned access should not be
-emulated. The ``Zam'' extension, described in Chapter~\ref{sec:zam},
-relaxes this requirement and specifies the semantics of misaligned
-AMOs.
-
-The operations supported are swap, integer add, bitwise AND, bitwise
-OR, bitwise XOR, and signed and unsigned integer maximum and minimum.
-Without ordering constraints, these AMOs can be used to implement
-parallel reduction operations, where typically the return value would
-be discarded by writing to {\tt x0}.
-
-\begin{commentary}
-We provided fetch-and-op style atomic primitives as they scale to
-highly parallel systems better than LR/SC or CAS. A simple
-microarchitecture can implement AMOs using the LR/SC primitives. More
-complex implementations might also implement AMOs at memory
-controllers, and can optimize away fetching the original value when
-the destination is {\tt x0}.
-
-The set of AMOs was chosen to support the C11/C++11 atomic memory
-operations efficiently, and also to support parallel reductions in
-memory. Another use of AMOs is to provide atomic updates to
-memory-mapped device registers (e.g., setting, clearing, or toggling
-bits) in the I/O space.
-\end{commentary}
-
-To help implement multiprocessor synchronization, the AMOs optionally
-provide release consistency semantics. If the {\em aq} bit is set,
-then no later memory operations in this RISC-V hart can be observed
-to take place before the AMO.
-Conversely, if the {\em rl} bit is set, then other
-RISC-V harts will not observe the AMO before memory accesses
-preceding the AMO in this RISC-V hart. Setting both the {\em aq} and the {\em
-rl} bit on an AMO makes the sequence sequentially consistent, meaning that
-it cannot be reordered with earlier or later memory operations from the same
-hart.
-
-\begin{commentary}
-The AMOs were designed to implement the C11 and C++11 memory models
-efficiently. Although the FENCE R, RW instruction suffices to
-implement the {\em acquire} operation and FENCE RW, W suffices to
-implement {\em release}, both imply additional unnecessary ordering as
-compared to AMOs with the corresponding {\em aq} or {\em rl} bit set.
-\end{commentary}
-
-An example code sequence for a critical section guarded by a
-test-and-set spinlock is shown in Figure~\ref{critical}. Note the
-first AMO is marked {\em aq} to order the lock acquisition before the
-critical section, and the second AMO is marked {\em rl} to order
-the critical section before the lock relinquishment.
-
-\begin{figure}[h!]
-\begin{center}
-\begin{verbatim}
- li t0, 1 # Initialize swap value.
- again:
- amoswap.w.aq t0, t0, (a0) # Attempt to acquire lock.
- bnez t0, again # Retry if held.
- # ...
- # Critical section.
- # ...
- amoswap.w.rl x0, x0, (a0) # Release lock by storing 0.
-\end{verbatim}
-\end{center}
-\caption{Sample code for mutual exclusion. {\tt a0} contains the address of the lock.}
-\label{critical}
-\end{figure}
-
-\begin{commentary}
-We recommend the use of the AMO Swap idiom shown above for both lock
-acquire and release to simplify the implementation of speculative lock
-elision~\cite{Rajwar:2001:SLE}.
-\end{commentary}
-
-The instructions in the ``A'' extension can also be used to provide
-sequentially consistent loads and stores. A sequentially consistent load can
-be implemented as an LR with both {\em aq} and {\em rl} set. A sequentially
-consistent store can be implemented as an AMOSWAP that writes the old value to
-x0 and has both {\em aq} and {\em rl} set.
diff --git a/src/assembly.tex b/src/assembly.tex
deleted file mode 100644
index cfbc0d0..0000000
--- a/src/assembly.tex
+++ /dev/null
@@ -1,163 +0,0 @@
-\chapter{RISC-V Assembly Programmer's Handbook}
-\label{assembly}
-
-This chapter is a placeholder for an assembly programmer's manual.
-
-Table~\ref{regmap} lists the assembler mnemonics for the {\tt x} and {\tt f}
-registers and their role in the first standard calling convention.
-
-\vspace{0.2in}
-\begin{table*}[htbp]
-\begin{center}
-\begin{tabular}{|l|l|l|l|}
-
- \hline
- Register & ABI Name & Description & Saver \\ \hline
- \tt x0 & \tt zero & Hard-wired zero & --- \\
- \tt x1 & \tt ra & Return address & Caller \\
- \tt x2 & \tt sp & Stack pointer & Callee \\
- \tt x3 & \tt gp & Global pointer & --- \\
- \tt x4 & \tt tp & Thread pointer & --- \\
- \tt x5 & {\tt t0} & Temporary/alternate link register& Caller \\
- {\tt x6}--{\tt 7} & {\tt t1}--{\tt 2} & Temporaries & Caller \\
- \tt x8 & {\tt s0}/\tt fp & Saved register/frame pointer & Callee \\
- \tt x9 & {\tt s1} & Saved register & Callee \\
- {\tt x10}--{\tt 11} & {\tt a0}--{\tt 1} & Function arguments/return values & Caller \\
- {\tt x12}--{\tt 17} & {\tt a2}--{\tt 7} & Function arguments & Caller \\
- {\tt x18}--{\tt 27} & {\tt s2}--{\tt 11} & Saved registers & Callee \\
- {\tt x28}--{\tt 31} & {\tt t3}--{\tt 6} & Temporaries & Caller \\
- \hline
- {\tt f0}--{\tt 7} & {\tt ft0}--{\tt 7} & FP temporaries & Caller \\
- {\tt f8}--{\tt 9} & {\tt fs0}--{\tt 1} & FP saved registers & Callee \\
- {\tt f10}--{\tt 11} & {\tt fa0}--{\tt 1} & FP arguments/return values & Caller \\
- {\tt f12}--{\tt 17} & {\tt fa2}--{\tt 7} & FP arguments & Caller \\
- {\tt f18}--{\tt 27} & {\tt fs2}--{\tt 11} & FP saved registers & Callee \\
- {\tt f28}--{\tt 31} & {\tt ft8}--{\tt 11} & FP temporaries & Caller \\
- \hline
-
- \end{tabular}
-\end{center}
-\caption{Assembler mnemonics for RISC-V integer and floating-point
- registers, and their role in the first standard calling convention.}
-\label{regmap}
-\end{table*}
-
-\pagebreak
-
-\begin{commentary}
- There may be future different calling conventions, but note that
- registers {\tt x1}, {\tt x2}, and {\tt x5} have special meanings
- encoded in the standard ISA and/or the compressed extension.
-\end{commentary}
-
-Tables~\ref{pseudos} and \ref{csr-pseudos} contain a listing of standard
-RISC-V pseudoinstructions.
-
-\begin{table}[h]
-\begin{small}
-\begin{center}
-\begin{tabular}{l l l}
-pseudoinstruction & Base Instruction(s) & Meaning \\ \hline
-
-\tt la rd, symbol & {\tt auipc rd, ${\tt delta[31:12]} + {\tt delta[11]}$} & Load absolute address, \\
- & {\tt addi rd, rd, delta[11:0]} & where ${\tt delta} = {\tt symbol} - {\tt pc}$ \\[1ex]
-\tt l\{b|h|w|d\} rd, symbol & {\tt auipc rd, ${\tt delta[31:12]} + {\tt delta[11]}$} & Load global \\
- & {\tt l\{b|h|w|d\} rd, delta[11:0](rd)} & \\[1ex]
-\tt s\{b|h|w|d\} rd, symbol, rt & {\tt auipc rt, ${\tt delta[31:12]} + {\tt delta[11]}$} & Store global \\
- & {\tt s\{b|h|w|d\} rd, delta[11:0](rt)} & \\[1ex]
-\tt fl\{w|d\} rd, symbol, rt & {\tt auipc rt, ${\tt delta[31:12]} + {\tt delta[11]}$} & Floating-point load global \\
- & {\tt fl\{w|d\} rd, delta[11:0](rt)} & \\[1ex]
-\tt fs\{w|d\} rd, symbol, rt & {\tt auipc rt, ${\tt delta[31:12]} + {\tt delta[11]}$} & Floating-point store global \\
- & {\tt fs\{w|d\} rd, delta[11:0](rt)} & \\[1ex]
-\multicolumn{3}{p{.99\textwidth}}{\small \em The base instructions use {\tt pc}-relative addressing, so the linker subtracts {\tt pc} from {\tt symbol} to get {\tt delta}. The linker adds {\tt delta[11]} to the 20-bit high part, counteracting sign extension of the 12-bit low part.} \\
-~\\
-\hline
-{\tt nop} & {\tt addi x0, x0, 0} & No operation \\
-{\tt li rd, immediate} & {\em Myriad sequences} & Load immediate \\
-{\tt mv rd, rs} & {\tt addi rd, rs, 0} & Copy register \\
-{\tt not rd, rs} & {\tt xori rd, rs, -1} & One's complement \\
-{\tt neg rd, rs} & {\tt sub rd, x0, rs} & Two's complement \\
-{\tt negw rd, rs} & {\tt subw rd, x0, rs} & Two's complement word \\
-{\tt sext.w rd, rs} & {\tt addiw rd, rs, 0} & Sign extend word \\
-{\tt seqz rd, rs} & {\tt sltiu rd, rs, 1} & Set if $=$ zero \\
-{\tt snez rd, rs} & {\tt sltu rd, x0, rs} & Set if $\neq$ zero \\
-{\tt sltz rd, rs} & {\tt slt rd, rs, x0} & Set if $<$ zero \\
-{\tt sgtz rd, rs} & {\tt slt rd, x0, rs} & Set if $>$ zero \\
-\hline
-{\tt fmv.s rd, rs} & {\tt fsgnj.s rd, rs, rs} & Copy single-precision register \\
-{\tt fabs.s rd, rs} & {\tt fsgnjx.s rd, rs, rs} & Single-precision absolute value \\
-{\tt fneg.s rd, rs} & {\tt fsgnjn.s rd, rs, rs} & Single-precision negate \\
-{\tt fmv.d rd, rs} & {\tt fsgnj.d rd, rs, rs} & Copy double-precision register \\
-{\tt fabs.d rd, rs} & {\tt fsgnjx.d rd, rs, rs} & Double-precision absolute value \\
-{\tt fneg.d rd, rs} & {\tt fsgnjn.d rd, rs, rs} & Double-precision negate \\
-\hline
-{\tt beqz rs, offset} & {\tt beq rs, x0, offset} & Branch if $=$ zero \\
-{\tt bnez rs, offset} & {\tt bne rs, x0, offset} & Branch if $\neq$ zero \\
-{\tt blez rs, offset} & {\tt bge x0, rs, offset} & Branch if $\leq$ zero \\
-{\tt bgez rs, offset} & {\tt bge rs, x0, offset} & Branch if $\geq$ zero \\
-{\tt bltz rs, offset} & {\tt blt rs, x0, offset} & Branch if $<$ zero \\
-{\tt bgtz rs, offset} & {\tt blt x0, rs, offset} & Branch if $>$ zero \\
-\hline
-{\tt bgt rs, rt, offset} & {\tt blt rt, rs, offset} & Branch if $>$ \\
-{\tt ble rs, rt, offset} & {\tt bge rt, rs, offset} & Branch if $\leq$ \\
-{\tt bgtu rs, rt, offset} & {\tt bltu rt, rs, offset} & Branch if $>$, unsigned \\
-{\tt bleu rs, rt, offset} & {\tt bgeu rt, rs, offset} & Branch if $\leq$, unsigned \\
-\hline
-{\tt j offset} & {\tt jal x0, offset} & Jump \\
-{\tt jal offset} & {\tt jal x1, offset} & Jump and link \\
-{\tt jr rs} & {\tt jalr x0, 0(rs)} & Jump register \\
-{\tt jalr rs} & {\tt jalr x1, 0(rs)} & Jump and link register \\
-{\tt ret} & {\tt jalr x0, 0(x1)} & Return from subroutine \\
-\tt call offset & {\tt auipc x1, ${\tt offset[31:12]} + {\tt offset[11]}$} & Call far-away subroutine \\
- & {\tt jalr x1, offset[11:0](x1)} & \\
-\tt tail offset & {\tt auipc x6, ${\tt offset[31:12]} + {\tt offset[11]}$} & Tail call far-away subroutine \\
- & {\tt jalr x0, offset[11:0](x6)} & \\
-\hline
-{\tt fence} & {\tt fence iorw, iorw} & Fence on all memory and I/O \\
-\hline
-
-\end{tabular}
-\end{center}
-\end{small}
-\caption{RISC-V pseudoinstructions.}
-\label{pseudos}
-\end{table}
-
-\begin{table}[h]
-\begin{small}
-\begin{center}
-\begin{tabular}{l l l}
-pseudoinstruction & Base Instruction & Meaning \\ \hline
-
-{\tt rdinstret[h] rd} & {\tt csrrs rd, instret[h], x0} & Read instructions-retired counter \\
-{\tt rdcycle[h] rd} & {\tt csrrs rd, cycle[h], x0} & Read cycle counter \\
-{\tt rdtime[h] rd} & {\tt csrrs rd, time[h], x0} & Read real-time clock \\
-\hline
-{\tt csrr rd, csr} & {\tt csrrs rd, csr, x0} & Read CSR \\
-{\tt csrw csr, rs} & {\tt csrrw x0, csr, rs} & Write CSR \\
-{\tt csrs csr, rs} & {\tt csrrs x0, csr, rs} & Set bits in CSR \\
-{\tt csrc csr, rs} & {\tt csrrc x0, csr, rs} & Clear bits in CSR \\
-\hline
-{\tt csrwi csr, imm} & {\tt csrrwi x0, csr, imm} & Write CSR, immediate \\
-{\tt csrsi csr, imm} & {\tt csrrsi x0, csr, imm} & Set bits in CSR, immediate \\
-{\tt csrci csr, imm} & {\tt csrrci x0, csr, imm} & Clear bits in CSR, immediate \\
-\hline
-{\tt frcsr rd} & {\tt csrrs rd, fcsr, x0} & Read FP control/status register \\
-{\tt fscsr rd, rs} & {\tt csrrw rd, fcsr, rs} & Swap FP control/status register \\
-{\tt fscsr rs} & {\tt csrrw x0, fcsr, rs} & Write FP control/status register \\
-\hline
-{\tt frrm rd} & {\tt csrrs rd, frm, x0} & Read FP rounding mode \\
-{\tt fsrm rd, rs} & {\tt csrrw rd, frm, rs} & Swap FP rounding mode \\
-{\tt fsrm rs} & {\tt csrrw x0, frm, rs} & Write FP rounding mode \\
-\hline
-{\tt frflags rd} & {\tt csrrs rd, fflags, x0} & Read FP exception flags \\
-{\tt fsflags rd, rs} & {\tt csrrw rd, fflags, rs} & Swap FP exception flags \\
-{\tt fsflags rs} & {\tt csrrw x0, fflags, rs} & Write FP exception flags \\
-\hline
-
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Pseudoinstructions for accessing control and status registers.}
-\label{csr-pseudos}
-\end{table}
diff --git a/src/b-st-ext.adoc b/src/b-st-ext.adoc
new file mode 100644
index 0000000..99f332f
--- /dev/null
+++ b/src/b-st-ext.adoc
@@ -0,0 +1,3865 @@
+[[bits]]
+== "B" Extension for Bit Manipulation, Version 1.0.0
+
+The B standard extension comprises instructions provided by the Zba, Zbb, and
+Zbs extensions.
+
+[[preface]]
+=== Zb* Overview
+
+The bit-manipulation (bitmanip) extension collection is comprised of several component extensions to the base RISC-V architecture that are intended to provide some combination of code size reduction, performance improvement, and energy reduction.
+While the instructions are intended to have general use, some instructions are more useful in some domains than others.
+Hence, several smaller bitmanip extensions are provided. Each of these smaller extensions is grouped by common function and use case, and each has its own Zb*-extension name.
+
+Each bitmanip extension includes a group of several bitmanip instructions that have similar purposes and that can often share the same logic. Some instructions are available in only one extension while others are available in several.
+The instructions have mnemonics and encodings that are independent of the extensions in which they appear.
+Thus, when implementing extensions with overlapping instructions, there is no redundancy in logic or encoding.
+
+The bitmanip extensions are defined for RV32 and RV64.
+
+=== Word Instructions
+
+The bitmanip extension follows the convention in RV64 that _w_-suffixed instructions (without a dot before the _w_) ignore the upper 32 bits of their inputs, operate on the least-significant 32-bits as signed values and produce a 32-bit signed result that is sign-extended to XLEN.
+
+Bitmanip instructions with the suffix _.uw_ have one operand that is an unsigned 32-bit value that is extracted from the least significant 32 bits of the specified register. Other than that, these perform full XLEN operations.
+
+Bitmanip instructions with the suffix _.b_, _.h_ and _.w_ only look at the least significant 8-bits, 16-bits and 32-bits of the input (respectively) and produce an XLEN-wide result that is sign-extended or zero-extended, based on the specific instruction.
+
+=== Pseudocode for instruction semantics
+
+The semantics of each instruction in <<#insns-b>> is expressed in a SAIL-like syntax.
+
+=== Extensions
+
+The first group of bitmanip extensions to be released for Public Review are:
+
+* <<#zba>>
+* <<#zbb>>
+* <<#zbc>>
+* <<#zbs>>
+
+Below is a list of all of the instructions that are included in these extensions
+along with their specific mapping:
+
+[%header,cols="^3,^3,10,16,^2,^2,^2,^2"]
+|====
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+|Zba
+|Zbb
+|Zbc
+|Zbs
+
+|
+|&#10003;
+|add.uw _rd_, _rs1_, _rs2_
+|<<#insns-add_uw>>
+|&#10003;
+|
+|
+|
+
+|&#10003;
+|&#10003;
+|andn _rd_, _rs1_, _rs2_
+|<<#insns-andn>>
+|
+|&#10003;
+|
+|
+
+
+|&#10003;
+|&#10003;
+|clmul _rd_, _rs1_, _rs2_
+|<<#insns-clmul>>
+|
+|
+|&#10003;
+|
+
+|&#10003;
+|&#10003;
+|clmulh _rd_, _rs1_, _rs2_
+|<<#insns-clmulh>>
+|
+|
+|&#10003;
+|
+
+|&#10003;
+|&#10003;
+|clmulr _rd_, _rs1_, _rs2_
+|<<#insns-clmulr>>
+|
+|
+|&#10003;
+|
+
+|&#10003;
+|&#10003;
+|clz _rd_, _rs_
+|<<#insns-clz>>
+|
+|&#10003;
+|
+|
+
+|
+|&#10003;
+|clzw _rd_, _rs_
+|<<#insns-clzw>>
+|
+|&#10003;
+|
+|
+|&#10003;
+|&#10003;
+|cpop _rd_, _rs_
+|<<#insns-cpop>>
+|
+|&#10003;
+|
+|
+
+|
+|&#10003;
+|cpopw _rd_, _rs_
+|<<#insns-cpopw>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|ctz _rd_, _rs_
+|<<#insns-ctz>>
+|
+|&#10003;
+|
+|
+
+|
+|&#10003;
+|ctzw _rd_, _rs_
+|<<#insns-ctzw>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|max _rd_, _rs1_, _rs2_
+|<<#insns-max>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|maxu _rd_, _rs1_, _rs2_
+|<<#insns-maxu>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|min _rd_, _rs1_, _rs2_
+|<<#insns-min>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|minu _rd_, _rs1_, _rs2_
+|<<#insns-minu>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|orc.b _rd_, _rs_
+|<<#insns-orc_b>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|orn _rd_, _rs1_, _rs2_
+|<<#insns-orn>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|rev8 _rd_, _rs_
+|<<#insns-rev8>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|rol _rd_, _rs1_, _rs2_
+|<<#insns-rol>>
+|
+|&#10003;
+|
+|
+
+|
+|&#10003;
+|rolw _rd_, _rs1_, _rs2_
+|<<#insns-rolw>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|ror _rd_, _rs1_, _rs2_
+|<<#insns-ror>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|rori _rd_, _rs1_, _shamt_
+|<<#insns-rori>>
+|
+|&#10003;
+|
+|
+
+|
+|&#10003;
+|roriw _rd_, _rs1_, _shamt_
+|<<#insns-roriw>>
+|
+|&#10003;
+|
+|
+
+|
+|&#10003;
+|rorw _rd_, _rs1_, _rs2_
+|<<#insns-rorw>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|bclr _rd_, _rs1_, _rs2_
+|<<#insns-bclr>>
+|
+|
+|
+|&#10003;
+
+|&#10003;
+|&#10003;
+|bclri _rd_, _rs1_, _imm_
+|<<#insns-bclri>>
+|
+|
+|
+|&#10003;
+
+|&#10003;
+|&#10003;
+|bext _rd_, _rs1_, _rs2_
+|<<#insns-bext>>
+|
+|
+|
+|&#10003;
+
+|&#10003;
+|&#10003;
+|bexti _rd_, _rs1_, _imm_
+|<<#insns-bexti>>
+|
+|
+|
+|&#10003;
+
+|&#10003;
+|&#10003;
+|binv _rd_, _rs1_, _rs2_
+|<<#insns-binv>>
+|
+|
+|
+|&#10003;
+
+|&#10003;
+|&#10003;
+|binvi _rd_, _rs1_, _imm_
+|<<#insns-binvi>>
+|
+|
+|
+|&#10003;
+
+|&#10003;
+|&#10003;
+|bset _rd_, _rs1_, _rs2_
+|<<#insns-bset>>
+|
+|
+|
+|&#10003;
+
+|&#10003;
+|&#10003;
+|bseti _rd_, _rs1_, _imm_
+|<<#insns-bseti>>
+|
+|
+|
+|&#10003;
+
+|&#10003;
+|&#10003;
+|sext.b _rd_, _rs_
+|<<#insns-sext_b>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|sext.h _rd_, _rs_
+|<<#insns-sext_h>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|sh1add _rd_, _rs1_, _rs2_
+|<<#insns-sh1add>>
+|&#10003;
+|
+|
+|
+
+|
+|&#10003;
+|sh1add.uw _rd_, _rs1_, _rs2_
+|<<#insns-sh1add_uw>>
+|&#10003;
+|
+|
+|
+
+|&#10003;
+|&#10003;
+|sh2add _rd_, _rs1_, _rs2_
+|<<#insns-sh2add>>
+|&#10003;
+|
+|
+|
+
+|
+|&#10003;
+|sh2add.uw _rd_, _rs1_, _rs2_
+|<<#insns-sh2add_uw>>
+|&#10003;
+|
+|
+|
+
+|&#10003;
+|&#10003;
+|sh3add _rd_, _rs1_, _rs2_
+|<<#insns-sh3add>>
+|&#10003;
+|
+|
+|
+
+|
+|&#10003;
+|sh3add.uw _rd_, _rs1_, _rs2_
+|<<#insns-sh3add_uw>>
+|&#10003;
+|
+|
+|
+
+|
+|&#10003;
+|slli.uw _rd_, _rs1_, _imm_
+|<<#insns-slli_uw>>
+|&#10003;
+|
+|
+|
+
+|&#10003;
+|&#10003;
+|xnor _rd_, _rs1_, _rs2_
+|<<#insns-xnor>>
+|
+|&#10003;
+|
+|
+
+|&#10003;
+|&#10003;
+|zext.h _rd_, _rs_
+|<<#insns-zext_h>>
+|
+|&#10003;
+|
+|
+
+|====
+
+[#zba,reftext=Address generation instructions]
+==== Zba: Address generation
+
+The Zba instructions can be used to accelerate the generation of addresses that index into arrays of basic types (halfword, word, doubleword) using both unsigned word-sized and XLEN-sized indices: a shifted index is added to a base address.
+
+The shift and add instructions do a left shift of 1, 2, or 3 because these are commonly found in real-world code and because they can be implemented with a minimal amount of additional hardware beyond that of the simple adder. This avoids lengthening the critical path in implementations.
+
+While the shift and add instructions are limited to a maximum left shift of 3, the slli instruction (from the base ISA) can be used to perform similar shifts for indexing into arrays of wider elements. The slli.uw -- added in this extension -- can be used when the index is to be interpreted as an unsigned word.
+
+The following instructions comprise the Zba extension:
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|
+|&#10003;
+|add.uw _rd_, _rs1_, _rs2_
+|<<#insns-add_uw>>
+
+|&#10003;
+|&#10003;
+|sh1add _rd_, _rs1_, _rs2_
+|<<#insns-sh1add>>
+
+|
+|&#10003;
+|sh1add.uw _rd_, _rs1_, _rs2_
+|<<#insns-sh1add_uw>>
+
+|&#10003;
+|&#10003;
+|sh2add _rd_, _rs1_, _rs2_
+|<<#insns-sh2add>>
+
+|
+|&#10003;
+|sh2add.uw _rd_, _rs1_, _rs2_
+|<<#insns-sh2add_uw>>
+
+|&#10003;
+|&#10003;
+|sh3add _rd_, _rs1_, _rs2_
+|<<#insns-sh3add>>
+
+|
+|&#10003;
+|sh3add.uw _rd_, _rs1_, _rs2_
+|<<#insns-sh3add_uw>>
+
+|
+|&#10003;
+|slli.uw _rd_, _rs1_, _imm_
+|<<#insns-slli_uw>>
+
+|===
+
+[#zbb,reftext="Basic bit-manipulation"]
+==== Zbb: Basic bit-manipulation
+
+===== Logical with negate
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|andn _rd_, _rs1_, _rs2_
+|<<#insns-andn>>
+
+|&#10003;
+|&#10003;
+|orn _rd_, _rs1_, _rs2_
+|<<#insns-orn>>
+
+|&#10003;
+|&#10003;
+|xnor _rd_, _rs1_, _rs2_
+|<<#insns-xnor>>
+|===
+
+.Implementation Hint
+[NOTE, caption="Imp" ]
+===============================================================
+The Logical with Negate instructions can be implemented by inverting the _rs2_ inputs to the base-required AND, OR, and XOR logic instructions.
+In some implementations, the inverter on rs2 used for subtraction can be reused for this purpose.
+===============================================================
+
+===== Count leading/trailing zero bits
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|clz _rd_, _rs_
+|<<#insns-clz>>
+
+|
+|&#10003;
+|clzw _rd_, _rs_
+|<<#insns-clzw>>
+
+|&#10003;
+|&#10003;
+|ctz _rd_, _rs_
+|<<#insns-ctz>>
+
+|
+|&#10003;
+|ctzw _rd_, _rs_
+|<<#insns-ctzw>>
+|===
+
+===== Count population
+
+These instructions count the number of set bits (1-bits). This is also
+commonly referred to as population count.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|cpop _rd_, _rs_
+|<<#insns-cpop>>
+
+|
+|&#10003;
+|cpopw _rd_, _rs_
+|<<#insns-cpopw>>
+|===
+
+===== Integer minimum/maximum
+
+The integer minimum/maximum instructions are arithmetic R-type
+instructions that return the smaller/larger of two operands.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|max _rd_, _rs1_, _rs2_
+|<<#insns-max>>
+
+|&#10003;
+|&#10003;
+|maxu _rd_, _rs1_, _rs2_
+|<<#insns-maxu>>
+
+|&#10003;
+|&#10003;
+|min _rd_, _rs1_, _rs2_
+|<<#insns-min>>
+
+|&#10003;
+|&#10003;
+|minu _rd_, _rs1_, _rs2_
+|<<#insns-minu>>
+|===
+
+===== Sign extension and zero extension
+
+These instructions perform the sign extension or zero extension of the least significant 8 bits or 16 bits of the source register.
+
+These instructions replace the generalized idioms `slli rd,rs,(XLEN-<size>) + srai` (for sign extension of 8-bit and 16-bit quantities) and `slli + srli` (for zero extension of 16-bit quantities).
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|sext.b _rd_, _rs_
+|<<#insns-sext_b>>
+
+|&#10003;
+|&#10003;
+|sext.h _rd_, _rs_
+|<<#insns-sext_h>>
+
+|&#10003;
+|&#10003;
+|zext.h _rd_, _rs_
+|<<#insns-zext_h>>
+|===
+
+===== Bitwise rotation
+
+Bitwise rotation instructions are similar to the shift-logical operations from the base spec. However, where the shift-logical
+instructions shift in zeros, the rotate instructions shift in the bits that were shifted out of the other side of the value.
+Such operations are also referred to as ‘circular shifts’.
+
+
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|rol _rd_, _rs1_, _rs2_
+|<<#insns-rol>>
+
+|
+|&#10003;
+|rolw _rd_, _rs1_, _rs2_
+|<<#insns-rolw>>
+
+|&#10003;
+|&#10003;
+|ror _rd_, _rs1_, _rs2_
+|<<#insns-ror>>
+
+|&#10003;
+|&#10003;
+|rori _rd_, _rs1_, _shamt_
+|<<#insns-rori>>
+
+|
+|&#10003;
+|roriw _rd_, _rs1_, _shamt_
+|<<#insns-roriw>>
+
+|
+|&#10003;
+|rorw _rd_, _rs1_, _rs2_
+|<<#insns-rorw>>
+|===
+
+.Architecture Explanation
+[NOTE, caption="AE" ]
+===============================================================
+The rotate instructions were included to replace a common
+four-instruction sequence to achieve the same effect (neg; sll/srl; srl/sll; or)
+===============================================================
+
+===== OR Combine
+
+*orc.b* sets the bits of each byte in the result _rd_ to all zeros if no bit within the respective byte of _rs_ is set, or to all ones if any bit within the respective byte of _rs_ is set.
+
+One use-case is string-processing functions, such as *strlen* and *strcpy*, which can use *orc.b* to test for the terminating zero byte by counting the set bits in leading non-zero bytes in a word.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|orc.b _rd_, _rs_
+|<<#insns-orc_b>>
+|===
+
+===== Byte-reverse
+
+*rev8* reverses the byte-ordering of _rs_.
+
+[%header,cols="^1,^1,4,8"]
+|====
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|rev8 _rd_, _rs_
+|<<#insns-rev8>>
+
+|====
+
+[#zbc,reftext="Carry-less multiplication"]
+==== Zbc: Carry-less multiplication
+
+Carry-less multiplication is the multiplication in the polynomial ring over GF(2).
+
+*clmul* produces the lower half of the carry-less product and *clmulh* produces the upper half of the 2&#x2715;XLEN carry-less product.
+
+*clmulr* produces bits 2&#x2715;XLEN−2:XLEN-1 of the 2&#x2715;XLEN carry-less product.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|clmul _rd_, _rs1_, _rs2_
+|<<#insns-clmul>>
+
+|&#10003;
+|&#10003;
+|clmulh _rd_, _rs1_, _rs2_
+|<<#insns-clmulh>>
+
+|&#10003;
+|&#10003;
+|clmulr _rd_, _rs1_, _rs2_
+|<<#insns-clmulr>>
+
+|===
+
+[#zbs,reftext="Single-bit instructions"]
+==== Zbs: Single-bit instructions
+
+The single-bit instructions provide a mechanism to set, clear, invert, or extract
+a single bit in a register. The bit is specified by its index.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|bclr _rd_, _rs1_, _rs2_
+|<<#insns-bclr>>
+
+|&#10003;
+|&#10003;
+|bclri _rd_, _rs1_, _imm_
+|<<#insns-bclri>>
+
+|&#10003;
+|&#10003;
+|bext _rd_, _rs1_, _rs2_
+|<<#insns-bext>>
+
+|&#10003;
+|&#10003;
+|bexti _rd_, _rs1_, _imm_
+|<<#insns-bexti>>
+
+|&#10003;
+|&#10003;
+|binv _rd_, _rs1_, _rs2_
+|<<#insns-binv>>
+
+|&#10003;
+|&#10003;
+|binvi _rd_, _rs1_, _imm_
+|<<#insns-binvi>>
+
+|&#10003;
+|&#10003;
+|bset _rd_, _rs1_, _rs2_
+|<<#insns-bset>>
+
+|&#10003;
+|&#10003;
+|bseti _rd_, _rs1_, _imm_
+|<<#insns-bseti>>
+
+|===
+
+[[zbkb,Bit-manipulation for Cryptography]]
+==== Zbkb: Bit-manipulation for Cryptography
+
+This extension contains instructions essential for implementing
+common operations in cryptographic workloads.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+
+| &#10003;
+| &#10003;
+| rol
+| <<insns-rol>>
+
+|
+| &#10003;
+| rolw
+| <<insns-rolw>>
+
+| &#10003;
+| &#10003;
+| ror
+| <<insns-ror>>
+
+| &#10003;
+| &#10003;
+| rori
+| <<insns-rori>>
+
+|
+| &#10003;
+| roriw
+| <<insns-roriw>>
+
+|
+| &#10003;
+| rorw
+| <<insns-rorw>>
+
+| &#10003;
+| &#10003;
+| andn
+| <<insns-andn>>
+
+| &#10003;
+| &#10003;
+| orn
+| <<insns-orn>>
+
+| &#10003;
+| &#10003;
+| xnor
+| <<insns-xnor>>
+
+| &#10003;
+| &#10003;
+| pack
+| <<insns-pack>>
+
+| &#10003;
+| &#10003;
+| packh
+| <<insns-packh>>
+
+|
+| &#10003;
+| packw
+| <<insns-packw>>
+
+| &#10003;
+| &#10003;
+| brev8
+| <<insns-brev8>>
+
+| &#10003;
+| &#10003;
+| rev8
+| <<insns-rev8>>
+
+| &#10003;
+|
+| zip
+| <<insns-zip>>
+
+| &#10003;
+|
+| unzip
+| <<insns-unzip>>
+
+|===
+
+[[zbkc,Carry-less multiplication for Cryptography]]
+==== Zbkc: Carry-less multiplication for Cryptography
+
+Carry-less multiplication is the multiplication in the polynomial ring over
+GF(2). This is a critical operation in some cryptographic workloads,
+particularly the AES-GCM authenticated encryption scheme.
+This extension provides only the instructions needed to
+efficiently implement the GHASH operation, which is part of this workload.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|clmul _rd_, _rs1_, _rs2_
+|<<#insns-clmul>>
+
+|&#10003;
+|&#10003;
+|clmulh _rd_, _rs1_, _rs2_
+|<<#insns-clmulh>>
+
+|===
+
+[[zbkx,Crossbar permutations]]
+==== Zbkx: Crossbar permutations
+
+These instructions implement a "lookup table" for 4 and 8 bit elements
+inside the general purpose registers.
+_rs1_ is used as a vector of N-bit words, and _rs2_ as a vector of N-bit
+indices into _rs1_.
+Elements in _rs1_ are replaced by the indexed element in _rs2_, or zero
+if the index into _rs2_ is out of bounds.
+
+These instructions are useful for expressing N-bit to N-bit boolean
+operations, and implementing cryptographic code with secret
+dependent memory accesses (particularly SBoxes) such that the execution
+latency does not depend on the (secret) data being operated on.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|xperm4 _rd_, _rs1_, _rs2_
+|<<#insns-xperm4>>
+
+|&#10003;
+|&#10003;
+|xperm8 _rd_, _rs1_, _rs2_
+|<<#insns-xperm8>>
+
+|===
+
+<<<
+
+[#insns-b,reftext="Instructions (in alphabetical order)"]
+=== Instructions (in alphabetical order)
+
+[#insns-add_uw,reftext=Add unsigned word]
+==== add.uw
+
+Synopsis::
+Add unsigned word
+
+Mnemonic::
+add.uw _rd_, _rs1_, _rs2_
+
+
+Pseudoinstructions::
+zext.w _rd_, _rs1_ &#8594; add.uw _rd_, _rs1_, zero
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x3b, attr: ['OP-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x0, attr: ['ADD.UW'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x04, attr: ['ADD.UW'] },
+]}
+....
+
+Description::
+This instruction performs an XLEN-wide addition between _rs2_ and the zero-extended least-significant word of _rs1_.
+
+Operation::
+[source,sail]
+--
+let base = X(rs2);
+let index = EXTZ(X(rs1)[31..0]);
+
+X(rd) = base + index;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zba (<<zba>>)
+|0.93
+|Ratified
+|===
+
+<<<
+[#insns-andn,reftext="AND with inverted operand"]
+==== andn
+
+Synopsis::
+AND with inverted operand
+
+Mnemonic::
+andn _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x7, attr: ['ANDN']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x20, attr: ['ANDN'] },
+]}
+....
+
+Description::
+This instruction performs the bitwise logical AND operation between _rs1_ and the bitwise inversion of _rs2_.
+
+Operation::
+[source,sail]
+--
+X(rd) = X(rs1) & ~X(rs2);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-bclr,reftext="Single-Bit Clear (Register)"]
+==== bclr
+
+Synopsis::
+Single-Bit Clear (Register)
+
+Mnemonic::
+bclr _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['BCLR'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x24, attr: ['BCLR/BEXT'] },
+]}
+....
+
+Description::
+This instruction returns _rs1_ with a single bit cleared at the index specified in _rs2_.
+The index is read from the lower log2(XLEN) bits of _rs2_.
+
+Operation::
+[source,sail]
+--
+let index = X(rs2) & (XLEN - 1);
+X(rd) = X(rs1) & ~(1 << index)
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbs (<<#zbs>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-bclri,reftext="Single-Bit Clear (Immediate)"]
+==== bclri
+
+Synopsis::
+Single-Bit Clear (Immediate)
+
+Mnemonic::
+bclri _rd_, _rs1_, _shamt_
+
+Encoding (RV32)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['BCLRI'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'shamt' },
+ { bits: 7, name: 0x24, attr: ['BCLRI'] },
+]}
+....
+
+Encoding (RV64)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['BCLRI'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 6, name: 'shamt' },
+ { bits: 6, name: 0x12, attr: ['BCLRI'] },
+]}
+....
+
+Description::
+This instruction returns _rs1_ with a single bit cleared at the index specified in _shamt_.
+The index is read from the lower log2(XLEN) bits of _shamt_.
+For RV32, the encodings corresponding to shamt[5]=1 are reserved.
+
+Operation::
+[source,sail]
+--
+let index = shamt & (XLEN - 1);
+X(rd) = X(rs1) & ~(1 << index)
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbs (<<#zbs>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-bext,reftext="Single-Bit Extract (Register)"]
+==== bext
+
+Synopsis::
+Single-Bit Extract (Register)
+// Should we describe this as a Set-if-bit-is-set?
+
+Mnemonic::
+bext _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['BEXT'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x24, attr: ['BCLR/BEXT'] },
+]}
+....
+
+Description::
+This instruction returns a single bit extracted from _rs1_ at the index specified in _rs2_.
+The index is read from the lower log2(XLEN) bits of _rs2_.
+
+Operation::
+[source,sail]
+--
+let index = X(rs2) & (XLEN - 1);
+X(rd) = (X(rs1) >> index) & 1;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbs (<<#zbs>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-bexti,reftext="Single-Bit Extract (Immediate)"]
+==== bexti
+
+Synopsis::
+Single-Bit Extract (Immediate)
+
+Mnemonic::
+bexti _rd_, _rs1_, _shamt_
+
+Encoding (RV32)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['BEXTI'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'shamt' },
+ { bits: 7, name: 0x24, attr: ['BEXTI/BCLRI'] },
+]}
+....
+
+Encoding (RV64)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['BEXTI'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 6, name: 'shamt' },
+ { bits: 6, name: 0x12, attr: ['BEXTI/BCLRI'] },
+]}
+....
+
+Description::
+This instruction returns a single bit extracted from _rs1_ at the index specified in _shamt_.
+The index is read from the lower log2(XLEN) bits of _shamt_.
+For RV32, the encodings corresponding to shamt[5]=1 are reserved.
+
+Operation::
+[source,sail]
+--
+let index = shamt & (XLEN - 1);
+X(rd) = (X(rs1) >> index) & 1;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbs (<<#zbs>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-binv,reftext="Single-Bit Invert (Register)"]
+==== binv
+
+Synopsis::
+Single-Bit Invert (Register)
+
+Mnemonic::
+binv _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['BINV'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x34, attr: ['BINV'] },
+]}
+....
+
+Description::
+This instruction returns _rs1_ with a single bit inverted at the index specified in _rs2_.
+The index is read from the lower log2(XLEN) bits of _rs2_.
+
+Operation::
+[source,sail]
+--
+let index = X(rs2) & (XLEN - 1);
+X(rd) = X(rs1) ^ (1 << index)
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbs (<<#zbs>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-binvi,reftext="Single-Bit Invert (Immediate)"]
+==== binvi
+
+Synopsis::
+Single-Bit Invert (Immediate)
+
+Mnemonic::
+binvi _rd_, _rs1_, _shamt_
+
+Encoding (RV32)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['BINV'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'shamt' },
+ { bits: 7, name: 0x34, attr: ['BINVI'] },
+]}
+....
+
+Encoding (RV64)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['BINV'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 6, name: 'shamt' },
+ { bits: 6, name: 0x1a, attr: ['BINVI'] },
+]}
+....
+
+Description::
+This instruction returns _rs1_ with a single bit inverted at the index specified in _shamt_.
+The index is read from the lower log2(XLEN) bits of _shamt_.
+For RV32, the encodings corresponding to shamt[5]=1 are reserved.
+
+Operation::
+[source,sail]
+--
+let index = shamt & (XLEN - 1);
+X(rd) = X(rs1) ^ (1 << index)
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbs (<<#zbs>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-bset,reftext="Single-Bit Set (Register)"]
+==== bset
+
+Synopsis::
+Single-Bit Set (Register)
+
+Mnemonic::
+bset _rd_, _rs1_,_rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['BSET'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x14, attr: ['BSET'] },
+]}
+....
+
+Description::
+This instruction returns _rs1_ with a single bit set at the index specified in _rs2_.
+The index is read from the lower log2(XLEN) bits of _rs2_.
+
+Operation::
+[source,sail]
+--
+let index = X(rs2) & (XLEN - 1);
+X(rd) = X(rs1) | (1 << index)
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbs (<<#zbs>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-bseti,reftext="Single-Bit Set (Immediate)"]
+==== bseti
+
+Synopsis::
+Single-Bit Set (Immediate)
+
+Mnemonic::
+bseti _rd_, _rs1_,_shamt_
+
+Encoding (RV32)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['BSETI'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'shamt' },
+ { bits: 7, name: 0x14, attr: ['BSETI'] },
+]}
+....
+
+Encoding (RV64)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['BSETI'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 6, name: 'shamt' },
+ { bits: 6, name: 0x0a, attr: ['BSETI'] },
+]}
+....
+
+Description::
+This instruction returns _rs1_ with a single bit set at the index specified in _shamt_.
+The index is read from the lower log2(XLEN) bits of _shamt_.
+For RV32, the encodings corresponding to shamt[5]=1 are reserved.
+
+Operation::
+[source,sail]
+--
+let index = shamt & (XLEN - 1);
+X(rd) = X(rs1) | (1 << index)
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbs (<<#zbs>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-clmul,reftext="Carry-less multiply (low-part)"]
+==== clmul
+
+Synopsis::
+Carry-less multiply (low-part)
+
+Mnemonic::
+clmul _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['CLMUL'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x5, attr: ['MINMAX/CLMUL'] },
+]}
+....
+
+Description::
+clmul produces the lower half of the 2·XLEN carry-less product.
+
+Operation::
+[source,sail]
+--
+let rs1_val = X(rs1);
+let rs2_val = X(rs2);
+let output : xlenbits = 0;
+
+foreach (i from 0 to (xlen - 1) by 1) {
+ output = if ((rs2_val >> i) & 1)
+ then output ^ (rs1_val << i);
+ else output;
+}
+
+X[rd] = output
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbc (<<#zbc>>)
+|v1.0
+|Ratified
+
+|Zbkc (<<#zbkc>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-clmulh,reftext="Carry-less multiply (high-part)"]
+==== clmulh
+
+Synopsis::
+Carry-less multiply (high-part)
+
+Mnemonic::
+clmulh _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x3, attr: ['CLMULH'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x5, attr: ['MINMAX/CLMUL'] },
+]}
+....
+
+Description::
+clmulh produces the upper half of the 2·XLEN carry-less product.
+
+Operation::
+[source,sail]
+--
+let rs1_val = X(rs1);
+let rs2_val = X(rs2);
+let output : xlenbits = 0;
+
+foreach (i from 1 to xlen by 1) {
+ output = if ((rs2_val >> i) & 1)
+ then output ^ (rs1_val >> (xlen - i));
+ else output;
+}
+
+X[rd] = output
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbc (<<#zbc>>)
+|v1.0
+|Ratified
+
+|Zbkc (<<#zbkc>>)
+|v1.0
+|Ratified
+|===
+
+
+<<<
+[#insns-clmulr,reftext="Carry-less multiply (reversed)"]
+==== clmulr
+
+Synopsis::
+Carry-less multiply (reversed)
+
+Mnemonic::
+clmulr _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x2, attr: ['CLMULR'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x5, attr: ['MINMAX/CLMUL'] },
+]}
+....
+
+Description::
+*clmulr* produces bits 2·XLEN−2:XLEN-1 of the 2·XLEN carry-less
+product.
+
+Operation::
+[source,sail]
+--
+let rs1_val = X(rs1);
+let rs2_val = X(rs2);
+let output : xlenbits = 0;
+
+foreach (i from 0 to (xlen - 1) by 1) {
+ output = if ((rs2_val >> i) & 1)
+ then output ^ (rs1_val >> (xlen - i - 1));
+ else output;
+}
+
+X[rd] = output
+--
+
+.Note
+[NOTE, caption="A" ]
+===============================================================
+The *clmulr* instruction is used to accelerate CRC calculations.
+The *r* in the instruction's mnemonic stands for _reversed_, as the
+instruction is equivalent to bit-reversing the inputs, performing
+a *clmul*, then bit-reversing the output.
+===============================================================
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbc (<<#zbc>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-clz,reftext="Count leading zero bits"]
+==== clz
+
+Synopsis::
+Count leading zero bits
+
+Mnemonic::
+clz _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['CLZ'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 0x0, attr: ['CLZ'] },
+ { bits: 7, name: 0x30, attr: ['CLZ'] },
+]}
+....
+
+Description::
+This instruction counts the number of 0's before the first 1, starting at the most-significant bit (i.e., XLEN-1) and progressing to bit 0. Accordingly, if the input is 0, the output is XLEN, and if the most-significant bit of the input is a 1, the output is 0.
+
+Operation::
+[source,sail]
+--
+val HighestSetBit : forall ('N : Int), 'N >= 0. bits('N) -> int
+
+function HighestSetBit x = {
+ foreach (i from (xlen - 1) to 0 by 1 in dec)
+ if [x[i]] == 0b1 then return(i) else ();
+ return -1;
+}
+
+let rs = X(rs);
+X[rd] = (xlen - 1) - HighestSetBit(rs);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-clzw,reftext="Count leading zero bits in word"]
+==== clzw
+
+Synopsis::
+Count leading zero bits in word
+
+Mnemonic::
+clzw _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x1b, attr: ['OP-IMM-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['CLZW'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 0x0, attr: ['CLZW'] },
+ { bits: 7, name: 0x30, attr: ['CLZW'] },
+]}
+....
+
+Description::
+This instruction counts the number of 0's before the first 1 starting at bit 31 and progressing to bit 0.
+Accordingly, if the least-significant word is 0, the output is 32, and if the most-significant bit of the word (i.e., bit 31) is a 1, the output is 0.
+
+Operation::
+[source,sail]
+--
+val HighestSetBit32 : forall ('N : Int), 'N >= 0. bits('N) -> int
+
+function HighestSetBit32 x = {
+ foreach (i from 31 to 0 by 1 in dec)
+ if [x[i]] == 0b1 then return(i) else ();
+ return -1;
+}
+
+let rs = X(rs);
+X[rd] = 31 - HighestSetBit(rs);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-cpop,reftext="Count set bits"]
+==== cpop
+
+Synopsis::
+Count set bits
+
+Mnemonic::
+cpop _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['CPOP'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 0x2, attr: ['CPOP'] },
+ { bits: 7, name: 0x30, attr: ['CPOP'] },
+]}
+....
+Description::
+This instructions counts the number of 1's (i.e., set bits) in the source register.
+
+Operation::
+[source,sail]
+--
+let bitcount = 0;
+let rs = X(rs);
+
+foreach (i from 0 to (xlen - 1) in inc)
+ if rs[i] == 0b1 then bitcount = bitcount + 1 else ();
+
+X[rd] = bitcount
+--
+
+.Software Hint
+[NOTE, caption="SH" ]
+===============================================================
+This operations is known as population count, popcount, sideways sum, bit summation, or Hamming weight.
+
+The GCC builtin function `+__builtin_popcount (unsigned int x)+` is implemented by cpop on RV32 and by *cpopw* on RV64.
+The GCC builtin function `+__builtin_popcountl (unsigned long x)+` for LP64 is implemented by *cpop* on RV64.
+===============================================================
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-cpopw,reftext="Count set bits in word"]
+==== cpopw
+
+Synopsis::
+Count set bits in word
+
+Mnemonic::
+cpopw _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x1b, attr: ['OP-IMM-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['CPOPW'] },
+ { bits: 5, name: 'rs' },
+ { bits: 5, name: 0x2, attr: ['CPOPW'] },
+ { bits: 7, name: 0x30, attr: ['CPOPW'] },
+]}
+....
+Description::
+This instructions counts the number of 1's (i.e., set bits) in the least-significant word of the source register.
+
+Operation::
+[source,sail]
+--
+let bitcount = 0;
+let val = X(rs);
+
+foreach (i from 0 to 31 in inc)
+ if val[i] == 0b1 then bitcount = bitcount + 1 else ();
+
+X[rd] = bitcount
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-ctz,reftext="Count trailing zero bits"]
+==== ctz
+
+Synopsis::
+Count trailing zeros
+
+Mnemonic::
+ctz _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['CTZ/CTZW'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 0x1, attr: ['CTZ/CTZW'] },
+ { bits: 7, name: 0x30, attr: ['CTZ/CTZW'] },
+]}
+....
+
+Description::
+This instruction counts the number of 0's before the first 1, starting at the least-significant bit (i.e., 0) and progressing to the most-significant bit (i.e., XLEN-1).
+Accordingly, if the input is 0, the output is XLEN, and if the least-significant bit of the input is a 1, the output is 0.
+
+Operation::
+[source,sail]
+--
+val LowestSetBit : forall ('N : Int), 'N >= 0. bits('N) -> int
+
+function LowestSetBit x = {
+ foreach (i from 0 to (xlen - 1) by 1 in dec)
+ if [x[i]] == 0b1 then return(i) else ();
+ return xlen;
+}
+
+let rs = X(rs);
+X[rd] = LowestSetBit(rs);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-ctzw,reftext="Count trailing zero bits in word"]
+==== ctzw
+
+Synopsis::
+Count trailing zero bits in word
+
+Mnemonic::
+ctzw _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x1b, attr: ['OP-IMM-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['CTZ/CTZW'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 0x1, attr: ['CTZ/CTZW'] },
+ { bits: 7, name: 0x30, attr: ['CTZ/CTZW'] },
+]}
+....
+
+Description::
+This instruction counts the number of 0's before the first 1, starting at the least-significant bit (i.e., 0) and progressing to the most-significant bit of the least-significant word (i.e., 31). Accordingly, if the least-significant word is 0, the output is 32, and if the least-significant bit of the input is a 1, the output is 0.
+
+Operation::
+[source,sail]
+--
+val LowestSetBit32 : forall ('N : Int), 'N >= 0. bits('N) -> int
+
+function LowestSetBit32 x = {
+ foreach (i from 0 to 31 by 1 in dec)
+ if [x[i]] == 0b1 then return(i) else ();
+ return 32;
+}
+
+let rs = X(rs);
+X[rd] = LowestSetBit32(rs);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-max,reftext="Maximum"]
+==== max
+
+Synopsis::
+Maximum
+
+Mnemonic::
+max _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x6, attr: ['MAX']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x05, attr: ['MINMAX/CLMUL'] },
+]}
+....
+
+Description::
+This instruction returns the larger of two signed integers.
+
+Operation::
+[source,sail]
+--
+let rs1_val = X(rs1);
+let rs2_val = X(rs2);
+
+let result = if rs1_val <_s rs2_val
+ then rs2_val
+ else rs1_val;
+
+X(rd) = result;
+--
+
+.Software Hint
+[NOTE, caption="SW"]
+===============================================================
+Calculating the absolute value of a signed integer can be performed
+using the following sequence: *neg rD,rS* followed by *max
+rD,rS,rD*. When using this common sequence, it is suggested that they
+are scheduled with no intervening instructions so that
+implementations that are so optimized can fuse them together.
+===============================================================
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-maxu,reftext="Unsigned maximum"]
+==== maxu
+
+Synopsis::
+Unsigned maximum
+
+Mnemonic::
+maxu _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x7, attr: ['MAXU']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x05, attr: ['MINMAX/CLMUL'] },
+]}
+....
+
+Description::
+This instruction returns the larger of two unsigned integers.
+
+Operation::
+[source,sail]
+--
+let rs1_val = X(rs1);
+let rs2_val = X(rs2);
+
+let result = if rs1_val <_u rs2_val
+ then rs2_val
+ else rs1_val;
+
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-min,reftext="Minimum"]
+==== min
+
+Synopsis::
+Minimum
+
+Mnemonic::
+min _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x4, attr: ['MIN']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x05, attr: ['MINMAX/CLMUL'] },
+]}
+....
+
+Description::
+This instruction returns the smaller of two signed integers.
+
+Operation::
+[source,sail]
+--
+let rs1_val = X(rs1);
+let rs2_val = X(rs2);
+
+let result = if rs1_val <_s rs2_val
+ then rs1_val
+ else rs2_val;
+
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-minu,reftext="Unsigned minimum"]
+==== minu
+
+Synopsis::
+Unsigned minimum
+
+Mnemonic::
+minu _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['MINU']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x05, attr: ['MINMAX/CLMUL'] },
+]}
+....
+
+Description::
+This instruction returns the smaller of two unsigned integers.
+
+Operation::
+[source,sail]
+--
+let rs1_val = X(rs1);
+let rs2_val = X(rs2);
+
+let result = if rs1_val <_u rs2_val
+ then rs1_val
+ else rs2_val;
+
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-orc_b,reftext="Bitwise OR-Combine, byte granule"]
+==== orc.b
+
+Synopsis::
+Bitwise OR-Combine, byte granule
+
+Mnemonic::
+orc.b _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5 },
+ { bits: 5, name: 'rs' },
+ { bits: 12, name: 0x287 }
+]}
+....
+
+Description::
+Combines the bits within each byte using bitwise logical OR.
+This sets the bits of each byte in the result _rd_ to all zeros if no bit within the respective byte of _rs_ is set, or to all ones if any bit within the respective byte of _rs_ is set.
+
+Operation::
+[source,sail]
+--
+let input = X(rs);
+let output : xlenbits = 0;
+
+foreach (i from 0 to (xlen - 8) by 8) {
+ output[(i + 7)..i] = if input[(i + 7)..i] == 0
+ then 0b00000000
+ else 0b11111111;
+}
+
+X[rd] = output;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-orn,reftext="OR with inverted operand"]
+==== orn
+
+Synopsis::
+OR with inverted operand
+
+Mnemonic::
+orn _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x6, attr: ['ORN']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x20, attr: ['ORN'] },
+]}
+....
+
+Description::
+This instruction performs the bitwise logical OR operation between _rs1_ and the bitwise inversion of _rs2_.
+
+Operation::
+[source,sail]
+--
+X(rd) = X(rs1) | ~X(rs2);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-pack,reftext="Pack low halves of registers"]
+==== pack
+
+Synopsis::
+Pack the low halves of _rs1_ and _rs2_ into _rd_.
+
+Mnemonic::
+pack _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ {bits: 7, name: 0x33, attr: ['OP'] },
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 0x4, attr:['PACK']},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'rs2'},
+ {bits: 7, name: 0x4, attr:['PACK']},
+]}
+....
+
+Description::
+The pack instruction packs the XLEN/2-bit lower halves of _rs1_ and _rs2_ into
+_rd_, with _rs1_ in the lower half and _rs2_ in the upper half.
+
+Operation::
+[source,sail]
+--
+let lo_half : bits(xlen/2) = X(rs1)[xlen/2-1..0];
+let hi_half : bits(xlen/2) = X(rs2)[xlen/2-1..0];
+X(rd) = EXTZ(hi_half @ lo_half);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+NOTE: For RV32, the `pack` instruction with _rs2_=`x0` is the `zext.h`
+instruction.
+Hence, for RV32, any extension that contains the `pack` instruction also
+contains the `zext.h` instruction (but not necessarily the `c.zext.h`
+instruction, which is only guaranteed to exist if both the Zcb and Zbb
+extensions are implemented).
+
+<<<
+[#insns-packh,reftext="Pack low bytes of registers"]
+==== packh
+
+Synopsis::
+Pack the low bytes of _rs1_ and _rs2_ into _rd_.
+
+Mnemonic::
+packh _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ {bits: 7, name: 0x33, attr: ['OP'] },
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 0x7, attr: ['PACKH']},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'rs2'},
+ {bits: 7, name: 0x4, attr: ['PACKH']},
+]}
+....
+
+Description::
+The packh instruction packs the least-significant bytes of
+_rs1_ and _rs2_ into the 16 least-significant bits of _rd_,
+zero extending the rest of _rd_.
+
+Operation::
+[source,sail]
+--
+let lo_half : bits(8) = X(rs1)[7..0];
+let hi_half : bits(8) = X(rs2)[7..0];
+X(rd) = EXTZ(hi_half @ lo_half);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-packw,reftext="Pack low 16-bits of registers (RV64)"]
+==== packw
+
+Synopsis::
+Pack the low 16-bits of _rs1_ and _rs2_ into _rd_ on RV64.
+
+Mnemonic::
+packw _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x3b, attr: ['OP-32']},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x4},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 7, name: 0x4},
+]}
+....
+
+Description::
+This instruction packs the low 16 bits of
+_rs1_ and _rs2_ into the 32 least-significant bits of _rd_,
+sign extending the 32-bit result to the rest of _rd_.
+This instruction only exists on RV64 based systems.
+
+Operation::
+[source,sail]
+--
+let lo_half : bits(16) = X(rs1)[15..0];
+let hi_half : bits(16) = X(rs2)[15..0];
+X(rd) = EXTS(hi_half @ lo_half);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+NOTE: For RV64, the `packw` instruction with _rs2_=`x0` is the `zext.h`
+instruction.
+Hence, for RV64, any extension that contains the `packw` instruction also
+contains the `zext.h` instruction (but not necessarily the `c.zext.h`
+instruction, which is only guaranteed to exist if both the Zcb and Zbb
+extensions are implemented).
+
+<<<
+[#insns-rev8,reftext="Byte-reverse register"]
+==== rev8
+
+Synopsis::
+Byte-reverse register
+
+Mnemonic::
+rev8 _rd_, _rs_
+
+Encoding (RV32)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5 },
+ { bits: 5, name: 'rs' },
+ { bits: 12, name: 0x698 }
+]}
+....
+
+Encoding (RV64)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5 },
+ { bits: 5, name: 'rs' },
+ { bits: 12, name: 0x6b8 }
+]}
+....
+
+Description::
+This instruction reverses the order of the bytes in _rs_.
+
+Operation::
+[source,sail]
+--
+let input = X(rs);
+let output : xlenbits = 0;
+let j = xlen - 1;
+
+foreach (i from 0 to (xlen - 8) by 8) {
+ output[i..(i + 7)] = input[(j - 7)..j];
+ j = j - 8;
+}
+
+X[rd] = output
+--
+
+.Note
+[NOTE, caption="A" ]
+===============================================================
+The *rev8* mnemonic corresponds to different instruction encodings in RV32 and RV64.
+===============================================================
+
+.Software Hint
+[NOTE, caption="SH" ]
+===============================================================
+The byte-reverse operation is only available for the full register
+width. To emulate word-sized and halfword-sized byte-reversal,
+perform a `rev8 rd,rs` followed by a `srai rd,rd,K`, where K is
+XLEN-32 and XLEN-16, respectively.
+===============================================================
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0
+|Ratified
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-brev8,reftext="Reverse bits in bytes"]
+==== brev8
+
+Synopsis::
+Reverse the bits in each byte of a source register.
+
+Mnemonic::
+brev8 _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5 },
+ { bits: 5, name: 'rs' },
+ { bits: 12, name: 0x687 }
+]}
+....
+
+Description::
+This instruction reverses the order of the bits in every byte of a register.
+
+Operation::
+[source,sail]
+--
+result : xlenbits = EXTZ(0b0);
+foreach (i from 0 to sizeof(xlen) by 8) {
+ result[i+7..i] = reverse_bits_in_byte(X(rs1)[i+7..i]);
+};
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-rol,reftext="Rotate left (Register)"]
+==== rol
+
+Synopsis::
+Rotate Left (Register)
+
+Mnemonic::
+rol _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['ROL']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x30, attr: ['ROL'] },
+]}
+....
+
+Description::
+This instruction performs a rotate left of _rs1_ by the amount in least-significant log2(XLEN) bits of _rs2_.
+
+Operation::
+[source,sail]
+--
+let shamt = if xlen == 32
+ then X(rs2)[4..0]
+ else X(rs2)[5..0];
+let result = (X(rs1) << shamt) | (X(rs1) >> (xlen - shamt));
+
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|0.93
+|Ratified
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-rolw,reftext="Rotate Left Word (Register)"]
+==== rolw
+
+Synopsis::
+Rotate Left Word (Register)
+
+Mnemonic::
+rolw _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x3b, attr: ['OP-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['ROLW']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x30, attr: ['ROLW'] },
+]}
+....
+
+Description::
+This instruction performs a rotate left on the least-significant word of _rs1_ by the amount in least-significant 5 bits of _rs2_.
+The resulting word value is sign-extended by copying bit 31 to all of the more-significant bits.
+
+Operation::
+[source,sail]
+--
+let rs1 = EXTZ(X(rs1)[31..0])
+let shamt = X(rs2)[4..0];
+let result = (rs1 << shamt) | (rs1 >> (32 - shamt));
+X(rd) = EXTS(result[31..0]);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|0.93
+|Ratified
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-ror,reftext="Rotate right (Register)"]
+==== ror
+
+Synopsis::
+Rotate Right
+
+Mnemonic::
+ror _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['ROR']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x30, attr: ['ROR'] },
+]}
+....
+
+Description::
+This instruction performs a rotate right of _rs1_ by the amount in least-significant log2(XLEN) bits of _rs2_.
+
+Operation::
+[source,sail]
+--
+let shamt = if xlen == 32
+ then X(rs2)[4..0]
+ else X(rs2)[5..0];
+let result = (X(rs1) >> shamt) | (X(rs1) << (xlen - shamt));
+
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|0.93
+|Ratified
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-rori,reftext="Rotate right (Immediate)"]
+==== rori
+
+Synopsis::
+Rotate Right (Immediate)
+
+Mnemonic::
+rori _rd_, _rs1_, _shamt_
+
+Encoding (RV32)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['RORI']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'shamt' },
+ { bits: 7, name: 0x30, attr: ['RORI'] },
+]}
+....
+
+Encoding (RV64)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['RORI']},
+ { bits: 5, name: 'rs1' },
+ { bits: 6, name: 'shamt' },
+ { bits: 6, name: 0x18, attr: ['RORI'] },
+]}
+....
+
+Description::
+This instruction performs a rotate right of _rs1_ by the amount in the least-significant log2(XLEN) bits of _shamt_.
+For RV32, the encodings corresponding to shamt[5]=1 are reserved.
+
+Operation::
+[source,sail]
+--
+let shamt = if xlen == 32
+ then shamt[4..0]
+ else shamt[5..0];
+let result = (X(rs1) >> shamt) | (X(rs1) << (xlen - shamt));
+
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|0.93
+|Ratified
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-roriw,reftext="Rotate right Word (Immediate)"]
+==== roriw
+
+Synopsis::
+Rotate Right Word by Immediate
+
+Mnemonic::
+roriw _rd_, _rs1_, _shamt_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x1b, attr: ['OP-IMM-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['RORIW']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'shamt' },
+ { bits: 7, name: 0x30, attr: ['RORIW'] },
+]}
+....
+
+Description::
+This instruction performs a rotate right on the least-significant word
+of _rs1_ by the amount in the least-significant log2(XLEN) bits of
+_shamt_.
+The resulting word value is sign-extended by copying bit 31 to all of
+the more-significant bits.
+
+
+Operation::
+[source,sail]
+--
+let rs1_data = EXTZ(X(rs1)[31..0];
+let result = (rs1_data >> shamt) | (rs1_data << (32 - shamt));
+X(rd) = EXTS(result[31..0]);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|0.93
+|Ratified
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-rorw,reftext="Rotate right Word (Register)"]
+==== rorw
+
+Synopsis::
+Rotate Right Word (Register)
+
+Mnemonic::
+rorw _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x3b, attr: ['OP-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['RORW']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x30, attr: ['RORW'] },
+]}
+....
+
+Description::
+This instruction performs a rotate right on the least-significant word of _rs1_ by the amount in least-significant 5 bits of _rs2_.
+The resultant word is sign-extended by copying bit 31 to all of the more-significant bits.
+
+Operation::
+[source,sail]
+--
+let rs1 = EXTZ(X(rs1)[31..0])
+let shamt = X(rs2)[4..0];
+let result = (rs1 >> shamt) | (rs1 << (32 - shamt));
+X(rd) = EXTS(result);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|0.93
+|Ratified
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-sext_b,reftext="Sign-extend byte"]
+==== sext.b
+
+Synopsis::
+Sign-extend byte
+
+Mnemonic::
+sext.b _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['SEXT.B/SEXT.H'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 0x04, attr: ['SEXT.B'] },
+ { bits: 7, name: 0x30 },
+]}
+....
+
+Description::
+This instruction sign-extends the least-significant byte in the source to XLEN by copying the most-significant bit in the byte (i.e., bit 7) to all of the more-significant bits.
+
+Operation::
+[source,sail]
+--
+X(rd) = EXTS(X(rs)[7..0]);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|0.93
+|Ratified
+|===
+
+<<<
+[#insns-sext_h,reftext="Sign-extend halfword"]
+==== sext.h
+
+Synopsis::
+Sign-extend halfword
+
+Mnemonic::
+sext.h _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['SEXT.B/SEXT.H'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 0x05, attr: ['SEXT.H'] },
+ { bits: 7, name: 0x30 },
+]}
+....
+
+Description::
+This instruction sign-extends the least-significant halfword in _rs_ to XLEN by copying the most-significant bit in the halfword (i.e., bit 15) to all of the more-significant bits.
+
+Operation::
+[source,sail]
+--
+X(rd) = EXTS(X(rs)[15..0]);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|0.93
+|Ratified
+|===
+
+
+<<<
+[#insns-sh1add,reftext=Shift left by 1 and add]
+==== sh1add
+
+Synopsis::
+Shift left by 1 and add
+
+Mnemonic::
+sh1add _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x2, attr: ['SH1ADD'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x10, attr: ['SH1ADD'] },
+]}
+....
+
+Description::
+This instruction shifts _rs1_ to the left by 1 bit and adds it to _rs2_.
+
+Operation::
+[source,sail]
+--
+X(rd) = X(rs2) + (X(rs1) << 1);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zba (<<#zba>>)
+|0.93
+|Ratified
+|===
+
+// We have decided that this and all other instructions will not have reserved encodings for "useless encodings"
+// We could follow suit of the base ISA and create HINTs if there is some recognized value for doing so
+
+<<<
+[#insns-sh1add_uw,reftext=Shift unsigned word left by 1 and add]
+==== sh1add.uw
+
+Synopsis::
+Shift unsigned word left by 1 and add
+
+Mnemonic::
+sh1add.uw _rd_, _rs1_, _rs2_
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x3b, attr: ['OP-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x2, attr: ['SH1ADD.UW'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x10, attr: ['SH1ADD.UW'] },
+]}
+....
+
+Description::
+This instruction performs an XLEN-wide addition of two addends.
+The first addend is _rs2_. The second addend is the unsigned value formed by extracting the least-significant word of _rs1_ and shifting it left by 1 place.
+
+Operation::
+[source,sail]
+--
+let base = X(rs2);
+let index = EXTZ(X(rs1)[31..0]);
+
+X(rd) = base + (index << 1);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zba (<<#zba>>)
+|0.93
+|Ratified
+|===
+
+<<<
+[#insns-sh2add,reftext=Shift left by 2 and add]
+==== sh2add
+
+Synopsis::
+Shift left by 2 and add
+
+Mnemonic::
+sh2add _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x4, attr: ['SH2ADD'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x10, attr: ['SH2ADD'] },
+]}
+....
+
+Description::
+This instruction shifts _rs1_ to the left by 2 places and adds it to _rs2_.
+
+Operation::
+[source,sail]
+--
+X(rd) = X(rs2) + (X(rs1) << 2);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zba (<<#zba>>)
+|0.93
+|Ratified
+|===
+
+<<<
+[#insns-sh2add_uw,reftext=Shift unsigned word left by 2 and add]
+==== sh2add.uw
+
+Synopsis::
+Shift unsigned word left by 2 and add
+
+Mnemonic::
+sh2add.uw _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x3b, attr: ['OP-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x4, attr: ['SH2ADD.UW'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x10, attr: ['SH2ADD.UW'] },
+]}
+....
+
+Description::
+This instruction performs an XLEN-wide addition of two addends.
+The first addend is _rs2_.
+The second addend is the unsigned value formed by extracting the least-significant word of _rs1_ and shifting it left by 2 places.
+
+Operation::
+[source,sail]
+--
+let base = X(rs2);
+let index = EXTZ(X(rs1)[31..0]);
+
+X(rd) = base + (index << 2);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zba (<<#zba>>)
+|0.93
+|Ratified
+|===
+
+<<<
+[#insns-sh3add,reftext=Shift left by 3 and add]
+==== sh3add
+
+Synopsis::
+Shift left by 3 and add
+
+Mnemonic::
+sh3add _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x6, attr: ['SH3ADD'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x10, attr: ['SH3ADD'] },
+]}
+....
+
+Description::
+This instruction shifts _rs1_ to the left by 3 places and adds it to _rs2_.
+
+Operation::
+[source,sail]
+--
+X(rd) = X(rs2) + (X(rs1) << 3);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zba (<<#zba>>)
+|0.93
+|Ratified
+|===
+
+<<<
+[#insns-sh3add_uw,reftext=Shift unsigned word left by 3 and add]
+==== sh3add.uw
+
+Synopsis::
+Shift unsigned word left by 3 and add
+
+Mnemonic::
+sh3add.uw _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x3b, attr: ['OP-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x6, attr: ['SH3ADD.UW'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x10, attr: ['SH3ADD.UW'] },
+]}
+....
+
+Description::
+This instruction performs an XLEN-wide addition of two addends. The first addend is _rs2_. The second addend is the unsigned value formed by extracting the least-significant word of _rs1_ and shifting it left by 3 places.
+
+Operation::
+[source,sail]
+--
+let base = X(rs2);
+let index = EXTZ(X(rs1)[31..0]);
+
+X(rd) = base + (index << 3);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zba (<<#zba>>)
+|0.93
+|Ratified
+|===
+
+<<<
+[#insns-slli_uw,reftext="Shift-left unsigned word (Immediate)"]
+==== slli.uw
+
+Synopsis::
+Shift-left unsigned word (Immediate)
+
+Mnemonic::
+slli.uw _rd_, _rs1_, _shamt_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x1b, attr: ['OP-IMM-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['SLLI.UW'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 6, name: 'shamt' },
+ { bits: 6, name: 0x02, attr: ['SLLI.UW'] },
+]}
+....
+
+Description::
+This instruction takes the least-significant word of _rs1_, zero-extends it, and shifts it left by the immediate.
+
+Operation::
+[source,sail]
+--
+X(rd) = (EXTZ(X(rs)[31..0]) << shamt);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zba (<<#zba>>)
+|0.93
+|Ratified
+|===
+
+.Architecture Explanation
+[NOTE, caption="A" ]
+===============================================================
+This instruction is the same as *slli* with *zext.w* performed on _rs1_ before shifting.
+===============================================================
+
+<<<
+[#insns-unzip,reftext="Bit deinterleave"]
+==== unzip
+
+Synopsis::
+Place odd and even bits of the source register into upper and lower halves of
+the destination register, respectively.
+
+Mnemonic::
+unzip _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13, attr: ['OP-IMM']},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x5},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0xf},
+{bits: 7, name: 0x4},
+]}
+....
+
+Description::
+This instruction scatters all of the odd and even bits of a source word into
+the high and low halves of a destination word.
+It is the inverse of the <<insns-zip-sc,zip>> instruction.
+This instruction is available only on RV32.
+
+Operation::
+[source,sail]
+--
+foreach (i from 0 to xlen/2-1) {
+ X(rd)[i] = X(rs1)[2*i]
+ X(rd)[i+xlen/2] = X(rs1)[2*i+1]
+}
+--
+
+.Software Hint
+[NOTE, caption="SH" ]
+===============================================================
+This instruction is useful for implementing the SHA3 cryptographic
+hash function on a 32-bit architecture, as it implements the
+bit-interleaving operation used to speed up the 64-bit rotations
+directly.
+===============================================================
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb>>) (RV32)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-xnor,reftext="Exclusive NOR"]
+==== xnor
+
+Synopsis::
+Exclusive NOR
+
+Mnemonic::
+xnor _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x4, attr: ['XNOR']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x20, attr: ['XNOR'] },
+]}
+....
+
+Description::
+This instruction performs the bit-wise exclusive-NOR operation on _rs1_ and _rs2_.
+
+Operation::
+[source,sail]
+--
+X(rd) = ~(X(rs1) ^ X(rs2));
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|0.93
+|Ratified
+
+|Zbkb (<<#zbkb>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-xperm8,reftext="Crossbar permutation (bytes)"]
+==== xperm8
+
+Synopsis::
+Byte-wise lookup of indices into a vector in registers.
+
+Mnemonic::
+xperm8 _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33, attr: ['OP'] },
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x4},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 7, name: 0x14},
+]}
+....
+
+Description::
+The xperm8 instruction operates on bytes.
+The _rs1_ register contains a vector of XLEN/8 8-bit elements.
+The _rs2_ register contains a vector of XLEN/8 8-bit indexes.
+The result is each element in _rs2_ replaced by the indexed element in _rs1_,
+or zero if the index into _rs2_ is out of bounds.
+
+Operation::
+[source,sail]
+--
+val xperm8_lookup : (bits(8), xlenbits) -> bits(8)
+function xperm8_lookup (idx, lut) = {
+ (lut >> (idx @ 0b000))[7..0]
+}
+
+function clause execute ( XPERM8 (rs2,rs1,rd)) = {
+ result : xlenbits = EXTZ(0b0);
+ foreach(i from 0 to xlen by 8) {
+ result[i+7..i] = xperm8_lookup(X(rs2)[i+7..i], X(rs1));
+ };
+ X(rd) = result;
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkx (<<#zbkx>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-xperm4,reftext="Crossbar permutation (nibbles)"]
+==== xperm4
+
+Synopsis::
+Nibble-wise lookup of indices into a vector.
+
+Mnemonic::
+xperm4 _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33, attr: ['OP'] },
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x2},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 7, name: 0x14},
+]}
+....
+
+Description::
+The xperm4 instruction operates on nibbles.
+The _rs1_ register contains a vector of XLEN/4 4-bit elements.
+The _rs2_ register contains a vector of XLEN/4 4-bit indexes.
+The result is each element in _rs2_ replaced by the indexed element in _rs1_,
+or zero if the index into _rs2_ is out of bounds.
+
+Operation::
+[source,sail]
+--
+val xperm4_lookup : (bits(4), xlenbits) -> bits(4)
+function xperm4_lookup (idx, lut) = {
+ (lut >> (idx @ 0b00))[3..0]
+}
+
+function clause execute ( XPERM4 (rs2,rs1,rd)) = {
+ result : xlenbits = EXTZ(0b0);
+ foreach(i from 0 to xlen by 4) {
+ result[i+3..i] = xperm4_lookup(X(rs2)[i+3..i], X(rs1));
+ };
+ X(rd) = result;
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkx (<<#zbkx>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+[#insns-zext_h,reftext="Zero-extend halfword"]
+==== zext.h
+
+Synopsis::
+Zero-extend halfword
+
+Mnemonic::
+zext.h _rd_, _rs_
+
+Encoding (RV32)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x4, attr: ['ZEXT.H']},
+ { bits: 5, name: 'rs' },
+ { bits: 5, name: 0x00 },
+ { bits: 7, name: 0x04 },
+]}
+....
+
+Encoding (RV64)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x3b, attr: ['OP-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x4, attr: ['ZEXT.H']},
+ { bits: 5, name: 'rs' },
+ { bits: 5, name: 0x00 },
+ { bits: 7, name: 0x04 },
+]}
+....
+
+Description::
+This instruction zero-extends the least-significant halfword of the source to XLEN by inserting 0's into all of the bits more significant than 15.
+
+Operation::
+[source,sail]
+--
+X(rd) = EXTZ(X(rs)[15..0]);
+--
+
+.Note
+[NOTE, caption="A" ]
+===============================================================
+The *zext.h* mnemonic corresponds to different instruction encodings in RV32 and RV64.
+===============================================================
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|0.93
+|Ratified
+|===
+
+<<<
+[#insns-zip,reftext="Bit interleave"]
+==== zip
+
+Synopsis::
+Interleave upper and lower halves of the source register into odd and even
+bits of the destination register, respectively.
+
+Mnemonic::
+zip _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13, attr: ['OP-IMM']},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0xf},
+{bits: 7, name: 0x4},
+]}
+....
+
+Description::
+This instruction gathers bits from the high and low halves of the source
+word into odd/even bit positions in the destination word.
+It is the inverse of the <<insns-unzip-sc,unzip>> instruction.
+This instruction is available only on RV32.
+
+Operation::
+[source,sail]
+--
+foreach (i from 0 to xlen/2-1) {
+ X(rd)[2*i] = X(rs1)[i]
+ X(rd)[2*i+1] = X(rs1)[i+xlen/2]
+}
+--
+
+.Software Hint
+[NOTE, caption="SH" ]
+===============================================================
+This instruction is useful for implementing the SHA3 cryptographic
+hash function on a 32-bit architecture, as it implements the
+bit-interleaving operation used to speed up the 64-bit rotations
+directly.
+===============================================================
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb>>) (RV32)
+|v1.0
+|Ratified
+|===
+
+
+=== Software optimization guide
+
+==== strlen
+
+The *orc.b* instruction allows for the efficient detection of *NUL* bytes in an XLEN-sized chunk of data:
+
+ * the result of *orc.b* on a chunk that does not contain any *NUL* bytes will be all-ones, and
+ * after a bitwise-negation of the result of *orc.b*, the number of data bytes before the first *NUL* byte (if any) can be detected by *ctz*/*clz* (depending on the endianness of data).
+
+A full example of a *strlen* function, which uses these techniques and also demonstrates the use of it for unaligned/partial data, is the following:
+
+[source,asm]
+--
+#include <sys/asm.h>
+
+ .text
+ .globl strlen
+ .type strlen, @function
+strlen:
+ andi a3, a0, (SZREG-1) // offset
+ andi a1, a0, -SZREG // align pointer
+.Lprologue:
+ li a4, SZREG
+ sub a4, a4, a3 // XLEN - offset
+ slli a3, a3, 3 // offset * 8
+ REG_L a2, 0(a1) // chunk
+ /*
+ * Shift the partial/unaligned chunk we loaded to remove the bytes
+ * from before the start of the string, adding NUL bytes at the end.
+ */
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ srl a2, a2 ,a3 // chunk >> (offset * 8)
+#else
+ sll a2, a2, a3
+#endif
+ orc.b a2, a2
+ not a2, a2
+ /*
+ * Non-NUL bytes in the string have been expanded to 0x00, while
+ * NUL bytes have become 0xff. Search for the first set bit
+ * (corresponding to a NUL byte in the original chunk).
+ */
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ ctz a2, a2
+#else
+ clz a2, a2
+#endif
+ /*
+ * The first chunk is special: compare against the number of valid
+ * bytes in this chunk.
+ */
+ srli a0, a2, 3
+ bgtu a4, a0, .Ldone
+ addi a3, a1, SZREG
+ li a4, -1
+ .align 2
+ /*
+ * Our critical loop is 4 instructions and processes data in 4 byte
+ * or 8 byte chunks.
+ */
+.Lloop:
+ REG_L a2, SZREG(a1)
+ addi a1, a1, SZREG
+ orc.b a2, a2
+ beq a2, a4, .Lloop
+
+.Lepilogue:
+ not a2, a2
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ ctz a2, a2
+#else
+ clz a2, a2
+#endif
+ sub a1, a1, a3
+ add a0, a0, a1
+ srli a2, a2, 3
+ add a0, a0, a2
+.Ldone:
+ ret
+--
+
+==== strcmp
+
+[source,asm]
+--
+#include <sys/asm.h>
+
+ .text
+ .globl strcmp
+ .type strcmp, @function
+strcmp:
+ or a4, a0, a1
+ li t2, -1
+ and a4, a4, SZREG-1
+ bnez a4, .Lsimpleloop
+
+ # Main loop for aligned strings
+.Lloop:
+ REG_L a2, 0(a0)
+ REG_L a3, 0(a1)
+ orc.b t0, a2
+ bne t0, t2, .Lfoundnull
+ addi a0, a0, SZREG
+ addi a1, a1, SZREG
+ beq a2, a3, .Lloop
+
+ # Words don't match, and no null byte in first word.
+ # Get bytes in big-endian order and compare.
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ rev8 a2, a2
+ rev8 a3, a3
+#endif
+ # Synthesize (a2 >= a3) ? 1 : -1 in a branchless sequence.
+ sltu a0, a2, a3
+ neg a0, a0
+ ori a0, a0, 1
+ ret
+
+.Lfoundnull:
+ # Found a null byte.
+ # If words don't match, fall back to simple loop.
+ bne a2, a3, .Lsimpleloop
+
+ # Otherwise, strings are equal.
+ li a0, 0
+ ret
+
+ # Simple loop for misaligned strings
+.Lsimpleloop:
+ lbu a2, 0(a0)
+ lbu a3, 0(a1)
+ addi a0, a0, 1
+ addi a1, a1, 1
+ bne a2, a3, 1f
+ bnez a2, .Lsimpleloop
+
+1:
+ sub a0, a2, a3
+ ret
+
+.size strcmp, .-strcmp
+--
diff --git a/src/b.tex b/src/b.tex
deleted file mode 100644
index 0951df4..0000000
--- a/src/b.tex
+++ /dev/null
@@ -1,19 +0,0 @@
-\chapter{``B'' Standard Extension for Bit Manipulation, Version 0.0}
-\label{sec:bits}
-
-This chapter is a placeholder for a future standard extension to
-provide bit manipulation instructions, including instructions to
-insert, extract, and test bit fields, and for rotations, funnel
-shifts, and bit and byte permutations.
-
-\begin{commentary}
-Although bit manipulation instructions are very effective in some
-application domains, particularly when dealing with externally packed
-data structures, we excluded them from the base ISA as they are not
-useful in all domains and can add additional complexity or instruction
-formats to supply all needed operands.
-
-We anticipate the B extension will be a brownfield encoding within the
-base 30-bit instruction space.
-\end{commentary}
-
diff --git a/src/bfloat16.adoc b/src/bfloat16.adoc
new file mode 100644
index 0000000..c50efcd
--- /dev/null
+++ b/src/bfloat16.adoc
@@ -0,0 +1,780 @@
+[[bf16]]
+== "BF16" Extensions for BFloat16-precision Floating-Point, Version 1.0
+
+[[BF16_introduction]]
+=== Introduction
+
+When FP16 (officially called binary16) was first introduced by the IEEE-754 standard,
+it was just an interchange format. It was intended as a space/bandwidth efficient
+encoding that would be used to transfer information. This is in line with the Zfhmin
+extension.
+
+However, there were some applications (notably graphics) that found that the smaller
+precision and dynamic range was sufficient for their space. So, FP16 started to see
+some widespread adoption as an arithmetic format. This is in line with
+the Zfh extension.
+
+While it was not the intention of '754 to have FP16 be an arithmetic format, it is
+supported by the standard. Even though the '754 committee recognized that FP16 was
+gaining popularity, the committee decided to hold off on making it a basic format
+in the 2019 release. This means that a '754 compliant implementation of binary
+floating point, which needs to support at least one basic format, cannot support
+only FP16 - it needs to support at least one of binary32, binary64, and binary128.
+
+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.
+The final computations were then typically converted back into the more compact FP16
+encoding. This approach has become very common in machine learning
+(ML) inference where the weights and
+activations are stored in FP16 encodings. There was the added benefit that smaller
+multiplication blocks could be created for the FP16's smaller number of significant bits. At this
+point, widening multiply-accumulate instructions became much more common. Also, more
+complicated dot product instructions started to show up including those that packed two
+FP16 numbers in a 32-bit register, multiplied these by another pair of FP16 numbers in
+another register, added these two products to an FP32 accumulate value in a 3rd register
+and returned an FP32 result.
+
+Experts working in machine learning at Google who continued to work with FP32 values
+noted that the least significant 16 bits of their mantissas were not always needed
+for good results, even in training. They proposed a truncated version of FP32, which was
+the 16 most significant bits of the FP32 encoding. This format was named BFloat16
+(or BF16). The B in BF16, stands for Brain since it was initially introduced
+by the Google Brain team. Not only did they find that the number of
+significant bits in BF16 tended to be sufficient for their work (despite being fewer than
+in FP16), but it was very easy for them to reuse their existing data; FP32 numbers could
+be readily rounded to BF16 with a minimal amount of work. Furthermore, the even smaller
+number of the BF16 significant bits enabled even smaller
+multiplication blocks to be built. Similar
+to FP16, BF16 multiply-accumulate widening and dot-product instructions started to
+proliferate.
+
+// include::riscv-bfloat16-audience.adoc[]
+[[BF16_audience]]
+=== Intended Audience
+Floating-point arithmetic is a specialized subject, requiring people with many different
+backgrounds to cooperate in its correct and efficient implementation.
+Where possible, we have written this specification to be understandable by
+all, though we recognize that the motivations and references to
+algorithms or other specifications and standards may be unfamiliar to those
+who are not domain experts.
+
+This specification anticipates being read and acted on by various people
+with different backgrounds.
+We have tried to capture these backgrounds
+here, with a brief explanation of what we expect them to know, and how
+it relates to the specification.
+We hope this aids people's understanding of which aspects of the specification
+are particularly relevant to them, and which they may (safely!) ignore or
+pass to a colleague.
+
+Software developers::
+These are the people we expect to write code using the instructions
+in this specification.
+They should understand the motivations for the
+instructions we include, and be familiar with most of the algorithms
+and outside standards to which we refer.
+
+Computer architects::
+We expect architects to have some basic floating-point background.
+Furthermore, we expect architects to be able to examine our instructions
+for implementation issues, understand how the instructions will be used
+in context, and advise on how they best to fit the functionality.
+
+Digital design engineers & micro-architects::
+These are the people who will implement the specification inside a
+core. Floating-point expertise is assumed as not all of the corner
+cases are pointed out in the specification.
+
+Verification engineers::
+Responsible for ensuring the correct implementation of the extension
+in hardware. These people are expected to have some floating-point
+expertise so that they can identify and generate the interesting corner
+cases --- include exceptions --- that are common in floating-point
+architectures and implementations.
+
+
+These are by no means the only people concerned with the specification,
+but they are the ones we considered most while writing it.
+
+[[BF16_format]]
+=== Number Format
+
+==== BF16 Operand Format
+
+BF16 bits::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'frac'},
+{bits: 8, name: 'expo'},
+{bits: 1, name: 'S'},
+]}
+....
+
+IEEE Compliance: While BF16 (also known as BFloat16) is not an IEEE-754 _standard_ format, it is a valid
+floating-point format as defined by IEEE-754.
+There are three parameters that specify a format: radix (b), number of digits in the significand (p),
+and maximum exponent (emax).
+For BF16 these values are:
+
+[%autowidth]
+.BF16 parameters
+[cols = "2,1"]
+|===
+| Parameter | Value
+|radix (b)|2
+|significand (p)|8
+|emax|127
+|===
+
+
+[%autowidth]
+.Obligatory Floating Point Format Table
+[cols = "1,1,1,1,1,1,1,1"]
+|===
+|Format|Sign Bits|Expo Bits|fraction bits|padded 0s|encoding bits|expo max/bias|expo min
+
+|FP16 |1| 5|10| 0|16| 15| -14
+|BF16|1| 8| 7| 0|16| 127|-126
+|TF32 |1| 8|10|13|32| 127|-126
+|FP32 |1| 8|23| 0|32| 127|-126
+|FP64 |1|11|52| 0|64|1023|-1022
+|FP128 |1|15|112|0|128|16,383|-16,382
+|===
+
+==== BF16 Behavior
+
+For these BF16 extensions, instruction behavior on BF16 operands is the same as for other floating-point
+instructions in the RISC-V ISA. For easy reference, some of this behavior is repeated here.
+
+===== Subnormal Numbers:
+Floating-point values that are too small to be represented as normal numbers, but can still be expressed
+by the format's smallest exponent value with a "0" integer bit and at least one "1" bit
+in the trailing fractional bits are called subnormal numbers. Basically, the idea is there is
+a trade off of precision to support _gradual underflow_.
+
+All of the BF16 instructions in the extensions defined in this specification (i.e., Zfbfmin, Zvfbfmin,
+and Zvfbfwma) fully support subnormal numbers. That is, instructions are able to accept subnormal values as
+inputs and they can produce subnormal results.
+
+
+[NOTE]
+====
+Future floating-point extensions, including those that operate on BF16 values, may chose not to support subnormal numbers.
+The comments about supporting subnormal BF16 values are limited to those instructions defined in this specification.
+====
+
+===== Infinities:
+Infinities are used to represent values that are too large to be represented by the target format.
+These are usually produced as a result of overflows (depending on the rounding mode), but can also
+be provided as inputs. Infinities have a sign associated with them: there are positive infinities and negative infinities.
+
+Infinities are important for keeping meaningless results from being operated upon.
+
+===== NaNs
+
+NaN stands for Not a Number.
+
+There are two types of NaNs: signalling (sNaN) and quiet (qNaN). No computational
+instruction will ever produce an sNaN; These are only provided as input data. Operating on an sNaN will cause
+an invalid operation exception. Operating on a Quiet NaN usually does not cause an exception.
+
+QNaNs 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 qNaN because
+there is no real number that can represent the result. NaNs can also be used as inputs.
+
+NaNs include a sign bit, but the bit has no meaning.
+
+NaNs are important for keeping meaningless results from being operated upon.
+
+Except where otherwise explicitly stated, when the result of a floating-point operation is a qNaN, it
+is the RISC-V canonical NaN. For BF16, the RISC-V canonical NaN corresponds to the pattern of _0x7fc0_ which
+is the most significant 16 bits of the RISC-V single-precision canonical NaN.
+
+===== Scalar NaN Boxing
+
+RISC-V applies NaN boxing to scalar results and checks for NaN boxing when a floating-point operation
+--- even a vector-scalar operation --- consumes a value from a scalar floating-point register.
+If the value is properly NaN-boxed, its least significant bits are used as the operand, otherwise
+it is treated as if it were the canonical QNaN.
+
+NaN boxing is nothing more than putting the smaller encoding in the least significant bits of a register
+and setting all of the more significant bits to “1”. This matches the encoding of a qNaN (although
+not the canonical NaN) in the larger precision.
+
+Nan-boxing never affects the value of the operand itself, it just changes the bits of the register that
+are more significant than the operand's most significant bit.
+
+
+===== Rounding Modes:
+
+As is the case with other floating-point instructions,
+the BF16 instructions support all 5 RISC-V Floating-point rounding modes.
+These modes can be specified in the `rm` field of scalar instructions
+as well as in the `frm` CSR
+
+[%autowidth]
+.RISC-V Floating Point Rounding Modes
+[cols = "1,1,1"]
+|===
+|Rounding Mode | Mnemonic | Meaning
+| 000 | RNE | Round to Nearest, ties to Even
+| 001 | RTZ | Round towards Zero
+| 010 | RDN | Round Down (towards −{inf})
+| 011 | RUP | Round Up (towards +{inf})
+|100 | RMM | Round to Nearest, ties to Max Magnitude
+|===
+
+As with other scalar floating-point instructions, the rounding mode field
+`rm` can also take on the
+`DYN` encoding, which indicates that the instruction uses the rounding
+mode specified in the `frm` CSR.
+
+[%autowidth]
+.Additional encoding for the `rm` field of scalar instructions
+[cols = "1,1,1"]
+|===
+|Rounding Mode | Mnemonic | Meaning
+|111 | DYN | select dynamic rounding mode
+|===
+
+In practice, the default IEEE rounding mode (round to nearest, ties to even) is generally used for arithmetic.
+
+===== Handling exceptions
+RISC-V supports IEEE-defined default exception handling. BF16 is no exception.
+
+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,
+BF16 instructions set floating-point exception flags the same way as all other floating-point instructions
+in RISC-V.
+
+====== Underflow
+
+The IEEE-defined underflow exception requires that a result be inexact and tiny, where tininess can be
+detected before or after rounding. In RISC-V, tininess is detected after rounding.
+
+It is important to note that the detection of tininess after rounding requires its own rounding
+that is different from the final result rounding. This tininess detection requires rounding as if the
+exponent were unbounded.
+This means that the input to the rounder is always a normal number.
+This is different from the final result rounding where the input to the rounder is a subnormal number when
+the value is too small to be represented as a normal number in the target format.
+The two different roundings can result in underflow being signalled for results that are rounded
+back to the normal range.
+
+As is defined in '754, under default exception handling, underflow is only signalled when the result is tiny
+and inexact. In such a case, both the underflow and inexact flags are raised.
+
+<<<
+
+[[BF16_extensions]]
+=== Extensions
+
+The group of extensions introduced by the BF16 Instruction Set
+Extensions is listed here.
+
+Detection of individual BF16 extensions uses the
+unified software-based RISC-V discovery method.
+
+[NOTE]
+====
+At the time of writing, these discovery mechanisms are still a work in
+progress.
+====
+
+The BF16 extensions defined in this specification (i.e., `Zfbfmin`,
+`Zvfbfmin`, and `Zvfbfwma`) depend on the single-precision floating-point extension
+`F`. Furthermore, the vector BF16 extensions (i.e.,`Zvfbfmin`, and
+`Zvfbfwma`) depend on the `"V"` Vector Extension for Application
+Processors or the `Zve32f` Vector Extension for Embedded Processors.
+
+As stated later in this specification,
+there exists a dependency between the newly defined extensions:
+`Zvfbfwma` depends on `Zfbfmin`
+and `Zvfbfmin`.
+
+This initial set of BF16 extensions provides very basic functionality
+including scalar and vector conversion between BF16 and
+single-precision values, and vector widening multiply-accumulate
+instructions.
+
+
+// include::riscv-bfloat16-zfbfmin.adoc[]
+[[zfbfmin, Zfbfmin]]
+==== `Zfbfmin` - Scalar BF16 Converts
+
+This extension provides the minimal set of instructions needed to enable scalar support
+of the BF16 format. It enables BF16 as an interchange format as it provides conversion
+between BF16 values and FP32 values.
+
+This extension depends upon the single-precision floating-point extension
+`F`.
+
+This extension includes six instructions: the `FCVT.BF16.S` and `FCVT.S.BF16`
+instructions, defined below, and the `FLH`, `FSH`, `FMV.X.H`, and `FMV.H.X`
+instructions, defined in <<chap:zfh>>.
+
+[NOTE]
+====
+While conversion instructions tend to include all supported formats, in these extensions we
+only support conversion between BF16 and FP32 as we are targeting a special use case.
+These extensions are intended to support the case where BF16 values are used as reduced
+precision versions of FP32 values, where use of BF16 provides a two-fold advantage for
+storage, bandwidth, and computation. In this use case, the BF16 values are typically
+multiplied by each other and accumulated into FP32 sums.
+These sums are typically converted to BF16
+and then used as subsequent inputs. The operations on the BF16 values can be performed
+on the CPU or a loosely coupled coprocessor.
+
+Subsequent extensions might provide support for native BF16 arithmetic. Such extensions
+could add additional conversion
+instructions to allow all supported formats to be converted to and from BF16.
+====
+
+[NOTE]
+====
+BF16 addition, subtraction, multiplication, division, and square-root operations can be
+faithfully emulated by converting the BF16 operands to single-precision, performing the
+operation using single-precision arithmetic, and then converting back to BF16. Performing
+BF16 fused multiply-addition using this method can produce results that differ by 1-ulp
+on some inputs for the RNE and RMM rounding modes.
+
+
+Conversions between BF16 and formats larger than FP32 can be
+emulated.
+Exact widening conversions from BF16 can be synthesized by first
+converting to FP32 and then converting from FP32 to the target
+precision.
+Conversions narrowing to BF16 can be synthesized by first
+converting to FP32 through a series of halving steps and then
+converting from FP32 to BF16.
+As with the fused multiply-addition instruction described above,
+this method of converting values to BF16 can be off by 1-ulp
+on some inputs for the RNE and RMM rounding modes.
+====
+
+[%autowidth]
+[%header,cols="2,4"]
+|===
+|Mnemonic
+|Instruction
+|FCVT.BF16.S | <<insns-fcvt.bf16.s>>
+|FCVT.S.BF16 | <<insns-fcvt.s.bf16>>
+|FLH |
+|FSH |
+|FMV.H.X |
+|FMV.X.H |
+|===
+
+// include::riscv-bfloat16-zvfbfmin.adoc[]
+[[zvfbfmin,Zvfbfmin]]
+==== `Zvfbfmin` - Vector BF16 Converts
+
+This extension provides the minimal set of instructions needed to enable vector support of the BF16
+format. It enables BF16 as an interchange format as it provides conversion between BF16 values
+and FP32 values.
+
+This extension depends upon `Zve32f` vector extension.
+
+[NOTE]
+====
+While conversion instructions tend to include all supported formats, in these extensions we
+only support conversion between BF16 and FP32 as we are targeting a special use case.
+These extensions are intended to support the case where BF16 values are used as reduced
+precision versions of FP32 values, where use of BF16 provides a two-fold advantage for
+storage, bandwidth, and computation. In this use case, the BF16 values are typically
+multiplied by each other and accumulated into FP32 sums.
+These sums are typically converted to BF16
+and then used as subsequent inputs. The operations on the BF16 values can be performed
+on the CPU or a loosely coupled coprocessor.
+
+Subsequent extensions might provide support for native BF16 arithmetic. Such extensions
+could add additional conversion
+instructions to allow all supported formats to be converted to and from BF16.
+====
+
+[NOTE]
+====
+BF16 addition, subtraction, multiplication, division, and square-root operations can be
+faithfully emulated by converting the BF16 operands to single-precision, performing the
+operation using single-precision arithmetic, and then converting back to BF16. Performing
+BF16 fused multiply-addition using this method can produce results that differ by 1-ulp
+on some inputs for the RNE and RMM rounding modes.
+
+Conversions between BF16 and formats larger than FP32 can be
+faithfully emulated.
+Exact widening conversions from BF16 can be synthesized by first
+converting to FP32 and then converting from FP32 to the target
+precision. Conversions narrowing to BF16 can be synthesized by first
+converting to FP32 through a series of halving steps using
+vector round-towards-odd narrowing conversion instructions
+(_vfncvt.rod.f.f.w_). The final convert from FP32 to BF16 would use
+the desired rounding mode.
+
+====
+
+[%autowidth]
+[%header,cols="^2,4"]
+|===
+|Mnemonic
+|Instruction
+| vfncvtbf16.f.f.w | <<insns-vfncvtbf16.f.f.w>>
+| vfwcvtbf16.f.f.v | <<insns-vfwcvtbf16.f.f.v>>
+|===
+
+// include::riscv-bfloat16-zvfbfwma.adoc[]
+[[zvfbfwma,Zvfbfwma]]
+==== `Zvfbfwma` - Vector BF16 widening mul-add
+
+This extension provides
+a vector widening BF16 mul-add instruction that accumulates into FP32.
+
+This extension depends upon the `Zvfbfmin` extension and the `Zfbfmin` extension.
+
+[%autowidth]
+[%header,cols="2,4"]
+|===
+|Mnemonic
+|Instruction
+
+|VFWMACCBF16 | <<insns-vfwmaccbf16>>
+|===
+
+
+[[BF16_insns, reftext="BF16 Instructions"]]
+=== Instructions
+
+// include::insns/fcvt_BF16_S.adoc[]
+// <<<
+[[insns-fcvt.bf16.s, Convert FP32 to BF16]]
+
+==== fcvt.bf16.s
+
+Synopsis::
+Convert FP32 value to a BF16 value
+
+Mnemonic::
+fcvt.bf16.s rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: '1010011', attr: ['OP-FP']},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 'rm'},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: '01000', attr: ['bf16.s']},
+{bits: 2, name: '10', attr: ['h']},
+{bits: 5, name: '01000', attr: 'fcvt'},
+]}
+....
+
+
+[NOTE]
+====
+.Encoding
+While the mnemonic of this instruction is consistent with that of the other RISC-V floating-point convert instructions,
+a new encoding is used in bits 24:20.
+
+`BF16.S` and `H` are used to signify that the source is FP32 and the destination is BF16.
+====
+
+
+Description::
+Narrowing convert FP32 value to a BF16 value. Round according to the RM field.
+
+This instruction is similar to other narrowing
+floating-point-to-floating-point conversion instructions.
+
+
+Exceptions: Overflow, Underflow, Inexact, Invalid
+
+Included in: <<zfbfmin>>
+
+<<<
+// include::insns/fcvt_S_BF16.adoc[]
+// <<<
+[[insns-fcvt.s.bf16, Convert BF16 to FP32]]
+==== fcvt.s.bf16
+
+Synopsis::
+Convert BF16 value to an FP32 value
+
+Mnemonic::
+fcvt.s.bf16 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: '1010011', attr: ['OP-FP']},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 'rm'},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: '00110', attr: ['bf16']},
+{bits: 2, name: '00', attr: ['s']},
+{bits: 5, name: '01000', attr: 'fcvt'},
+]}
+....
+
+[NOTE]
+====
+.Encoding
+While the mnemonic of this instruction is consistent with that of the other RISC-V floating-point
+convert instructions, a new encoding is
+used in bits 24:20 to indicate that the source is BF16.
+====
+
+
+Description::
+Converts a BF16 value to an FP32 value. The conversion is exact.
+
+This instruction is similar to other widening
+floating-point-to-floating-point conversion instructions.
+
+[NOTE]
+====
+If the input is normal or infinity, the BF16 encoded value is shifted
+to the left by 16 places and the
+least significant 16 bits are written with 0s.
+
+The result is NaN-boxed by writing the most significant `FLEN`-32 bits with 1s.
+====
+
+
+
+Exceptions: Invalid
+
+Included in: <<zfbfmin>>
+
+<<<
+
+// include::insns/vfncvtbf16_f_f_w.adoc[]
+// <<<
+[[insns-vfncvtbf16.f.f.w, Vector convert FP32 to BF16]]
+==== vfncvtbf16.f.f.w
+
+Synopsis::
+Vector convert FP32 to BF16
+
+Mnemonic::
+vfncvtbf16.f.f.w vd, vs2, vm
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: '1010111', attr:['OP-V']},
+{bits: 5, name: 'vd'},
+{bits: 3, name: '001', attr:['OPFVV']},
+{bits: 5, name: '11101', attr:['vfncvtbf16']},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010010', attr:['VFUNARY0']},
+]}
+....
+
+Reserved Encodings::
+* `SEW` is any value other than 16
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2"]
+|===
+|Register
+|Direction
+|EEW
+|Definition
+
+| Vs2 | input | 32 | FP32 Source
+| Vd | output | 16 | BF16 Result
+|===
+
+
+
+Description::
+Narrowing convert from FP32 to BF16. Round according to the _frm_ register.
+
+This instruction is similar to `vfncvt.f.f.w` which converts a
+floating-point value in a 2*SEW-width format into an SEW-width format.
+However, here the SEW-width format is limited to BF16.
+
+Exceptions: Overflow, Underflow, Inexact, Invalid
+
+Included in: <<zvfbfmin>>
+
+<<<
+
+// include::insns/vfwcvtbf16_f_f_v.adoc[]
+// <<<
+[[insns-vfwcvtbf16.f.f.v, Vector convert BF16 to FP32]]
+==== vfwcvtbf16.f.f.v
+
+Synopsis::
+Vector convert BF16 to FP32
+
+Mnemonic::
+vfwcvtbf16.f.f.v vd, vs2, vm
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: '1010111', attr:['OP-V']},
+{bits: 5, name: 'vd'},
+{bits: 3, name: '001', attr:['OPFVV']},
+{bits: 5, name: '01101', attr:['vfwcvtbf16']},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010010', attr:['VFUNARY0']},
+]}
+....
+
+Reserved Encodings::
+* `SEW` is any value other than 16
+
+Arguments::
+[%autowidth]
+[%header,cols="4,2,2,2"]
+|===
+|Register
+|Direction
+|EEW
+|Definition
+
+| Vs2 | input | 16 | BF16 Source
+| Vd | output | 32 | FP32 Result
+|===
+
+Description::
+Widening convert from BF16 to FP32. The conversion is exact.
+
+This instruction is similar to `vfwcvt.f.f.v` which converts a
+floating-point value in an SEW-width format into a 2*SEW-width format.
+However, here the SEW-width format is limited to BF16.
+
+[NOTE]
+====
+If the input is normal or infinity, the BF16 encoded value is shifted
+to the left by 16 places and the
+least significant 16 bits are written with 0s.
+====
+
+Exceptions: Invalid
+
+Included in: <<zvfbfmin>>
+
+<<<
+
+// include::insns/vfwmaccbf16.adoc[]
+// <<<
+[#insns-vfwmaccbf16, reftext="Vector BF16 widening multiply-accumulate"]
+==== vfwmaccbf16
+
+Synopsis::
+Vector BF16 widening multiply-accumulate
+
+Mnemonic::
+vfwmaccbf16.vv vd, vs1, vs2, vm +
+vfwmaccbf16.vf vd, rs1, vs2, vm +
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: '1010111', attr:['OP-V']},
+{bits: 5, name: 'vd'},
+{bits: 3, name: '001', attr:['OPFVV']},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '111011', attr:['vfwmaccbf16']},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: '1010111', attr:['OP-V']},
+{bits: 5, name: 'vd'},
+{bits: 3, name: '101', attr:['OPFVF']},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '111011', attr:['vfwmaccbf16']},
+]}
+....
+
+Reserved Encodings::
+* `SEW` is any value other than 16
+
+Arguments::
+[%autowidth]
+[%header,cols="4,2,2,2"]
+|===
+|Register
+|Direction
+|EEW
+|Definition
+
+| Vd | input | 32 | FP32 Accumulate
+| Vs1/rs1 | input | 16 | BF16 Source
+| Vs2 | input | 16 | BF16 Source
+| Vd | output | 32 | FP32 Result
+|===
+
+Description::
+
+This instruction performs a widening fused multiply-accumulate
+operation, where each pair of BF16 values are multiplied and their
+unrounded product is added to the corresponding FP32 accumulate value.
+The sum is rounded according to the _frm_ register.
+
+
+In the vector-vector version, the BF16 elements are read from `vs1`
+and `vs2` and FP32 accumulate value is read from `vd`. The FP32 result
+is written to the destination register `vd`.
+
+The vector-scalar version is similar, but instead of reading elements
+from `vs1`, a scalar BF16 value is read from the FPU register `rs1`.
+
+
+Exceptions: Overflow, Underflow, Inexact, Invalid
+
+Operation::
+
+This `vfwmaccbf16.vv` instruction is equivalent to widening each of the BF16 inputs to
+FP32 and then performing an FMACC as shown in the following
+instruction sequence:
+
+[source,asm]
+--
+vfwcvtbf16.f.f.v T1, vs1, vm
+vfwcvtbf16.f.f.v T2, vs2, vm
+vfmacc.vv vd, T1, T2, vm
+--
+
+Likewise, `vfwmaccbf16.vf` is equivalent to the following instruction sequence:
+
+[source,asm]
+--
+fcvt.s.bf16 T1, rs1
+vfwcvtbf16.f.f.v T2, vs2, vm
+vfmacc.vf vd, T1, T2, vm
+--
+
+Included in: <<zvfbfwma>>
+
+
+// include::../bibliography.adoc[ieee]
+[bibliography]
+=== Bibliography
+
+// bibliography::[]
+
+https://ieeexplore.ieee.org/document/8766229[754-2019 - IEEE Standard for Floating-Point Arithmetic] +
+https://ieeexplore.ieee.org/document/4610935[754-2008 - IEEE Standard for Floating-Point Arithmetic]
diff --git a/src/bibliography.adoc b/src/bibliography.adoc
new file mode 100644
index 0000000..4cc3eb7
--- /dev/null
+++ b/src/bibliography.adoc
@@ -0,0 +1,4 @@
+[bibliography]
+== Bibliography
+
+bibliography::[]
diff --git a/src/c-st-ext.adoc b/src/c-st-ext.adoc
new file mode 100644
index 0000000..5fd72c1
--- /dev/null
+++ b/src/c-st-ext.adoc
@@ -0,0 +1,918 @@
+[[compressed]]
+== "C" Extension for Compressed Instructions, Version 2.0
+
+This chapter describes the RISC-V standard compressed instruction-set
+extension, named "C", which reduces static and dynamic code size by
+adding short 16-bit instruction encodings for common operations. The C
+extension can be added to any of the base ISAs (RV32I, RV32E, RV64I, RV64E), and
+we use the generic term "RVC" to cover any of these. Typically,
+50%-60% of the RISC-V instructions in a program can be replaced with RVC
+instructions, resulting in a 25%-30% code-size reduction.
+
+=== Overview
+
+RVC uses a simple compression scheme that offers shorter 16-bit versions
+of common 32-bit RISC-V instructions when:
+
+* the immediate or address offset is small, or
+* one of the registers is the zero register (`x0`), the ABI link register
+(`x1`), or the ABI stack pointer (`x2`), or
+* the destination register and the first source register are identical, or
+* the registers used are the 8 most popular ones.
+
+The C extension is compatible with all other standard instruction
+extensions. The C extension allows 16-bit instructions to be freely
+intermixed with 32-bit instructions, with the latter now able to start
+on any 16-bit boundary, i.e., IALIGN=16. With the addition of the C
+extension, no instructions can raise instruction-address-misaligned
+exceptions.
+
+[NOTE]
+====
+Removing the 32-bit alignment constraint on the original 32-bit
+instructions allows significantly greater code density.
+====
+
+The compressed instruction encodings are mostly common across RV32C and
+RV64C, but as shown in <<rvc-instr-table0>>, a few opcodes are used for
+different purposes depending on base ISA. For example, the wider
+address-space RV64C variant requires additional opcodes to
+compress loads and stores of 64-bit integer values, while RV32C uses the
+same opcodes to compress loads and stores of single-precision
+floating-point values.
+If the C extension is implemented, the
+appropriate compressed floating-point load and store instructions must
+be provided whenever the relevant standard floating-point extension (F
+and/or D) is also implemented. In addition, RV32C includes a compressed
+jump and link instruction to compress short-range subroutine calls,
+where the same opcode is used to compress ADDIW for RV64C.
+
+[NOTE]
+====
+Double-precision loads and stores are a significant fraction of static
+and dynamic instructions, hence the motivation to include them in the
+RV32C and RV64C encoding.
+
+Although single-precision loads and stores are not a significant source
+of static or dynamic compression for benchmarks compiled for the
+currently supported ABIs, for microcontrollers that only provide
+hardware single-precision floating-point units and have an ABI that only
+supports single-precision floating-point numbers, the single-precision
+loads and stores will be used at least as frequently as double-precision
+loads and stores in the measured benchmarks. Hence, the motivation to
+provide compressed support for these in RV32C.
+
+Short-range subroutine calls are more likely in small binaries for
+microcontrollers, hence the motivation to include these in RV32C.
+
+Although reusing opcodes for different purposes for different base ISAs
+adds some complexity to documentation, the impact on implementation
+complexity is small even for designs that support multiple base ISAs.
+The compressed floating-point load and store variants use the same
+instruction format with the same register specifiers as the wider
+integer loads and stores.
+====
+
+RVC was designed under the constraint that each RVC instruction expands
+into a single 32-bit instruction in either the base ISA (RV32I/E or RV64I/E)
+or the F and D standard extensions where present. Adopting
+this constraint has two main benefits:
+
+* Hardware designs can simply expand RVC instructions during decode,
+simplifying verification and minimizing modifications to existing
+microarchitectures.
+
+* Compilers can be unaware of the RVC extension and leave code compression
+to the assembler and linker, although a compression-aware compiler will
+generally be able to produce better results.
+
+[NOTE]
+====
+We felt the multiple complexity reductions of a simple one-one mapping
+between C and base IFD instructions far outweighed the potential gains
+of a slightly denser encoding that added additional instructions only
+supported in the C extension, or that allowed encoding of multiple IFD
+instructions in one C instruction.
+====
+
+It is important to note that the C extension is not designed to be a
+stand-alone ISA, and is meant to be used alongside a base ISA.
+
+[NOTE]
+====
+Variable-length instruction sets have long been used to improve code
+density. For example, the IBM Stretch cite:[stretch], developed in the late 1950s, had
+an ISA with 32-bit and 64-bit instructions, where some of the 32-bit
+instructions were compressed versions of the full 64-bit instructions.
+Stretch also employed the concept of limiting the set of registers that
+were addressable in some of the shorter instruction formats, with short
+branch instructions that could only refer to one of the index registers.
+The later IBM 360 architecture cite:[ibm360] supported a simple variable-length
+instruction encoding with 16-bit, 32-bit, or 48-bit instruction formats.
+
+In 1963, CDC introduced the Cray-designed CDC 6600 cite:[cdc6600], a precursor to RISC
+architectures, that introduced a register-rich load-store architecture
+with instructions of two lengths, 15-bits and 30-bits. The later Cray-1
+design used a very similar instruction format, with 16-bit and 32-bit
+instruction lengths.
+
+The initial RISC ISAs from the 1980s all picked performance over code
+size, which was reasonable for a workstation environment, but not for
+embedded systems. Hence, both ARM and MIPS subsequently made versions of
+the ISAs that offered smaller code size by offering an alternative
+16-bit wide instruction set instead of the standard 32-bit wide
+instructions. The compressed RISC ISAs reduced code size relative to
+their starting points by about 25-30%, yielding code that was
+significantly smaller than 80x86. This result surprised some, as their
+intuition was that the variable-length CISC ISA should be smaller than
+RISC ISAs that offered only 16-bit and 32-bit formats.
+
+Since the original RISC ISAs did not leave sufficient opcode space free
+to include these unplanned compressed instructions, they were instead
+developed as complete new ISAs. This meant compilers needed different
+code generators for the separate compressed ISAs. The first compressed
+RISC ISA extensions (e.g., ARM Thumb and MIPS16) used only a fixed
+16-bit instruction size, which gave good reductions in static code size
+but caused an increase in dynamic instruction count, which led to lower
+performance compared to the original fixed-width 32-bit instruction
+size. This led to the development of a second generation of compressed
+RISC ISA designs with mixed 16-bit and 32-bit instruction lengths (e.g.,
+ARM Thumb2, microMIPS, PowerPC VLE), so that performance was similar to
+pure 32-bit instructions but with significant code size savings.
+Unfortunately, these different generations of compressed ISAs are
+incompatible with each other and with the original uncompressed ISA,
+leading to significant complexity in documentation, implementations, and
+software tools support.
+
+Of the commonly used 64-bit ISAs, only PowerPC and microMIPS currently
+supports a compressed instruction format. It is surprising that the most
+popular 64-bit ISA for mobile platforms (ARM v8) does not include a
+compressed instruction format given that static code size and dynamic
+instruction fetch bandwidth are important metrics. Although static code
+size is not a major concern in larger systems, instruction fetch
+bandwidth can be a major bottleneck in servers running commercial
+workloads, which often have a large instruction working set.
+
+Benefiting from 25 years of hindsight, RISC-V was designed to support
+compressed instructions from the outset, leaving enough opcode space for
+RVC to be added as a simple extension on top of the base ISA (along with
+many other extensions). The philosophy of RVC is to reduce code size for
+embedded applications _and_ to improve performance and energy-efficiency
+for all applications due to fewer misses in the instruction cache.
+Waterman shows that RVC fetches 25%-30% fewer instruction bits, which
+reduces instruction cache misses by 20%-25%, or roughly the same
+performance impact as doubling the instruction cache size. cite:[waterman-ms]
+====
+
+=== Compressed Instruction Formats
+((((compressed, formats))))
+
+<<rvc-form>> shows the nine compressed instruction
+formats. CR, CI, and CSS can use any of the 32 RVI registers, but CIW,
+CL, CS, CA, and CB are limited to just 8 of them.
+<<registers>> lists these popular registers, which
+correspond to registers `x8` to `x15`. Note that there is a separate
+version of load and store instructions that use the stack pointer as the
+base address register, since saving to and restoring from the stack are
+so prevalent, and that they use the CI and CSS formats to allow access
+to all 32 data registers. CIW supplies an 8-bit immediate for the
+ADDI4SPN instruction.
+
+[NOTE]
+====
+The RISC-V ABI was changed to make the frequently used registers map to
+registers 'x8-x15'. This simplifies the decompression decoder by
+having a contiguous naturally aligned set of register numbers, and is
+also compatible with the RV32E and RV64E base ISAs, which only have 16 integer
+registers.
+====
+Compressed register-based floating-point loads and stores also use the
+CL and CS formats respectively, with the eight registers mapping to `f8` to `f15`.
+((((calling convention, standard))))
+[NOTE]
+====
+_The standard RISC-V calling convention maps the most frequently used
+floating-point registers to registers `f8` to `f15`, which allows the
+same register decompression decoding as for integer register numbers._
+====
+((((register source specifiers, c-ext))))
+The formats were designed to keep bits for the two register source
+specifiers in the same place in all instructions, while the destination
+register field can move. When the full 5-bit destination register
+specifier is present, it is in the same place as in the 32-bit RISC-V
+encoding. Where immediates are sign-extended, the sign extension is
+always from bit 12. Immediate fields have been scrambled, as in the base
+specification, to reduce the number of immediate multiplexers required.
+[NOTE]
+====
+The immediate fields are scrambled in the instruction formats instead of
+in sequential order so that as many bits as possible are in the same
+position in every instruction, thereby simplifying implementations.
+====
+
+For many RVC instructions, zero-valued immediates are disallowed and
+`x0` is not a valid 5-bit register specifier. These restrictions free up
+encoding space for other instructions requiring fewer operand bits.
+
+//[[cr-register]]
+//include::images/wavedrom/cr-register.edn[]
+//.Compressed 16-bit RVC instructions
+//(((compressed, 16-bit)))
+
+[[rvc-form]]
+.Compressed 16-bit RVC instruction formats
+//[%header]
+[float="center",align="center",cols="1a, 2a",frame="none",grid="none"]
+|===
+|
+[%autowidth,float="right",align="right",cols="^,^",frame="none",grid="none",options="noheader"]
+!===
+!Format ! Meaning
+!CR ! Register
+!CI ! Immediate
+!CSS ! Stack-relative Store
+!CIW ! Wide Immediate
+!CL ! Load
+!CS ! Store
+!CA ! Arithmetic
+!CB ! Branch/Arithmetic
+!CJ ! Jump
+!===
+|
+[float="left",align="left",cols="1,1,1,1,1,1,1",options="noheader"]
+!===
+^!15 14 13 ^!12 ^!11 10 ^!9 8 7 ^!6 5 ^!4 3 2 ^!1 0
+2+^!funct4 2+^!rd/rs1 2+^!rs2 ^! op
+^!funct3 ^!imm 2+^!rd/rs1 2+^!imm ^! op
+^!funct3 3+^!imm 2+^!rs2 ^! op
+^!funct3 4+^!imm ^!rd&#x2032; ^! op
+^!funct3 2+^!imm ^!rs1&#x2032; ^!imm ^!rd&#x2032; ^! op
+^!funct3 2+^!imm ^!rs1&#x2032; ^! imm ^!rs2&#x2032; ^! op
+3+^!funct6 ^!rd&#x2032;/rs1&#x2032; ^!funct2 ^!rs2&#x2032; ^! op
+^!funct3 2+^!offset ^!rd&#x2032;/rs1&#x2032; 2+^!offset ^! op
+^!funct3 5+^!jump target ^! op
+!===
+|===
+
+[[registers]]
+.Registers specified by the three-bit _rs1_&#x2032;, _rs2_&#x2032;, and _rd_&#x2032; fields of the CIW, CL, CS, CA, and CB formats.
+//[cols="20%,10%,10%,10%,10%,10%,10%,10%,10%"]
+[float="center",align="center",cols="1a, 1a",frame="none",grid="none"]
+|===
+|
+[%autowidth,cols="<",frame="none",grid="none",options="noheader"]
+!===
+!RVC Register Number
+!Integer Register Number
+!Integer Register ABI Name
+!Floating-Point Register Number
+!Floating-Point Register ABI Name
+!===
+|
+
+[%autowidth,cols="^,^,^,^,^,^,^,^",options="noheader"]
+!===
+!`000` !`001` !`010` !`011` !`100` !`101` !`110` !`111`
+!`x8` !`x9` !`x10` !`x11` !`x12` !`x13` !`x14`!`x15`
+!`s0` !`s1` !`a0` !`a1` !`a2` !`a3` !`a4`!`a5`
+!`f8` !`f9` !`f10` !`f11` !`f12` !`f13`!`f14` !`f15`
+!`fs0` !`fs1` !`fa0` !`fa1` !`fa2`!`fa3` !`fa4` !`fa5`
+!===
+|===
+
+
+=== Load and Store Instructions
+
+To increase the reach of 16-bit instructions, data-transfer instructions
+use zero-extended immediates that are scaled by the size of the data in
+bytes: ×4 for words, ×8 for double
+words, and ×16 for quad words.
+
+RVC provides two variants of loads and stores. One uses the ABI stack
+pointer, `x2`, as the base address and can target any data register. The
+other can reference one of 8 base address registers and one of 8 data
+registers.
+
+==== Stack-Pointer-Based Loads and Stores
+
+include::images/wavedrom/c-sp-load-store.edn[]
+[[c-sp-load-store]]
+//.Stack-Pointer-Based Loads and Stores--these instructions use the CI format.
+
+These instructions use the CI format.
+
+C.LWSP loads a 32-bit value from memory into register _rd_. It computes
+an effective address by adding the _zero_-extended offset, scaled by 4,
+to the stack pointer, `x2`. It expands to `lw rd, offset(x2)`. C.LWSP is
+valid only when _rd_≠`x0`; the code points with _rd_=`x0` are reserved.
+
+C.LDSP is an RV64C-only instruction that loads a 64-bit value
+from memory into register _rd_. It computes its effective address by
+adding the zero-extended offset, scaled by 8, to the stack pointer,
+`x2`. It expands to `ld rd, offset(x2)`. C.LDSP is valid only when
+_rd_≠`x0`; the code points with
+_rd_=`x0` are reserved.
+
+C.FLWSP is an RV32FC-only instruction that loads a single-precision
+floating-point value from memory into floating-point register _rd_. It
+computes its effective address by adding the _zero_-extended offset,
+scaled by 4, to the stack pointer, `x2`. It expands to
+`flw rd, offset(x2)`.
+
+C.FLDSP is an RV32DC/RV64DC-only instruction that loads a
+double-precision floating-point value from memory into floating-point
+register _rd_. It computes its effective address by adding the
+_zero_-extended offset, scaled by 8, to the stack pointer, `x2`. It
+expands to `fld rd, offset(x2)`.
+
+include::images/wavedrom/c-sp-load-store-css.edn[]
+[[c-sp-load-store-css]]
+//.Stack-Pointer-Based Loads and Stores--these instructions use the CSS format.
+
+These instructions use the CSS format.
+
+C.SWSP stores a 32-bit value in register _rs2_ to memory. It computes an
+effective address by adding the _zero_-extended offset, scaled by 4, to
+the stack pointer, `x2`. It expands to `sw rs2, offset(x2)`.
+
+C.SDSP is an RV64C-only instruction that stores a 64-bit value in
+register _rs2_ to memory. It computes an effective address by adding the
+_zero_-extended offset, scaled by 8, to the stack pointer, `x2`. It
+expands to `sd rs2, offset(x2)`.
+
+C.FSWSP is an RV32FC-only instruction that stores a single-precision
+floating-point value in floating-point register _rs2_ to memory. It
+computes an effective address by adding the _zero_-extended offset,
+scaled by 4, to the stack pointer, `x2`. It expands to
+`fsw rs2, offset(x2)`.
+
+C.FSDSP is an RV32DC/RV64DC-only instruction that stores a
+double-precision floating-point value in floating-point register _rs2_
+to memory. It computes an effective address by adding the
+_zero_-extended offset, scaled by 8, to the stack pointer, `x2`. It
+expands to `fsd rs2, offset(x2)`.
+
+[NOTE]
+====
+Register save/restore code at function entry/exit represents a
+significant portion of static code size. The stack-pointer-based
+compressed loads and stores in RVC are effective at reducing the
+save/restore static code size by a factor of 2 while improving
+performance by reducing dynamic instruction bandwidth.
+
+A common mechanism used in other ISAs to further reduce save/restore
+code size is load-multiple and store-multiple instructions. We
+considered adopting these for RISC-V but noted the following drawbacks
+to these instructions:
+
+* These instructions complicate processor implementations.
+* For virtual memory systems, some data accesses could be resident in
+physical memory and some could not, which requires a new restart
+mechanism for partially executed instructions.
+* Unlike the rest of the RVC instructions, there is no IFD equivalent to
+Load Multiple and Store Multiple.
+* Unlike the rest of the RVC instructions, the compiler would have to be aware
+of these load-multiple and store-multiple instructions to both allocate
+registers in the expected order and also to schedule the loads and
+stores contiguously and in the proper order, to maximize the chances of them
+being detected and replaced by an assembler or linker with the equivalent
+load-multiple or store-multiple compressed instruction.
+* Simple microarchitectural implementations will constrain how other
+instructions can be scheduled around the load and store multiple
+instructions, leading to a potential performance loss.
+* The desire for sequential register allocation might conflict with the
+featured registers selected for the CIW, CL, CS, CA, and CB formats.
+
+Furthermore, much of the gains can be realized in software by replacing
+prologue and epilogue code with subroutine calls to common prologue and
+epilogue code, a technique described in Section 5.6 of cite:[waterman-phd].
+
+While reasonable architects might come to different conclusions, we
+decided to omit load and store multiple and instead use the
+software-only approach of calling save/restore millicode routines to
+attain the greatest code size reduction.
+====
+
+==== Register-Based Loads and Stores
+
+[[reg-based-ldnstr]]
+include::images/wavedrom/reg-based-ldnstr.edn[]
+//.Compressed, register-based load and stores--these instructions use the CL format.
+(((compressed, register-based load and store)))
+These instructions use the CL format.
+
+C.LW loads a 32-bit value from memory into register
+`_rd′_`. It computes an effective address by adding the
+_zero_-extended offset, scaled by 4, to the base address in register
+`_rs1′_`. It expands to `lw rd′, offset(rs1′)`.
+
+C.LD is an RV64C-only instruction that loads a 64-bit value from
+memory into register `_rd′_`. It computes an effective
+address by adding the _zero_-extended offset, scaled by 8, to the base
+address in register `_rs1′_`. It expands to
+`ld rd′, offset(rs1′)`.
+
+C.FLW is an RV32FC-only instruction that loads a single-precision
+floating-point value from memory into floating-point register
+`_rd′_`. It computes an effective address by adding the
+_zero_-extended offset, scaled by 4, to the base address in register
+`_rs1′_`. It expands to
+`flw rd′, offset(rs1′)`.
+
+C.FLD is an RV32DC/RV64DC-only instruction that loads a double-precision
+floating-point value from memory into floating-point register
+`_rd′_`. It computes an effective address by adding the
+_zero_-extended offset, scaled by 8, to the base address in register
+`_rs1′_`. It expands to
+`fld rd′, offset(rs1′)`.
+
+[[c-cs-format-ls]]
+include::images/wavedrom/c-cs-format-ls.edn[]
+//.Compressed, CS format load and store--these instructions use the CS format.
+(((compressed, cs-format load and store)))
+
+These instructions use the CS format.
+
+C.SW stores a 32-bit value in register `_rs2′_` to memory.
+It computes an effective address by adding the _zero_-extended offset,
+scaled by 4, to the base address in register `_rs1′_`. It
+expands to `sw rs2′, offset(rs1′)`.
+
+C.SD is an RV64C-only instruction that stores a 64-bit value in
+register `_rs2′_` to memory. It computes an effective
+address by adding the _zero_-extended offset, scaled by 8, to the base
+address in register `_rs1′_`. It expands to
+`sd rs2′, offset(rs1′)`.
+
+C.FSW is an RV32FC-only instruction that stores a single-precision
+floating-point value in floating-point register `_rs2′_` to
+memory. It computes an effective address by adding the _zero_-extended
+offset, scaled by 4, to the base address in register
+`_rs1′_`. It expands to
+`fsw rs2′, offset(rs1′)`.
+
+C.FSD is an RV32DC/RV64DC-only instruction that stores a
+double-precision floating-point value in floating-point register
+`_rs2′_` to memory. It computes an effective address by
+adding the _zero_-extended offset, scaled by 8, to the base address in
+register `_rs1′_`. It expands to
+`fsd rs2′, offset(rs1′)`.
+
+=== Control Transfer Instructions
+
+RVC provides unconditional jump instructions and conditional branch
+instructions. As with base RVI instructions, the offsets of all RVC
+control transfer instructions are in multiples of 2 bytes.
+
+[[c-cj-format-ls]]
+include::images/wavedrom/c-cj-format-ls.edn[]
+//.Compressed, CJ format load and store--these instructions use the CJ format.
+(((compressed, cj-format load and store)))
+
+These instructions use the CJ format.
+
+C.J performs an unconditional control transfer. The offset is
+sign-extended and added to the `pc` to form the jump target address. C.J
+can therefore target a &#177;2 KiB range. C.J expands to
+`jal x0, offset`.
+
+C.JAL is an RV32C-only instruction that performs the same operation as
+C.J, but additionally writes the address of the instruction following
+the jump (`pc+2`) to the link register, `x1`. C.JAL expands to
+`jal x1, offset`.
+
+[[c-cr-format-ls]]
+include::images/wavedrom/c-cr-format-ls.edn[]
+//.Compressed, CR format load and store--these instructions use the CR format.
+(((compressed, cr-format load and store)))
+
+These instructions use the CR format.
+
+C.JR (jump register) performs an unconditional control transfer to the
+address in register _rs1_. C.JR expands to `jalr x0, 0(rs1)`. C.JR is
+valid only when _rs1_≠`x0`; the code
+point with _rs1_=`x0` is reserved.
+
+C.JALR (jump and link register) performs the same operation as C.JR, but
+additionally writes the address of the instruction following the jump
+(`pc`+2) to the link register, `x1`. C.JALR expands to
+`jalr x1, 0(rs1)`. C.JALR is valid only when
+_rs1_≠`x0`; the code point with
+_rs1_=`x0` corresponds to the C.EBREAK
+instruction.
+
+[NOTE]
+====
+Strictly speaking, C.JALR does not expand exactly to a base RVI
+instruction as the value added to the PC to form the link address is 2
+rather than 4 as in the base ISA, but supporting both offsets of 2 and 4
+bytes is only a very minor change to the base microarchitecture.
+====
+
+[[c-cb-format-ls]]
+include::images/wavedrom/c-cb-format-ls.edn[]
+//.Compressed, CB format load and store--these instructions use the CB format.
+(((compressed, cb-format load and store)))
+
+These instructions use the CB format.
+
+C.BEQZ performs conditional control transfers. The offset is
+sign-extended and added to the `pc` to form the branch target address.
+It can therefore target a &#177;256 B range. C.BEQZ takes the
+branch if the value in register _rs1′_ is zero. It
+expands to `beq rs1′, x0, offset`.
+
+C.BNEZ is defined analogously, but it takes the branch if
+_rs1′_ contains a nonzero value. It expands to
+`bne rs1′, x0, offset`.
+
+=== Integer Computational Instructions
+
+RVC provides several instructions for integer arithmetic and constant
+generation.
+
+==== Integer Constant-Generation Instructions
+
+The two constant-generation instructions both use the CI instruction
+format and can target any integer register.
+
+[[c-integer-const-gen]]
+include::images/wavedrom/c-integer-const-gen.edn[]
+//.Integer constant generation format.
+(((compressed, integer constant generation)))
+
+
+C.LI loads the sign-extended 6-bit immediate, _imm_, into register _rd_.
+C.LI expands into `addi rd, x0, imm`.
+The C.LI code points with _rd_=`x0` are HINTs.
+
+C.LUI loads the non-zero 6-bit immediate field into bits 17–12 of the
+destination register, clears the bottom 12 bits, and sign-extends bit 17
+into all higher bits of the destination. C.LUI expands into
+`lui rd, imm`. C.LUI is valid only when
+_rd_≠`x2`,
+and when the immediate is not equal to zero. The code points with
+_imm_=0 are reserved.
+The code points with _rd_=`x2` and _imm_≠0 correspond to the
+C.ADDI16SP instruction.
+The code points with _rd_=`x0` and _imm_≠0 are HINTs.
+
+==== Integer Register-Immediate Operations
+
+These integer register-immediate operations are encoded in the CI format
+and perform operations on an integer register and a 6-bit immediate.
+
+[[c-integer-register-immediate]]
+include::images/wavedrom/c-int-reg-immed.edn[]
+//.Integer register-immediate format.
+(((compressed, integer register-immediate)))
+
+C.ADDI adds the non-zero sign-extended 6-bit immediate to the value in
+register _rd_ then writes the result to _rd_. C.ADDI expands into
+`addi rd, rd, imm`.
+The code points with _rd_≠0 and _imm_=0 are HINTs.
+The code points with _rd_=`x0` encode the C.NOP instruction, of
+which the code points with _imm_≠0 are HINTs.
+
+
+C.ADDIW is an RV64C-only instruction that performs the same
+computation but produces a 32-bit result, then sign-extends result to 64
+bits. C.ADDIW expands into `addiw rd, rd, imm`. The immediate can be
+zero for C.ADDIW, where this corresponds to `sext.w rd`. C.ADDIW is
+valid only when _rd_≠`x0`; the code points with
+_rd_=`x0` are reserved.
+
+C.ADDI16SP (add immediate to stack pointer)
+shares the opcode with C.LUI, but has a destination field of
+`x2`. C.ADDI16SP adds the non-zero sign-extended 6-bit immediate to the
+value in the stack pointer (`sp=x2`), where the immediate is scaled to
+represent multiples of 16 in the range [-512, 496]. C.ADDI16SP is used to
+adjust the stack pointer in procedure prologues and epilogues. It
+expands into `addi x2, x2, nzimm[9:4]`. C.ADDI16SP is valid only when
+_nzimm_≠0; the code point with _nzimm_=0 is reserved.
+
+[NOTE]
+====
+In the standard RISC-V calling convention, the stack pointer `sp` is
+always 16-byte aligned.
+====
+
+[[c-ciw]]
+include::images/wavedrom/c-ciw.edn[]
+//.CIW format.
+(((compressed, CIW)))
+C.ADDI4SPN (add immediate to stack pointer, non-destructive)
+is a CIW-format instruction that adds a _zero_-extended
+non-zero immediate, scaled by 4, to the stack pointer, `x2`, and writes
+the result to `rd′`. This instruction is used to generate
+pointers to stack-allocated variables, and expands to
+`addi rd′, x2, nzuimm[9:2]`. C.ADDI4SPN is valid only when
+_nzuimm_≠0; the code points with _nzuimm_=0 are
+reserved.
+
+[[c-ci]]
+include::images/wavedrom/c-ci.edn[]
+//.CI format.
+(((compressed, CI)))
+
+C.SLLI is a CI-format instruction that performs a logical left shift of
+the value in register _rd_ then writes the result to _rd_. The shift
+amount is encoded in the _shamt_ field.
+C.SLLI expands into `slli rd, rd, shamt[5:0]`.
+
+The C.SLLI code points with _shamt_=0 or with _rd_=`x0` are HINTs.
+
+For RV32C, _shamt[5]_ must be zero; the code points with _shamt[5]_=1
+are designated for custom extensions.
+
+[[c-srli-srai]]
+
+include::images/wavedrom/c-srli-srai.edn[]
+//.C-SRLI-SRAI format.
+(((compressed, C.SRLI, C.SRAI)))
+
+C.SRLI is a CB-format instruction that performs a logical right shift of
+the value in register _rd′_ then writes the result to
+_rd′_. The shift amount is encoded in the _shamt_ field.
+C.SRLI expands into `srli rd′, rd′, shamt`.
+
+The C.SRLI code points with _shamt_=0 are HINTs.
+
+For RV32C, _shamt[5]_ must be zero; the code points with _shamt[5]_=1
+are designated for custom extensions.
+
+C.SRAI is defined analogously to C.SRLI, but instead performs an
+arithmetic right shift. C.SRAI expands to
+`srai rd′, rd′, shamt`.
+
+[NOTE]
+====
+Left shifts are usually more frequent than right shifts, as left shifts
+are frequently used to scale address values. Right shifts have therefore
+been granted less encoding space and are placed in an encoding quadrant
+where all other immediates are sign-extended.
+====
+[[c-andi]]
+include::images/wavedrom/c-andi.edn[]
+//.C.ANDI format
+(((compressed, C.ANDI)))
+
+C.ANDI is a CB-format instruction that computes the bitwise AND of the
+value in register _rd′_ and the sign-extended 6-bit
+immediate, then writes the result to _rd′_. C.ANDI
+expands to `andi rd′, rd′, imm`.
+
+==== Integer Register-Register Operations
+
+[[c-cr]]
+include::images/wavedrom/c-int-reg-to-reg-cr-format.edn[]
+//C.CR format
+((((compressed. C.CR))))
+These instructions use the CR format.
+
+C.MV copies the value in register _rs2_ into register _rd_. C.MV expands
+into `add rd, x0, rs2`. C.MV is valid only when
+_rs2_≠`x0`; the code points with _rs2_=`x0` correspond to the C.JR instruction. The code points with _rs2_≠`x0` and _rd_=`x0` are HINTs.
+
+[NOTE]
+====
+_C.MV expands to a different instruction than the canonical MV
+pseudoinstruction, which instead uses ADDI. Implementations that handle
+MV specially, e.g. using register-renaming hardware, may find it more
+convenient to expand C.MV to MV instead of ADD, at slight additional
+hardware cost._
+====
+
+C.ADD adds the values in registers _rd_ and _rs2_ and writes the result
+to register _rd_. C.ADD expands into `add rd, rd, rs2`. C.ADD is only
+valid when _rs2_≠`x0`; the code points with _rs2_=`x0` correspond to the C.JALR
+and C.EBREAK instructions. The code points with _rs2_≠`x0` and _rd_=`x0` are HINTs.
+
+[[c-ca]]
+include::images/wavedrom/c-int-reg-to-reg-ca-format.edn[]
+//C.CA format
+((((compressed. C.CA))))
+
+These instructions use the CA format.
+
+`C.AND` computes the bitwise `AND` of the values in registers
+_rd′_ and _rs2′_, then writes the result
+to register _rd′_. `C.AND` expands into
+`and rd′, rd′, rs2′`.
+
+`C.OR` computes the bitwise `OR` of the values in registers
+_rd′_ and _rs2′_, then writes the result
+to register _rd′_. `C.OR` expands into
+`or rd′, rd′, rs2′`.
+
+`C.XOR` computes the bitwise `XOR` of the values in registers
+_rd′_ and _rs2′_, then writes the result
+to register _rd′_. `C.XOR` expands into
+`xor rd′, rd′, rs2′`.
+
+`C.SUB` subtracts the value in register _rs2′_ from the
+value in register _rd′_, then writes the result to
+register _rd′_. `C.SUB` expands into
+`sub rd′, rd′, rs2′`.
+
+`C.ADDW` is an RV64C-only instruction that adds the values in
+registers _rd′_ and _rs2′_, then
+sign-extends the lower 32 bits of the sum before writing the result to
+register _rd′_. `C.ADDW` expands into
+`addw rd′, rd′, rs2′`.
+
+`C.SUBW` is an RV64C-only instruction that subtracts the value in
+register _rs2′_ from the value in register
+_rd′_, then sign-extends the lower 32 bits of the
+difference before writing the result to register _rd′_.
+`C.SUBW` expands into `subw rd′, rd′, rs2′`.
+
+[NOTE]
+====
+This group of six instructions do not provide large savings
+individually, but do not occupy much encoding space and are
+straightforward to implement, and as a group provide a worthwhile
+improvement in static and dynamic compression.
+====
+
+==== Defined Illegal Instruction
+
+[[c-def-illegal-inst]]
+include::images/wavedrom/c-def-illegal-inst.edn[]
+((((compressed. C.DIINST))))
+
+A 16-bit instruction with all bits zero is permanently reserved as an
+illegal instruction.
+
+[NOTE]
+====
+We reserve all-zero instructions to be illegal instructions to help trap
+attempts to execute zero-ed or non-existent portions of the memory
+space. The all-zero value should not be redefined in any non-standard
+extension. Similarly, we reserve instructions with all bits set to 1
+(corresponding to very long instructions in the RISC-V variable-length
+encoding scheme) as illegal to capture another common value seen in
+non-existent memory regions.
+====
+
+==== NOP Instruction
+
+[[c-nop-instr]]
+include::images/wavedrom/c-nop-instr.edn[]
+((((compressed. C.NOPINSTR))))
+
+`C.NOP` is a CI-format instruction that does not change any user-visible
+state, except for advancing the `pc` and incrementing any applicable
+performance counters. `C.NOP` expands to `nop`. The `C.NOP` code points
+with _imm_≠0 encode HINTs.
+
+==== Breakpoint Instruction
+
+[[c-breakpoint-instr]]
+include::images/wavedrom/c-breakpoint-instr.edn[]
+((((compressed. C.BREAKPOINTINSTR))))
+
+Debuggers can use the `C.EBREAK` instruction, which expands to `ebreak`,
+to cause control to be transferred back to the debugging environment.
+`C.EBREAK` shares the opcode with the `C.ADD` instruction, but with _rd_ and
+_rs2_ both zero, thus can also use the `CR` format.
+
+=== Usage of C Instructions in LR/SC Sequences
+
+On implementations that support the C extension, compressed forms of the
+I instructions permitted inside constrained LR/SC sequences, as
+described in <<sec:lrscseq>>, are also permitted
+inside constrained LR/SC sequences.
+
+[NOTE]
+====
+The implication is that any implementation that claims to support both
+the A and C extensions must ensure that LR/SC sequences containing valid
+C instructions will eventually complete.
+====
+
+[[rvc-hints]]
+=== HINT Instructions
+
+A portion of the RVC encoding space is reserved for microarchitectural
+HINTs. Like the HINTs in the RV32I base ISA (see
+<<rv32i-hints>>), these instructions do not
+modify any architectural state, except for advancing the `pc` and any
+applicable performance counters. HINTs are executed as no-ops on
+implementations that ignore them.
+
+RVC HINTs are encoded as computational instructions that do not modify
+the architectural state, either because _rd_=`x0` (e.g.
+`C.ADD _x0_, _t0_`), or because _rd_ is overwritten with a copy of itself
+(e.g. `C.ADDI _t0_, 0`).
+
+[NOTE]
+====
+This HINT encoding has been chosen so that simple implementations can
+ignore HINTs altogether, and instead execute a HINT as a regular
+computational instruction that happens not to mutate the architectural
+state.
+====
+
+RVC HINTs do not necessarily expand to their RVI HINT counterparts. For
+example, `C.ADD` _x0_, _a0_ might not encode the same HINT as
+`ADD` _x0_, _x0_, _a0_.
+
+[NOTE]
+====
+The primary reason to not require an RVC HINT to expand to an RVI HINT
+is that HINTs are unlikely to be compressible in the same manner as the
+underlying computational instruction. Also, decoupling the RVC and RVI
+HINT mappings allows the scarce RVC HINT space to be allocated to the
+most popular HINTs, and in particular, to HINTs that are amenable to
+macro-op fusion.
+====
+
+<<rvc-t-hints>> lists all RVC HINT code points. For RV32C, 78%
+of the HINT space is reserved for standard HINTs. The remainder of the HINT space is designated for custom HINTs;
+no standard HINTs will ever be defined in this subspace.
+
+[[rvc-t-hints]]
+.RVC HINT instructions.
+[cols="<,<,>,<",options="header",]
+|===
+|Instruction |Constraints |Code Points |Purpose
+
+|C.NOP |_imm_≠0 |63 .6+.^|_Designated for future standard use_
+
+|C.ADDI | _rd_≠`x0`, _imm_=0 |31
+
+|C.LI | _rd_=`x0` |64
+
+|C.LUI | _rd_=`x0`, _imm_≠0 |63
+
+|C.MV | _rd_=`x0`, _rs2_≠`x0` |31
+
+|C.ADD | _rd_=`x0`, _rs2_≠`x0`, _rs2_≠`x2-x5` | 27
+
+|C.ADD | _rd_=`x0`, _rs2_=`x2-x5` |4|(rs2=x2) C.NTL.P1 (rs2=x3) C.NTL.PALL (rs2=x4) C.NTL.S1 (rs2=x5) C.NTL.ALL
+
+|C.SLLI |_rd_=`x0` or _imm_=0 |63 (RV32), 95 (RV64) .3+.^|_Designated for custom use_
+
+|C.SRLI | _imm_=0 |8
+
+|C.SRAI | _imm_=0 |8
+|===
+
+=== RVC Instruction Set Listings
+
+<<rvcopcodemap>> shows a map of the major
+opcodes for RVC. Each row of the table corresponds to one quadrant of
+the encoding space. The last quadrant, which has the two
+least-significant bits set, corresponds to instructions wider than 16
+bits, including those in the base ISAs. Several instructions are only
+valid for certain operands; when invalid, they are marked either _RES_
+to indicate that the opcode is reserved for future standard extensions;
+_Custom_ to indicate that the opcode is designated for custom
+extensions; or _HINT_ to indicate that the opcode is reserved for
+microarchitectural hints (see <<rvc-hints>>).
+
+<<<
+
+[[rvcopcodemap]]
+.RVC opcode map instructions.
+[%autowidth,float="center",align="center",cols=">,^,^,^,^,^,^,^,^,^,<]
+|===
+2+>|inst[15:13] +
+inst[1:0] ^.^s|000 ^.^s|001 ^.^s|010 ^.^s|011 ^.^s|100 ^.^s|101 ^.^s|110 ^.^s|111 |
+
+2+>.^|00 .^|ADDI4SPN ^.^|FLD +
+FLD ^.^| LW ^.^| FLW +
+LD ^.^| _Reserved_ ^.^| FSD +
+FSD ^.^| SW ^.^| FSW +
+SD
+^.^| RV32 +
+RV64
+
+2+>.^|01 ^.^|ADDI ^.^|JAL +
+ADDIW ^.^|LI ^.^|LUI/ADDI16SP ^.^|MISC-ALU ^.^|J ^.^|BEQZ ^.^|BNEZ ^.^|RV32 +
+RV64
+
+2+>.^|10 ^.^|SLLI ^.^|FLDSP +
+FLDSP ^.^|LWSP ^.^|FLWSP +
+LDSP ^.^|J[AL]R/MV/ADD ^.^|FSDSP +
+FSDSP ^.^|SWSP ^.^|FSWSP +
+SDSP ^.^|RV32 +
+RV64
+
+2+>.^|11 9+^|>16b
+|===
+
+<<rvc-instr-table0>>, <<rvc-instr-table1>>, and <<rvc-instr-table2>> list the RVC instructions.
+
+[[rvc-instr-table0]]
+.Instruction listing for RVC, Quadrant 0
+include::images/bytefield/rvc-instr-quad0.edn[]
+
+[[rvc-instr-table1]]
+.Instruction listing for RVC, Quadrant 1
+include::images/bytefield/rvc-instr-quad1.edn[]
+
+[[rvc-instr-table2]]
+.Instruction listing for RVC, Quadrant 2
+include::images/bytefield/rvc-instr-quad2.edn[]
diff --git a/src/c.tex b/src/c.tex
deleted file mode 100644
index 6d49253..0000000
--- a/src/c.tex
+++ /dev/null
@@ -1,1225 +0,0 @@
-\chapter{``C'' Standard Extension for Compressed Instructions, Version
-2.0}
-\label{compressed}
-
-This chapter describes the current proposal for the RISC-V
-standard compressed instruction-set extension, named ``C'', which
-reduces static and dynamic code size by adding short 16-bit
-instruction encodings for common operations. The C extension can be
-added to any of the base ISAs (RV32, RV64, RV128), and we use the
-generic term ``RVC'' to cover any of these. Typically, 50\%--60\% of
-the RISC-V instructions in a program can be replaced with RVC
-instructions, resulting in a 25\%--30\% code-size reduction.
-
-\section{Overview}
-
-RVC uses a simple compression scheme that offers shorter 16-bit
-versions of common 32-bit RISC-V instructions when:
-\begin{tightlist}
- \item the immediate or address offset is small, or
- \item one of the registers is the zero register ({\tt x0}), the
- ABI link register ({\tt x1}), or the ABI stack pointer ({\tt
- x2}), or
- \item the destination register and the first source register are
- identical, or
- \item the registers used are the 8 most popular ones.
-\end{tightlist}
-
-The C extension is compatible with all other standard instruction
-extensions. The C extension allows 16-bit instructions to be freely
-intermixed with 32-bit instructions, with the latter now able to start
-on any 16-bit boundary, i.e., IALIGN=16. With the addition of the C
-extension, no instructions can raise instruction-address-misaligned
-exceptions.
-
-\pagebreak
-
-\begin{commentary}
-Removing the 32-bit alignment constraint on the original 32-bit
-instructions allows significantly greater code density.
-\end{commentary}
-
-The compressed instruction encodings are mostly common across RV32C,
-RV64C, and RV128C, but as shown in Table~\ref{rvcopcodemap}, a few
-opcodes are used for different purposes depending on base ISA width.
-For example, the wider address-space RV64C and RV128C variants require
-additional opcodes to compress loads and stores of 64-bit integer
-values, while RV32C uses the same opcodes to compress loads and stores
-of single-precision floating-point values. Similarly, RV128C requires
-additional opcodes to capture loads and stores of 128-bit integer
-values, while these same opcodes are used for loads and stores of
-double-precision floating-point values in RV32C and RV64C. If the C
-extension is implemented, the appropriate compressed floating-point
-load and store instructions must be provided whenever the relevant
-standard floating-point extension (F and/or D) is also implemented.
-In addition, RV32C includes a compressed jump and link instruction to
-compress short-range subroutine calls, where the same opcode is used
-to compress ADDIW for RV64C and RV128C.
-
-\begin{commentary}
-Double-precision loads and stores are a significant fraction of static
-and dynamic instructions, hence the motivation to include them in the
-RV32C and RV64C encoding.
-
-Although single-precision loads and stores are not a significant
-source of static or dynamic compression for benchmarks compiled for
-the currently supported ABIs, for microcontrollers that only provide
-hardware single-precision floating-point units and have an ABI that
-only supports single-precision floating-point numbers, the
-single-precision loads and stores will be used at least as frequently
-as double-precision loads and stores in the measured benchmarks.
-Hence, the motivation to provide compressed support for these in
-RV32C.
-
-Short-range subroutine calls are more likely in small binaries for
-microcontrollers, hence the motivation to include these in RV32C.
-
-Although reusing opcodes for different purposes for different base
-register widths adds some complexity to documentation, the impact on
-implementation complexity is small even for designs that support
-multiple base ISA register widths. The compressed floating-point load
-and store variants use the same instruction format with the same
-register specifiers as the wider integer loads and stores.
-\end{commentary}
-
-RVC was designed under the constraint that each RVC instruction
-expands into a single 32-bit instruction in either the base ISA
-(RV32I/E, RV64I, or RV128I) or the F and D standard extensions where
-present. Adopting this constraint has two main benefits:
-
-\begin{tightlist}
-\item Hardware designs can simply expand RVC instructions during
- decode, simplifying verification and minimizing modifications to
- existing microarchitectures.
-\item Compilers can be unaware of the RVC extension and leave code
- compression to the assembler and linker, although a
- compression-aware compiler will generally be able to produce better
- results.
-\end{tightlist}
-
-\begin{commentary}
-We felt the multiple complexity reductions of a simple one-one mapping
-between C and base IFD instructions far outweighed the potential gains
-of a slightly denser encoding that added additional instructions only
-supported in the C extension, or that allowed encoding of multiple IFD
-instructions in one C instruction.
-\end{commentary}
-
-It is important to note that the C extension is not designed to be a
-stand-alone ISA, and is meant to be used alongside a base ISA.
-
-\begin{commentary}
-Variable-length instruction sets have long been used to improve code
-density. For example, the IBM Stretch~\cite{stretch}, developed in
-the late 1950s, had an ISA with 32-bit and 64-bit instructions, where
-some of the 32-bit instructions were compressed versions of the full
-64-bit instructions. Stretch also employed the concept of limiting
-the set of registers that were addressable in some of the shorter
-instruction formats, with short branch instructions that could only
-refer to one of the index registers. The later IBM 360
-architecture~\cite{ibm360} supported a simple variable-length
-instruction encoding with 16-bit, 32-bit, or 48-bit instruction
-formats.
-
-In 1963, CDC introduced the Cray-designed CDC 6600~\cite{cdc6600}, a
-precursor to RISC architectures, that introduced a register-rich
-load-store architecture with instructions of two lengths, 15-bits and
-30-bits. The later Cray-1 design used a very similar instruction
-format, with 16-bit and 32-bit instruction lengths.
-
-The initial RISC ISAs from the 1980s all picked performance over code
-size, which was reasonable for a workstation environment, but not for
-embedded systems. Hence, both ARM and MIPS subsequently made versions
-of the ISAs that offered smaller code size by offering an alternative
-16-bit wide instruction set instead of the standard 32-bit wide
-instructions. The compressed RISC ISAs reduced code size relative to
-their starting points by about 25--30\%, yielding code that was
-significantly \emph{smaller} than 80x86. This result surprised some,
-as their intuition was that the variable-length CISC ISA should be
-smaller than RISC ISAs that offered only 16-bit and 32-bit formats.
-
-Since the original RISC ISAs did not leave sufficient opcode space
-free to include these unplanned compressed instructions, they were
-instead developed as complete new ISAs. This meant compilers needed
-different code generators for the separate compressed ISAs. The first
-compressed RISC ISA extensions (e.g., ARM Thumb and MIPS16) used only
-a fixed 16-bit instruction size, which gave good reductions in static
-code size but caused an increase in dynamic instruction count, which
-led to lower performance compared to the original fixed-width 32-bit
-instruction size. This led to the development of a second generation
-of compressed RISC ISA designs with mixed 16-bit and 32-bit
-instruction lengths (e.g., ARM Thumb2, microMIPS, PowerPC VLE), so
-that performance was similar to pure 32-bit instructions but with
-significant code size savings. Unfortunately, these different
-generations of compressed ISAs are incompatible with each other and
-with the original uncompressed ISA, leading to significant complexity
-in documentation, implementations, and software tools support.
-
-Of the commonly used 64-bit ISAs, only PowerPC and microMIPS currently
-supports a compressed instruction format. It is surprising that the
-most popular 64-bit ISA for mobile platforms (ARM v8) does not include
-a compressed instruction format given that static code size and
-dynamic instruction fetch bandwidth are important metrics. Although
-static code size is not a major concern in larger systems, instruction
-fetch bandwidth can be a major bottleneck in servers running
-commercial workloads, which often have a large instruction working
-set.
-
-Benefiting from 25 years of hindsight, RISC-V was designed to support
-compressed instructions from the outset, leaving enough opcode
-space for RVC to be added as a simple extension on top of the base ISA
-(along with many other extensions). The philosophy of RVC is to
-reduce code size for embedded applications \emph{and} to improve
-performance and energy-efficiency for all applications due to fewer
-misses in the instruction cache. Waterman shows that RVC fetches
-25\%-30\% fewer instruction bits, which reduces instruction cache
-misses by 20\%-25\%, or roughly the same performance impact as
-doubling the instruction cache size~\cite{waterman-ms}.
-\end{commentary}
-
-
-\section{Compressed Instruction Formats}
-
-Table~\ref{rvc-formats} shows the nine compressed instruction
-formats. CR, CI, and CSS can use any of the 32 RVI registers, but CIW,
-CL, CS, CA, and CB are limited to just 8 of them. Table~\ref{registers}
-lists these popular registers, which correspond to registers {\tt x8}
-to {\tt x15}. Note that there is a
-separate version of load and store instructions that use the stack
-pointer as the base address register, since saving to and restoring
-from the stack are so prevalent, and that they use the CI and CSS
-formats to allow access to all 32 data registers. CIW supplies an
-8-bit immediate for the ADDI4SPN instruction.
-
-\begin{commentary}
-The RISC-V ABI was changed to make the frequently used registers map
-to registers {\tt x8}--{\tt x15}. This simplifies the decompression
-decoder by having a contiguous naturally aligned set of register
-numbers, and is also compatible with the RV32E subset base
-specification, which only has 16 integer registers.
-\end{commentary}
-
-Compressed register-based floating-point loads and stores also use the
-CL and CS formats respectively, with the eight registers mapping to
-{\tt f8} to {\tt f15}.
-
-\begin{commentary}
-The standard RISC-V calling convention maps the most frequently used
-floating-point registers to registers {\tt f8} to {\tt f15}, which
-allows the same register decompression decoding as for integer
-register numbers.
-\end{commentary}
-
-The formats were designed to keep bits for the two register source
-specifiers in the same place in all instructions, while the
-destination register field can move. When the full 5-bit destination
-register specifier is present, it is in the same place as in the
-32-bit RISC-V encoding. Where immediates are
-sign-extended, the sign-extension is always from bit 12. Immediate
-fields have been scrambled, as in the base specification, to reduce
-the number of immediate muxes required.
-
-\begin{commentary}
-The immediate fields are scrambled in the instruction formats instead
-of in sequential order so that as many bits as possible are in the
-same position in every instruction, thereby simplifying
-implementations. For example, immediate bits 17---10 are always sourced from
-the same instruction bit positions. Five other immediate bits (5, 4,
-3, 1, and 0) have just two source instruction bits, while four (9, 7,
-6, and 2) have three sources and one (8) has four sources.
-\end{commentary}
-
-For many RVC instructions, zero-valued immediates are disallowed and
-{\tt x0} is not a valid 5-bit register specifier. These restrictions
-free up encoding space for other instructions requiring fewer operand
-bits.
-
-\begin{table}[h]
-{
-\begin{small}
-\begin{center}
-\begin{tabular}{c c p{0in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}}
-& & & & & & & & & \\
-Format & Meaning &
-\instbit{15} &
-\instbit{14} &
-\instbit{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbit{11} &
-\instbit{10} &
-\instbit{9} &
-\instbit{8} &
-\instbit{7} &
-\instbit{6} &
-\multicolumn{1}{r}{\instbit{5}} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\cline{3-18}
-
-CR & Register &
-\multicolumn{4}{|c|}{funct4} &
-\multicolumn{5}{c|}{rd/rs1} &
-\multicolumn{5}{c|}{rs2} &
-\multicolumn{2}{c|}{op} \\
-\cline{3-18}
-
-CI & Immediate &
-\multicolumn{3}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{5}{c|}{rd/rs1} &
-\multicolumn{5}{c|}{imm} &
-\multicolumn{2}{c|}{op} \\
-\cline{3-18}
-
-CSS & Stack-relative Store &
-\multicolumn{3}{|c|}{funct3} &
-\multicolumn{6}{c|}{imm} &
-\multicolumn{5}{c|}{rs2} &
-\multicolumn{2}{c|}{op} \\
-\cline{3-18}
-
-CIW & Wide Immediate &
-\multicolumn{3}{|c|}{funct3} &
-\multicolumn{8}{c|}{imm} &
-\multicolumn{3}{c|}{rd$'$} &
-\multicolumn{2}{c|}{op} \\
-\cline{3-18}
-
-CL & Load &
-\multicolumn{3}{|c|}{funct3} &
-\multicolumn{3}{c|}{imm} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{imm} &
-\multicolumn{3}{c|}{rd$'$} &
-\multicolumn{2}{c|}{op} \\
-\cline{3-18}
-
-CS & Store &
-\multicolumn{3}{|c|}{funct3} &
-\multicolumn{3}{c|}{imm} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{imm} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{op} \\
-\cline{3-18}
-
-CA & Arithmetic &
-\multicolumn{6}{|c|}{funct6} &
-\multicolumn{3}{c|}{rd$'$/rs1$'$} &
-\multicolumn{2}{c|}{funct2} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{op} \\
-\cline{3-18}
-
-CB & Branch &
-\multicolumn{3}{|c|}{funct3} &
-\multicolumn{3}{c|}{offset} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{5}{c|}{offset} &
-\multicolumn{2}{c|}{op} \\
-\cline{3-18}
-
-CJ & Jump &
-\multicolumn{3}{|c|}{funct3} &
-\multicolumn{11}{c|}{jump target} &
-\multicolumn{2}{c|}{op} \\
-\cline{3-18}
-
-\end{tabular}
-\end{center}
-\end{small}
-}
-\caption{Compressed 16-bit RVC instruction formats.}
-\label{rvc-formats}
-\end{table}
-
-
-\begin{table}[H]
-{
-\begin{center}
-\begin{tabular}{l|c|c|c|c|c|c|c|c|}
-\cline{2-9}
-RVC Register Number & 000 & 001 & 010 & 011 & 100 & 101 & 110 & 111
-\\ \cline{2-9}
-Integer Register Number & {\tt x8} & {\tt x9} & {\tt x10} & {\tt x11} & {\tt x12} & {\tt x13} & {\tt x14} & {\tt x15} \\ \cline{2-9}
-Integer Register ABI Name & {\tt s0} & {\tt s1} & {\tt a0} & {\tt a1} & {\tt a2} & {\tt a3} & {\tt a4} & {\tt a5} \\ \cline{2-9}
-Floating-Point Register Number & {\tt f8} & {\tt f9} & {\tt f10} & {\tt f11} & {\tt f12} & {\tt f13} & {\tt f14} & {\tt f15} \\ \cline{2-9}
-Floating-Point Register ABI Name & {\tt fs0} & {\tt fs1} & {\tt fa0} & {\tt fa1} & {\tt fa2} & {\tt fa3} & {\tt fa4} & {\tt fa5} \\ \cline{2-9}
-\end{tabular}
-\end{center}
-}
-\caption{Registers specified by the three-bit {\em rs1$'$}, {\em rs2$'$}, and {\em rd$'$} fields of the CIW, CL, CS, CA, and CB formats.}
-\label{registers}
-\end{table}
-
-\section{Load and Store Instructions}
-
-To increase the reach of 16-bit instructions, data-transfer
-instructions use zero-extended immediates that are scaled by the size
-of the data in bytes: $\times$4 for words, $\times$8 for double words,
-and $\times$16 for quad words.
-
-RVC provides two variants of loads and stores. One uses the ABI stack
-pointer, {\tt x2}, as the base address and can target any data register. The
-other can reference one of 8 base address registers and one of 8 data
-registers.
-
-\subsection*{Stack-Pointer-Based Loads and Stores}
-
-\begin{center}
-\begin{tabular}{S@{}W@{}T@{}T@{}Y}
-\\
-\instbitrange{15}{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbitrange{11}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 1 & 5 & 5 & 2 \\
-C.LWSP & offset[5] & dest$\neq$0 & offset[4:2$\vert$7:6] & C2 \\
-C.LDSP & offset[5] & dest$\neq$0 & offset[4:3$\vert$8:6] & C2 \\
-C.LQSP & offset[5] & dest$\neq$0 & offset[4$\vert$9:6] & C2 \\
-C.FLWSP& offset[5] & dest & offset[4:2$\vert$7:6] & C2 \\
-C.FLDSP& offset[5] & dest & offset[4:3$\vert$8:6] & C2 \\
-\end{tabular}
-\end{center}
-These instructions use the CI format.
-
-C.LWSP loads a 32-bit value from memory into register {\em rd}. It computes
-an effective address by adding the {\em zero}-extended offset, scaled by 4, to
-the stack pointer, {\tt x2}. It expands to {\tt lw rd, offset[7:2](x2)}.
-C.LWSP is only valid when $\textit{rd}{\neq}\texttt{x0}$.
-
-C.LDSP is an RV64C/RV128C-only instruction that loads a 64-bit value from memory into
-register {\em rd}. It computes its effective address by adding the
-zero-extended offset, scaled by 8, to the stack pointer, {\tt x2}.
-It expands to {\tt ld rd, offset[8:3](x2)}.
-C.LDSP is only valid when $\textit{rd}{\neq}\texttt{x0}$.
-
-C.LQSP is an RV128C-only instruction that loads a 128-bit value from memory
-into register {\em rd}. It computes its effective address by adding the
-zero-extended offset, scaled by 16, to the stack pointer, {\tt x2}.
-It expands to {\tt lq rd, offset[9:4](x2)}.
-C.LQSP is only valid when $\textit{rd}{\neq}\texttt{x0}$.
-
-C.FLWSP is an RV32FC-only instruction that loads a single-precision
-floating-point value from memory into floating-point register {\em rd}. It
-computes its effective address by adding the {\em zero}-extended offset,
-scaled by 4, to the stack pointer, {\tt x2}. It expands to {\tt flw rd,
-offset[7:2](x2)}.
-
-C.FLDSP is an RV32DC/RV64DC-only instruction that loads a double-precision
-floating-point value from memory into floating-point register {\em rd}. It
-computes its effective address by adding the {\em zero}-extended offset,
-scaled by 8, to the stack pointer, {\tt x2}. It expands to {\tt fld rd,
-offset[8:3](x2)}.
-
-\begin{center}
-\begin{tabular}{S@{}M@{}T@{}Y}
-\\
-\instbitrange{15}{13} &
-\instbitrange{12}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 6 & 5 & 2 \\
-C.SWSP & offset[5:2$\vert$7:6] & src & C2 \\
-C.SDSP & offset[5:3$\vert$8:6] & src & C2 \\
-C.SQSP & offset[5:4$\vert$9:6] & src & C2 \\
-C.FSWSP& offset[5:2$\vert$7:6] & src & C2 \\
-C.FSDSP& offset[5:3$\vert$8:6] & src & C2 \\
-\end{tabular}
-\end{center}
-These instructions use the CSS format.
-
-C.SWSP stores a 32-bit value in register {\em rs2} to memory. It computes
-an effective address by adding the {\em zero}-extended offset, scaled by 4, to
-the stack pointer, {\tt x2}.
-It expands to {\tt sw rs2, offset[7:2](x2)}.
-
-C.SDSP is an RV64C/RV128C-only instruction that stores a 64-bit value in register
-{\em rs2} to memory. It computes an effective address by adding the {\em
-zero}-extended offset, scaled by 8, to the stack pointer, {\tt x2}.
-It expands to {\tt sd rs2, offset[8:3](x2)}.
-
-C.SQSP is an RV128C-only instruction that stores a 128-bit value in register
-{\em rs2} to memory. It computes an effective address by adding the {\em
-zero}-extended offset, scaled by 16, to the stack pointer, {\tt x2}.
-It expands to {\tt sq rs2, offset[9:4](x2)}.
-
-C.FSWSP is an RV32FC-only instruction that stores a single-precision
-floating-point value in floating-point register {\em rs2} to memory. It
-computes an effective address by adding the {\em zero}-extended offset, scaled
-by 4, to the stack pointer, {\tt x2}. It expands to {\tt fsw rs2,
-offset[7:2](x2)}.
-
-C.FSDSP is an RV32DC/RV64DC-only instruction that stores a double-precision
-floating-point value in floating-point register {\em rs2} to memory. It
-computes an effective address by adding the {\em zero}-extended offset, scaled
-by 8, to the stack pointer, {\tt x2}. It expands to {\tt fsd rs2,
-offset[8:3](x2)}.
-
-\begin{commentary}
-Register save/restore code at function entry/exit represents a
-significant portion of static code size. The stack-pointer-based
-compressed loads and stores in RVC are effective at reducing the
-save/restore static code size by a factor of 2 while improving
-performance by reducing dynamic instruction bandwidth.
-
-A common mechanism used in other ISAs to further reduce
-save/restore code size is load-multiple and store-multiple
-instructions. We considered adopting these for RISC-V but noted the
-following drawbacks to these instructions:
-\begin{itemize}
-\item These instructions complicate processor implementations.
-\item For virtual memory systems, some data accesses could be
- resident in physical memory and some could not, which requires a
- new restart mechanism for partially executed instructions.
-\item Unlike the rest of the RVC instructions, there is no IFD
- equivalent to Load Multiple and Store Multiple.
-\item Unlike the rest of the RVC instructions, the compiler would
- have to be aware of these instructions to both generate the
- instructions and to allocate registers in an order to maximize
- the chances of the them being saved and stored, since they would
- be saved and restored in sequential order.
-\item Simple microarchitectural implementations will constrain how
- other instructions can be scheduled around the load and store
- multiple instructions, leading to a potential performance loss.
-\item The desire for sequential register allocation might conflict with
- the featured registers selected for the CIW, CL, CS, CA, and CB formats.
-\end{itemize}
-Furthermore, much of the gains can be realized in software by replacing
-prologue and epilogue code with subroutine calls to common
-prologue and epilogue code, a technique described in
-Section 5.6 of~\cite{waterman-phd}.
-
-While reasonable architects might come to different conclusions, we
-decided to omit load and store multiple and instead use the
-software-only approach of calling save/restore millicode routines to
-attain the greatest code size reduction.
-\end{commentary}
-
-\subsection*{Register-Based Loads and Stores}
-
-\begin{center}
-\begin{tabular}{S@{}S@{}S@{}Y@{}S@{}Y}
-\\
-\instbitrange{15}{13} &
-\instbitrange{12}{10} &
-\instbitrange{9}{7} &
-\instbitrange{6}{5} &
-\instbitrange{4}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{rs1$'$} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{rd$'$} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 3 & 3 & 2 & 3 & 2 \\
-C.LW & offset[5:3] & base & offset[2$\vert$6] & dest & C0 \\
-C.LD & offset[5:3] & base & offset[7:6] & dest & C0 \\
-C.LQ & offset[5$\vert$4$\vert$8] & base & offset[7:6] & dest & C0 \\
-C.FLW& offset[5:3] & base & offset[2$\vert$6] & dest & C0 \\
-C.FLD& offset[5:3] & base & offset[7:6] & dest & C0 \\
-\end{tabular}
-\end{center}
-These instructions use the CL format.
-
-C.LW loads a 32-bit value from memory into register {\em rd$'$}. It computes
-an effective address by adding the {\em zero}-extended offset, scaled by 4, to
-the base address in register {\em rs1$'$}.
-It expands to {\tt lw rd$'$, offset[6:2](rs1$'$)}.
-
-C.LD is an RV64C/RV128C-only instruction that loads a 64-bit value from memory into
-register {\em rd$'$}. It computes an effective address by adding the {\em
-zero}-extended offset, scaled by 8, to the base address in register {\em
-rs1$'$}.
-It expands to {\tt ld rd$'$, offset[7:3](rs1$'$)}.
-
-C.LQ is an RV128C-only instruction that loads a 128-bit value from memory into
-register {\em rd$'$}. It computes an effective address by adding the {\em
-zero}-extended offset, scaled by 16, to the base address in register {\em
-rs1$'$}.
-It expands to {\tt lq rd$'$, offset[8:4](rs1$'$)}.
-
-C.FLW is an RV32FC-only instruction that loads a single-precision
-floating-point value from memory into floating-point register {\em rd$'$}. It
-computes an effective address by adding the {\em zero}-extended offset, scaled
-by 4, to the base address in register {\em rs1$'$}. It expands to {\tt flw
-rd$'$, offset[6:2](rs1$'$)}.
-
-C.FLD is an RV32DC/RV64DC-only instruction that loads a double-precision
-floating-point value from memory into floating-point register {\em rd$'$}. It
-computes an effective address by adding the {\em zero}-extended offset, scaled
-by 8, to the base address in register {\em rs1$'$}. It expands to {\tt fld
-rd$'$, offset[7:3](rs1$'$)}.
-
-\begin{center}
-\begin{tabular}{S@{}S@{}S@{}Y@{}S@{}Y}
-\\
-\instbitrange{15}{13} &
-\instbitrange{12}{10} &
-\instbitrange{9}{7} &
-\instbitrange{6}{5} &
-\instbitrange{4}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{rs1$'$} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{rs2$'$} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 3 & 3 & 2 & 3 & 2 \\
-C.SW & offset[5:3] & base & offset[2$\vert$6] & src & C0 \\
-C.SD & offset[5:3] & base & offset[7:6] & src & C0 \\
-C.SQ & offset[5$\vert$4$\vert$8] & base & offset[7:6] & src & C0 \\
-C.FSW& offset[5:3] & base & offset[2$\vert$6] & src & C0 \\
-C.FSD& offset[5:3] & base & offset[7:6] & src & C0 \\
-\end{tabular}
-\end{center}
-These instructions use the CS format.
-
-C.SW stores a 32-bit value in register {\em rs2$'$} to memory. It computes an
-effective address by adding the {\em zero}-extended offset, scaled by 4, to
-the base address in register {\em rs1$'$}.
-It expands to {\tt sw rs2$'$, offset[6:2](rs1$'$)}.
-
-C.SD is an RV64C/RV128C-only instruction that stores a 64-bit value in
-register {\em rs2$'$} to memory. It computes an effective address by adding
-the {\em zero}-extended offset, scaled by 8, to the base address in register
-{\em rs1$'$}.
-It expands to {\tt sd rs2$'$, offset[7:3](rs1$'$)}.
-
-C.SQ is an RV128C-only instruction that stores a 128-bit value in register
-{\em rs2$'$} to memory. It computes an effective address by adding the {\em
-zero}-extended offset, scaled by 16, to the base address in register {\em
-rs1$'$}.
-It expands to {\tt sq rs2$'$, offset[8:4](rs1$'$)}.
-
-C.FSW is an RV32FC-only instruction that stores a single-precision
-floating-point value in floating-point register {\em rs2$'$} to memory. It
-computes an effective address by adding the {\em zero}-extended offset, scaled
-by 4, to the base address in register {\em rs1$'$}. It expands to {\tt fsw
-rs2$'$, offset[6:2](rs1$'$)}.
-
-C.FSD is an RV32DC/RV64DC-only instruction that stores a double-precision
-floating-point value in floating-point register {\em rs2$'$} to memory. It
-computes an effective address by adding the {\em zero}-extended offset, scaled
-by 8, to the base address in register {\em rs1$'$}. It expands to {\tt fsd
-rs2$'$, offset[7:3](rs1$'$)}.
-
-\section{Control Transfer Instructions}
-
-RVC provides unconditional jump instructions and conditional branch
-instructions. As with base RVI instructions, the offsets of all RVC
-control transfer instruction are in multiples of 2 bytes.
-
-\begin{center}
-\begin{tabular}{S@{}L@{}Y}
-\\
-\instbitrange{15}{13} &
-\instbitrange{12}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 11 & 2 \\
-C.J & offset[11$\vert$4$\vert$9:8$\vert$10$\vert$6$\vert$7$\vert$3:1$\vert$5] & C1 \\
-C.JAL & offset[11$\vert$4$\vert$9:8$\vert$10$\vert$6$\vert$7$\vert$3:1$\vert$5] & C1 \\
-\end{tabular}
-\end{center}
-These instructions use the CJ format.
-
-C.J performs an unconditional control transfer. The offset is sign-extended and
-added to the {\tt pc} to form the jump target address. C.J can therefore target
-a $\pm$\wunits{2}{KiB} range. C.J expands to {\tt jal x0, offset[11:1]}.
-
-C.JAL is an RV32C-only instruction that performs the same operation as C.J,
-but additionally writes the address of the instruction following the jump
-({\tt pc}+2) to the link register, {\tt x1}. C.JAL expands to {\tt jal x1,
-offset[11:1]}.
-
-\begin{center}
-\begin{tabular}{E@{}T@{}T@{}Y}
-\\
-\instbitrange{15}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct4} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{op} \\
-\hline
-4 & 5 & 5 & 2 \\
-C.JR & src$\neq$0 & 0 & C2 \\
-C.JALR & src$\neq$0 & 0 & C2 \\
-\end{tabular}
-\end{center}
-These instructions use the CR format.
-
-C.JR (jump register) performs an unconditional control transfer to
-the address in register {\em rs1}. C.JR expands to {\tt jalr x0, 0(rs1)}.
-
-C.JALR (jump and link register) performs the same operation as C.JR,
-but additionally writes the address of the instruction following the
-jump ({\tt pc}+2) to the link register, {\tt x1}. C.JALR expands to
-{\tt jalr x1, 0(rs1)}.
-
-\begin{commentary}
-Strictly speaking, C.JALR does not expand exactly to a base RVI
-instruction as the value added to the PC to form the link address is 2
-rather than 4 as in the base ISA, but supporting both offsets of 2 and
-4 bytes is only a very minor change to the base microarchitecture.
-\end{commentary}
-
-\begin{center}
-\begin{tabular}{S@{}S@{}S@{}T@{}Y}
-\\
-\instbitrange{15}{13} &
-\instbitrange{12}{10} &
-\instbitrange{9}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{rs1$'$} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 3 & 3 & 5 & 2 \\
-C.BEQZ & offset[8$\vert$4:3] & src & offset[7:6$\vert$2:1$\vert$5] & C1 \\
-C.BNEZ & offset[8$\vert$4:3] & src & offset[7:6$\vert$2:1$\vert$5] & C1 \\
-\end{tabular}
-\end{center}
-These instructions use the CB format.
-
-C.BEQZ performs conditional control transfers. The offset is sign-extended
-and added to the {\tt pc} to form the branch target address. It can
-therefore target a $\pm$\wunits{256}{B} range. C.BEQZ takes the branch if the
-value in register {\em rs1$'$} is zero. It expands to {\tt beq rs1$'$, x0,
-offset[8:1]}.
-
-C.BNEZ is defined analogously, but it takes the branch if {\em rs1$'$} contains
-a nonzero value. It expands to {\tt bne rs1$'$, x0, offset[8:1]}.
-
-\section{Integer Computational Instructions}
-
-RVC provides several instructions for integer arithmetic and constant generation.
-
-\subsection*{Integer Constant-Generation Instructions}
-
-The two constant-generation instructions both use the CI instruction
-format and can target any integer register.
-
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{S@{}W@{}T@{}T@{}Y}
-\\
-\instbitrange{15}{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbitrange{11}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm[5]} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 1 & 5 & 5 & 2 \\
-C.LI & imm[5] & dest$\neq$0 & imm[4:0] & C1 \\
-C.LUI & nzimm[17] & $\textrm{dest}{\neq}{\left\{0,2\right\}}$ & nzimm[16:12] & C1 \\
-\end{tabular}
-\end{center}
-C.LI loads the sign-extended 6-bit immediate, {\em imm}, into
-register {\em rd}. C.LI is only valid when {\em rd}$\neq${\tt x0}.
-C.LI expands into {\tt addi rd, x0, imm[5:0]}.
-
-C.LUI loads the non-zero 6-bit immediate field into bits 17--12 of the
-destination register, clears the bottom 12 bits, and sign-extends bit
-17 into all higher bits of the destination. C.LUI is only valid when
-$\textit{rd}{\neq}{\left\{\texttt{x0},\texttt{x2}\right\}}$,
-and when the immediate is not equal to zero.
-C.LUI expands into {\tt lui rd, nzimm[17:12]}.
-
-\subsection*{Integer Register-Immediate Operations}
-
-These integer register-immediate operations are encoded in the CI
-format and perform operations on an integer register and
-a 6-bit immediate.
-
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{S@{}W@{}T@{}T@{}Y}
-\\
-\instbitrange{15}{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbitrange{11}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm[5]} &
-\multicolumn{1}{c|}{rd/rs1} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 1 & 5 & 5 & 2 \\
-C.ADDI & nzimm[5] & dest$\neq$0 & nzimm[4:0] & C1 \\
-C.ADDIW & imm[5] & dest$\neq$0 & imm[4:0] & C1 \\
-C.ADDI16SP & nzimm[9] & 2 & nzimm[4$\vert$6$\vert$8:7$\vert$5] & C1 \\
-\end{tabular}
-\end{center}
-
-C.ADDI adds the non-zero sign-extended 6-bit immediate to the value in
-register {\em rd} then writes the result to {\em rd}. C.ADDI expands
-into {\tt addi rd, rd, nzimm[5:0]}.
-C.ADDI is only valid when {\em rd}$\neq${\tt x0}.
-
-C.ADDIW is an RV64C/RV128C-only instruction that performs the same
-computation but produces a 32-bit result, then sign-extends result to
-64 bits. C.ADDIW expands into {\tt addiw rd, rd, imm[5:0]}. The
-immediate can be zero for C.ADDIW, where this corresponds to {\tt
-sext.w rd}. C.ADDIW is only valid when {\em rd}$\neq${\tt x0}.
-
-C.ADDI16SP shares the opcode with C.LUI, but has a destination field
-of {\tt x2}. C.ADDI16SP adds the non-zero sign-extended 6-bit immediate to
-the value in the stack pointer ({\tt sp}={\tt x2}), where the
-immediate is scaled to represent multiples of 16 in the range
-(-512,496). C.ADDI16SP is used to adjust the stack pointer in procedure
-prologues and epilogues. It expands into {\tt addi x2, x2, nzimm[9:4]}.
-
-\begin{commentary}
-In the standard RISC-V calling convention, the stack pointer {\tt sp}
-is always 16-byte aligned.
-\end{commentary}
-
-\begin{center}
-\begin{tabular}{@{}S@{}K@{}S@{}Y}
-\\
-\instbitrange{15}{13} &
-\instbitrange{12}{5} &
-\instbitrange{4}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm} &
-\multicolumn{1}{c|}{rd$'$} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 8 & 3 & 2 \\
-C.ADDI4SPN & nzuimm[5:4$\vert$9:6$\vert$2$\vert$3] & dest & C0 \\
-\end{tabular}
-\end{center}
-
-C.ADDI4SPN is a CIW-format instruction that adds a {\em zero}-extended
-non-zero immediate, scaled by 4, to the stack pointer, {\tt x2}, and
-writes the result to {\tt rd$'$}. This instruction is used
-to generate pointers to stack-allocated variables, and expands to
-{\tt addi rd$'$, x2, nzuimm[9:2]}.
-
-
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{S@{}W@{}T@{}T@{}Y}
-\\
-\instbitrange{15}{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbitrange{11}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{shamt[5]} &
-\multicolumn{1}{c|}{rd/rs1} &
-\multicolumn{1}{c|}{shamt[4:0]} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 1 & 5 & 5 & 2 \\
-C.SLLI & shamt[5] & dest$\neq$0 & shamt[4:0] & C2 \\
-\end{tabular}
-\end{center}
-
-C.SLLI is a CI-format instruction that performs a logical left shift
-of the value in register {\em rd} then writes the result to {\em rd}.
-The shift amount is encoded in the {\em shamt} field, where {\em
- shamt[5]} must be zero for RV32C. For RV32C and RV64C, the shift
-amount must be non-zero. For RV128C, a shift amount of zero is used
-to encode a shift of 64. C.SLLI expands into {\tt slli rd, rd,
- shamt[5:0]}, except for RV128C with {\tt shamt=0}, which expands to
-{\tt slli rd, rd, 64}.
-
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{S@{}W@{}Y@{}S@{}T@{}Y}
-\\
-\instbitrange{15}{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbitrange{11}{10} &
-\instbitrange{9}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{shamt[5]} &
-\multicolumn{1}{|c|}{funct2} &
-\multicolumn{1}{c|}{rd$'$/rs1$'$} &
-\multicolumn{1}{c|}{shamt[4:0]} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 1 & 2 & 3 & 5 & 2 \\
-C.SRLI & shamt[5] & C.SRLI & dest & shamt[4:0] & C1 \\
-C.SRAI & shamt[5] & C.SRAI & dest & shamt[4:0] & C1 \\
-\end{tabular}
-\end{center}
-
-C.SRLI is a CB-format instruction that performs a logical right shift
-of the value in register {\em rd$'$} then writes the result to {\em rd$'$}.
-The shift amount is encoded in the {\em shamt} field, where {\em
- shamt[5]} must be zero for RV32C. For RV32C and RV64C, the shift
-amount must be non-zero. For RV128C, a shift amount of zero is used
-to encode a shift of 64. Furthermore, the shift amount is sign-extended
-for RV128C, and so the legal shift amounts are 1--31, 64, and 96--127.
-C.SRLI expands into {\tt srli rd$'$, rd$'$, shamt[5:0]},
-except for RV128C with {\tt shamt=0}, which expands to
-{\tt srli rd$'$, rd$'$, 64}.
-
-C.SRAI is defined analogously to C.SRLI, but instead performs an arithmetic
-right shift.
-C.SRAI expands to {\tt srai rd$'$, rd$'$, shamt[5:0]}.
-
-\begin{commentary}
-Left shifts are usually more frequent than right shifts, as left
-shifts are frequently used to scale address values. Right shifts have
-therefore been granted less encoding space and are placed in an
-encoding quadrant where all other immediates are sign-extended. For
-RV128, the decision was made to have the 6-bit shift-amount immediate
-also be sign-extended. Apart from reducing the decode complexity, we
-believe right-shift amounts of 96--127 will be more useful than 64--95,
-to allow extraction of tags located in the high portions of 128-bit
-address pointers. We note that RV128C will not be frozen at the same
-point as RV32C and RV64C, to allow evaluation of typical usage of
-128-bit address-space codes.
-\end{commentary}
-
-\begin{center}
-\begin{tabular}{S@{}W@{}Y@{}S@{}T@{}Y}
-\\
-\instbitrange{15}{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbitrange{11}{10} &
-\instbitrange{9}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm[5]} &
-\multicolumn{1}{|c|}{funct2} &
-\multicolumn{1}{c|}{rd$'$/rs1$'$} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 1 & 2 & 3 & 5 & 2 \\
-C.ANDI & imm[5] & C.ANDI & dest & imm[4:0] & C1 \\
-\end{tabular}
-\end{center}
-
-C.ANDI is a CB-format instruction that computes the bitwise AND of
-of the value in register {\em rd$'$} and the sign-extended 6-bit immediate,
-then writes the result to {\em rd$'$}.
-C.ANDI expands to {\tt andi rd$'$, rd$'$, imm[5:0]}.
-
-\subsection*{Integer Register-Register Operations}
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{E@{}T@{}T@{}Y}
-\\
-\instbitrange{15}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct4} &
-\multicolumn{1}{c|}{rd/rs1} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{op} \\
-\hline
-4 & 5 & 5 & 2 \\
-C.MV & dest$\neq$0 & src$\neq$0 & C2 \\
-C.ADD & dest$\neq$0 & src$\neq$0 & C2 \\
-\end{tabular}
-\end{center}
-These instructions use the CR format.
-
-C.MV copies the value in register {\em rs2} into register {\em rd}. C.MV
-expands into {\tt add rd, x0, rs2}.
-
-\begin{commentary}
-C.MV expands to a different instruction than the canonical MV
-pseudoinstruction, which instead uses ADDI. Implementations that handle MV
-specially, e.g. using register-renaming hardware, may find it more convenient
-to expand C.MV to MV instead of ADD, at slight additional hardware cost.
-\end{commentary}
-
-C.ADD adds the values in registers {\em rd} and {\em rs2} and writes the
-result to register {\em rd}. C.ADD expands into {\tt add rd, rd, rs2}.
-
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{M@{}S@{}Y@{}S@{}Y}
-\\
-\instbitrange{15}{10} &
-\instbitrange{9}{7} &
-\instbitrange{6}{5} &
-\instbitrange{4}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct6} &
-\multicolumn{1}{c|}{rd$'$/rs1$'$} &
-\multicolumn{1}{c|}{funct2} &
-\multicolumn{1}{c|}{rs2$'$} &
-\multicolumn{1}{c|}{op} \\
-\hline
-6 & 3 & 2 & 3 & 2 \\
-C.AND & dest & C.AND & src & C1 \\
-C.OR & dest & C.OR & src & C1 \\
-C.XOR & dest & C.XOR & src & C1 \\
-C.SUB & dest & C.SUB & src & C1 \\
-C.ADDW & dest & C.ADDW & src & C1 \\
-C.SUBW & dest & C.SUBW & src & C1 \\
-\end{tabular}
-\end{center}
-
-These instructions use the CA format.
-
-C.AND computes the bitwise AND of the values in registers {\em rd$'$}
-and {\em rs2$'$}, then writes the result to register {\em rd$'$}.
-C.AND expands into {\tt and rd$'$, rd$'$, rs2$'$}.
-
-C.OR computes the bitwise OR of the values in registers {\em rd$'$}
-and {\em rs2$'$}, then writes the result to register {\em rd$'$}.
-C.OR expands into {\tt or rd$'$, rd$'$, rs2$'$}.
-
-C.XOR computes the bitwise XOR of the values in registers {\em rd$'$}
-and {\em rs2$'$}, then writes the result to register {\em rd$'$}.
-C.XOR expands into {\tt xor rd$'$, rd$'$, rs2$'$}.
-
-C.SUB subtracts the value in register {\em rs2$'$} from the value in
-register {\em rd$'$}, then writes the result to register {\em rd$'$}.
-C.SUB expands into {\tt sub rd$'$, rd$'$, rs2$'$}.
-
-C.ADDW is an RV64C/RV128C-only instruction that adds the values in
-registers {\em rd$'$} and {\em rs2$'$}, then sign-extends the lower
-32 bits of the sum before writing the result to register {\em rd$'$}.
-C.ADDW expands into {\tt addw rd$'$, rd$'$, rs2$'$}.
-
-C.SUBW is an RV64C/RV128C-only instruction that subtracts the value in
-register {\em rs2$'$} from the value in register {\em rd$'$}, then
-sign-extends the lower 32 bits of the difference before writing the result
-to register {\em rd$'$}. C.SUBW expands into {\tt subw rd$'$, rd$'$, rs2$'$}.
-
-\begin{commentary}
-This group of six instructions do not provide large savings
-individually, but do not occupy much encoding space and are
-straightforward to implement, and as a group provide a worthwhile
-improvement in static and dynamic compression.
-\end{commentary}
-
-\subsection*{Defined Illegal Instruction}
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{SW@{}T@{}T@{}Y}
-\\
-\instbitrange{15}{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbitrange{11}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{0} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{1}{c|}{0} \\
-\hline
-3 & 1 & 5 & 5 & 2 \\
-0 & 0 & 0 & 0 & 0 \\
-\end{tabular}
-\end{center}
-
-A 16-bit instruction with all bits zero is permanently reserved as an
-illegal instruction.
-\begin{commentary}
-We reserve all-zero instructions to be illegal instructions to help
-trap attempts to execute zero-ed or non-existent portions of the
-memory space. The all-zero value should not be redefined in any
-non-standard extension. Similarly, we reserve instructions with all
-bits set to 1 (corresponding to very long instructions in the RISC-V
-variable-length encoding scheme) as illegal to capture another common
-value seen in non-existent memory regions.
-\end{commentary}
-
-\subsection*{NOP Instruction}
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{SW@{}T@{}T@{}Y}
-\\
-\instbitrange{15}{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbitrange{11}{7} &
-\instbitrange{6}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct3} &
-\multicolumn{1}{c|}{imm[5]} &
-\multicolumn{1}{c|}{rd/rs1} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{op} \\
-\hline
-3 & 1 & 5 & 5 & 2 \\
-C.NOP & 0 & 0 & 0 & C1 \\
-\end{tabular}
-\end{center}
-
-C.NOP is a CI-format instruction that does not change any user-visible state,
-except for advancing the {\tt pc} and incrementing any applicable performance
-counters. C.NOP expands to {\tt nop}.
-
-\subsection*{Breakpoint Instruction}
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{E@{}U@{}Y}
-\\
-\instbitrange{15}{12} &
-\instbitrange{11}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct4} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{1}{c|}{op} \\
-\hline
-4 & 10 & 2 \\
-C.EBREAK & 0 & C2 \\
-\end{tabular}
-\end{center}
-
-Debuggers can use the C.EBREAK instruction, which expands to {\tt ebreak},
-to cause control to be transferred back to the debugging environment.
-C.EBREAK shares the opcode with the C.ADD instruction, but with {\em
- rd} and {\em rs2} both zero, thus can also use the CR format.
-
-\section{Usage of C Instructions in LR/SC Sequences}
-
-On implementations that support the C extension, compressed forms of
-the I instructions permitted inside LR/SC sequences can be used while
-retaining the guarantee of eventual success, as described in
-Section~\ref{lrscseq}.
-
-\begin{commentary}
-The implication is that any implementation that claims to support both
-the A and C extensions must ensure that LR/SC sequences containing
-valid C instructions will eventually complete.
-\end{commentary}
-
-\section{HINT Instructions}
-\label{sec:rvc-hints}
-
-A portion of the RVC encoding space is reserved for microarchitectural HINTs.
-Like the HINTs in the RV32I base ISA (see Section~\ref{sec:rv32i-hints}),
-these instructions do not modify any architectural state, except for advancing
-the {\tt pc} and any applicable performance counters. HINTs are
-executed as no-ops on implementations that ignore them.
-
-RVC HINTs are encoded as computational instructions that do not modify the
-architectural state, either because {\em rd}={\tt x0}
-(e.g. \mbox{C.ADD {\em x0}, {\em t0}}), or because {\em rd} is overwritten
-with a copy of itself (e.g. \mbox{C.ADDI {\em t0}, 0}).
-
-\begin{commentary}
-This HINT encoding has been chosen so that simple implementations can ignore
-HINTs altogether, and instead execute a HINT as a regular computational
-instruction that happens not to mutate the architectural state.
-\end{commentary}
-
-RVC HINTs do not necessarily expand to their RVI HINT counterparts. For
-example, \mbox{C.ADD {\em x0}, {\em t0}} might not encode the same HINT
-as \mbox{ADD {\em x0}, {\em x0}, {\em t0}}.
-
-\begin{commentary}
-The primary reason to not require an RVC HINT to expand to an RVI HINT
-is that HINTs are unlikely to be compressible in the same manner as
-the underlying computational instruction. Also, decoupling the RVC
-and RVI HINT mappings allows the scarce RVC HINT space to be allocated
-to the most popular HINTs, and in particular, to HINTs that are
-amenable to macro-op fusion.
-\end{commentary}
-
-Table~\ref{tab:rvc-hints} lists all RVC HINT code points. For RV32C, 78\% of
-the HINT space is reserved for standard HINTs, but none are presently defined.
-The remainder of the HINT space is reserved for custom HINTs: no standard
-HINTs will ever be defined in this subspace.
-
-\begin{table}[hbt]
-\centering
-\begin{tabular}{|l|l|r|l|}
- \hline
- Instruction & Constraints & Code Points & Purpose \\ \hline \hline
- C.NOP & {\em nzimm}$\neq$0 & 63 & \multirow{6}{*}{\em Reserved for future standard use} \\ \cline{1-3}
- C.ADDI & {\em rd}$\neq${\tt x0}, {\em nzimm}=0 & 31 & \\ \cline{1-3}
- C.LI & {\em rd}={\tt x0} & 64 & \\ \cline{1-3}
- C.LUI & {\em rd}={\tt x0}, {\em nzimm}$\neq$0 & 63 & \\ \cline{1-3}
- C.MV & {\em rd}={\tt x0}, {\em rs2}$\neq${\tt x0} & 31 & \\ \cline{1-3}
- C.ADD & {\em rd}={\tt x0}, {\em rs2}$\neq${\tt x0} & 31 & \\ \hline \hline
- \multirow{2}{*}{C.SLLI} & \multirow{2}{*}{{\em rd}={\tt x0}, {\em nzimm}$\neq$0} & 31 (RV32) & \multirow{6}{*}{\em Reserved for custom use} \\
- & & 63 (RV64/128) & \\ \cline{1-3}
- C.SLLI64 & {\em rd}={\tt x0} & 1 & \\ \cline{1-3}
- C.SLLI64 & {\em rd}$\neq${\tt x0}, RV32 and RV64 only & 31 & \\ \cline{1-3}
- C.SRLI64 & RV32 and RV64 only & 8 & \\ \cline{1-3}
- C.SRAI64 & RV32 and RV64 only & 8 & \\ \hline
-\end{tabular}
-\caption{RVC HINT instructions.}
-\label{tab:rvc-hints}
-\end{table}
-
-\clearpage
-
-\section{RVC Instruction Set Listings}
-
-Table~\ref{rvcopcodemap} shows a map of the major opcodes for RVC.
-Opcodes with the lower two bits set correspond to instructions wider
-than 16 bits, including those in the base ISAs. Several instructions
-are only valid for certain operands; when invalid, they are marked
-either {\em RES} to indicate that the opcode is reserved for future
-standard extensions; {\em NSE} to indicate that the opcode is reserved
-for non-standard extensions; or {\em HINT} to indicate that the opcode
-is reserved for microarchitectural hints (see Section~\ref{sec:rvc-hints}).
-
-\input{rvc-opcode-map}
-
-Tables~\ref{rvc-instr-table0}--\ref{rvc-instr-table2} list the RVC instructions.
-\input{rvc-instr-table}
diff --git a/src/calling-convention.adoc b/src/calling-convention.adoc
new file mode 100644
index 0000000..f5cb079
--- /dev/null
+++ b/src/calling-convention.adoc
@@ -0,0 +1,29 @@
+[appendix]
+== Calling Convention for Vector State (Not authoritative - Placeholder Only)
+
+NOTE: This Appendix is only a placeholder to help explain the
+conventions used in the code examples, and is not considered frozen or
+part of the ratification process. The official RISC-V psABI document
+is being expanded to specify the vector calling conventions.
+
+In the RISC-V psABI, the vector registers `v0`-`v31` are all caller-saved.
+The `vl` and `vtype` CSRs are also caller-saved.
+
+Procedures may assume that `vstart` is zero upon entry. Procedures may
+assume that `vstart` is zero upon return from a procedure call.
+
+NOTE: Application software should normally not write `vstart` explicitly.
+Any procedure that does explicitly write `vstart` to a nonzero value must
+zero `vstart` before either returning or calling another procedure.
+
+The `vxrm` and `vxsat` fields of `vcsr` have thread storage duration.
+
+Executing a system call causes all caller-saved vector registers
+(`v0`-`v31`, `vl`, `vtype`) and `vstart` to become unspecified.
+
+NOTE: This scheme allows system calls that cause context switches to avoid
+saving and later restoring the vector registers.
+
+NOTE: Most OSes will choose to either leave these registers intact or reset
+them to their initial state to avoid leaking information across process
+boundaries.
diff --git a/src/cfgstr.tex b/src/cfgstr.tex
deleted file mode 100644
index fab9ee6..0000000
--- a/src/cfgstr.tex
+++ /dev/null
@@ -1,63 +0,0 @@
-\chapter{Machine Configuration Description}
-\label{cfgstr}
-
-\begin{commentary}
- To reduce porting effort for OS boots, we have reverted back to
- using Device Trees to communicate platform information to the
- kernel, so this chapter is out of date. Config string was designed
- for other uses in addition, but for now, we are staying with a
- standard device tree model.
- \end{commentary}
-
-RISC-V platforms may contain myriad devices, processor cores, and
-configuration parameters. To support higher-level software, including
-bootloaders and operating systems, it is recommended that hardware
-platforms embed a description of their components in read-only memory
-that is directly accessible after processor reset for use by low-level
-system software, external debuggers, or manufacturing test procedures.
-We call this low-level embedded information a configuration
-description. We define here a standard mechanism to encode and locate
-the configuration information, and to determine the format of the
-configuration information.
-
-\section{Configuration String Search Procedure}
-
-The platform must describe how to locate a pointer to find this
-string, for example, by specifying a fixed physical address at which
-the pointer resides. To support a wide variety of platforms,
-configuration formats, and chips with manufacturing-time programming
-of configuration options, a flexible search procedure is defined to
-locate the configuration information seeded by the initial pointer
-specified by the platform.
-
-The configuration string pointer provided by the platform points to an
-initial memory address at which the search for configuration string
-begins.
-
-The configuration string cannot begin with a padding byte, where a
-padding byte is defined to contain either {\tt 0x0} or {\tt 0xff}, but
-can be preceded by up to 63 padding bytes that are ignored. If 64
-padding bytes are encountered, then the search terminates without
-finding a config string.
-
-\begin{commentary}
-The padding bytes represent common values returned by unpopulated
-memory or bus regions or unprogrammed non-volatile
-memory. Configuration strings can therefore include pointers to
-regions that are optionally populated or programmed, and these regions
-will be ignored if there is nothing present. The padding bytes also
-support alignment of binary data structures.
-\end{commentary}
-
-Otherwise the first non-padding byte is the beginning of the
-configuration information. For example, configuration information in
-Device Tree String format would begin with a ``/dts-v1/''.
-Configuration information in Flattened Device Tree format would begin
-with the magic number {\tt 0xd00dfeed}. Configuration information in
-the config string format would begin with ``/cs-v1/''.
-\begin{commentary}
- Config string is a new format that is backwards-compatible with
- device tree string (as far as DTS specs exist) but can include
- additional configuration information in other memory regions.
-\end{commentary}
-
diff --git a/src/cmo.adoc b/src/cmo.adoc
new file mode 100644
index 0000000..01c692f
--- /dev/null
+++ b/src/cmo.adoc
@@ -0,0 +1,1126 @@
+[[cmo]]
+== "CMO" Extensions for Base Cache Management Operation ISA, Version 1.0.0
+
+=== Pseudocode for instruction semantics
+
+The semantics of each instruction in the <<#insns>> chapter is expressed in a
+SAIL-like syntax.
+
+[#intro-cmo,reftext="Introduction"]
+=== Introduction
+
+_Cache-management operation_ (or _CMO_) instructions perform operations on
+copies of data in the memory hierarchy. In general, CMO instructions operate on
+cached copies of data, but in some cases, a CMO instruction may operate on
+memory locations directly. Furthermore, CMO instructions are grouped by
+operation into the following classes:
+
+* A _management_ instruction manipulates cached copies of data with respect to a
+ set of agents that can access the data
+* A _zero_ instruction zeros out a range of memory locations, potentially
+ allocating cached copies of data in one or more caches
+* A _prefetch_ instruction indicates to hardware that data at a given memory
+ location may be accessed in the near future, potentially allocating cached
+ copies of data in one or more caches
+
+This document introduces a base set of CMO ISA extensions that operate
+specifically on cache blocks or the memory locations corresponding to a cache
+block; these are known as _cache-block operation_ (or _CBO_) instructions. Each
+of the above classes of instructions represents an extension in this
+specification:
+
+* The _Zicbom_ extension defines a set of cache-block management instructions:
+ `CBO.INVAL`, `CBO.CLEAN`, and `CBO.FLUSH`
+* The _Zicboz_ extension defines a cache-block zero instruction: `CBO.ZERO`
+* The _Zicbop_ extension defines a set of cache-block prefetch instructions:
+ `PREFETCH.R`, `PREFETCH.W`, and `PREFETCH.I`
+
+The execution behavior of the above instructions is also modified by CSR state
+added by this specification.
+
+The remainder of this document provides general background information on CMO
+instructions and describes each of the above ISA extensions.
+
+[NOTE]
+====
+_The term CMO encompasses all operations on caches or resources related to
+caches. The term CBO represents a subset of CMOs that operate only on cache
+blocks. The first CMO extensions only define CBOs._
+====
+
+[#background,reftext="Background"]
+=== Background
+
+This chapter provides information common to all CMO extensions.
+
+[#memory-caches,reftext="Memory and Caches"]
+==== Memory and Caches
+
+A _memory location_ is a physical resource in a system uniquely identified by a
+_physical address_. An _agent_ is a logic block, such as a RISC-V hart,
+accelerator, I/O device, etc., that can access a given memory location.
+
+[NOTE]
+====
+_A given agent may not be able to access all memory locations in a system, and
+two different agents may or may not be able to access the same set of memory
+locations._
+====
+
+A _load operation_ (or _store operation_) is performed by an agent to consume
+(or modify) the data at a given memory location. Load and store operations are
+performed as a result of explicit memory accesses to that memory location.
+Additionally, a _read transfer_ from memory fetches the data at the memory
+location, while a _write transfer_ to memory updates the data at the memory
+location.
+
+A _cache_ is a structure that buffers copies of data to reduce average memory
+latency. Any number of caches may be interspersed between an agent and a memory
+location, and load and store operations from an agent may be satisfied by a
+cache instead of the memory location.
+
+[NOTE]
+====
+_Load and store operations are decoupled from read and write transfers by
+caches. For example, a load operation may be satisfied by a cache without
+performing a read transfer from memory, or a store operation may be satisfied by
+a cache that first performs a read transfer from memory._
+====
+
+Caches organize copies of data into _cache blocks_, each of which represents a
+contiguous, naturally aligned power-of-two (or _NAPOT_) range of memory
+locations. A cache block is identified by any of the physical addresses corresponding to
+the underlying memory locations. The capacity and organization of a cache and
+the size of a cache block are both _implementation-specific_, and the execution
+environment provides software a means to discover information about the caches
+and cache blocks in a system. In the initial set of CMO extensions, the size of
+a cache block shall be uniform throughout the system.
+
+[NOTE]
+====
+_In future CMO extensions, the requirement for a uniform cache block size may be
+relaxed._
+====
+
+Implementation techniques such as speculative execution or hardware prefetching
+may cause a given cache to allocate or deallocate a copy of a cache block at any
+time, provided the corresponding physical addresses are accessible according to
+the supported access type PMA and are cacheable according to the cacheability
+PMA. Allocating a copy of a cache block results in a read transfer from another
+cache or from memory, while deallocating a copy of a cache block may result in a
+write transfer to another cache or to memory depending on whether the data in
+the copy were modified by a store operation. Additional details are discussed in
+<<#coherent-agents-caches>>.
+
+==== Cache-Block Operations
+
+A CBO instruction causes one or more operations to be performed on the cache
+blocks identified by the instruction. In general, a CBO instruction may identify
+one or more cache blocks; however, in the initial set of CMO extensions, CBO
+instructions identify a single cache block only.
+
+A cache-block management instruction performs one of the following operations,
+relative to the copy of a given cache block allocated in a given cache:
+
+* An _invalidate operation_ deallocates the copy of the cache block
+
+* A _clean operation_ performs a write transfer to another cache or to memory if
+ the data in the copy of the cache block have been modified by a store
+ operation
+
+* A _flush operation_ atomically performs a clean operation followed by an
+ invalidate operation
+
+Additional details, including the actual operation performed by a given
+cache-block management instruction, are described in <<#Zicbom>>.
+
+A cache-block zero instruction performs a set of store operations that write
+zeros to the set of bytes corresponding to a cache block. Unless specified
+otherwise, the store operations generated by a cache-block zero instruction have
+the same general properties and behaviors that other store instructions in the
+architecture have. An implementation may or may not update the entire set of
+bytes atomically with a single store operation. Additional details are described
+in <<#Zicboz>>.
+
+A cache-block prefetch instruction is a HINT to the hardware that software
+expects to perform a particular type of memory access in the near future.
+Additional details are described in <<#Zicbop>>.
+
+[#coherent-agents-caches,reftext="Coherent Agents and Caches"]
+=== Coherent Agents and Caches
+
+For a given memory location, a _set of coherent agents_ consists of the agents
+for which all of the following hold:
+
+* Store operations from all agents in the set appear to be serialized with
+ respect to each other
+* Store operations from all agents in the set eventually appear to all other
+ agents in the set
+* A load operation from an agent in the set returns data from a store operation
+ from an agent in the set (or from the initial data in memory)
+
+The coherent agents within such a set shall access a given memory location with
+the same physical address and the same physical memory attributes; however, if
+the coherence PMA for a given agent indicates a given memory location is not
+coherent, that agent shall not be a member of a set of coherent agents with any
+other agent for that memory location and shall be the sole member of a set of
+coherent agents consisting of itself.
+
+An agent who is a member of a set of coherent agents is said to be _coherent_
+with respect to the other agents in the set. On the other hand, an agent who is
+_not_ a member is said to be _non-coherent_ with respect to the agents in the
+set.
+
+Caches introduce the possibility that multiple copies of a given cache block may
+be present in a system at the same time. An _implementation-specific_ mechanism
+keeps these copies coherent with respect to the load and store operations from
+the agents in the set of coherent agents. Additionally, if a coherent agent in
+the set executes a CBO instruction that specifies the cache block, the resulting
+operation shall apply to any and all of the copies in the caches that can be
+accessed by the load and store operations from the coherent agents.
+
+[NOTE]
+====
+_An operation from a CBO instruction is defined to operate only on the copies of
+a cache block that are cached in the caches accessible by the explicit memory
+accesses performed by the set of coherent agents. This includes copies of a
+cache block in caches that are accessed only indirectly by load and store
+operations, e.g. coherent instruction caches._
+====
+
+The set of caches subject to the above mechanism form a _set of coherent
+caches_, and each coherent cache has the following behaviors, assuming all
+operations are performed by the agents in a set of coherent agents:
+
+* A coherent cache is permitted to allocate and deallocate copies of a cache
+ block and perform read and write transfers as described in <<#memory-caches>>
+
+* A coherent cache is permitted to perform a write transfer to memory provided
+ that a store operation has modified the data in the cache block since the most
+ recent invalidate, clean, or flush operation on the cache block
+
+* At least one coherent cache is responsible for performing a write transfer to
+ memory once a store operation has modified the data in the cache block until
+ the next invalidate, clean, or flush operation on the cache block, after which
+ no coherent cache is responsible (or permitted) to perform a write transfer to
+ memory until the next store operation has modified the data in the cache block
+
+* A coherent cache is required to perform a write transfer to memory if a store
+ operation has modified the data in the cache block since the most recent
+ invalidate, clean, or flush operation on the cache block and if the next clean
+ or flush operation requires a write transfer to memory
+
+[NOTE]
+====
+_The above restrictions ensure that a "clean" copy of a cache block, fetched by
+a read transfer from memory and unmodified by a store operation, cannot later
+overwrite the copy of the cache block in memory updated by a write transfer to
+memory from a non-coherent agent._
+====
+
+A non-coherent agent may initiate a cache-block operation that operates on the
+set of coherent caches accessed by a set of coherent agents. The mechanism to
+perform such an operation is _implementation-specific_.
+
+==== Memory Ordering
+
+===== Preserved Program Order
+
+The preserved program order (abbreviated _PPO_) rules are defined by the RVWMO
+memory ordering model. How the operations resulting from CMO instructions fit
+into these rules is described below.
+
+For cache-block management instructions, the resulting invalidate, clean, and
+flush operations behave as stores in the PPO rules subject to one additional
+overlapping address rule. Specifically, if _a_ precedes _b_ in program order,
+then _a_ will precede _b_ in the global memory order if:
+
+* _a_ is an invalidate, clean, or flush, _b_ is a load, and _a_ and _b_ access
+ overlapping memory addresses
+
+[NOTE]
+====
+_The above rule ensures that a subsequent load in program order never appears
+in the global memory order before a preceding invalidate, clean, or flush
+operation to an overlapping address._
+====
+
+Additionally, invalidate, clean, and flush operations are classified as W or O
+(depending on the physical memory attributes for the corresponding physical
+addresses) for the purposes of predecessor and successor sets in `FENCE`
+instructions. These operations are _not_ ordered by other instructions that
+order stores, e.g. `FENCE.I` and `SFENCE.VMA`.
+
+For cache-block zero instructions, the resulting store operations behave as
+stores in the PPO rules and are ordered by other instructions that order stores.
+
+Finally, for cache-block prefetch instructions, the resulting operations are
+_not_ ordered by the PPO rules nor are they ordered by any other ordering
+instructions.
+
+===== Load Values
+
+An invalidate operation may change the set of values that can be returned by a
+load. In particular, an additional condition is added to the Load Value Axiom:
+
+* If an invalidate operation _i_ precedes a load _r_ and operates on a byte _x_
+ returned by _r_, and no store to _x_ appears between _i_ and _r_ in program
+ order or in the global memory order, then _r_ returns any of the following
+ values for _x_:
+
+. If no clean or flush operations on _x_ precede _i_ in the global memory order,
+ either the initial value of _x_ or the value of any store to _x_ that precedes
+ _i_
+
+. If no store to _x_ precedes a clean or flush operation on _x_ in the global
+ memory order and if the clean or flush operation on _x_ precedes _i_ in the
+ global memory order, either the initial value of _x_ or the value of any store
+ to _x_ that precedes _i_
+
+. If a store to _x_ precedes a clean or flush operation on _x_ in the global
+ memory order and if the clean or flush operation on _x_ precedes _i_ in the
+ global memory order, either the value of the latest store to _x_ that precedes
+ the latest clean or flush operation on _x_ or the value of any store to _x_
+ that both precedes _i_ and succeeds the latest clean or flush operation on _x_
+ that precedes _i_
+
+. The value of any store to _x_ by a non-coherent agent regardless of the above
+ conditions
+
+[NOTE]
+====
+_The first three bullets describe the possible load values at different points
+in the global memory order relative to clean or flush operations. The final
+bullet implies that the load value may be produced by a non-coherent agent at
+any time._
+====
+
+==== Traps
+
+Execution of certain CMO instructions may result in traps due to CSR state,
+described in the <<#csr_state>> section, or due to the address translation and
+protection mechanisms. The trapping behavior of CMO instructions is described in
+the following sections.
+
+===== Illegal-Instruction and Virtual-Instruction Exceptions
+
+Cache-block management instructions and cache-block zero instructions may raise
+illegal-instruction exceptions or virtual-instruction exceptions depending on
+the current privilege mode and the state of the CMO control registers described
+in the <<#csr_state>> section.
+
+Cache-block prefetch instructions raise neither illegal-instruction exceptions
+nor virtual-instruction exceptions.
+
+===== Page-Fault, Guest-Page-Fault, and Access-Fault Exceptions
+
+Similar to load and store instructions, CMO instructions are explicit memory
+access instructions that compute an effective address. The effective address is
+ultimately translated into a physical address based on the privilege mode and
+the enabled translation mechanisms, and the CMO extensions impose the following
+constraints on the physical addresses in a given cache block:
+
+* The PMP access control bits shall be the same for _all_ physical addresses in
+ the cache block, and if write permission is granted by the PMP access control
+ bits, read permission shall also be granted
+
+* The PMAs shall be the same for _all_ physical addresses in the cache block,
+ and if write permission is granted by the supported access type PMAs, read
+ permission shall also be granted
+
+If the above constraints are not met, the behavior of a CBO instruction is
+UNSPECIFIED.
+
+[NOTE]
+====
+_This specification assumes that the above constraints will typically be met for
+main memory regions and may be met for certain I/O regions._
+====
+
+Additionally, for the purposes of PMP and PMA checks, the access size of a CMO
+instruction equals the size of the cache block accessed by the instruction.
+
+The Zicboz extension introduces an additional supported access type PMA for
+cache-block zero instructions. Main memory regions are required to support
+accesses by cache-block zero instructions; however, I/O regions may specify
+whether accesses by cache-block zero instructions are supported.
+
+A cache-block management instruction is permitted to access the specified cache
+block whenever a load instruction or store instruction is permitted to access
+the corresponding physical addresses. If neither a load instruction nor store
+instruction is permitted to access the physical addresses, but an instruction
+fetch is permitted to access the physical addresses, whether a cache-block
+management instruction is permitted to access the cache block is UNSPECIFIED. If
+access to the cache block is not permitted, a cache-block management instruction
+raises a store page-fault or store guest-page-fault exception if address
+translation does not permit any access or raises a store access-fault exception
+otherwise. During address translation, the instruction also checks the accessed
+bit and may either raise an exception or set the bit as required.
+
+[NOTE]
+====
+_The interaction between cache-block management instructions and instruction
+fetches will be specified in a future extension._
+
+_As implied by omission, a cache-block management instruction does not check the
+dirty bit and neither raises an exception nor sets the bit._
+====
+
+A cache-block zero instruction is permitted to access the specified cache block
+whenever a store instruction is permitted to access the corresponding physical
+addresses and when the PMAs indicate that cache-block zero instructions are a
+supported access type. If access to the cache block is not permitted, a
+cache-block zero instruction raises a store page-fault or store guest-page-fault
+exception if address translation does not permit write access or raises a store
+access-fault exception otherwise. During address translation, the instruction
+also checks the accessed and dirty bits and may either raise an exception or set
+the bits as required.
+
+A cache-block prefetch instruction is permitted to access the specified cache
+block whenever a load instruction, store instruction, or instruction fetch is
+permitted to access the corresponding physical addresses. If access to the cache
+block is not permitted, a cache-block prefetch instruction does not raise any
+exceptions and shall not access any caches or memory. During address
+translation, the instruction does _not_ check the accessed and dirty bits and
+neither raises an exception nor sets the bits.
+
+When a page-fault, guest-page-fault, or access-fault exception is taken, the
+relevant *tval CSR is written with the faulting effective address (i.e. the
+value of _rs1_).
+
+[NOTE]
+====
+_Like a load or store instruction, a CMO instruction may or may not be permitted
+to access a cache block based on the states of the `MPRV`, `MPV`, and `MPP` bits
+in `mstatus` and the `SUM` and `MXR` bits in `mstatus`, `sstatus`, and
+`vsstatus`._
+
+_This specification expects that implementations will process cache-block
+management instructions like store/AMO instructions, so store/AMO exceptions are
+appropriate for these instructions, regardless of the permissions required._
+====
+
+===== Address-Misaligned Exceptions
+
+CMO instructions do _not_ generate address-misaligned exceptions.
+
+===== Breakpoint Exceptions and Debug Mode Entry
+
+Unless otherwise defined by the debug architecture specification, the behavior
+of trigger modules with respect to CMO instructions is UNSPECIFIED.
+
+[NOTE]
+====
+_For the Zicbom, Zicboz, and Zicbop extensions, this specification recommends
+the following common trigger module behaviors:_
+
+* Type 6 address match triggers, i.e. `tdata1.type=6` and `mcontrol6.select=0`,
+ should be supported
+
+* Type 2 address/data match triggers, i.e. `tdata1.type=2`, should be
+ unsupported
+
+* The size of a memory access equals the size of the cache block accessed, and
+ the compare values follow from the addresses of the NAPOT memory region
+ corresponding to the cache block containing the effective address
+
+* Unless an encoding for a cache block is added to the `mcontrol6.size` field,
+ an address trigger should only match a memory access from a CBO instruction if
+ `mcontrol6.size=0`
+
+_If the Zicbom extension is implemented, this specification recommends the
+following additional trigger module behaviors:_
+
+* Implementing address match triggers should be optional
+
+* Type 6 data match triggers, i.e. `tdata1.type=6` and `mcontrol6.select=1`,
+ should be unsupported
+
+* Memory accesses are considered to be stores, i.e. an address trigger matches
+ only if `mcontrol6.store=1`
+
+_If the Zicboz extension is implemented, this specification recommends the
+following additional trigger module behaviors:_
+
+* Implementing address match triggers should be mandatory
+
+* Type 6 data match triggers, i.e. `tdata1.type=6` and `mcontrol6.select=1`,
+ should be supported, and implementing these triggers should be optional
+
+* Memory accesses are considered to be stores, i.e. an address trigger matches
+ only if `mcontrol6.store=1`
+
+_If the Zicbop extension is implemented, this specification recommends the
+following additional trigger module behaviors:_
+
+* Implementing address match triggers should be optional
+
+* Type 6 data match triggers, i.e. `tdata1.type=6` and `mcontrol6.select=1`,
+ should be unsupported
+
+* Memory accesses may be considered to be loads or stores depending on the
+ implementation, i.e. whether an address trigger matches on these instructions
+ when `mcontrol6.load=1` or `mcontrol6.store=1` is _implementation-specific_
+
+_This specification also recommends that the behavior of trigger modules with
+respect to the Zicboz extension should be defined in version 1.0 of the debug
+architecture specification. The behavior of trigger modules with respect to the
+Zicbom and Zicbop extensions is expected to be defined in future extensions._
+====
+
+===== Hypervisor Extension
+
+For the purposes of writing the `mtinst` or `htinst` register on a trap, the
+following standard transformation is defined for cache-block management
+instructions and cache-block zero instructions:
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 'opcode'},
+ { bits: 5, name: 0x0 },
+ { bits: 3, name: 'funct3'},
+ { bits: 5, name: 0x0},
+ { bits: 12, name: 'operation'},
+]}
+....
+
+The `operation` field corresponds to the 12 most significant bits of the
+trapping instruction.
+
+[NOTE]
+====
+_As described in the hypervisor extension, a zero may be written into `mtinst`
+or `htinst` instead of the standard transformation defined above._
+====
+
+==== Effects on Constrained LR/SC Loops
+
+The following event is added to the list of events that satisfy the eventuality
+guarantee provided by constrained LR/SC loops, as defined in the A extension:
+
+* Some other hart executes a cache-block management instruction or a cache-block
+ zero instruction to the reservation set of the LR instruction in _H_'s
+ constrained LR/SC loop.
+
+[NOTE]
+====
+_The above event has been added to accommodate cache coherence protocols that
+cannot distinguish between invalidations for stores and invalidations for
+cache-block management operations._
+
+_Aside from the above event, CMO instructions neither change the properties of
+constrained LR/SC loops nor modify the eventuality guarantee provided by them.
+For example, executing a CMO instruction may cause a constrained LR/SC loop on
+any hart to fail periodically or may cause a unconstrained LR/SC sequence on the
+same hart to fail always. Additionally, executing a cache-block prefetch
+instruction does not impact the eventuality guarantee provided by constrained
+LR/SC loops executed on any hart._
+====
+
+==== Software Discovery
+
+The initial set of CMO extensions requires the following information to be
+discovered by software:
+
+* The size of the cache block for management and prefetch instructions
+* The size of the cache block for zero instructions
+* CBIE support at each privilege level
+
+Other general cache characteristics may also be specified in the discovery
+mechanism.
+
+[#csr_state,reftext="Control and Status Register State"]
+=== Control and Status Register State
+
+Three CSRs control the execution of CMO instructions:
+
+* `m{csrname}`
+* `s{csrname}`
+* `h{csrname}`
+
+The `s{csrname}` register is used by all supervisor modes, including VS-mode. A
+hypervisor is responsible for saving and restoring `s{csrname}` on guest context
+switches. The `h{csrname}` register is only present if the H-extension is
+implemented and enabled.
+
+Each `x{csrname}` register (where `x` is `m`, `s`, or `h`) has the following
+generic format:
+
+.Generic Format for x{csrname} CSRs
+[cols="^10,^10,80a"]
+|===
+| Bits | Name | Description
+
+| [5:4] | `CBIE` | Cache Block Invalidate instruction Enable. *WARL*.
+
+Enables the execution of the cache block invalidate instruction, `CBO.INVAL`, in
+a lower privilege mode:
+
+* `00`: The instruction raises an illegal-instruction or virtual-instruction
+ exception
+* `01`: The instruction is executed and performs a flush operation
+* `10`: _Reserved_
+* `11`: The instruction is executed and performs an invalidate operation
+
+| [6] | `CBCFE` | Cache Block Clean and Flush instruction Enable
+
+Enables the execution of the cache block clean instruction, `CBO.CLEAN`, and the
+cache block flush instruction, `CBO.FLUSH`, in a lower privilege mode:
+
+* `0`: The instruction raises an illegal-instruction or virtual-instruction
+ exception
+* `1`: The instruction is executed
+
+| [7] | `CBZE` | Cache Block Zero instruction Enable
+
+Enables the execution of the cache block zero instruction, `CBO.ZERO`, in a
+lower privilege mode:
+
+* `0`: The instruction raises an illegal-instruction or virtual-instruction
+ exception
+* `1`: The instruction is executed
+
+|===
+
+The x{csrname} registers control CBO instruction execution based on the current
+privilege mode and the state of the appropriate CSRs, as detailed below.
+
+A `CBO.INVAL` instruction executes or raises either an illegal-instruction
+exception or a virtual-instruction exception based on the state of the
+`x{csrname}.CBIE` fields:
+
+[source,sail,subs="attributes+"]
+--
+
+// illegal-instruction exceptions
+if (((priv_mode != M) && (m{csrname}.CBIE == 00)) ||
+ ((priv_mode == U) && (s{csrname}.CBIE == 00)))
+{
+ <raise illegal-instruction exception>
+}
+// virtual-instruction exceptions
+else if (((priv_mode == VS) && (h{csrname}.CBIE == 00)) ||
+ ((priv_mode == VU) && ((h{csrname}.CBIE == 00) || (s{csrname}.CBIE == 00))))
+{
+ <raise virtual-instruction exception>
+}
+// execute instruction
+else
+{
+ if (((priv_mode != M) && (m{csrname}.CBIE == 01)) ||
+ ((priv_mode == U) && (s{csrname}.CBIE == 01)) ||
+ ((priv_mode == VS) && (h{csrname}.CBIE == 01)) ||
+ ((priv_mode == VU) && ((h{csrname}.CBIE == 01) || (s{csrname}.CBIE == 01))))
+ {
+ <execute CBO.INVAL and perform flush operation>
+ }
+ else
+ {
+ <execute CBO.INVAL and perform invalidate operation>
+ }
+}
+
+
+--
+
+[NOTE]
+====
+_Until a modified cache block has updated memory, a `CBO.INVAL` instruction may
+expose stale data values in memory if the CSRs are programmed to perform an
+invalidate operation. This behavior may result in a security hole if lower
+privileged level software performs an invalidate operation and accesses
+sensitive information in memory._
+
+_To avoid such holes, higher privileged level software must perform either a
+clean or flush operation on the cache block before permitting lower privileged
+level software to perform an invalidate operation on the block. Alternatively,
+higher privileged level software may program the CSRs so that `CBO.INVAL`
+either traps or performs a flush operation in a lower privileged level._
+====
+
+A `CBO.CLEAN` or `CBO.FLUSH` instruction executes or raises an illegal-instruction
+or virtual-instruction exception based on the state of the
+`x{csrname}.CBCFE` bits:
+
+[source,sail,subs="attributes+"]
+--
+
+// illegal-instruction exceptions
+if (((priv_mode != M) && !m{csrname}.CBCFE) ||
+ ((priv_mode == U) && !s{csrname}.CBCFE))
+{
+ <raise illegal-instruction exception>
+}
+// virtual-instruction exceptions
+else if (((priv_mode == VS) && !h{csrname}.CBCFE) ||
+ ((priv_mode == VU) && !(h{csrname}.CBCFE && s{csrname}.CBCFE)))
+{
+ <raise virtual-instruction exception>
+}
+// execute instruction
+else
+{
+ <execute CBO.CLEAN or CBO.FLUSH>
+}
+
+--
+
+Finally, a `CBO.ZERO` instruction executes or raises an illegal-instruction or
+virtual-instruction exception based on the state of the `x{csrname}.CBZE` bits:
+
+[source,sail,subs="attributes+"]
+--
+
+// illegal-instruction exceptions
+if (((priv_mode != M) && !m{csrname}.CBZE) ||
+ ((priv_mode == U) && !s{csrname}.CBZE))
+{
+ <raise illegal-instruction exception>
+}
+// virtual-instruction exceptions
+else if (((priv_mode == VS) && !h{csrname}.CBZE) ||
+ ((priv_mode == VU) && !(h{csrname}.CBZE && s{csrname}.CBZE)))
+{
+ <raise virtual-instruction exception>
+}
+// execute instruction
+else
+{
+ <execute CBO.ZERO>
+}
+
+--
+
+The CBIE/CBCFE/CBZE fields in each `x{csrname}` register do not affect the
+read and write behavior of the same fields in the other `x{csrname}` registers.
+
+Each `x{csrname}` register is WARL; however, software should determine the legal
+values from the execution environment discovery mechanism.
+
+[#extensions,reftext="Extensions"]
+=== Extensions
+
+CMO instructions are defined in the following extensions:
+
+* <<#Zicbom>>
+* <<#Zicboz>>
+* <<#Zicbop>>
+
+[#Zicbom,reftext="Cache-Block Management Instructions"]
+==== Cache-Block Management Instructions
+
+Cache-block management instructions enable software running on a set of coherent
+agents to communicate with a set of non-coherent agents by performing one of the
+following operations:
+
+* An invalidate operation makes data from store operations performed by a set of
+ non-coherent agents visible to the set of coherent agents at a point common to
+ both sets by deallocating all copies of a cache block from the set of coherent
+ caches up to that point
+
+* A clean operation makes data from store operations performed by the set of
+ coherent agents visible to a set of non-coherent agents at a point common to
+ both sets by performing a write transfer of a copy of a cache block to that
+ point provided a coherent agent performed a store operation that modified the
+ data in the cache block since the previous invalidate, clean, or flush
+ operation on the cache block
+
+* A flush operation atomically performs a clean operation followed by an
+ invalidate operation
+
+In the Zicbom extension, the instructions operate to a point common to _all_
+agents in the system. In other words, an invalidate operation ensures that store
+operations from all non-coherent agents visible to agents in the set of coherent
+agents, and a clean operation ensures that store operations from coherent agents
+visible to all non-coherent agents.
+
+[NOTE]
+====
+_The Zicbom extension does not prohibit agents that fall outside of the above
+architectural definition; however, software cannot rely on the defined cache
+operations to have the desired effects with respect to those agents._
+
+_Future extensions may define different sets of agents for the purposes of
+performance optimization._
+====
+
+These instructions operate on the cache block whose effective address is
+specified in _rs1_. The effective address is translated into a corresponding
+physical address by the appropriate translation mechanisms.
+
+The following instructions comprise the Zicbom extension:
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|cbo.clean _base_
+|<<#insns-cbo_clean>>
+
+|&#10003;
+|&#10003;
+|cbo.flush _base_
+|<<#insns-cbo_flush>>
+
+|&#10003;
+|&#10003;
+|cbo.inval _base_
+|<<#insns-cbo_inval>>
+
+|===
+
+[NOTE]
+====
+_Cache-block management instructions ignore cacheability attributes and operate
+on the cache block irrespective of the PMA cacheable attribute and any Page-Based
+Memory Type (PBMT) downgrade from cacheable to non-cacheable._
+====
+
+[#Zicboz,reftext="Cache-Block Zero Instructions"]
+==== Cache-Block Zero Instructions
+
+Cache-block zero instructions store zeros to the set of bytes corresponding to a
+cache block. An implementation may update the bytes in any order and with any
+granularity and atomicity, including individual bytes.
+
+[NOTE]
+====
+_Cache-block zero instructions store zeros independently of whether data from
+the underlying memory locations are cacheable. In addition, this specification
+does not constrain how the bytes are written._
+====
+
+These instructions operate on the cache block, or the memory locations
+corresponding to the cache block, whose effective address is specified in _rs1_.
+The effective address is translated into a corresponding physical address by the
+appropriate translation mechanisms.
+
+The following instructions comprise the Zicboz extension:
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|cbo.zero _base_
+|<<#insns-cbo_zero>>
+
+|===
+
+[#Zicbop,reftext="Cache-Block Prefetch Instructions"]
+==== Cache-Block Prefetch Instructions
+
+Cache-block prefetch instructions are HINTs to the hardware to indicate that
+software intends to perform a particular type of memory access in the near
+future. The types of memory accesses are instruction fetch, data read (i.e.
+load), and data write (i.e. store).
+
+These instructions operate on the cache block whose effective address is the sum
+of the base address specified in _rs1_ and the sign-extended offset encoded in
+_imm[11:0]_, where _imm[4:0]_ shall equal `0b00000`. The effective address is
+translated into a corresponding physical address by the appropriate translation
+mechanisms.
+
+[NOTE]
+====
+_Cache-block prefetch instructions are encoded as ORI instructions with rd equal
+to `0b00000`; however, for the purposes of effective address calculation, this
+field is also interpreted as imm[4:0] like a store instruction._
+====
+
+The following instructions comprise the Zicbop extension:
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|prefetch.i _offset_(_base_)
+|<<#insns-prefetch_i>>
+
+|&#10003;
+|&#10003;
+|prefetch.r _offset_(_base_)
+|<<#insns-prefetch_r>>
+
+|&#10003;
+|&#10003;
+|prefetch.w _offset_(_base_)
+|<<#insns-prefetch_w>>
+
+|===
+
+[#insns,reftext="Instructions"]
+=== Instructions
+
+[#insns-cbo_clean,reftext="Cache Block Clean"]
+==== cbo.clean
+
+Synopsis::
+Perform a clean operation on a cache block
+
+Mnemonic::
+cbo.clean _offset_(_base_)
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0xF, attr: ['MISC-MEM'] },
+ { bits: 5, name: 0x0 },
+ { bits: 3, name: 0x2, attr: ['CBO'] },
+ { bits: 5, name: 'rs1', attr: ['base'] },
+ { bits: 12, name: 0x001, attr: ['CBO.CLEAN'] },
+]}
+....
+
+Description::
+
+A *cbo.clean* instruction performs a clean operation on the cache block whose
+effective address is the base address specified in _rs1_. The offset operand may
+be omitted; otherwise, any expression that computes the offset shall evaluate to
+zero. The instruction operates on the set of coherent caches accessed by the
+agent executing the instruction.
+
+[NOTE]
+====
+_When executing a *cbo.clean* instruction, an implementation may instead perform
+a flush operation, since the result of that operation is indistinguishable from
+the sequence of performing a clean operation just before deallocating all cached
+copies in the set of coherent caches._
+====
+
+[#insns-cbo_flush,reftext="Cache Block Flush"]
+==== cbo.flush
+
+Synopsis::
+Perform a flush operation on a cache block
+
+Mnemonic::
+cbo.flush _offset_(_base_)
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0xF, attr: ['MISC-MEM'] },
+ { bits: 5, name: 0x0 },
+ { bits: 3, name: 0x2, attr: ['CBO'] },
+ { bits: 5, name: 'rs1', attr: ['base'] },
+ { bits: 12, name: 0x002, attr: ['CBO.FLUSH'] },
+]}
+....
+
+Description::
+
+A *cbo.flush* instruction performs a flush operation on the cache block whose
+that contains the address specified in _rs1_. It is not required that _rs1_ is
+aligned to the size of a cache block. On faults, the faulting virtual address
+is considered to be the value in rs1, rather than the base address of the cache
+block. The instruction operates on the set of coherent caches accessed by the
+agent executing the instruction.
+
+The assembly _offset_ operand may be omitted. If it isn't then any expression
+that computes the offset shall evaluate to zero.
+
+[#insns-cbo_inval,reftext="Cache Block Invalidate"]
+==== cbo.inval
+
+Synopsis::
+Perform an invalidate operation on a cache block
+
+Mnemonic::
+cbo.inval _offset_(_base_)
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0xF, attr: ['MISC-MEM'] },
+ { bits: 5, name: 0x0 },
+ { bits: 3, name: 0x2, attr: ['CBO'] },
+ { bits: 5, name: 'rs1', attr: ['base'] },
+ { bits: 12, name: 0x000, attr: ['CBO.INVAL'] },
+]}
+....
+
+Description::
+
+A *cbo.inval* instruction performs an invalidate operation on the cache block
+that contains the address specified in _rs1_. It is not required that _rs1_ is
+aligned to the size of a cache block. On faults, the faulting virtual address
+is considered to be the value in rs1, rather than the base address of the cache
+block. The instruction operates on the set of coherent caches accessed by the
+agent executing the instruction.
+
+Depending on CSR programming, the instruction may perform a flush operation
+instead of an invalidate operation.
+
+The assembly _offset_ operand may be omitted. If it isn't then any expression
+that computes the offset shall evaluate to zero.
+
+[NOTE]
+====
+_When executing a *cbo.inval* instruction, an implementation may instead perform
+a flush operation, since the result of that operation is indistinguishable from
+the sequence of performing a write transfer to memory just before performing an
+invalidate operation._
+====
+
+[#insns-cbo_zero,reftext="Cache Block Zero"]
+==== cbo.zero
+
+Synopsis::
+Store zeros to the full set of bytes corresponding to a cache block
+
+Mnemonic::
+cbo.zero _offset_(_base_)
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0xF, attr: ['MISC-MEM'] },
+ { bits: 5, name: 0x0 },
+ { bits: 3, name: 0x2, attr: ['CBO'] },
+ { bits: 5, name: 'rs1', attr: ['base'] },
+ { bits: 12, name: 0x004, attr: ['CBO.ZERO'] },
+]}
+....
+
+Description::
+
+A *cbo.zero* instruction performs stores of zeros to the full set of bytes
+corresponding to the cache block that contains the address specified in _rs1_.
+It is not required that _rs1_ is aligned to the size of a cache block. On
+faults, the faulting virtual address is considered to be the value in rs1,
+rather than the base address of the cache block. An implementation may or
+may not update the entire set of bytes atomically.
+
+The assembly _offset_ operand may be omitted. If it isn't then any expression
+that computes the offset shall evaluate to zero.
+
+[#insns-prefetch_i,reftext="Cache Block Prefetch for Instruction Fetch"]
+==== prefetch.i
+
+Synopsis::
+Provide a HINT to hardware that a cache block is likely to be accessed by an
+instruction fetch in the near future
+
+Mnemonic::
+prefetch.i _offset_(_base_)
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 0x0, attr: ['offset[4:0]'] },
+ { bits: 3, name: 0x6, attr: ['ORI'] },
+ { bits: 5, name: 'rs1', attr: ['base'] },
+ { bits: 5, name: 0x0, attr: ['PREFETCH.I'] },
+ { bits: 7, name: 'imm[11:5]', attr: ['offset[11:5]'] },
+]}
+....
+
+Description::
+
+A *prefetch.i* instruction indicates to hardware that the cache block whose
+effective address is the sum of the base address specified in _rs1_ and the
+sign-extended offset encoded in _imm[11:0]_, where _imm[4:0]_ equals `0b00000`,
+is likely to be accessed by an instruction fetch in the near future.
+
+[NOTE]
+====
+_An implementation may opt to cache a copy of the cache block in a cache
+accessed by an instruction fetch in order to improve memory access latency, but
+this behavior is not required._
+====
+
+[#insns-prefetch_r,reftext="Cache Block Prefetch for Data Read"]
+==== prefetch.r
+
+Synopsis::
+Provide a HINT to hardware that a cache block is likely to be accessed by a data
+read in the near future
+
+Mnemonic::
+prefetch.r _offset_(_base_)
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 0x0, attr: ['offset[4:0]'] },
+ { bits: 3, name: 0x6, attr: ['ORI'] },
+ { bits: 5, name: 'rs1', attr: ['base'] },
+ { bits: 5, name: 0x1, attr: ['PREFETCH.R'] },
+ { bits: 7, name: 'imm[11:5]', attr: ['offset[11:5]'] },
+]}
+....
+
+Description::
+
+A *prefetch.r* instruction indicates to hardware that the cache block whose
+effective address is the sum of the base address specified in _rs1_ and the
+sign-extended offset encoded in _imm[11:0]_, where _imm[4:0]_ equals `0b00000`,
+is likely to be accessed by a data read (i.e. load) in the near future.
+
+[NOTE]
+====
+_An implementation may opt to cache a copy of the cache block in a cache
+accessed by a data read in order to improve memory access latency, but this
+behavior is not required._
+====
+
+[#insns-prefetch_w,reftext="Cache Block Prefetch for Data Write"]
+==== prefetch.w
+
+Synopsis::
+Provide a HINT to hardware that a cache block is likely to be accessed by a data
+write in the near future
+
+Mnemonic::
+prefetch.w _offset_(_base_)
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 0x0, attr: ['offset[4:0]'] },
+ { bits: 3, name: 0x6, attr: ['ORI'] },
+ { bits: 5, name: 'rs1', attr: ['base'] },
+ { bits: 5, name: 0x3, attr: ['PREFETCH.W'] },
+ { bits: 7, name: 'imm[11:5]', attr: ['offset[11:5]'] },
+]}
+....
+
+Description::
+
+A *prefetch.w* instruction indicates to hardware that the cache block whose
+effective address is the sum of the base address specified in _rs1_ and the
+sign-extended offset encoded in _imm[11:0]_, where _imm[4:0]_ equals `0b00000`,
+is likely to be accessed by a data write (i.e. store) in the near future.
+
+[NOTE]
+====
+_An implementation may opt to cache a copy of the cache block in a cache
+accessed by a data write in order to improve memory access latency, but this
+behavior is not required._
+====
diff --git a/src/colophon.adoc b/src/colophon.adoc
new file mode 100644
index 0000000..39bbcbf
--- /dev/null
+++ b/src/colophon.adoc
@@ -0,0 +1,464 @@
+[colophon]
+== Preface
+// Had to make the above a level 1 heading (two equals signs) to avoid error when building
+// the ISA manual as a book with other "parts". This is opposite to what the adoc says to do
+// but otherwise asciidoctor creates the error message:
+//
+// asciidoctor: ERROR: ext/riscv-isa-manual/src/colophon.adoc: line 2: invalid part, must have at least one section (e.g., chapter, appendix, etc.)
+//
+// See asciidoctor doc which seems wrong: https://docs.asciidoctor.org/asciidoc/latest/sections/colophon/
+[.big]*_Preface to Document Version 20250508_*
+
+This document describes the RISC-V unprivileged architecture.
+
+The ISA modules marked *Ratified* have been ratified at this time. The
+modules marked _Frozen_ are not expected to change significantly before
+being put up for ratification. The modules marked _Draft_ are expected
+to change before ratification.
+
+The document contains the following versions of the RISC-V ISA modules:
+
+[%autowidth,float="center",align="center",cols="^,<,^",options="header"]
+|===
+|Base |Version |Status
+|*RV32I* |*2.1* |*Ratified*
+|*RV32E* |*2.0* |*Ratified*
+|*RV64E* |*2.0* |*Ratified*
+|*RV64I* |*2.1* |*Ratified*
+
+h|Extension h|Version h|Status
+
+|*Zifencei* |*2.0* |*Ratified*
+|*Zicsr* |*2.0* |*Ratified*
+|*Zicntr* |*2.0* |*Ratified*
+|*Zihintntl* |*1.0* |*Ratified*
+|*Zihintpause* |*2.0* |*Ratified*
+|*Zimop* | *1.0* | *Ratified*
+|*Zicond* | *1.0* |*Ratified*
+|*Zilsd* | *1.0* |*Ratified*
+|*M* |*2.0* |*Ratified*
+|*Zmmul* |*1.0* |*Ratified*
+|*A* |*2.1* |*Ratified*
+|*Zawrs* |*1.01* |*Ratified*
+|*Zacas* |*1.0* |*Ratified*
+|*Zabha* |*1.0* |*Ratified*
+|*RVWMO* |*2.0* |*Ratified*
+|*Ztso* |*1.0* |*Ratified*
+|*CMO* |*1.0* |*Ratified*
+|*F* |*2.2* |*Ratified*
+|*D* |*2.2* |*Ratified*
+|*Q* |*2.2* |*Ratified*
+|*Zfh* |*1.0* |*Ratified*
+|*Zfhmin* |*1.0* |*Ratified*
+|*BF16* |*1.0* |*Ratified*
+|*Zfa* |*1.0* |*Ratified*
+|*Zfinx* |*1.0* |*Ratified*
+|*Zdinx* |*1.0* |*Ratified*
+|*Zhinx* |*1.0* |*Ratified*
+|*Zhinxmin* |*1.0* |*Ratified*
+|*C* |*2.0* |*Ratified*
+|*Zce* |*1.0* |*Ratified*
+|*Zclsd* |*1.0* |*Ratified*
+|*B* |*1.0* |*Ratified*
+|*V* |*1.0* |*Ratified*
+|*Zbkb* |*1.0* |*Ratified*
+|*Zbkc* |*1.0* |*Ratified*
+|*Zbkx* |*1.0* |*Ratified*
+|*Zk* |*1.0* |*Ratified*
+|*Zks* |*1.0* |*Ratified*
+|*Zvbb* |*1.0* |*Ratified*
+|*Zvbc* |*1.0* |*Ratified*
+|*Zvkg* |*1.0* |*Ratified*
+|*Zvkned* |*1.0* |*Ratified*
+|*Zvknhb* |*1.0* |*Ratified*
+|*Zvksed* |*1.0* |*Ratified*
+|*Zvksh* |*1.0* |*Ratified*
+|*Zvkt* |*1.0* |*Ratified*
+|*Zicfiss* |*1.0* |*Ratified*
+|*Zicfilp* |*1.0* |*Ratified*
+|===
+
+The changes in this version of the document include:
+
+* The inclusion of all ratified extensions through May 2025.
+* Removal of all unratified material.
+* Addition of the BFloat16-precision Floating Point extension.
+* Addition of the Zabha extension for Byte and Halfword Atomic Memory Operations.
+
+
+[.big]*_Preface to Document Version 20240411_*
+
+This document describes the RISC-V unprivileged architecture.
+It contains the following versions of the RISC-V ISA modules:
+
+[%autowidth,float="center",align="center",cols="^,<,^",options="header"]
+|===
+|Base |Version |Status
+|*RV32I* |*2.1* |*Ratified*
+|*RV32E* |*2.0* |*Ratified*
+|*RV64E* |*2.0* |*Ratified*
+|*RV64I* |*2.1* |*Ratified*
+
+h|Extension h|Version h|Status
+
+|*Zifencei* |*2.0* |*Ratified*
+|*Zicsr* |*2.0* |*Ratified*
+|*Zicntr* |*2.0* |*Ratified*
+|*Zihintntl* |*1.0* |*Ratified*
+|*Zihintpause* |*2.0* |*Ratified*
+|*Zimop* | *1.0* | *Ratified*
+|*Zicond* | *1.0* |*Ratified*
+|*Zilsd* | *1.0* |*Ratified*
+|*M* |*2.0* |*Ratified*
+|*Zmmul* |*1.0* |*Ratified*
+|*A* |*2.1* |*Ratified*
+|*Zawrs* |*1.01* |*Ratified*
+|*Zacas* |*1.0* |*Ratified*
+|*Zabha* |*1.0* |*Ratified*
+|*RVWMO* |*2.0* |*Ratified*
+|*Ztso* |*1.0* |*Ratified*
+|*CMO* |*1.0* |*Ratified*
+|*F* |*2.2* |*Ratified*
+|*D* |*2.2* |*Ratified*
+|*Q* |*2.2* |*Ratified*
+|*Zfh* |*1.0* |*Ratified*
+|*Zfhmin* |*1.0* |*Ratified*
+|*Zfa* |*1.0* |*Ratified*
+|*Zfinx* |*1.0* |*Ratified*
+|*Zdinx* |*1.0* |*Ratified*
+|*Zhinx* |*1.0* |*Ratified*
+|*Zhinxmin* |*1.0* |*Ratified*
+|*C* |*2.0* |*Ratified*
+|*Zce* |*1.0* |*Ratified*
+|*Zclsd* |*1.0* |*Ratified*
+|*B* |*1.0* |*Ratified*
+|*V* |*1.0* |*Ratified*
+|*Zbkb* |*1.0* |*Ratified*
+|*Zbkc* |*1.0* |*Ratified*
+|*Zbkx* |*1.0* |*Ratified*
+|*Zk* |*1.0* |*Ratified*
+|*Zks* |*1.0* |*Ratified*
+|*Zvbb* |*1.0* |*Ratified*
+|*Zvbc* |*1.0* |*Ratified*
+|*Zvkg* |*1.0* |*Ratified*
+|*Zvkned* |*1.0* |*Ratified*
+|*Zvknhb* |*1.0* |*Ratified*
+|*Zvksed* |*1.0* |*Ratified*
+|*Zvksh* |*1.0* |*Ratified*
+|*Zvkt* |*1.0* |*Ratified*
+|*Zicfiss* |*1.0* |*Ratified*
+|*Zicfilp* |*1.0* |*Ratified*
+|===
+
+The changes in this version of the document include:
+
+* The inclusion of all ratified extensions through February 2025.
+* The draft Zam extension has been removed, in favor of the definition of a misaligned atomicity granule PMA.
+* The concept of vacant memory regions has been superseded by inaccessible memory or I/O regions.
+* The removal of unratified content, including the sketch of the RV128I base ISA.
+
+[.big]*_Preface to Document Version 20191213-Base-Ratified_*
+
+This document describes the RISC-V unprivileged architecture.
+
+The ISA modules marked *Ratified* have been ratified at this time. The
+modules marked _Frozen_ are not expected to change significantly before
+being put up for ratification. The modules marked _Draft_ are expected
+to change before ratification.
+
+The document contains the following versions of the RISC-V ISA modules:
+
+[%autowidth,float="center",align="center",cols="^,<,^",options="header",]
+|===
+|Base |Version |Status
+|RVWMO |2.0 |*Ratified*
+|*RV32I* |*2.1* |*Ratified*
+|*RV64I* |*2.1* |*Ratified*
+|_RV32E_ |_1.9_ |_Draft_
+|_RV128I_ |_1.7_ |_Draft_
+h|Extension h|Version h|Status
+|*M* |*2.0* |*Ratified*
+|*A* |*2.1* |*Ratified*
+|*F* |*2.2* |*Ratified*
+|*D* |*2.2* |*Ratified*
+|*Q* |*2.2* |*Ratified*
+|*C* |*2.0* |*Ratified*
+|_Counters_ |_2.0_ |_Draft_
+|_L_ |_0.0_ |_Draft_
+|_B_ |_0.0_ |_Draft_
+|_J_ |_0.0_ |_Draft_
+|_T_ |_0.0_ |_Draft_
+|_P_ |_0.2_ |_Draft_
+|_V_ |_0.7_ |_Draft_
+|*Zicsr* |*2.0* |*Ratified*
+|*Zifencei* |*2.0* |*Ratified*
+|_Zam_ |_0.1_ |_Draft_
+|_Ztso_ |_0.1_ |_Frozen_
+|===
+
+The changes in this version of the document include:
+
+* The A extension, now version 2.1, was ratified by the board in
+December 2019.
+* Defined big-endian ISA variant.
+* Moved N extension for user-mode interrupts into Volume II.
+* Defined PAUSE hint instruction.
+
+[.big]*_Preface to Document Version 20190608-Base-Ratified_*
+
+This document describes the RISC-V unprivileged architecture.
+
+The RVWMO memory model has been ratified at this time. The ISA modules
+marked *Ratified*, have been ratified at this time. The modules marked
+_Frozen_ are not expected to change significantly before being put up
+for ratification. The modules marked _Draft_ are expected to change
+before ratification.
+
+The document contains the following versions of the RISC-V ISA modules:
+
+[%autowidth,float="center",align="center",cols="^,<,^",options="header",]
+|===
+|Base |Version |Status
+|RVWMO |2.0 |*Ratified*
+|*RV32I* |*2.1* |*Ratified*
+|*RV64I* |*2.1* |*Ratified*
+|_RV32E_ |_1.9_ |_Draft_
+|_RV128I_ |_1.7_ |_Draft_
+h|Extension h|Version h|Status
+|*Zifencei* |*2.0* |*Ratified*
+|*Zicsr* |*2.0* |*Ratified*
+|*M* |*2.0* |*Ratified*
+|_A_ |_2.0_ |Frozen
+|*F* |*2.2* |*Ratified*
+|*D* |*2.2* |*Ratified*
+|*Q* |*2.2* |*Ratified*
+|*C* |*2.0* |*Ratified*
+|_Ztso_ |_0.1_ |_Frozen_
+|_Counters_ |_2.0_ |_Draft_
+|_L_ |_0.0_ |_Draft_
+|_B_ |_0.0_ |_Draft_
+|_J_ |_0.0_ |_Draft_
+|_T_ |_0.0_ |_Draft_
+|_P_ |_0.2_ |_Draft_
+|_V_ |_0.7_ |_Draft_
+|_Zam_ |_0.1_ |_Draft_
+|===
+
+The changes in this version of the document include:
+
+* Moved description to *Ratified* for the ISA modules ratified by the
+board in early 2019.
+* Removed the A extension from ratification.
+* Changed document version scheme to avoid confusion with versions of
+the ISA modules.
+* Incremented the version numbers of the base integer ISA to 2.1,
+reflecting the presence of the ratified RVWMO memory model and exclusion
+of FENCE.I, counters, and CSR instructions that were in previous base
+ISA.
+* Incremented the version numbers of the F and D extensions to 2.2,
+reflecting that version 2.1 changed the canonical NaN, and version 2.2
+defined the NaN-boxing scheme and changed the definition of the FMIN and
+FMAX instructions.
+* Changed name of document to refer to "unprivileged" instructions as
+part of move to separate ISA specifications from platform profile
+mandates.
+* Added clearer and more precise definitions of execution environments,
+harts, traps, and memory accesses.
+* Defined instruction-set categories: _standard_, _reserved_, _custom_,
+_non-standard_, and _non-conforming_.
+* Removed text implying operation under alternate endianness, as
+alternate-endianness operation has not yet been defined for RISC-V.
+* Changed description of misaligned load and store behavior. The
+specification now allows visible misaligned address traps in execution
+environment interfaces, rather than just mandating invisible handling of
+misaligned loads and stores in user mode. Also, now allows access-fault
+exceptions to be reported for misaligned accesses (including atomics)
+that should not be emulated.
+* Moved FENCE.I out of the mandatory base and into a separate extension,
+with Zifencei ISA name. FENCE.I was removed from the Linux user ABI and
+is problematic in implementations with large incoherent instruction and
+data caches. However, it remains the only standard instruction-fetch
+coherence mechanism.
+* Removed prohibitions on using RV32E with other extensions.
+* Removed platform-specific mandates that certain encodings produce
+illegal-instruction exceptions in RV32E and RV64I chapters.
+* Counter/timer instructions are now not considered part of the
+mandatory base ISA, and so CSR instructions were moved into separate
+chapter and marked as version 2.0, with the unprivileged counters moved
+into another separate chapter. The counters are not ready for
+ratification as there are outstanding issues, including counter
+inaccuracies.
+* A CSR-access ordering model has been added.
+* Explicitly defined the 16-bit half-precision floating-point format for
+floating-point instructions in the 2-bit _fmt field._
+* Defined the signed-zero behavior of FMIN._fmt_ and FMAX._fmt_, and
+changed their behavior on signaling-NaN inputs to conform to the
+`minimumNumber` and `maximumNumber` operations in the proposed IEEE 754-201x
+specification.
+* The memory consistency model, RVWMO, has been defined.
+* The "Zam" extension, which permits misaligned AMOs and specifies
+their semantics, has been defined.
+* The "Ztso" extension, which enforces a stricter memory consistency
+model than RVWMO, has been defined.
+* Improvements to the description and commentary.
+* Defined the term `IALIGN` as shorthand to describe the
+instruction-address alignment constraint.
+* Removed text of `P` extension chapter as now superseded by active task
+group documents.
+* Removed text of `V` extension chapter as now superseded by separate
+vector extension draft document.
+
+[.big]*_Preface to Document Version 2.2_*
+
+This is version 2.2 of the document describing the RISC-V user-level
+architecture. The document contains the following versions of the RISC-V
+ISA modules:
+
+[%autowidth,float="center",align="center",cols="^,<,^",options="header",]
+|===
+h|Base h|_Version_ h|_Draft Frozen?_
+|RV32I |2.0 |Y
+|RV32E |1.9 |N
+|RV64I |2.0 |Y
+|RV128I |1.7 |N
+h|Extension h|Version h|Frozen?
+|M |2.0 |Y
+|A |2.0 |Y
+|F |2.0 |Y
+|D |2.0 |Y
+|Q |2.0 |Y
+|L |0.0 |N
+|C |2.0 |Y
+|B |0.0 |N
+|J |0.0 |N
+|T |0.0 |N
+|P |0.1 |N
+|V |0.7 |N
+|N |1.1 |N
+|===
+
+To date, no parts of the standard have been officially ratified by the
+RISC-V Foundation, but the components labeled "frozen" above are not
+expected to change during the ratification process beyond resolving
+ambiguities and holes in the specification.
+
+The major changes in this version of the document include:
+
+* The previous version of this document was released under a Creative
+Commons Attribution 4.0 International License by the original authors,
+and this and future versions of this document will be released under the
+same license.
+* Rearranged chapters to put all extensions first in canonical order.
+* Improvements to the description and commentary.
+* Modified implicit hinting suggestion on `JALR` to support more efficient
+macro-op fusion of `LUI/JALR` and `AUIPC/JALR` pairs.
+* Clarification of constraints on load-reserved/store-conditional
+sequences.
+* A new table of control and status register (CSR) mappings.
+* Clarified purpose and behavior of high-order bits of `fcsr`.
+* Corrected the description of the `FNMADD`._fmt_ and `FNMSUB`._fmt_
+instructions, which had suggested the incorrect sign of a zero result.
+* Instructions `FMV.S.X` and `FMV.X.S` were renamed to `FMV.W.X` and `FMV.X.W`
+respectively to be more consistent with their semantics, which did not
+change. The old names will continue to be supported in the tools.
+* Specified behavior of narrower (<FLEN) floating-point
+values held in wider `f` registers using NaN-boxing model.
+* Defined the exception behavior of FMA({inf}, 0, qNaN).
+* Added note indicating that the `P` extension might be reworked into an
+integer packed-SIMD proposal for fixed-point operations using the
+integer registers.
+* A draft proposal of the V vector instruction-set extension.
+* An early draft proposal of the N user-level traps extension.
+* An expanded pseudoinstruction listing.
+* Removal of the calling convention chapter, which has been superseded
+by the RISC-V ELF psABI Specification cite:[riscv-elf-psabi].
+* The C extension has been frozen and renumbered version 2.0.
+
+[.big]*_Preface to Document Version 2.1_*
+
+This is version 2.1 of the document describing the RISC-V user-level
+architecture. Note the frozen user-level ISA base and extensions `IMAFDQ`
+version 2.0 have not changed from the previous version of this
+document cite:[riscvtr2], but some specification holes have been fixed and the
+documentation has been improved. Some changes have been made to the
+software conventions.
+
+* Numerous additions and improvements to the commentary sections.
+* Separate version numbers for each chapter.
+* Modification to long instruction encodings >64 bits to
+avoid moving the _rd_ specifier in very long instruction formats.
+* CSR instructions are now described in the base integer format where
+the counter registers are introduced, as opposed to only being
+introduced later in the floating-point section (and the companion
+privileged architecture manual).
+* The SCALL and SBREAK instructions have been renamed to `ECALL` and
+`EBREAK`, respectively. Their encoding and functionality are unchanged.
+* Clarification of floating-point NaN handling, and a new canonical NaN
+value.
+* Clarification of values returned by floating-point to integer
+conversions that overflow.
+* Clarification of `LR/SC` allowed successes and required failures,
+including use of compressed instructions in the sequence.
+* A new `RV32E` base ISA proposal for reduced integer register counts,
+supports `MAC` extensions.
+* A revised calling convention.
+* Relaxed stack alignment for soft-float calling convention, and
+description of the RV32E calling convention.
+* A revised proposal for the `C` compressed extension, version 1.9 .
+
+[.big]*_Preface to Version 2.0_*
+
+This is the second release of the user ISA specification, and we intend
+the specification of the base user ISA plus general extensions (i.e.,
+IMAFD) to remain fixed for future development. The following changes
+have been made since Version 1.0 cite:[riscvtr] of this ISA specification.
+
+* The ISA has been divided into an integer base with several standard
+extensions.
+* The instruction formats have been rearranged to make immediate
+encoding more efficient.
+* The base ISA has been defined to have a little-endian memory system,
+with big-endian or bi-endian as non-standard variants.
+* Load-Reserved/Store-Conditional (`LR/SC`) instructions have been added
+in the atomic instruction extension.
+* `AMOs` and `LR/SC` can support the release consistency model.
+* The `FENCE` instruction provides finer-grain memory and I/O orderings.
+* An `AMO` for fetch-and-`XOR` (`AMOXOR`) has been added, and the encoding for
+`AMOSWAP` has been changed to make room.
+* The `AUIPC` instruction, which adds a 20-bit upper immediate to the `PC`,
+replaces the `RDNPC` instruction, which only read the current `PC` value.
+This results in significant savings for position-independent code.
+* The `JAL` instruction has now moved to the `U-Type` format with an
+explicit destination register, and the `J` instruction has been dropped
+being replaced by `JAL` with _rd_=`x0`. This removes the only instruction
+with an implicit destination register and removes the `J-Type` instruction
+format from the base ISA. There is an accompanying reduction in `JAL`
+reach, but a significant reduction in base ISA complexity.
+* The static hints on the `JALR` instruction have been dropped. The hints
+are redundant with the _rd_ and _rs1_ register specifiers for code
+compliant with the standard calling convention.
+* The `JALR` instruction now clears the lowest bit of the calculated
+target address, to simplify hardware and to allow auxiliary information
+to be stored in function pointers.
+* The `MFTX.S` and `MFTX.D` instructions have been renamed to `FMV.X.S` and
+`FMV.X.D`, respectively. Similarly, `MXTF.S` and `MXTF.D` instructions have
+been renamed to `FMV.S.X` and `FMV.D.X`, respectively.
+* The `MFFSR` and `MTFSR` instructions have been renamed to `FRCSR` and `FSCSR`,
+respectively. `FRRM`, `FSRM`, `FRFLAGS`, and `FSFLAGS` instructions have been
+added to individually access the rounding mode and exception flags
+subfields of the `fcsr`.
+* The `FMV.X.S` and `FMV.X.D` instructions now source their operands from
+_rs1_, instead of _rs2_. This change simplifies datapath design.
+* `FCLASS.S` and `FCLASS.D` floating-point classify instructions have been
+added.
+* A simpler NaN generation and propagation scheme has been adopted.
+* For `RV32I`, the system performance counters have been extended to
+64-bits wide, with separate read access to the upper and lower 32 bits.
+* Canonical `NOP` and `MV` encodings have been defined.
+* Standard instruction-length encodings have been defined for 48-bit,
+64-bit, and >64-bit instructions.
+* Description of a 128-bit address space variant, `RV128`, has been added.
+* Major opcodes in the 32-bit base instruction format have been
+allocated for user-defined custom extensions.
+* A typographical error that suggested that stores source their data
+from _rd_ has been corrected to refer to _rs2_.
diff --git a/src/counters.adoc b/src/counters.adoc
new file mode 100644
index 0000000..a56ce02
--- /dev/null
+++ b/src/counters.adoc
@@ -0,0 +1,236 @@
+[[counters]]
+== "Zicntr" and "Zihpm" Extensions for Counters, Version 2.0
+
+RISC-V ISAs provide a set of up to thirty-two 64-bit performance
+counters and timers that are accessible via unprivileged XLEN-bit
+read-only CSR registers `0xC00`–`0xC1F` (when XLEN=32, the upper 32 bits
+are accessed via CSR registers `0xC80`–`0xC9F`). These counters are
+divided between the "Zicntr" and "Zihpm" extensions.
+
+=== "Zicntr" Extension for Base Counters and Timers
+
+The Zicntr standard extension comprises the first three of these
+counters (CYCLE, TIME, and INSTRET), which have dedicated functions
+(cycle count, real-time clock, and instructions retired, respectively).
+The Zicntr extension depends on the Zicsr extension.
+
+[NOTE]
+====
+We recommend provision of these basic counters in implementations as
+they are essential for basic performance analysis, adaptive and dynamic
+optimization, and to allow an application to work with real-time
+streams. Additional counters in the separate Zihpm extension can help
+diagnose performance problems and these should be made accessible from
+user-level application code with low overhead.
+
+Some execution environments might prohibit access to counters, for
+example, to impede timing side-channel attacks.
+====
+
+include::images/wavedrom/counters-diag.edn[]
+
+
+For base ISAs with XLEN&#8805;64, CSR instructions can access
+the full 64-bit CSRs directly. In particular, the RDCYCLE, RDTIME, and
+RDINSTRET pseudoinstructions read the full 64 bits of the `cycle`,
+`time`, and `instret` counters.
+
+[NOTE]
+====
+The counter pseudoinstructions are mapped to the read-only
+`csrrs rd, counter, x0` canonical form, but the other read-only CSR
+instruction forms (based on CSRRC/CSRRSI/CSRRCI) are also legal ways to
+read these CSRs.
+====
+For base ISAs with XLEN=32, the Zicntr extension enables the three
+64-bit read-only counters to be accessed in 32-bit pieces. The RDCYCLE,
+RDTIME, and RDINSTRET pseudoinstructions provide the lower 32 bits, and
+the RDCYCLEH, RDTIMEH, and RDINSTRETH pseudoinstructions provide the
+upper 32 bits of the respective counters.
+[NOTE]
+====
+We required the counters be 64 bits wide, even when XLEN=32, as
+otherwise it is very difficult for software to determine if values have
+overflowed. For a low-end implementation, the upper 32 bits of each
+counter can be implemented using software counters incremented by a trap
+handler triggered by overflow of the lower 32 bits. The sample code
+given below shows how the full 64-bit width value can be safely read
+using the individual 32-bit width pseudoinstructions.
+====
+
+The RDCYCLE pseudoinstruction reads the low XLEN bits of the `cycle`
+CSR which holds a count of the number of clock cycles executed by the
+processor core on which the hart is running from an arbitrary start time
+in the past. RDCYCLEH is only present when XLEN=32 and reads bits 63-32
+of the same cycle counter. The underlying 64-bit counter should never
+overflow in practice. The rate at which the cycle counter advances will
+depend on the implementation and operating environment. The execution
+environment should provide a means to determine the current rate
+(cycles/second) at which the cycle counter is incrementing.
+[NOTE]
+====
+RDCYCLE is intended to return the number of cycles executed by the
+processor core, not the hart. Precisely defining what is a "core" is
+difficult given some implementation choices (e.g., AMD Bulldozer).
+Precisely defining what is a "clock cycle" is also difficult given the
+range of implementations (including software emulations), but the intent
+is that RDCYCLE is used for performance monitoring along with the other
+performance counters. In particular, where there is one hart/core, one
+would expect cycle-count/instructions-retired to measure CPI for a hart.
+
+Cores don't have to be exposed to software at all, and an implementer
+might choose to pretend multiple harts on one physical core are running
+on separate cores with one hart/core, and provide separate cycle
+counters for each hart. This might make sense in a simple barrel
+processor (e.g., CDC 6600 peripheral processors) where inter-hart timing
+interactions are non-existent or minimal.
+
+Where there is more than one hart/core and dynamic multithreading, it is
+not generally possible to separate out cycles per hart (especially with
+SMT). It might be possible to define a separate performance counter that
+tried to capture the number of cycles a particular hart was running, but
+this definition would have to be very fuzzy to cover all the possible
+threading implementations. For example, should we only count cycles for
+which any instruction was issued to execution for this hart, and/or
+cycles any instruction retired, or include cycles this hart was
+occupying machine resources but couldn't execute due to stalls while
+other harts went into execution? Likely, "all of the above" would be
+needed to have understandable performance stats. This complexity of
+defining a per-hart cycle count, and also the need in any case for a
+total per-core cycle count when tuning multithreaded code led to just
+standardizing the per-core cycle counter, which also happens to work
+well for the common single hart/core case.
+
+Standardizing what happens during "sleep" is not practical given that
+what "sleep" means is not standardized across execution environments,
+but if the entire core is paused (entirely clock-gated or powered-down
+in deep sleep), then it is not executing clock cycles, and the cycle
+count shouldn't be increasing per the spec. There are many details,
+e.g., whether clock cycles required to reset a processor after waking up
+from a power-down event should be counted, and these are considered
+execution-environment-specific details.
+
+Even though there is no precise definition that works for all platforms,
+this is still a useful facility for most platforms, and an imprecise,
+common, "usually correct" standard here is better than no standard.
+The intent of RDCYCLE was primarily performance monitoring/tuning, and
+the specification was written with that goal in mind.
+====
+The RDTIME pseudoinstruction reads the low XLEN bits of the "time" CSR,
+which counts wall-clock real time that has passed from an arbitrary
+start time in the past. RDTIMEH is only present when XLEN=32 and reads
+bits 63-32 of the same real-time counter. The underlying 64-bit counter
+increments by one with each tick of the real-time clock, and, for
+realistic real-time clock frequencies, should never overflow in
+practice. The execution environment should provide a means of
+determining the period of a counter tick (seconds/tick). The period
+should be constant within a small error bound. The environment should
+provide a means to determine the accuracy of the clock (i.e., the
+maximum relative error between the nominal and actual real-time clock
+periods).
+[NOTE]
+====
+On some simple platforms, cycle count might represent a valid
+implementation of RDTIME, in which case RDTIME and RDCYCLE may return
+the same result.
+
+It is difficult to provide a strict mandate on clock period given the
+wide variety of possible implementation platforms. The maximum error
+bound should be set based on the requirements of the platform.
+====
+
+The real-time clocks of all harts must be synchronized to within one
+tick of the real-time clock.
+[NOTE]
+====
+As with other architectural mandates, it suffices to appear "as if"
+harts are synchronized to within one tick of the real-time clock, i.e.,
+software is unable to observe that there is a greater delta between the
+real-time clock values observed on two harts.
+
+If, for example, the real-time clock increments at a frequency of 1 GHz, then
+all harts must appear to be synchronized to within 1 nsec.
+But it is also acceptable for this example implementation to only update the
+real-time clock at, say, a frequency of 100 MHz with increments of 10 ticks.
+As long as software cannot observe this seeming violation of the above
+synchronization requirement, and software always observes time across harts to
+be monotonically nondecreasing, then this implementation is compliant.
+
+A platform spec may then, for example, specify an apparent real-time clock
+tick frequency (e.g. 1 GHz) and also a minimum update frequency (e.g. 100 MHz)
+at which updated time values are guaranteed to be observable by software.
+Software may read time more frequently, but it should only observe
+monotonically nondecreasing values and it should observe a new value at least
+once every 10 ns (corresponding to the 100 MHz update frequency in this
+example).
+====
+The RDINSTRET pseudoinstruction reads the low XLEN bits of the
+`instret` CSR, which counts the number of instructions retired by this
+hart from some arbitrary start point in the past. RDINSTRETH is only
+present when XLEN=32 and reads bits 63-32 of the same instruction
+counter. The underlying 64-bit counter should never overflow in
+practice.
+[NOTE]
+====
+Instructions that cause synchronous exceptions, including ECALL and
+EBREAK, are not considered to retire and hence do not increment the
+`instret` CSR.
+====
+The following code sequence will read a valid 64-bit cycle counter value
+into `x3:x2`, even if the counter overflows its lower half between
+reading its upper and lower halves.
+
+[source,asm.]
+.Sample code for reading the 64-bit cycle counter when XLEN=32.
+ again:
+ rdcycleh x3
+ rdcycle x2
+ rdcycleh x4
+ bne x3, x4, again
+
+
+=== "Zihpm" Extension for Hardware Performance Counters
+
+The Zihpm extension comprises up to 29 additional unprivileged 64-bit
+hardware performance counters, `hpmcounter3-hpmcounter31`. When
+XLEN=32, the upper 32 bits of these performance counters are accessible
+via additional CSRs `hpmcounter3h- hpmcounter31h`. The Zihpm extension
+depends on the Zicsr extension.
+[NOTE]
+====
+In some applications, it is important to be able to read multiple
+counters at the same instant in time. When run under a multitasking
+environment, a user thread can suffer a context switch while attempting
+to read the counters. One solution is for the user thread to read the
+real-time counter before and after reading the other counters to
+determine if a context switch occurred in the middle of the sequence, in
+which case the reads can be retried. We considered adding output latches
+to allow a user thread to snapshot the counter values atomically, but
+this would increase the size of the user context, especially for
+implementations with a richer set of counters.
+====
+
+The implemented number and width of these additional counters, and the
+set of events they count, is platform-specific. Accessing an
+unimplemented or ill-configured counter may cause an illegal-instruction
+exception or may return a constant value.
+
+The execution environment should provide a means to determine the number
+and width of the implemented counters, and an interface to configure the
+events to be counted by each counter.
+[NOTE]
+====
+For execution environments implemented on RISC-V privileged platforms,
+the privileged architecture manual describes privileged CSRs controlling
+access by lower privileged modes to these counters, and to set the
+events to be counted.
+
+Alternative execution environments (e.g., user-level-only software
+performance models) may provide alternative mechanisms to configure the
+events counted by the performance counters.
+
+It would be useful to eventually standardize event settings to count
+ISA-level metrics, such as the number of floating-point instructions
+executed for example, and possibly a few common microarchitectural
+metrics, such as "L1 instruction cache misses".
+====
diff --git a/src/counters.tex b/src/counters.tex
deleted file mode 100644
index 1700f15..0000000
--- a/src/counters.tex
+++ /dev/null
@@ -1,205 +0,0 @@
-\chapter{Counters}
-\label{counters}
-
-RISC-V ISAs provide a set of up to 32$\times$64-bit performance counters and
-timers that are accessible via unprivileged XLEN read-only CSR
-registers {\tt 0xC00}--{\tt 0xC1F} (with the upper 32 bits accessed
-via CSR registers {\tt 0xC80}--{\tt 0xC9F} on RV32). The first three
-of these (CYCLE, TIME, and INSTRET) have dedicated functions (cycle
-count, real-time clock, and instructions-retired respectively), while
-the remaining counters, if implemented, provide programmable event
-counting.
-
-\section{Base Counters and Timers}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}S}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{csr} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-RDCYCLE[H] & 0 & CSRRS & dest & SYSTEM \\
-RDTIME[H] & 0 & CSRRS & dest & SYSTEM \\
-RDINSTRET[H] & 0 & CSRRS & dest & SYSTEM \\
-\end{tabular}
-\end{center}
-
-RV32I provides a number of 64-bit read-only user-level counters, which
-are mapped into the 12-bit CSR address space and accessed in 32-bit
-pieces using CSRRS instructions. In RV64I, the CSR instructions can
-manipulate 64-bit CSRs. In particular, the RDCYCLE, RDTIME, and
-RDINSTRET pseudoinstructions read the full 64 bits of the {\tt cycle},
-{\tt time}, and {\tt instret} counters. Hence, the RDCYCLEH, RDTIMEH,
-and RDINSTRETH instructions are not required in RV64I.
-
-\begin{commentary}
-Some execution environments might prohibit access to counters to
-impede timing side-channel attacks.
-\end{commentary}
-
-The RDCYCLE pseudoinstruction reads the low XLEN bits of the {\tt
- cycle} CSR which holds a count of the number of clock cycles
-executed by the processor core on which the hart is running from an
-arbitrary start time in the past. RDCYCLEH is an RV32I
-instruction that reads bits 63--32 of the same cycle counter. The
-underlying 64-bit counter should never overflow in practice. The rate
-at which the cycle counter advances will depend on the implementation
-and operating environment. The execution environment should provide a
-means to determine the current rate (cycles/second) at which the cycle
-counter is incrementing.
-
-\begin{commentary}
-RDCYCLE is intended to return the number of cycles executed by the
-processor core, not the hart. Precisely defining what is a ``core'' is
-difficult given some implementation choices (e.g., AMD Bulldozer).
-Precisely defining what is a ``clock cycle'' is also difficult given the
-range of implementations (including software emulations), but the
-intent is that RDCYCLE is used for performance monitoring along with the
-other performance counters. In particular, where there is one
-hart/core, one would expect cycle-count/instructions-retired to
-measure CPI for a hart.
-
-Cores don't have to be exposed to software at all, and an implementor
-might choose to pretend multiple harts on one physical core are
-running on separate cores with one hart/core, and provide separate
-cycle counters for each hart. This might make sense in a simple
-barrel processor (e.g., CDC 6600 peripheral processors) where
-inter-hart timing interactions are non-existent or minimal.
-
-Where there is more than one hart/core and dynamic multithreading, it
-is not generally possible to separate out cycles per hart (especially
-with SMT). It might be possible to define a separate performance
-counter that tried to capture the number of cycles a particular hart
-was running, but this definition would have to be very fuzzy to cover
-all the possible threading implementations. For example, should we
-only count cycles for which any instruction was issued to execution
-for this hart, and/or cycles any instruction retired, or include
-cycles this hart was occupying machine resources but couldn't execute
-due to stalls while other harts went into execution? Likely, ``all of
-the above'' would be needed to have understandable performance stats.
-This complexity of defining a per-hart cycle count, and also the need
-in any case for a total per-core cycle count when tuning multithreaded
-code led to just standardizing the per-core cycle counter, which also
-happens to work well for the common single hart/core case.
-
-Standardizing what happens during ``sleep'' is not practical given
-that what ``sleep'' means is not standardized across execution
-environments, but if the entire core is paused (entirely clock-gated
-or powered-down in deep sleep), then it is not executing clock cycles,
-and the cycle count shouldn't be increasing per the spec. There are
-many details, e.g., whether clock cycles required to reset a processor
-after waking up from a power-down event should be counted, and these
-are considered execution-environment-specific details.
-
-Even though there is no precise definition that works for all
-platforms, this is still a useful facility for most platforms, and an
-imprecise, common, ``usually correct'' standard here is better than no
-standard. The intent of RDCYCLE was primarily performance
-monitoring/tuning, and the specification was written with that goal in
-mind.
-\end{commentary}
-
-The RDTIME pseudoinstruction reads the low XLEN bits of the {\tt
- time} CSR, which counts wall-clock real time that has passed from an
-arbitrary start time in the past. RDTIMEH is an RV32I-only instruction
-that reads bits 63--32 of the same real-time counter. The underlying 64-bit
-counter should never overflow in practice. The execution environment
-should provide a means of determining the period of the real-time
-counter (seconds/tick). The period must be constant. The
-real-time clocks of all harts in a single user application
-should be synchronized to within one tick of the real-time clock. The
-environment should provide a means to determine the accuracy of the
-clock.
-
-\begin{commentary}
-On some simple platforms, cycle count might represent a valid
-implementation of RDTIME, but in this case, platforms should implement
-the RDTIME instruction as an alias for RDCYCLE to make code more
-portable, rather than using RDCYCLE to measure wall-clock time.
-\end{commentary}
-
-The RDINSTRET pseudoinstruction reads the low XLEN bits of the {\tt
- instret} CSR, which counts the number of instructions retired by
-this hart from some arbitrary start point in the past. RDINSTRETH is
-an RV32I-only instruction that reads bits 63--32 of the same
-instruction counter. The underlying 64-bit counter should never
-overflow in practice.
-
-The following code sequence will read a valid 64-bit cycle counter value into
-{\tt x3}:{\tt x2}, even if the counter overflows between reading its upper
-and lower halves.
-
-\begin{figure}[h!]
-\begin{center}
-\begin{verbatim}
- again:
- rdcycleh x3
- rdcycle x2
- rdcycleh x4
- bne x3, x4, again
-\end{verbatim}
-\end{center}
-\caption{Sample code for reading the 64-bit cycle counter in RV32.}
-\label{rdcycle}
-\end{figure}
-
-\begin{commentary}
-We recommend provision of these basic counters in implementations
-as they are essential for basic performance analysis, adaptive and
-dynamic optimization, and to allow an application to work with
-real-time streams. Additional counters should be provided to help
-diagnose performance problems and these should be made accessible from
-user-level application code with low overhead.
-
-We required the counters be 64 bits wide, even on RV32, as otherwise
-it is very difficult for software to determine if values have
-overflowed. For a low-end implementation, the upper 32 bits of each
-counter can be implemented using software counters incremented by a
-trap handler triggered by overflow of the lower 32 bits. The sample
-code described above shows how the full 64-bit width value can be
-safely read using the individual 32-bit instructions.
-
-In some applications, it is important to be able to read multiple
-counters at the same instant in time. When run under a multitasking
-environment, a user thread can suffer a context switch while
-attempting to read the counters. One solution is for the user thread
-to read the real-time counter before and after reading the other
-counters to determine if a context switch occurred in the middle of the
-sequence, in which case the reads can be retried. We considered
-adding output latches to allow a user thread to snapshot the counter
-values atomically, but this would increase the size of the user
-context, especially for implementations with a richer set of counters.
-\end{commentary}
-
-\section{Hardware Performance Counters}
-
-There is CSR space allocated for 29 additional unprivileged 64-bit
-hardware performance counters, {\tt hpmcounter3}--{\tt hpmcounter31}.
-For RV32, the upper 32 bits of these performance counters is
-accessible via additional CSRs {\tt hpmcounter3h}--{\tt
- hpmcounter31h}. These counters count platform-specific events and
-are configured via additional privileged registers. The number and
-width of these additional counters, and the set of events they count
-is platform-specific.
-
-\begin{commentary}
- The privileged architecture manual describes the privileged CSRs
- controlling access to these counters and to set the events to be
- counted.
-
- It would be useful to eventually standardize event settings to count
- ISA-level metrics, such as the number of floating-point instructions
- executed for example, and possibly a few common microarchitectural
- metrics, such as ``L1 instruction cache misses''.
-\end{commentary}
diff --git a/src/csr.tex b/src/csr.tex
deleted file mode 100644
index eb52e27..0000000
--- a/src/csr.tex
+++ /dev/null
@@ -1,156 +0,0 @@
-\chapter{``Zicsr'', Control and Status Register (CSR) Instructions, Version 2.0}
-\label{csrinsts}
-
-RISC-V defines a separate address space of 4096 Control and Status
-registers associated with each hart. This chapter defines the full
-set of CSR instructions that operate on these CSRs.
-
-\begin{commentary}
- While CSRs are primarily used by the privileged architecture, there
- are several uses in unprivileged code including for counters and
- timers, and for floating-point status.
-
- The counters and timers are no longer considered mandatory parts of
- the standard base ISAs, and so the CSR instructions required to
- access them have been moved out of the base ISA chapter into this
- separate chapter.
-\end{commentary}
-
-\section{CSR Instructions}
-
-All CSR instructions atomically read-modify-write a single CSR, whose
-CSR specifier is encoded in the 12-bit {\em csr} field of the
-instruction held in bits 31--20. The immediate forms use a 5-bit
-zero-extended immediate encoded in the {\em rs1} field.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}S}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{csr} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-source/dest & source & CSRRW & dest & SYSTEM \\
-source/dest & source & CSRRS & dest & SYSTEM \\
-source/dest & source & CSRRC & dest & SYSTEM \\
-source/dest & uimm[4:0] & CSRRWI & dest & SYSTEM \\
-source/dest & uimm[4:0] & CSRRSI & dest & SYSTEM \\
-source/dest & uimm[4:0] & CSRRCI & dest & SYSTEM \\
-\end{tabular}
-\end{center}
-
-The CSRRW (Atomic Read/Write CSR) instruction atomically swaps values
-in the CSRs and integer registers. CSRRW reads the old value of the
-CSR, zero-extends the value to XLEN bits, then writes it to integer
-register {\em rd}. The initial value in {\em rs1} is written to the
-CSR. If {\em rd}={\tt x0}, then the instruction shall not read the CSR
-and shall not cause any of the side-effects that might occur on a CSR
-read.
-
-The CSRRS (Atomic Read and Set Bits in CSR) instruction reads the
-value of the CSR, zero-extends the value to XLEN bits, and writes it
-to integer register {\em rd}. The initial value in integer register
-{\em rs1} is treated as a bit mask that specifies bit positions to be
-set in the CSR. Any bit that is high in {\em rs1} will cause the
-corresponding bit to be set in the CSR, if that CSR bit is writable.
-Other bits in the CSR are unaffected (though CSRs might have side
-effects when written).
-
-The CSRRC (Atomic Read and Clear Bits in CSR) instruction reads the
-value of the CSR, zero-extends the value to XLEN bits, and writes it
-to integer register {\em rd}. The initial value in integer register
-{\em rs1} is treated as a bit mask that specifies bit positions to be
-cleared in the CSR. Any bit that is high in {\em rs1} will cause the
-corresponding bit to be cleared in the CSR, if that CSR bit is
-writable. Other bits in the CSR are unaffected.
-
-For both CSRRS and CSRRC, if {\em rs1}={\tt x0}, then the instruction
-will not write to the CSR at all, and so shall not cause any of the
-side effects that might otherwise occur on a CSR write, such as
-raising illegal instruction exceptions on accesses to read-only CSRs.
-Both CSRRS and CSRRC always read the addressed CSR and cause any read
-side effects regardless of {\em rs1} and {\em rd} fields. Note that
-if {\em rs1} specifies a register holding a zero value other than {\tt
- x0}, the instruction will still attempt to write the unmodified
-value back to the CSR and will cause any attendant side effects. A
-CSRRW with {\em rs1}={\tt x0} will attempt to write zero to the
-destination CSR.
-
-The CSRRWI, CSRRSI, and CSRRCI variants are similar to CSRRW, CSRRS,
-and CSRRC respectively, except they update the CSR using an XLEN-bit
-value obtained by zero-extending a 5-bit unsigned immediate (uimm[4:0]) field
-encoded in the {\em rs1} field instead of a value from an integer
-register. For CSRRSI and CSRRCI, if the uimm[4:0] field is zero, then
-these instructions will not write to the CSR, and shall not cause any
-of the side effects that might otherwise occur on a CSR write. For
-CSRRWI, if {\em rd}={\tt x0}, then the instruction shall not read the
-CSR and shall not cause any of the side-effects that might occur on a
-CSR read. Both CSRRSI and CSRRCI will always read the CSR and cause
-any read side-effects regardless of {\em rd} and {\em rs1} fields.
-
-\begin{table}
- \centering
- \begin{tabular}{|l|r|r|c|c|}
- \hline
- \multicolumn{5}{|c|}{Register operand} \\
- \hline
- Instruction & rd & rs1 & read CSR? & write CSR? \\
- \hline
- CSRRW & {\tt x0} & - & no & yes \\
- CSRRW & !{\tt x0} & - & yes & yes \\
- CSRR{S/C} & - & {\tt x0} & yes & no \\
- CSRR{S/C} & - & !{\tt x0} & yes & yes \\
- \hline
- \multicolumn{5}{|c|}{Immediate operand} \\
- \hline
-Instruction & rd & uimm & read CSR? & write CSR? \\
- \hline
- CSRRWI & {\tt x0} & - & no & yes \\
- CSRRWI & !{\tt x0} & - & yes & yes \\
- CSRR{S/C}I & - & 0 & yes & no \\
- CSRR{S/C}I & - & !0 & yes & yes \\
- \hline
- \end{tabular}
- \caption{Table showing whether a CSR instruction reads or writes a
- given CSR. The CSRRS and CSRRC instructions have same behavior so
- are shown as CSRR{S/C} in Table.}
- \label{tab:csrsideeffects}
-\end{table}
-
-Table~\ref{tab:csrsideeffects} summarizes the behavior of the CSR
-instructions with respect to whether they read and/or write the CSR.
-
-\begin{commentary}
- The CSRs defined so far do not have any architectural side effects on reads
- beyond raising illegal instruction exceptions on disallowed accesses.
- Custom extensions might add CSRs with side effects on reads.
-\end{commentary}
-
-Some CSRs, such as the instructions-retired counter, {\tt instret},
-may be modified as side effects of instruction execution. In these
-cases, if a CSR access instruction reads a CSR, it reads the value
-prior to the execution of the instruction. If a CSR access
-instruction writes such a CSR, the write is done instead of the
-increment. In particular, a value written to {\tt instret} by one
-instruction will be the value read by the following instruction.
-
-The assembler pseudoinstruction to read a CSR, CSRR {\em rd, csr}, is
-encoded as CSRRS {\em rd, csr, x0}. The assembler pseudoinstruction
-to write a CSR, CSRW {\em csr, rs1}, is encoded as CSRRW {\em x0, csr,
- rs1}, while CSRWI {\em csr, uimm}, is encoded as CSRRWI {\em x0,
- csr, uimm}.
-
-Further assembler pseudoinstructions are defined to set and clear
-bits in the CSR when the old value is not required: CSRS/CSRC {\em
- csr, rs1}; CSRSI/CSRCI {\em csr, uimm}.
-
diff --git a/src/d-st-ext.adoc b/src/d-st-ext.adoc
new file mode 100644
index 0000000..9cfd49b
--- /dev/null
+++ b/src/d-st-ext.adoc
@@ -0,0 +1,230 @@
+== "D" Extension for Double-Precision Floating-Point, Version 2.2
+
+This chapter describes the standard double-precision floating-point
+instruction-set extension, which is named "D" and adds
+double-precision floating-point computational instructions compliant
+with the IEEE 754-2008 arithmetic standard. The D extension depends on
+the base single-precision instruction subset F.
+(((double-precision, floating point)))
+(((floating point, double precision)))
+
+=== D Register State
+
+The D extension widens the 32 floating-point registers, `f0-f31`, to
+64 bits (FLEN=64 in <<fprs>>. The `f` registers can
+now hold either 32-bit or 64-bit floating-point values as described
+below in <<nanboxing>>.
+
+[NOTE]
+====
+FLEN can be 32, 64, or 128 depending on which of the F, D, and Q
+extensions are supported. There can be up to four different
+floating-point precisions supported, including H, F, D, and Q.
+====
+(((floating-point, supported precisions)))
+
+[[nanboxing]]
+=== NaN Boxing of Narrower Values
+
+When multiple floating-point precisions are supported, then valid values
+of narrower _n_-bit types, _n_<FLEN, are represented in the lower _n_ bits of an FLEN-bit NaN value, in a process termed NaN-boxing. The upper bits of a valid NaN-boxed value must be all 1s. Valid NaN-boxed _n_-bit values
+therefore appear as negative quiet NaNs (qNaNs) when viewed as any wider
+_m_-bit value, _n_ < _m_ &#8804; FLEN. Any operation that writes a narrower result to an 'f' register must write all 1s to the uppermost FLEN-_n_ bits to yield a legal NaN-boxedvalue.
+(((floating-point, requirements)))
+
+[NOTE]
+====
+Software might not know the current type of data stored in a
+floating-point register but has to be able to save and restore the
+register values, hence the result of using wider operations to transfer
+narrower values has to be defined. A common case is for callee-saved
+registers, but a standard convention is also desirable for features
+including variadic functions, user-level threading libraries, virtual machine
+migration, and debugging.
+====
+
+Floating-point _n_-bit transfer operations move external
+values held in IEEE standard formats into and out of the `f` registers,
+and comprise floating-point loads and stores (FL__n__/FS__n__) and floating-point move instructions (FMV._n_.X/FMV.X._n_). A narrower _n_-bit transfer, _n_<FLEN, into the `f` registers will create a valid NaN-boxed value. A narrower
+_n_-bit transfer out of the floating-point registers will
+transfer the lower _n_ bits of the register ignoring the
+upper FLEN-_n_ bits.
+
+Apart from transfer operations described in the previous paragraph, all
+other floating-point operations on narrower __n__-bit
+operations, _n_<FLEN, check if the input operands are
+correctly NaN-boxed, i.e., all upper FLEN-_n_ bits are 1. If
+so, the _n_ least-significant bits of the input are used as
+the input value, otherwise the input value is treated as an
+_n_-bit canonical NaN.
+
+[NOTE]
+====
+Earlier versions of this document did not define the behavior of feeding
+the results of narrower or wider operands into an operation, except to
+require that wider saves and restores would preserve the value of a
+narrower operand. The new definition removes this
+implementation-specific behavior, while still accommodating both
+non-recoded and recoded implementations of the floating-point unit. The
+new definition also helps catch software errors by propagating NaNs if
+values are used incorrectly.
+
+Non-recoded implementations unpack and pack the operands to IEEE
+standard format on the input and output of every floating-point
+operation. The NaN-boxing cost to a non-recoded implementation is
+primarily in checking if the upper bits of a narrower operation
+represent a legal NaN-boxed value, and in writing all 1s to the upper
+bits of a result.
+
+Recoded implementations use a more convenient internal format to
+represent floating-point values, with an added exponent bit to allow all
+values to be held normalized. The cost to the recoded implementation is
+primarily the extra tagging needed to track the internal types and sign
+bits, but this can be done without adding new state bits by recoding
+NaNs internally in the exponent field. Small modifications are needed to
+the pipelines used to transfer values in and out of the recoded format,
+but the datapath and latency costs are minimal. The recoding process has
+to handle shifting of input subnormal values for wide operands in any
+case, and extracting the NaN-boxed value is a similar process to
+normalization except for skipping over leading-1 bits instead of
+skipping over leading-0 bits, allowing the datapath multiplexing to be shared.
+====
+
+[[fld_fsd]]
+=== Double-Precision Load and Store Instructions
+
+The FLD instruction loads a double-precision floating-point value from
+memory into floating-point register _rd_. FSD stores a double-precision
+value from the floating-point registers to memory.
+(((floating point, load and store)))
+
+[NOTE]
+====
+The double-precision value may be a NaN-boxed single-precision value.
+====
+
+include::images/wavedrom/double-ls.edn[]
+[[double-ls]]
+//.Double-precision load and store
+
+FLD and FSD are only guaranteed to execute atomically if the effective
+address is naturally aligned and XLEN&#8805;64.
+
+FLD and FSD do not modify the bits being transferred; in particular, the
+payloads of non-canonical NaNs are preserved.
+
+=== Double-Precision Floating-Point Computational Instructions
+
+The double-precision floating-point computational instructions are
+defined analogously to their single-precision counterparts, but operate
+on double-precision operands and produce double-precision results.
+
+include::images/wavedrom/double-fl-compute.edn[]
+[[fl-compute]]
+//.Double-precision float computational
+
+=== Double-Precision Floating-Point Conversion and Move Instructions
+
+Floating-point-to-integer and integer-to-floating-point conversion
+instructions are encoded in the OP-FP major opcode space. FCVT.W.D or
+FCVT.L.D converts a double-precision floating-point number in
+floating-point register _rs1_ to a signed 32-bit or 64-bit integer,
+respectively, in integer register _rd_. FCVT.D.W or FCVT.D.L converts a
+32-bit or 64-bit signed integer, respectively, in integer register _rs1_
+into a double-precision floating-point number in floating-point register
+_rd_. FCVT.WU.D, FCVT.LU.D, FCVT.D.WU, and FCVT.D.LU variants convert to
+or from unsigned integer values. For RV64, FCVT.W[U].D sign-extends the
+32-bit result. FCVT.L[U].D and FCVT.D.L[U] are RV64-only instructions.
+The range of valid inputs for FCVT._int_.D and the behavior for invalid
+inputs are the same as for FCVT._int_.S.
+(((floating point, convert and move)))
+
+All floating-point to integer and integer to floating-point conversion
+instructions round according to the _rm_ field. Note FCVT.D.W[U] always
+produces an exact result and is unaffected by rounding mode.
+
+include::images/wavedrom/double-fl-convert-mv.edn[]
+[[fl-convert-mv]]
+//.Double-precision float convert and move
+
+The double-precision to single-precision and single-precision to
+double-precision conversion instructions, FCVT.S.D and FCVT.D.S, are
+encoded in the OP-FP major opcode space and both the source and
+destination are floating-point registers. The _rs2_ field encodes the
+datatype of the source, and the _fmt_ field encodes the datatype of the
+destination. FCVT.S.D rounds according to the RM field; FCVT.D.S will
+never round.
+(((double-precision, to single-precision)))
+(((single-precision, to double-precision )))
+
+include::images/wavedrom/fcvt-sd-ds.edn[]
+[[fcvt-sd-ds]]
+//.Double-precision FCVT.S.D and FCVT.D.S
+
+Floating-point to floating-point sign-injection instructions, FSGNJ.D,
+FSGNJN.D, and FSGNJX.D are defined analogously to the single-precision
+sign-injection instruction.
+//FSGNJ.D, FSGNJN.D, and FSGNJX.D
+
+include::images/wavedrom/fsjgnjnx-d.edn[]
+//.Double-precision sign-injection
+
+For XLEN&#8805;64 only, instructions are provided to move bit
+patterns between the floating-point and integer registers. FMV.X.D moves
+the double-precision value in floating-point register _rs1_ to a
+representation in IEEE 754-2008 standard encoding in integer register
+_rd_. FMV.D.X moves the double-precision value encoded in IEEE 754-2008
+standard encoding from the integer register _rs1_ to the floating-point
+register _rd_.
+
+FMV.X.D and FMV.D.X do not modify the bits being transferred; in
+particular, the payloads of non-canonical NaNs are preserved.
+
+include::images/wavedrom/d-xwwx.edn[]
+[[fmvxddx]]
+//.Double-precision float move to _rd_
+
+[NOTE]
+====
+Early versions of the RISC-V ISA had additional instructions to allow
+RV32 systems to transfer between the upper and lower portions of a
+64-bit floating-point register and an integer register. However, these
+would be the only instructions with partial register writes and would
+add complexity in implementations with recoded floating-point or
+register renaming, requiring a pipeline read-modify-write sequence.
+Scaling up to handling quad-precision for RV32 and RV64 would also
+require additional instructions if they were to follow this pattern. The
+ISA was defined to reduce the number of explicit int-float register
+moves, by having conversions and comparisons write results to the
+appropriate register file, so we expect the benefit of these
+instructions to be lower than for other ISAs.
+
+We note that for systems that implement a 64-bit floating-point unit
+including fused multiply-add support and 64-bit floating-point loads and
+stores, the marginal hardware cost of moving from a 32-bit to a 64-bit
+integer datapath is low, and a software ABI supporting 32-bit wide
+address-space and pointers can be used to avoid growth of static data
+and dynamic memory traffic.
+====
+
+=== Double-Precision Floating-Point Compare Instructions
+
+The double-precision floating-point compare instructions are defined
+analogously to their single-precision counterparts, but operate on
+double-precision operands.
+(((floating-point, compare)))
+
+include::images/wavedrom/double-fl-compare.edn[]
+[[fl-compare]]
+//.Double-precision float compare
+
+=== Double-Precision Floating-Point Classify Instruction
+
+The double-precision floating-point classify instruction, FCLASS.D, is
+defined analogously to its single-precision counterpart, but operates on
+double-precision operands.
+(((floating-point, classify)))
+
+include::images/wavedrom/double-fl-class.edn[]
+[[fl-class]]
+//.Double-precision float classify
diff --git a/src/d.tex b/src/d.tex
deleted file mode 100644
index c658ab3..0000000
--- a/src/d.tex
+++ /dev/null
@@ -1,439 +0,0 @@
-\chapter{``D'' Standard Extension for Double-Precision Floating-Point,
-Version 2.2}
-
-This chapter describes the standard double-precision floating-point
-instruction-set extension, which is named ``D'' and adds
-double-precision floating-point computational instructions compliant
-with the IEEE 754-2008 arithmetic standard. The D extension depends on
-the base single-precision instruction subset F.
-
-\section{D Register State}
-
-The D extension widens the 32 floating-point registers, {\tt f0}--{\tt
- f31}, to 64 bits (FLEN=64 in Figure~\ref{fprs}). The {\tt f}
-registers can now hold either 32-bit or 64-bit floating-point values
-as described below in Section~\ref{nanboxing}.
-
-\begin{commentary}
-FLEN can be 32, 64, or 128 depending on which of the F, D, and Q
-extensions are supported. There can be up to four different
-floating-point precisions supported, including H, F, D, and Q.
-\end{commentary}
-
-\section{NaN Boxing of Narrower Values}
-\label{nanboxing}
-
-When multiple floating-point precisions are supported, then valid
-values of narrower $n$-bit types, \mbox{$n<$ FLEN}, are represented in
-the lower $n$ bits of an FLEN-bit NaN value, in a process termed
-NaN-boxing. The upper bits of a valid NaN-boxed value must be all 1s.
-Valid NaN-boxed $n$-bit values therefore appear as negative quiet NaNs
-(qNaNs) when viewed as any wider $m$-bit value, \mbox{$n < m \leq$
- FLEN}. Any operation that writes a narrower result to an {\tt f}
-register must write all 1s to the uppermost FLEN$-n$ bits to yield a
-legal NaN-boxed value.
-
-\begin{samepage-commentary}
-Software might not know the current type of data stored in a
-floating-point register but has to be able to save and restore the
-register values, hence the result of using wider operations to
-transfer narrower values has to be defined. A common case is for
-callee-saved registers, but a standard convention is also desirable for
-features including varargs, user-level threading libraries, virtual
-machine migration, and debugging.
-\end{samepage-commentary}
-
-Floating-point $n$-bit transfer operations move external values held
-in IEEE standard formats into and out of the {\tt f} registers, and
-comprise floating-point loads and stores (FL$n$/FS$n$) and
-floating-point move instructions (FMV.$n$.X/FMV.X.$n$). A narrower
-$n$-bit transfer, \mbox{$n<$ FLEN}, into the {\tt f} registers will create a
-valid NaN-boxed value. A narrower $n$-bit transfer out of
-the floating-point registers will transfer the lower $n$ bits of the
-register ignoring the upper FLEN$-n$ bits.
-
-Apart from transfer operations described in the previous paragraph,
-all other floating-point operations on narrower $n$-bit operations,
-\mbox{$n<$ FLEN}, check if the input operands are correctly NaN-boxed,
-i.e., all upper FLEN$-n$ bits are 1. If so, the $n$ least-significant
-bits of the input are used as the input value, otherwise the input
-value is treated as an $n$-bit canonical NaN.
-
-\begin{commentary}
-Earlier versions of this document did not define the behavior of
-feeding the results of narrower or wider operands into an operation,
-except to require that wider saves and restores would preserve the
-value of a narrower operand. The new definition removes this
-implementation-specific behavior, while still accommodating both
-non-recoded and recoded implementations of the floating-point unit.
-The new definition also helps catch software errors by propagating
-NaNs if values are used incorrectly.
-
-Non-recoded implementations unpack and pack the operands to IEEE
-standard format on the input and output of every floating-point
-operation. The NaN-boxing cost to a non-recoded implementation is
-primarily in checking if the upper bits of a narrower operation
-represent a legal NaN-boxed value, and in writing all 1s to the upper
-bits of a result.
-
-Recoded implementations use a more convenient internal format to
-represent floating-point values, with an added exponent bit to allow
-all values to be held normalized. The cost to the recoded
-implementation is primarily the extra tagging needed to track the
-internal types and sign bits, but this can be done without adding new
-state bits by recoding NaNs internally in the exponent field. Small
-modifications are needed to the pipelines used to transfer values in
-and out of the recoded format, but the datapath and latency costs are
-minimal. The recoding process has to handle shifting of input
-subnormal values for wide operands in any case, and extracting the
-NaN-boxed value is a similar process to normalization except for
-skipping over leading-1 bits instead of skipping over leading-0 bits,
-allowing the datapath muxing to be shared.
-\end{commentary}
-
-\section{Double-Precision Load and Store Instructions}
-\label{fld_fsd}
-
-The FLD instruction loads a double-precision floating-point value from
-memory into floating-point register {\em rd}. FSD stores a double-precision
-value from the floating-point registers to memory.
-\begin{commentary}
-The double-precision value may be a NaN-boxed single-precision value.
-\end{commentary}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{width} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-offset[11:0] & base & D & dest & LOAD-FP \\
-\end{tabular}
-\end{center}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{O@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:5]} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{width} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-offset[11:5] & src & base & D & offset[4:0] & STORE-FP \\
-\end{tabular}
-\end{center}
-
-FLD and FSD are only guaranteed to execute atomically if the effective address
-is naturally aligned and XLEN$\geq$64.
-
-FLD and FSD do not modify the bits being transferred; in particular, the
-payloads of non-canonical NaNs are preserved.
-
-\section{Double-Precision Floating-Point Computational Instructions}
-
-The double-precision floating-point computational instructions are
-defined analogously to their single-precision counterparts, but operate on
-double-precision operands and produce double-precision results.
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FADD/FSUB & D & src2 & src1 & RM & dest & OP-FP \\
-FMUL/FDIV & D & src2 & src1 & RM & dest & OP-FP \\
-FMIN-MAX & D & src2 & src1 & MIN/MAX & dest & OP-FP \\
-FSQRT & D & 0 & src & RM & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{rs3} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-src3 & D & src2 & src1 & RM & dest & F[N]MADD/F[N]MSUB \\
-\end{tabular}
-\end{center}
-
-\section{Double-Precision Floating-Point Conversion and Move Instructions}
-
-Floating-point-to-integer and integer-to-floating-point conversion
-instructions are encoded in the OP-FP major opcode space.
-FCVT.W.D or FCVT.L.D converts a double-precision floating-point number
-in floating-point register {\em rs1} to a signed 32-bit or 64-bit
-integer, respectively, in integer register {\em rd}. FCVT.D.W
-or FCVT.D.L converts a 32-bit or 64-bit signed integer,
-respectively, in integer register {\em rs1} into a
-double-precision floating-point
-number in floating-point register {\em rd}. FCVT.WU.D,
-FCVT.LU.D, FCVT.D.WU, and FCVT.D.LU variants
-convert to or from unsigned integer values.
-For RV64, FCVT.W[U].D sign-extends the 32-bit result.
-FCVT.L[U].D and FCVT.D.L[U] are RV64-only instructions.
-The range of valid inputs for FCVT.{\em int}.D and
-the behavior for invalid inputs are the same as for FCVT.{\em int}.S.
-
-All floating-point to integer and integer to floating-point conversion
-instructions round according to the {\em rm} field. Note FCVT.D.W[U] always
-produces an exact result and is unaffected by rounding mode.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCVT.{\em int}.D & D & W[U]/L[U] & src & RM & dest & OP-FP \\
-FCVT.D.{\em int} & D & W[U]/L[U] & src & RM & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-The double-precision to single-precision and single-precision to
-double-precision conversion instructions, FCVT.S.D and FCVT.D.S, are
-encoded in the OP-FP major opcode space and both the source and
-destination are floating-point registers. The {\em rs2} field
-encodes the datatype of the source, and the {\em fmt} field encodes
-the datatype of the destination. FCVT.S.D rounds according to the
-RM field; FCVT.D.S will never round.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCVT.S.D & S & D & src & RM & dest & OP-FP \\
-FCVT.D.S & D & S & src & RM & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-Floating-point to floating-point sign-injection instructions, FSGNJ.D,
-FSGNJN.D, and FSGNJX.D are defined analogously to the single-precision
-sign-injection instruction.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FSGNJ & D & src2 & src1 & J[N]/JX & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-For XLEN$\geq$64 only, instructions are provided to move bit patterns
-between the floating-point and integer registers. FMV.X.D moves the
-double-precision value in floating-point register {\em rs1} to a
-representation in IEEE 754-2008 standard encoding in integer register
-{\em rd}. FMV.D.X moves the double-precision value encoded in IEEE
-754-2008 standard encoding from the integer register {\em rs1} to the
-floating-point register {\em rd}.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FMV.X.D & D & 0 & src & 000 & dest & OP-FP \\
-FMV.D.X & D & 0 & src & 000 & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-\begin{commentary}
- Early versions of the RISC-V ISA had additional instructions to
- allow RV32 systems to transfer between the upper and lower portions
- of a 64-bit floating-point register and an integer register.
- However, these would be the only instructions with partial register
- writes and would add complexity in implementations with recoded
- floating-point or register renaming, requiring a pipeline read-modify-write
- sequence. Scaling up to handling quad-precision for RV32 and RV64
- would also require additional instructions if they were to follow
- this pattern. The ISA was defined to reduce the number of explicit
- int-float register moves, by having conversions and comparisons
- write results to the appropriate register file, so we expect the
- benefit of these instructions to be lower than for other ISAs.
-
- We note that for systems that implement a 64-bit floating-point unit
- including fused multiply-add support and 64-bit floating-point loads
- and stores, the marginal hardware cost of moving from a 32-bit to
- a 64-bit integer datapath is low, and a software ABI supporting 32-bit
- wide address-space and pointers can be used to avoid growth of
- static data and dynamic memory traffic.
-\end{commentary}
-
-\section{Double-Precision Floating-Point Compare Instructions}
-
-The double-precision floating-point compare instructions are
-defined analogously to their single-precision counterparts, but operate on
-double-precision operands.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCMP & D & src2 & src1 & EQ/LT/LE & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-\section{Double-Precision Floating-Point Classify Instruction}
-
-The double-precision floating-point classify instruction, FCLASS.D, is
-defined analogously to its single-precision counterpart, but operates on
-double-precision operands.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCLASS & D & 0 & src & 001 & dest & OP-FP \\
-\end{tabular}
-\end{center}
diff --git a/src/dep-table.tex b/src/dep-table.tex
deleted file mode 100644
index c84cecd..0000000
--- a/src/dep-table.tex
+++ /dev/null
@@ -1,456 +0,0 @@
-\section{CSR Dependency Tracking Granularity}
-\label{sec:csr-granularity}
-
-\begin{table}[h!]
- \centering
- \begin{tabular}{|l|l|l|}
- \hline
- Name & Portions Tracked as Independent Units & Aliases \\
- \hline
- {\tt fflags} & Bits 4, 3, 2, 1, 0 & {\tt fcsr} \\
- \hline
- {\tt frm} & entire CSR & {\tt fcsr} \\
- \hline
- {\tt fcsr} & Bits 7-5, 4, 3, 2, 1, 0 & {\tt fflags}, {\tt frm} \\
- \hline
- \end{tabular}
- \caption{Granularities at which syntactic dependencies are tracked through CSRs}
-\end{table}
-
-Note: read-only CSRs are not listed, as they do not participate in the definition of syntactic dependencies.
-
-\section{Source and Destination Register Listings}
-\label{sec:source-dest-regs}
-
-This section provides a concrete listing of the source and destination registers for each instruction.
-These listings are used in the definition of syntactic dependencies in Section~\ref{sec:memorymodel:dependencies}.
-
-The term ``accumulating CSR'' is used to describe a CSR that is both a source and a destination register, but which carries a dependency only from itself to itself.
-
-Instructions carry a dependency from each source register in the ``Source Registers'' column to each destination register in the ``Destination Registers'' column, from each source register in the ``Source Registers'' column to each CSR in the ``Accumulating CSRs'' column, and from each CSR in the ``Accumulating CSRs'' column to itself, except where annotated otherwise.
-
-Key:
-
-$^A$Address source register
-
-$^D$Data source register
-
-$^\dagger$The instruction does not carry a dependency from any source register to any destination register
-
-$^\ddagger$The instruction carries dependencies from source register(s) to destination register(s) as specified
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV32I Base Integer Instruction Set} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- LUI & & {\em rd} & & \\
- \cline{2-4}
- AUIPC & & {\em rd} & & \\
- \cline{2-4}
- JAL & & {\em rd} & & \\
- \cline{2-4}
- JALR$^\dagger$ & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- BEQ & {\em rs1}, {\em rs2} & & & \\
- \cline{2-4}
- BNE & {\em rs1}, {\em rs2} & & & \\
- \cline{2-4}
- BLT & {\em rs1}, {\em rs2} & & & \\
- \cline{2-4}
- BGE & {\em rs1}, {\em rs2} & & & \\
- \cline{2-4}
- BLTU & {\em rs1}, {\em rs2} & & & \\
- \cline{2-4}
- BGEU & {\em rs1}, {\em rs2} & & & \\
- \cline{2-4}
- LB$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- LH$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- LW$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- LBU$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- LHU$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- SB & {\em rs1}$^A$, {\em rs2}$^D$ & & & \\
- \cline{2-4}
- SH & {\em rs1}$^A$, {\em rs2}$^D$ & & & \\
- \cline{2-4}
- SW & {\em rs1}$^A$, {\em rs2}$^D$ & & & \\
- \cline{2-4}
- ADDI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- SLTI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- SLTIU & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- XORI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- ORI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- ANDI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- SLLI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- SRLI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- SRAI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- ADD & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- SUB & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- SLL & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- SLT & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- SLTU & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- XOR & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- SRL & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- SRA & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- OR & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- AND & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- FENCE & & & & \\
- \cline{2-4}
- FENCE.I & & & & \\
- \cline{2-4}
- ECALL & & & & \\
- \cline{2-4}
- EBREAK & & & & \\
- \cline{2-4}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV32I Base Integer Instruction Set (continued)} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- CSRRW$^\ddagger$ & {\em rs1}, {\em csr}$^*$ & {\em rd}, {\em csr} & & $^*$unless {\em rd}={\tt x0} \\
- \cline{2-4}
- CSRRS$^\ddagger$ & {\em rs1}, {\em csr} & {\em rd}$^*$, {\em csr} & & $^*$unless {\em rs1}={\tt x0} \\
- \cline{2-4}
- CSRRC$^\ddagger$ & {\em rs1}, {\em csr} & {\em rd}$^*$, {\em csr} & & $^*$unless {\em rs1}={\tt x0} \\
- \cline{2-4}
- \multicolumn{1}{c}{} & \multicolumn{3}{l}{$\ddagger$carries a dependency from {\em rs1} to {\em csr} and from {\em csr} to {\em rd}}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV32I Base Integer Instruction Set (continued)} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- CSRRWI$^\ddagger$ & {\em csr}$^*$ & {\em rd}, {\em csr} & & $^*$unless {\em rd}={\tt x0} \\
- \cline{2-4}
- CSRRSI$^\ddagger$ & {\em csr} & {\em rd}, {\em csr}$^*$ & & $^*$unless uimm[4:0]=0 \\
- \cline{2-4}
- CSRRCI$^\ddagger$ & {\em csr} & {\em rd}, {\em csr}$^*$ & & $^*$unless uimm[4:0]=0 \\
- \cline{2-4}
- \multicolumn{1}{c}{} & \multicolumn{3}{l}{$\ddagger$carries a dependency from {\em csr} to {\em rd}}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV64I Base Integer Instruction Set} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- LWU$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- LD$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- SD & {\em rs1}$^A$, {\em rs2}$^D$ & & & \\
- \cline{2-4}
- SLLI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- SRLI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- SRAI & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- ADDIW & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- SLLIW & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- SRLIW & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- SRAIW & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- ADDW & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- SUBW & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- SLLW & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- SRLW & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- SRAW & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV32M Standard Extension} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- MUL & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- MULH & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- MULHSU & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- MULHU & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- DIV & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- DIVU & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- REM & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- REMU & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV64M Standard Extension} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- MULW & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- DIVW & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- DIVUW & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- REMW & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- REMUW & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV32A Standard Extension} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- LR.W$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- SC.W$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd}$^*$ & & $^*$if successful \\
- \cline{2-4}
- AMOSWAP.W$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOADD.W$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOXOR.W$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOAND.W$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOOR.W$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOMIN.W$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOMAX.W$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOMINU.W$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOMAXU.W$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV64A Standard Extension} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- LR.D$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- SC.D$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd}$^*$ & & $^*$if successful \\
- \cline{2-4}
- AMOSWAP.D$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOADD.D$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOXOR.D$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOAND.D$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOOR.D$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOMIN.D$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOMAX.D$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOMINU.D$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
- AMOMAXU.D$^\dagger$ & {\em rs1}$^A$, {\em rs2}$^D$ & {\em rd} & & \\
- \cline{2-4}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV32F Standard Extension} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- FLW$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- FSW & {\em rs1}$^A$, {\em rs2}$^D$ & & & \\
- \cline{2-4}
- FMADD.S & {\em rs1}, {\em rs2}, {\em rs3}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FMSUB.S & {\em rs1}, {\em rs2}, {\em rs3}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FNMSUB.S & {\em rs1}, {\em rs2}, {\em rs3}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FNMADD.S & {\em rs1}, {\em rs2}, {\em rs3}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FADD.S & {\em rs1}, {\em rs2}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FSUB.S & {\em rs1}, {\em rs2}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FMUL.S & {\em rs1}, {\em rs2}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FDIV.S & {\em rs1}, {\em rs2}, frm$^*$ & {\em rd} & NV, DZ, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FSQRT.S & {\em rs1}, frm$^*$ & {\em rd} & NV, NX & $^*$if rm=111 \\
- \cline{2-4}
- FSGNJ.S & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- FSGNJN.S & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- FSGNJX.S & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- FMIN.S & {\em rs1}, {\em rs2} & {\em rd} & NV & \\
- \cline{2-4}
- FMAX.S & {\em rs1}, {\em rs2} & {\em rd} & NV & \\
- \cline{2-4}
- FCVT.W.S & {\em rs1}, frm$^*$ & {\em rd} & NV, NX & $^*$if rm=111 \\
- \cline{2-4}
- FCVT.WU.S & {\em rs1}, frm$^*$ & {\em rd} & NV, NX & $^*$if rm=111 \\
- \cline{2-4}
- FMV.X.W & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- FEQ.S & {\em rs1}, {\em rs2} & {\em rd} & NV & \\
- \cline{2-4}
- FLT.S & {\em rs1}, {\em rs2} & {\em rd} & NV & \\
- \cline{2-4}
- FLE.S & {\em rs1}, {\em rs2} & {\em rd} & NV & \\
- \cline{2-4}
- FCLASS.S & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- FCVT.S.W & {\em rs1}, frm$^*$ & {\em rd} & NX & $^*$if rm=111 \\
- \cline{2-4}
- FCVT.S.WU & {\em rs1}, frm$^*$ & {\em rd} & NX & $^*$if rm=111 \\
- \cline{2-4}
- FMV.W.X & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV64F Standard Extension} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- FCVT.L.S & {\em rs1} & {\em rd} & NV, NX & \\
- \cline{2-4}
- FCVT.LU.S & {\em rs1} & {\em rd} & NV, NX & \\
- \cline{2-4}
- FCVT.S.L & {\em rs1} & {\em rd} & NX & \\
- \cline{2-4}
- FCVT.S.LU & {\em rs1} & {\em rd} & NX & \\
- \cline{2-4}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV32D Standard Extension} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- FLD$^\dagger$ & {\em rs1}$^A$ & {\em rd} & & \\
- \cline{2-4}
- FSD & {\em rs1}$^A$, {\em rs2}$^D$ & & & \\
- \cline{2-4}
- FMADD.D & {\em rs1}, {\em rs2}, {\em rs3}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FMSUB.D & {\em rs1}, {\em rs2}, {\em rs3}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FNMSUB.D & {\em rs1}, {\em rs2}, {\em rs3}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FNMADD.D & {\em rs1}, {\em rs2}, {\em rs3}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FADD.D & {\em rs1}, {\em rs2}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FSUB.D & {\em rs1}, {\em rs2}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FMUL.D & {\em rs1}, {\em rs2}, frm$^*$ & {\em rd} & NV, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FDIV.D & {\em rs1}, {\em rs2}, frm$^*$ & {\em rd} & NV, DZ, OF, UF, NX & $^*$if rm=111 \\
- \cline{2-4}
- FSQRT.D & {\em rs1}, frm$^*$ & {\em rd} & NV, NX & $^*$if rm=111 \\
- \cline{2-4}
- FSGNJ.D & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- FSGNJN.D & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- FSGNJX.D & {\em rs1}, {\em rs2} & {\em rd} & & \\
- \cline{2-4}
- FMIN.D & {\em rs1}, {\em rs2} & {\em rd} & NV & \\
- \cline{2-4}
- FMAX.D & {\em rs1}, {\em rs2} & {\em rd} & NV & \\
- \cline{2-4}
- FCVT.S.D & {\em rs1}, frm$^*$ & {\em rd} & NX & $^*$if rm=111 \\
- \cline{2-4}
- FCVT.D.S & {\em rs1}, frm$^*$ & {\em rd} & NX & $^*$if rm=111 \\
- \cline{2-4}
- FEQ.D & {\em rs1}, {\em rs2} & {\em rd} & NV & \\
- \cline{2-4}
- FLT.D & {\em rs1}, {\em rs2} & {\em rd} & NV & \\
- \cline{2-4}
- FLE.D & {\em rs1}, {\em rs2} & {\em rd} & NV & \\
- \cline{2-4}
- FCLASS.D & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- FCVT.W.D & {\em rs1}, frm$^*$ & {\em rd} & NV, NX & $^*$if rm=111 \\
- \cline{2-4}
- FCVT.WU.D & {\em rs1}, frm$^*$ & {\em rd} & NV, NX & $^*$if rm=111 \\
- \cline{2-4}
- FCVT.D.W & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- FCVT.D.WU & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
-\end{tabular}
-
-\begin{tabular}{p{3cm}|p{3cm}|p{2cm}|p{4cm}|p{4cm}}
- \multicolumn{4}{l}{\bf RV64D Standard Extension} \\
- \cline{2-4}
- & Source & Destination & Accumulating \\
- & Registers & Registers & CSRs \\
- \cline{2-4}
- FCVT.L.D & {\em rs1}, frm$^*$ & {\em rd} & NV, NX & $^*$if rm=111 \\
- \cline{2-4}
- FCVT.LU.D & {\em rs1}, frm$^*$ & {\em rd} & NV, NX & $^*$if rm=111 \\
- \cline{2-4}
- FMV.X.D & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
- FCVT.D.L & {\em rs1}, frm$^*$ & {\em rd} & NX & $^*$if rm=111 \\
- \cline{2-4}
- FCVT.D.LU & {\em rs1}, frm$^*$ & {\em rd} & NX & $^*$if rm=111 \\
- \cline{2-4}
- FMV.D.X & {\em rs1} & {\em rd} & & \\
- \cline{2-4}
-\end{tabular}
diff --git a/src/example/memcpy.s b/src/example/memcpy.s
new file mode 100644
index 0000000..5f6318a
--- /dev/null
+++ b/src/example/memcpy.s
@@ -0,0 +1,17 @@
+ .text
+ .balign 4
+ .global memcpy
+ # void *memcpy(void* dest, const void* src, size_t n)
+ # a0=dest, a1=src, a2=n
+ #
+ memcpy:
+ mv a3, a0 # Copy destination
+ loop:
+ vsetvli t0, a2, e8, m8, ta, ma # Vectors of 8b
+ vle8.v v0, (a1) # Load bytes
+ add a1, a1, t0 # Bump pointer
+ sub a2, a2, t0 # Decrement count
+ vse8.v v0, (a3) # Store bytes
+ add a3, a3, t0 # Bump pointer
+ bnez a2, loop # Any more?
+ ret # Return
diff --git a/src/example/saxpy.s b/src/example/saxpy.s
new file mode 100644
index 0000000..de7f224
--- /dev/null
+++ b/src/example/saxpy.s
@@ -0,0 +1,29 @@
+ .text
+ .balign 4
+ .global saxpy
+# void
+# saxpy(size_t n, const float a, const float *x, float *y)
+# {
+# size_t i;
+# for (i=0; i<n; i++)
+# y[i] = a * x[i] + y[i];
+# }
+#
+# register arguments:
+# a0 n
+# fa0 a
+# a1 x
+# a2 y
+
+saxpy:
+ vsetvli a4, a0, e32, m8, ta, ma
+ vle32.v v0, (a1)
+ sub a0, a0, a4
+ slli a4, a4, 2
+ add a1, a1, a4
+ vle32.v v8, (a2)
+ vfmacc.vf v8, fa0, v0
+ vse32.v v8, (a2)
+ add a2, a2, a4
+ bnez a0, saxpy
+ ret
diff --git a/src/example/sgemm.S b/src/example/sgemm.S
new file mode 100644
index 0000000..328149d
--- /dev/null
+++ b/src/example/sgemm.S
@@ -0,0 +1,221 @@
+ .text
+ .balign 4
+ .global sgemm_nn
+# RV64IDV system
+#
+# void
+# sgemm_nn(size_t n,
+# size_t m,
+# size_t k,
+# const float*a, // m * k matrix
+# size_t lda,
+# const float*b, // k * n matrix
+# size_t ldb,
+# float*c, // m * n matrix
+# size_t ldc)
+#
+# c += a*b (alpha=1, no transpose on input matrices)
+# matrices stored in C row-major order
+
+#define n a0
+#define m a1
+#define k a2
+#define ap a3
+#define astride a4
+#define bp a5
+#define bstride a6
+#define cp a7
+#define cstride t0
+#define kt t1
+#define nt t2
+#define bnp t3
+#define cnp t4
+#define akp t5
+#define bkp s0
+#define nvl s1
+#define ccp s2
+#define amp s3
+
+# Use args as additional temporaries
+#define ft12 fa0
+#define ft13 fa1
+#define ft14 fa2
+#define ft15 fa3
+
+# This version holds a 16*VLMAX block of C matrix in vector registers
+# in inner loop, but otherwise does not cache or TLB tiling.
+
+sgemm_nn:
+ addi sp, sp, -FRAMESIZE
+ sd s0, OFFSET(sp)
+ sd s1, OFFSET(sp)
+ sd s2, OFFSET(sp)
+
+ # Check for zero size matrices
+ beqz n, exit
+ beqz m, exit
+ beqz k, exit
+
+ # Convert elements strides to byte strides.
+ ld cstride, OFFSET(sp) # Get arg from stack frame
+ slli astride, astride, 2
+ slli bstride, bstride, 2
+ slli cstride, cstride, 2
+
+ slti t6, m, 16
+ bnez t6, end_rows
+
+c_row_loop: # Loop across rows of C blocks
+
+ mv nt, n # Initialize n counter for next row of C blocks
+
+ mv bnp, bp # Initialize B n-loop pointer to start
+ mv cnp, cp # Initialize C n-loop pointer
+
+c_col_loop: # Loop across one row of C blocks
+ vsetvli nvl, nt, e32, m1, ta, ma # 32-bit vectors, LMUL=1
+
+ mv akp, ap # reset pointer into A to beginning
+ mv bkp, bnp # step to next column in B matrix
+
+ # Initialize current C submatrix block from memory.
+ vle32.v v0, (cnp); add ccp, cnp, cstride;
+ vle32.v v1, (ccp); add ccp, ccp, cstride;
+ vle32.v v2, (ccp); add ccp, ccp, cstride;
+ vle32.v v3, (ccp); add ccp, ccp, cstride;
+ vle32.v v4, (ccp); add ccp, ccp, cstride;
+ vle32.v v5, (ccp); add ccp, ccp, cstride;
+ vle32.v v6, (ccp); add ccp, ccp, cstride;
+ vle32.v v7, (ccp); add ccp, ccp, cstride;
+ vle32.v v8, (ccp); add ccp, ccp, cstride;
+ vle32.v v9, (ccp); add ccp, ccp, cstride;
+ vle32.v v10, (ccp); add ccp, ccp, cstride;
+ vle32.v v11, (ccp); add ccp, ccp, cstride;
+ vle32.v v12, (ccp); add ccp, ccp, cstride;
+ vle32.v v13, (ccp); add ccp, ccp, cstride;
+ vle32.v v14, (ccp); add ccp, ccp, cstride;
+ vle32.v v15, (ccp)
+
+
+ mv kt, k # Initialize inner loop counter
+
+ # Inner loop scheduled assuming 4-clock occupancy of vfmacc instruction and single-issue pipeline
+ # Software pipeline loads
+ flw ft0, (akp); add amp, akp, astride;
+ flw ft1, (amp); add amp, amp, astride;
+ flw ft2, (amp); add amp, amp, astride;
+ flw ft3, (amp); add amp, amp, astride;
+ # Get vector from B matrix
+ vle32.v v16, (bkp)
+
+ # Loop on inner dimension for current C block
+ k_loop:
+ vfmacc.vf v0, ft0, v16
+ add bkp, bkp, bstride
+ flw ft4, (amp)
+ add amp, amp, astride
+ vfmacc.vf v1, ft1, v16
+ addi kt, kt, -1 # Decrement k counter
+ flw ft5, (amp)
+ add amp, amp, astride
+ vfmacc.vf v2, ft2, v16
+ flw ft6, (amp)
+ add amp, amp, astride
+ flw ft7, (amp)
+ vfmacc.vf v3, ft3, v16
+ add amp, amp, astride
+ flw ft8, (amp)
+ add amp, amp, astride
+ vfmacc.vf v4, ft4, v16
+ flw ft9, (amp)
+ add amp, amp, astride
+ vfmacc.vf v5, ft5, v16
+ flw ft10, (amp)
+ add amp, amp, astride
+ vfmacc.vf v6, ft6, v16
+ flw ft11, (amp)
+ add amp, amp, astride
+ vfmacc.vf v7, ft7, v16
+ flw ft12, (amp)
+ add amp, amp, astride
+ vfmacc.vf v8, ft8, v16
+ flw ft13, (amp)
+ add amp, amp, astride
+ vfmacc.vf v9, ft9, v16
+ flw ft14, (amp)
+ add amp, amp, astride
+ vfmacc.vf v10, ft10, v16
+ flw ft15, (amp)
+ add amp, amp, astride
+ addi akp, akp, 4 # Move to next column of a
+ vfmacc.vf v11, ft11, v16
+ beqz kt, 1f # Don't load past end of matrix
+ flw ft0, (akp)
+ add amp, akp, astride
+1: vfmacc.vf v12, ft12, v16
+ beqz kt, 1f
+ flw ft1, (amp)
+ add amp, amp, astride
+1: vfmacc.vf v13, ft13, v16
+ beqz kt, 1f
+ flw ft2, (amp)
+ add amp, amp, astride
+1: vfmacc.vf v14, ft14, v16
+ beqz kt, 1f # Exit out of loop
+ flw ft3, (amp)
+ add amp, amp, astride
+ vfmacc.vf v15, ft15, v16
+ vle32.v v16, (bkp) # Get next vector from B matrix, overlap loads with jump stalls
+ j k_loop
+
+1: vfmacc.vf v15, ft15, v16
+
+ # Save C matrix block back to memory
+ vse32.v v0, (cnp); add ccp, cnp, cstride;
+ vse32.v v1, (ccp); add ccp, ccp, cstride;
+ vse32.v v2, (ccp); add ccp, ccp, cstride;
+ vse32.v v3, (ccp); add ccp, ccp, cstride;
+ vse32.v v4, (ccp); add ccp, ccp, cstride;
+ vse32.v v5, (ccp); add ccp, ccp, cstride;
+ vse32.v v6, (ccp); add ccp, ccp, cstride;
+ vse32.v v7, (ccp); add ccp, ccp, cstride;
+ vse32.v v8, (ccp); add ccp, ccp, cstride;
+ vse32.v v9, (ccp); add ccp, ccp, cstride;
+ vse32.v v10, (ccp); add ccp, ccp, cstride;
+ vse32.v v11, (ccp); add ccp, ccp, cstride;
+ vse32.v v12, (ccp); add ccp, ccp, cstride;
+ vse32.v v13, (ccp); add ccp, ccp, cstride;
+ vse32.v v14, (ccp); add ccp, ccp, cstride;
+ vse32.v v15, (ccp)
+
+ # Following tail instructions should be scheduled earlier in free slots during C block save.
+ # Leaving here for clarity.
+
+ # Bump pointers for loop across blocks in one row
+ slli t6, nvl, 2
+ add cnp, cnp, t6 # Move C block pointer over
+ add bnp, bnp, t6 # Move B block pointer over
+ sub nt, nt, nvl # Decrement element count in n dimension
+ bnez nt, c_col_loop # Any more to do?
+
+ # Move to next set of rows
+ addi m, m, -16 # Did 16 rows above
+ slli t6, astride, 4 # Multiply astride by 16
+ add ap, ap, t6 # Move A matrix pointer down 16 rows
+ slli t6, cstride, 4 # Multiply cstride by 16
+ add cp, cp, t6 # Move C matrix pointer down 16 rows
+
+ slti t6, m, 16
+ beqz t6, c_row_loop
+
+ # Handle end of matrix with fewer than 16 rows.
+ # Can use smaller versions of above decreasing in powers-of-2 depending on code-size concerns.
+end_rows:
+ # Not done.
+
+exit:
+ ld s0, OFFSET(sp)
+ ld s1, OFFSET(sp)
+ ld s2, OFFSET(sp)
+ addi sp, sp, FRAMESIZE
+ ret
diff --git a/src/example/strcmp.s b/src/example/strcmp.s
new file mode 100644
index 0000000..5e9177c
--- /dev/null
+++ b/src/example/strcmp.s
@@ -0,0 +1,32 @@
+ .text
+ .balign 4
+ .global strcmp
+ # int strcmp(const char *src1, const char* src2)
+strcmp:
+ ## Using LMUL=2, but same register names work for larger LMULs
+ li t1, 0 # Initial pointer bump
+loop:
+ vsetvli t0, x0, e8, m2, ta, ma # Max length vectors of bytes
+ add a0, a0, t1 # Bump src1 pointer
+ vle8ff.v v8, (a0) # Get src1 bytes
+ add a1, a1, t1 # Bump src2 pointer
+ vle8ff.v v16, (a1) # Get src2 bytes
+
+ vmseq.vi v0, v8, 0 # Flag zero bytes in src1
+ vmsne.vv v1, v8, v16 # Flag if src1 != src2
+ vmor.mm v0, v0, v1 # Combine exit conditions
+
+ vfirst.m a2, v0 # ==0 or != ?
+ csrr t1, vl # Get number of bytes fetched
+
+ bltz a2, loop # Loop if all same and no zero byte
+
+ add a0, a0, a2 # Get src1 element address
+ lbu a3, (a0) # Get src1 byte from memory
+
+ add a1, a1, a2 # Get src2 element address
+ lbu a4, (a1) # Get src2 byte from memory
+
+ sub a0, a3, a4 # Return value.
+
+ ret
diff --git a/src/example/strcpy.s b/src/example/strcpy.s
new file mode 100644
index 0000000..109112d
--- /dev/null
+++ b/src/example/strcpy.s
@@ -0,0 +1,20 @@
+ .text
+ .balign 4
+ .global strcpy
+ # char* strcpy(char *dst, const char* src)
+strcpy:
+ mv a2, a0 # Copy dst
+ li t0, -1 # Infinite AVL
+loop:
+ vsetvli x0, t0, e8, m8, ta, ma # Max length vectors of bytes
+ vle8ff.v v8, (a1) # Get src bytes
+ csrr t1, vl # Get number of bytes fetched
+ vmseq.vi v1, v8, 0 # Flag zero bytes
+ vfirst.m a3, v1 # Zero found?
+ add a1, a1, t1 # Bump pointer
+ vmsif.m v0, v1 # Set mask up to and including zero byte.
+ vse8.v v8, (a2), v0.t # Write out bytes
+ add a2, a2, t1 # Bump pointer
+ bltz a3, loop # Zero byte not found, so loop
+
+ ret
diff --git a/src/example/strlen.s b/src/example/strlen.s
new file mode 100644
index 0000000..1c3af4b
--- /dev/null
+++ b/src/example/strlen.s
@@ -0,0 +1,22 @@
+ .text
+ .balign 4
+ .global strlen
+# size_t strlen(const char *str)
+# a0 holds *str
+
+strlen:
+ mv a3, a0 # Save start
+loop:
+ vsetvli a1, x0, e8, m8, ta, ma # Vector of bytes of maximum length
+ vle8ff.v v8, (a3) # Load bytes
+ csrr a1, vl # Get bytes read
+ vmseq.vi v0, v8, 0 # Set v0[i] where v8[i] = 0
+ vfirst.m a2, v0 # Find first set bit
+ add a3, a3, a1 # Bump pointer
+ bltz a2, loop # Not found?
+
+ add a0, a0, a1 # Sum start + bump
+ add a3, a3, a2 # Add index
+ sub a0, a3, a0 # Subtract start address+bump
+
+ ret
diff --git a/src/example/strncpy.s b/src/example/strncpy.s
new file mode 100644
index 0000000..87e5410
--- /dev/null
+++ b/src/example/strncpy.s
@@ -0,0 +1,36 @@
+ .text
+ .balign 4
+ .global strncpy
+ # char* strncpy(char *dst, const char* src, size_t n)
+strncpy:
+ mv a3, a0 # Copy dst
+loop:
+ vsetvli x0, a2, e8, m8, ta, ma # Vectors of bytes.
+ vle8ff.v v8, (a1) # Get src bytes
+ vmseq.vi v1, v8, 0 # Flag zero bytes
+ csrr t1, vl # Get number of bytes fetched
+ vfirst.m a4, v1 # Zero found?
+ vmsbf.m v0, v1 # Set mask up to before zero byte.
+ vse8.v v8, (a3), v0.t # Write out non-zero bytes
+ bgez a4, zero_tail # Zero remaining bytes.
+ sub a2, a2, t1 # Decrement count.
+ add a3, a3, t1 # Bump dest pointer
+ add a1, a1, t1 # Bump src pointer
+ bnez a2, loop # Anymore?
+
+ ret
+
+zero_tail:
+ sub a2, a2, a4 # Subtract count on non-zero bytes.
+ add a3, a3, a4 # Advance past non-zero bytes.
+ vsetvli t1, a2, e8, m8, ta, ma # Vectors of bytes.
+ vmv.v.i v0, 0 # Splat zero.
+
+zero_loop:
+ vse8.v v0, (a3) # Store zero.
+ sub a2, a2, t1 # Decrement count.
+ add a3, a3, t1 # Bump pointer
+ vsetvli t1, a2, e8, m8, ta, ma # Vectors of bytes.
+ bnez a2, zero_loop # Anymore?
+
+ ret
diff --git a/src/example/vvaddint32.s b/src/example/vvaddint32.s
new file mode 100644
index 0000000..34d849b
--- /dev/null
+++ b/src/example/vvaddint32.s
@@ -0,0 +1,22 @@
+ .text
+ .balign 4
+ .global vvaddint32
+ # vector-vector add routine of 32-bit integers
+ # void vvaddint32(size_t n, const int*x, const int*y, int*z)
+ # { for (size_t i=0; i<n; i++) { z[i]=x[i]+y[i]; } }
+ #
+ # a0 = n, a1 = x, a2 = y, a3 = z
+ # Non-vector instructions are indented
+vvaddint32:
+ vsetvli t0, a0, e32, m1, ta, ma # Set vector length based on 32-bit vectors
+ vle32.v v0, (a1) # Get first vector
+ sub a0, a0, t0 # Decrement number done
+ slli t0, t0, 2 # Multiply number done by 4 bytes
+ add a1, a1, t0 # Bump pointer
+ vle32.v v1, (a2) # Get second vector
+ add a2, a2, t0 # Bump pointer
+ vadd.vv v2, v0, v1 # Sum vectors
+ vse32.v v2, (a3) # Store result
+ add a3, a3, t0 # Bump pointer
+ bnez a0, vvaddint32 # Loop back
+ ret # Finished
diff --git a/src/extensions.tex b/src/extensions.tex
deleted file mode 100644
index 2517165..0000000
--- a/src/extensions.tex
+++ /dev/null
@@ -1,381 +0,0 @@
-\chapter{Extending RISC-V}
-\label{extensions}
-
-In addition to supporting standard general-purpose software
-development, another goal of RISC-V is to provide a basis for more
-specialized instruction-set extensions or more customized
-accelerators. The instruction encoding spaces and optional
-variable-length instruction encoding are designed to make it easier to
-leverage software development effort for the standard ISA toolchain
-when building more customized processors. For example, the intent is
-to continue to provide full software support for implementations that
-only use the standard I base, perhaps together with many non-standard
-instruction-set extensions.
-
-This chapter describes various ways in which the base RISC-V ISA can
-be extended, together with the scheme for managing instruction-set
-extensions developed by independent groups. This volume only deals
-with the unprivileged ISA, although the same approach and terminology is
-used for supervisor-level extensions described in the second volume.
-
-\section{Extension Terminology}
-
-This section defines some standard terminology for describing RISC-V
-extensions.
-\vspace{-0.2in}
-\subsection*{Standard versus Non-Standard Extension}
-
-Any RISC-V processor implementation must support a base integer ISA
-(RV32I or RV64I). In addition, an implementation may support one or
-more extensions. We divide extensions into two broad categories: {\em
- standard} versus {\em non-standard}.
-\begin{itemize}
-\item 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 complete or planned standard extensions.
-\item A non-standard extension may be highly specialized and may
- conflict with other standard or non-standard extensions. We
- anticipate a wide variety of non-standard extensions will be
- developed over time, with some eventually being promoted to standard
- extensions.
-\end{itemize}
-
-\vspace{-0.2in}
-\subsection*{Instruction Encoding Spaces and Prefixes}
-
-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 ISA is 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 {\em prefix} to refer to the bits to the {\em right}
-of an instruction encoding space (since 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 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 instruction
-format, but is considered part of the prefix for 22-bit 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.
-Table~\ref{encodingspaces} gives the suggested sizes for RISC-V.
-
-\begin{table}[H]
-\begin{center}
-\begin{tabular}{|c|l|r|r|r|r|}
-\hline
-\multicolumn{1}{|c|}{Size} & \multicolumn{1}{|c|}{Usage} &
-\multicolumn{4}{|c|}{\# Available in standard instruction length} \\ \cline{3-6}
- & &
-\multicolumn{1}{|c|}{16-bit} &
-\multicolumn{1}{|c|}{32-bit} &
-\multicolumn{1}{|c|}{48-bit} &
-\multicolumn{1}{|c|}{64-bit} \\ \hline \hline
-14-bit & Quadrant of compressed 16-bit encoding & 3 & & & \\ \hline \hline
-22-bit & Minor opcode in base 32-bit encoding & & $2^{8}$ & $2^{20}$ & $2^{35}$ \\ \hline
-25-bit & Major opcode in base 32-bit encoding & & 32 & $2^{17}$ & $2^{32}$ \\ \hline
-30-bit & Quadrant of base 32-bit encoding & & 1 & $2^{12}$ & $2^{27}$ \\ \hline \hline
-32-bit & Minor opcode in 48-bit encoding & & & $2^{10}$ & $2^{25}$ \\ \hline
-37-bit & Major opcode in 48-bit encoding & & & 32 & $2^{20}$ \\ \hline
-40-bit & Quadrant of 48-bit encoding & & & 4 & $2^{17}$ \\ \hline \hline
-45-bit & Sub-minor opcode in 64-bit encoding & & & & $2^{12}$ \\ \hline
-48-bit & Minor opcode in 64-bit encoding & & & & $2^{9}$ \\ \hline
-52-bit & Major opcode in 64-bit encoding & & & & 32\\ \hline
-\end{tabular}
-\end{center}
-\caption{Suggested standard RISC-V instruction encoding space sizes.}
-\label{encodingspaces}
-\end{table}
-
-\vspace{-0.2in}
-\subsection*{Greenfield versus Brownfield Extensions}
-
-We use the term {\em greenfield extension} to describe an extension
-that begins populating a new instruction encoding space, and hence can
-only cause encoding conflicts at the prefix level. We use the term
-{\em brownfield extension} to describe an extension that fits around
-existing encodings in a previously defined instruction space. A
-brownfield extension is necessarily tied to a particular greenfield
-parent encoding, and there may be multiple brownfield extensions to
-the same greenfield parent encoding. For example, the base ISAs are
-greenfield encodings of a 30-bit instruction space, while the FDQ
-floating-point extensions are all brownfield extensions adding to the
-parent base ISA 30-bit encoding space.
-
-Note that we consider the standard A extension to have a greenfield
-encoding as it defines a new previously empty 25-bit encoding space in
-the leftmost bits of the full 32-bit base instruction encoding, even
-though its standard prefix locates it within the 30-bit encoding space
-of the base ISA. Changing only its single 7-bit prefix could move the
-A extension to a different 30-bit encoding space while only worrying
-about conflicts at the prefix level, not within the encoding space
-itself.
-
-\begin{table}[H]
-{
-\begin{center}
-\begin{tabular}{|r|c|c|}
-\hline
- & Adds state & No new state \\ \hline
-Greenfield & RV32I(30), RV64I(30) & A(25) \\\hline
-Brownfield & F(I), D(F), Q(D) & M(I) \\
-\hline
-\end{tabular}
-\end{center}
-}
-\caption{Two-dimensional characterization of standard instruction-set
- extensions.}
-\label{exttax}
-\end{table}
-
-Table~\ref{exttax} 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 of the instruction encoding space is given in parentheses. For
-brownfield extensions, the name of the extension (greenfield or
-brownfield) it builds upon is given in parentheses. Additional
-user-level architectural state usually implies changes to the
-supervisor-level system or possibly to the standard calling
-convention.
-
-Note that RV64I is not considered an extension of RV32I, but a
-different complete base encoding.
-
-\vspace{-0.2in}
-\subsection*{Standard-Compatible Global Encodings}
-
-A complete or {\em global} encoding of an ISA for an actual RISC-V
-implementation must allocate a unique non-conflicting prefix for every
-included instruction encoding space. The bases and every standard
-extension have each had a standard prefix allocated to ensure they can
-all coexist in a global encoding.
-
-A {\em standard-compatible} global encoding is one where the base and
-every included standard extension have their standard prefixes. A
-standard-compatible global encoding can include non-standard
-extensions that do not conflict with the included standard extensions.
-A standard-compatible global encoding can also use standard prefixes
-for non-standard extensions if the associated standard extensions are
-not included in the global encoding. In other words, a standard
-extension must use its standard prefix if included in a
-standard-compatible global encoding, but otherwise its prefix is free
-to be reallocated. These constraints allow a common toolchain to
-target the standard subset of any RISC-V standard-compatible global
-encoding.
-
-\vspace{-0.2in}
-\subsection*{Guaranteed Non-Standard Encoding Space}
-
-To support development of proprietary custom extensions, portions of
-the encoding space are guaranteed to never be used by standard
-extensions.
-
-\section{RISC-V Extension Design Philosophy}
-
-We intend to support a large number of independently developed
-extensions by encouraging extension developers to operate within
-instruction encoding spaces, and by providing tools to pack these into
-a standard-compatible global encoding by allocating unique prefixes.
-Some extensions are more naturally implemented as brownfield
-augmentations of existing extensions, and will share whatever prefix
-is allocated to their parent greenfield extension. The standard
-extension prefixes avoid spurious incompatibilities in the encoding of
-core functionality, while allowing custom packing of more esoteric
-extensions.
-
-This capability of repacking RISC-V extensions into different
-standard-compatible global encodings can be used in a number of ways.
-
-One use-case is developing highly specialized custom accelerators,
-designed to run kernels from important application domains. These
-might want to drop all but the base integer ISA and add in only the
-extensions that are required for the task in hand. The base ISA has
-been designed to place minimal requirements on a hardware
-implementation, and has been encoded to use only a small fraction of a
-32-bit instruction encoding space.
-
-Another use-case is to build a research prototype for a new type of
-instruction-set extension. The researchers might not want to expend
-the effort to implement a variable-length instruction-fetch unit, and
-so would like to prototype their extension using a simple 32-bit
-fixed-width instruction encoding. However, this new extension might
-be too large to coexist with standard extensions in the 32-bit space.
-If the research experiments do not need all of the standard
-extensions, a standard-compatible global encoding might drop the
-unused standard extensions and reuse their prefixes to place the
-proposed extension in a non-standard location to simplify engineering
-of the research prototype. Standard tools will still be able to
-target the base and any standard extensions that are present to reduce
-development time. Once the instruction-set extension has been
-evaluated and refined, it could then be made available for packing
-into a larger variable-length encoding space to avoid conflicts with
-all standard extensions.
-
-The following sections describe increasingly sophisticated strategies
-for developing implementations with new instruction-set extensions.
-These are mostly intended for use in highly customized, educational,
-or experimental architectures rather than for the main line of RISC-V
-ISA development.
-
-\section{Extensions within fixed-width 32-bit instruction format}
-\label{fix32b}
-
-In this section, we discuss adding extensions to implementations that
-only support the base fixed-width 32-bit instruction format.
-
-\begin{commentary}
-We anticipate the simplest fixed-width 32-bit encoding will be popular for
-many restricted accelerators and research prototypes.
-\end{commentary}
-
-\subsection*{Available 30-bit instruction encoding spaces}
-
-In the standard encoding, three of the available 30-bit instruction
-encoding spaces (those with 2-bit prefixes 00, 01, and 10) are used to
-enable the optional compressed instruction extension. However, if the
-compressed instruction-set extension is not required, then these three
-further 30-bit encoding spaces become available. This quadruples the
-available encoding space within the 32-bit format.
-
-\subsection*{Available 25-bit instruction encoding spaces}
-
-A 25-bit instruction encoding space corresponds to a major opcode in
-the base and standard extension encodings.
-
-There are four major opcodes expressly reserved for custom extensions
-(Table~\ref{opcodemap}), 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 standard
-or non-standard extensions for RV32 and RV64.
-
-The two opcodes reserved for RV64 (OP-IMM-32 and OP-32) can also be
-used for standard and non-standard extensions to RV32 only.
-
-If an implementation does not require floating-point, then the seven
-major opcodes reserved for standard floating-point extensions
-(LOAD-FP, STORE-FP, MADD, MSUB, NMSUB, NMADD, OP-FP) can be reused for
-non-standard extensions. Similarly, the AMO major opcode can be
-reused 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 Table~\ref{opcodemap}).
-
-The base RV32I encoding uses only 11 major opcodes plus 3 reserved
-opcodes, leaving up to 18 available for extensions. The base RV64I
-encoding uses only 13 major opcodes plus 3 reserved opcodes, leaving
-up to 16 available for extensions.
-
-\subsection*{Available 22-bit instruction encoding spaces}
-
-A 22-bit encoding space corresponds to a funct3 minor opcode space in
-the base and standard extension encodings. Several major opcodes have
-a funct3 field minor opcode that is not completely occupied, leaving
-available several 22-bit encoding spaces.
-
-Usually a major opcode selects the format used to encode operands in
-the remaining bits of the instruction, and ideally, an extension
-should follow the operand format of the major opcode to simplify
-hardware decoding.
-
-\subsection*{Other spaces}
-
-Smaller spaces are available under certain major opcodes, and not all
-minor opcodes are entirely filled.
-
-\section{Adding aligned 64-bit instruction extensions}
-
-The simplest approach to provide space for extensions that are too
-large for the base 32-bit fixed-width instruction format is to add
-naturally aligned 64-bit instructions. The implementation must still
-support the 32-bit base instruction format, but can require that
-64-bit instructions 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 Figure~\ref{instlengthcode}. 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 instructions are not
-required, then a 64-bit instruction could be encoded using one or more
-zero bits in the first two bits of an instruction.
-
-\begin{commentary}
-We anticipate processor generators that produce instruction-fetch
-units capable of automatically handling any combination of supported
-variable-length instruction encodings.
-\end{commentary}
-
-\section{Supporting VLIW encodings}
-
-Although RISC-V was not designed as a base for a pure VLIW machine,
-VLIW encodings can be added as extensions using several alternative
-approaches. In all cases, the base 32-bit encoding has to be supported
-to allow use of any standard software tools.
-
-\subsection*{Fixed-size instruction group}
-
-The simplest approach is to define a single large naturally aligned
-instruction format (e.g., 128 bits) within which VLIW operations are
-encoded. In a conventional VLIW, this approach would tend to waste
-instruction memory to hold NOPs, but a RISC-V-compatible
-implementation would have to also support the base 32-bit
-instructions, confining the VLIW code size expansion to
-VLIW-accelerated functions.
-
-\subsection*{Encoded-Length Groups}
-
-Another approach is to use the standard length encoding from
-Figure~\ref{instlengthcode} 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 operations, and so on.
-Alternatively, a 48-bit instruction could hold one 42-bit operation,
-while a 96-bit instruction could hold two 42-bit operations, and so
-on.
-
-This approach has the advantage of retaining the base ISA encoding for
-instructions holding a single operation, but has the disadvantage of
-requiring a new 28-bit or 42-bit encoding for operations within the
-VLIW instructions, and misaligned instruction fetch for larger groups.
-One simplification is to not allow VLIW instructions to straddle
-certain microarchitecturally significant boundaries (e.g., cache lines
-or virtual memory pages).
-
-\subsection*{Fixed-Size Instruction Bundles}
-
-Another approach, similar to Itanium, is to use a larger naturally
-aligned fixed instruction bundle size (e.g., 128 bits) across which
-parallel operation groups are encoded. This simplifies instruction
-fetch, but shifts the complexity to the group execution engine. To
-remain RISC-V compatible, the base 32-bit instruction would still have
-to be supported.
-
-\subsection*{End-of-Group bits in Prefix}
-
-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 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 semantics, with each instruction at the end of a
-group and not predicated.
-
-The main disadvantage of this approach is that the base ISA lacks the
-complex predication support usually required in an aggressive VLIW
-system, and it is difficult to add space to specify more predicate
-registers in the standard 30-bit encoding space.
diff --git a/src/f-st-ext.adoc b/src/f-st-ext.adoc
new file mode 100644
index 0000000..def2154
--- /dev/null
+++ b/src/f-st-ext.adoc
@@ -0,0 +1,499 @@
+:stem: latexmath
+
+[[single-float]]
+== "F" Extension for Single-Precision Floating-Point, Version 2.2
+
+This chapter describes the standard instruction-set extension for
+single-precision floating-point, which is named "F" and adds
+single-precision floating-point computational instructions compliant
+with the IEEE 754-2008 arithmetic standard cite:[ieee754-2008]. The F extension depends on the "Zicsr" extension for control and status register access.
+
+=== F Register State
+
+The F extension adds 32 floating-point registers, `f0-f31`, each 32
+bits wide, and a floating-point control and status register `fcsr`,
+which contains the operating mode and exception status of the
+floating-point unit. This additional state is shown in
+<<fprs>>. We use the term FLEN to describe the width of
+the floating-point registers in the RISC-V ISA, and FLEN=32 for the F
+single-precision floating-point extension. Most floating-point
+instructions operate on values in the floating-point register file.
+Floating-point load and store instructions transfer floating-point
+values between registers and memory. Instructions to transfer values to and from the integer register file are also provided.
+
+[NOTE]
+====
+We considered a unified register file for both integer and
+floating-point values as this simplifies software register allocation
+and calling conventions, and reduces total user state. However, a split
+organization increases the total number of registers accessible with a
+given instruction width, simplifies provision of enough register file ports
+for wide superscalar issue, supports decoupled floating-point-unit
+architectures, and simplifies use of internal floating-point encoding
+techniques. Compiler support and calling conventions for split register
+file architectures are well understood, and using dirty bits on
+floating-point register file state can reduce context-switch overhead.
+====
+
+[[fprs]]
+.RISC-V standard F extension single-precision floating-point state
+[cols="<,^,>",options="header",width="50%",align="center",grid="rows"]
+|===
+| [.small]#FLEN-1#| >| [.small]#0#
+3+^| [.small]#f0#
+3+^| [.small]#f1#
+3+^| [.small]#f2#
+3+^| [.small]#f3#
+3+^| [.small]#f4#
+3+^| [.small]#f5#
+3+^| [.small]#f6#
+3+^| [.small]#f7#
+3+^| [.small]#f8#
+3+^| [.small]#f9#
+3+^| [.small]#f10#
+3+^| [.small]#f11#
+3+^| [.small]#f12#
+3+^| [.small]#f13#
+3+^| [.small]#f14#
+3+^| [.small]#f15#
+3+^| [.small]#f16#
+3+^| [.small]#f17#
+3+^| [.small]#f18#
+3+^| [.small]#f19#
+3+^| [.small]#f20#
+3+^| [.small]#f21#
+3+^| [.small]#f22#
+3+^| [.small]#f23#
+3+^| [.small]#f24#
+3+^| [.small]#f25#
+3+^| [.small]#f26#
+3+^| [.small]#f27#
+3+^| [.small]#f28#
+3+^| [.small]#f29#
+3+^| [.small]#f30#
+3+^| [.small]#f31#
+3+^| [.small]#FLEN#
+| [.small]#31#| >| [.small]#0#
+3+^| [.small]#fcsr#
+3+^| [.small]#32#
+|===
+
+=== Floating-Point Control and Status Register
+
+The floating-point control and status register, `fcsr`, is a RISC-V
+control and status register (CSR). It is a 32-bit read/write register
+that selects the dynamic rounding mode for floating-point arithmetic
+operations and holds the accrued exception flags, as shown in <<fcsr>>.
+
+[[fcsr, Floating-Point Control and Status Register]]
+.Floating-point control and status register
+include::images/wavedrom/float-csr.edn[]
+
+The `fcsr` register can be read and written with the FRCSR and FSCSR
+instructions, which are assembler pseudoinstructions built on the
+underlying CSR access instructions. FRCSR reads `fcsr` by copying it
+into integer register _rd_. FSCSR swaps the value in `fcsr` by copying
+the original value into integer register _rd_, and then writing a new
+value obtained from integer register _rs1_ into `fcsr`.
+
+The fields within the `fcsr` can also be accessed individually through
+different CSR addresses, and separate assembler pseudoinstructions are defined
+for these accesses. The FRRM instruction reads the Rounding Mode field `frm`
+(`fcsr` bits 7--5) and copies it into the least-significant three bits of
+integer register _rd_, with zero in all other bits. FSRM swaps the value in
+`frm` by copying the original value into integer register _rd_, and then
+writing a new value obtained from the three least-significant bits of integer
+register _rs1_ into `frm`. FRFLAGS and FSFLAGS are defined analogously for the
+Accrued Exception Flags field `fflags` (`fcsr` bits 4--0).
+
+Bits 31--8 of the `fcsr` are reserved for other standard extensions. If
+these extensions are not present, implementations shall ignore writes to
+these bits and supply a zero value when read. Standard software should
+preserve the contents of these bits.
+
+Floating-point operations use either a static rounding mode encoded in
+the instruction, or a dynamic rounding mode held in `frm`. Rounding
+modes are encoded as shown in <<rm>>. A value of 111 in the
+instruction's _rm_ field selects the dynamic rounding mode held in
+`frm`. The behavior of floating-point instructions that depend on
+rounding mode when executed with a reserved rounding mode is _reserved_, including both static reserved rounding modes (101-110) and dynamic reserved rounding modes (101-111). Some instructions, including widening conversions, have the _rm_ field but are nevertheless mathematically unaffected by the rounding mode; software should set their _rm_ field to
+RNE (000) but implementations must treat the _rm_ field as usual (in
+particular, with regard to decoding legal vs. reserved encodings).
+
+[[rm]]
+.Rounding mode encoding.
+[%autowidth,float="center",align="center",cols="^,^,<",options="header"]
+|===
+|Rounding Mode |Mnemonic |Meaning
+|000 |RNE |Round to Nearest, ties to Even
+|001 |RTZ |Round towards Zero
+|010 |RDN |Round Down (towards −{inf})
+|011 |RUP |Round Up (towards +{inf})
+|100 |RMM |Round to Nearest, ties to Max Magnitude
+|101 | |_Reserved for future use._
+|110 | |_Reserved for future use._
+|111 |DYN |In instruction's _rm_ field, selects dynamic rounding mode; In Rounding Mode register, _reserved_.
+|===
+
+[NOTE]
+====
+The C99 language standard effectively mandates the provision of a
+dynamic rounding mode register. In typical implementations, writes to
+the dynamic rounding mode CSR state will serialize the pipeline. Static
+rounding modes are used to implement specialized arithmetic operations
+that often have to switch frequently between different rounding modes.
+
+The ratified version of the F spec mandated that an illegal-instruction
+exception was raised when an instruction was executed with a reserved
+dynamic rounding mode. This has been weakened to reserved, which matches
+the behavior of static rounding-mode instructions. Raising an
+illegal-instruction exception is still valid behavior when encountering a
+reserved encoding, so implementations compatible with the ratified spec
+are compatible with the weakened spec.
+====
+
+The accrued exception flags indicate the exception conditions that have
+arisen on any floating-point arithmetic instruction since the field was
+last reset by software, as shown in <<bitdef>>. The base
+RISC-V ISA does not support generating a trap on the setting of a
+floating-point exception flag.
+(((floating-point, exception flag)))
+
+[[bitdef]]
+.Accrued exception flag encoding.
+[%autowidth,float="center",align="center",cols="^,<",options="header",]
+|===
+|Flag Mnemonic |Flag Meaning
+|NV |Invalid Operation
+|DZ |Divide by Zero
+|OF |Overflow
+|UF |Underflow
+|NX |Inexact
+|===
+
+[NOTE]
+====
+As allowed by the standard, we do not support traps on floating-point
+exceptions in the F extension, but instead require explicit checks of
+the flags in software. We considered adding branches controlled directly
+by the contents of the floating-point accrued exception flags, but
+ultimately chose to omit these instructions to keep the ISA simple.
+====
+
+=== NaN Generation and Propagation
+
+Except when otherwise stated, if the result of a floating-point
+operation is NaN, it is the canonical NaN. The canonical NaN has a
+positive sign and all significand bits clear except the MSB, a.k.a. the
+quiet bit. For single-precision floating-point, this corresponds to the pattern `0x7fc00000`.
+(((NaN, generation)))
+(((NaN, propagation)))
+
+[NOTE]
+====
+We considered propagating NaN payloads, as is recommended by the
+standard, but this decision would have increased hardware cost.
+Moreover, since this feature is optional in the standard, it cannot be
+used in portable code.
+
+Implementers are free to provide a NaN payload propagation scheme as a
+nonstandard extension enabled by a nonstandard operating mode. However, the canonical NaN scheme described above must always be supported and should be the default mode.
+====
+'''
+[NOTE]
+====
+We require implementations to return the standard-mandated default
+values in the case of exceptional conditions, without any further
+intervention on the part of user-level software (unlike the Alpha ISA
+floating-point trap barriers). We believe full hardware handling of
+exceptional cases will become more common, and so wish to avoid
+complicating the user-level ISA to optimize other approaches.
+Implementations can always trap to machine-mode software handlers to
+provide exceptional default values.
+====
+
+=== Subnormal Arithmetic
+
+Operations on subnormal numbers are handled in accordance with the IEEE 754-2008 standard.
+(((operations, subnormal)))
+
+In the parlance of the IEEE standard, tininess is detected after
+rounding.
+(((tininess, handling)))
+
+[NOTE]
+====
+Detecting tininess after rounding results in fewer spurious underflow
+signals.
+====
+
+=== Single-Precision Load and Store Instructions
+
+Floating-point loads and stores use the same base+offset addressing mode as the integer base ISAs, with a base address in register _rs1_ and a 12-bit signed byte offset. The FLW instruction loads a single-precision floating-point value from memory into floating-point register _rd_. FSW stores a single-precision value from floating-point register _rs2_ to memory.
+
+include::images/wavedrom/sp-load-store-2.edn[]
+[[sp-ldst]]
+//.SP load and store
+
+FLW and FSW are only guaranteed to execute atomically if the effective
+address is naturally aligned.
+
+FLW and FSW do not modify the bits being transferred; in particular, the payloads of non-canonical NaNs are preserved.
+
+As described in <<ldst>>, the execution environment defines whether misaligned floating-point loads and stores are handled invisibly or raise a contained or fatal trap.
+
+[[single-float-compute]]
+=== Single-Precision Floating-Point Computational Instructions
+
+Floating-point arithmetic instructions with one or two source operands
+use the R-type format with the OP-FP major opcode. FADD.S and FMUL.S
+perform single-precision floating-point addition and multiplication
+respectively, between _rs1_ and _rs2_. FSUB.S performs the
+single-precision floating-point subtraction of _rs2_ from _rs1_. FDIV.S performs the single-precision floating-point division of _rs1_ by _rs2_. FSQRT.S computes the square root of _rs1_. In each case, the result is written to _rd_.
+
+The 2-bit floating-point format field _fmt_ is encoded as shown in
+<<fmt>>. It is set to _S_ (00) for all instructions in the F extension.
+
+[[fmt]]
+.Format field encoding
+[%autowidth,float="center",align="center",cols="^,^,<",options="header",]
+|===
+|_fmt_ field |Mnemonic |Meaning
+|00 |S |32-bit single-precision
+|01 |D |64-bit double-precision
+|10 |H |16-bit half-precision
+|11 |Q |128-bit quad-precision
+|===
+
+All floating-point operations that perform rounding can select the
+rounding mode using the _rm_ field with the encoding shown in
+<<rm>>.
+
+Floating-point minimum-number and maximum-number instructions FMIN.S and FMAX.S write, respectively, the smaller or larger of _rs1_ and _rs2_ to _rd_. For the purposes of these instructions only, the value
+−0.0 is considered to be less than the value
++0.0. If both inputs are NaNs, the result is the canonical NaN. If only one operand is a NaN, the result is the non-NaN operand.
+Signaling NaN inputs set the invalid operation exception flag, even when the result is not NaN.
+
+[NOTE]
+====
+Note that in version 2.2 of the F extension, the FMIN.S and FMAX.S
+instructions were amended to implement the proposed IEEE 754-201x
+`minimumNumber` and `maximumNumber` operations, rather than the IEEE
+754-2008 minNum and maxNum operations. These operations differ in their
+handling of signaling NaNs.
+====
+
+include::images/wavedrom/spfloat.edn[]
+[[spfloat]]
+//.Single-Precision Floating-Point Computational Instructions
+(((floating point, fused multiply-add)))
+
+Floating-point fused multiply-add instructions require a new standard
+instruction format. R4-type instructions specify three source registers (_rs1_, _rs2_, and _rs3_) and a destination register (_rd_). This format is only used by the floating-point fused multiply-add instructions.
+
+FMADD.S multiplies the values in _rs1_ and _rs2_, adds the value in
+_rs3_, and writes the final result to _rd_. FMADD.S computes
+_(rs1×rs2)+rs3_.
+
+FMSUB.S multiplies the values in _rs1_ and _rs2_, subtracts the value in _rs3_, and writes the final result to _rd_. FMSUB.S computes
+_(rs1×rs2)−rs3_.
+
+FNMSUB.S multiplies the values in _rs1_ and _rs2_, negates the product, adds the value in _rs3_, and writes the final result to _rd_. FNMSUB.S computes _−(rs1×rs2)+rs3_.
+
+FNMADD.S multiplies the values in _rs1_ and _rs2_, negates the product, subtracts the value in _rs3_, and writes the final result to _rd_. FNMADD.S computes _−(rs1×rs2)−rs3_.
+
+[NOTE]
+====
+The FNMSUB and FNMADD instructions are counterintuitively named, owing
+to the naming of the corresponding instructions in MIPS-IV. The MIPS
+instructions were defined to negate the sum, rather than negating the
+product as the RISC-V instructions do, so the naming scheme was more
+rational at the time. The two definitions differ with respect to
+signed-zero results. The RISC-V definition matches the behavior of the
+x86 and ARM fused multiply-add instructions, but unfortunately the
+RISC-V FNMSUB and FNMADD instruction names are swapped as compared to x86,
+whereas the RISC-V FMSUB and FNMSUB instruction names are swapped as
+compared to ARM.
+====
+
+include::images/wavedrom/spfloat2.edn[]
+[[fnmaddsub]]
+//.F[N]MADD/F[N]MSUB instructions
+
+[NOTE]
+====
+The fused multiply-add (FMA) instructions consume a large part of the
+32-bit instruction encoding space. Some alternatives considered were to
+restrict FMA to only use dynamic rounding modes, but static rounding
+modes are useful in code that exploits the lack of product rounding.
+Another alternative would have been to use rd to provide rs3, but this
+would require additional move instructions in some common sequences. The current design still leaves a large portion of the 32-bit encoding space open while avoiding having FMA be non-orthogonal.
+====
+
+The fused multiply-add instructions must set the invalid operation
+exception flag when the multiplicands are {inf} and zero, even when the addend is a quiet NaN.
+
+[NOTE]
+====
+The IEEE 754-2008 standard permits, but does not require, raising the
+invalid exception for the operation {inf}×0 + qNaN.
+====
+
+=== Single-Precision Floating-Point Conversion and Move Instructions
+
+Floating-point-to-integer and integer-to-floating-point conversion
+instructions are encoded in the OP-FP major opcode space. FCVT.W.S or
+FCVT.L.S converts a floating-point number in floating-point register
+_rs1_ to a signed 32-bit or 64-bit integer, respectively, in integer
+register _rd_. FCVT.S.W or FCVT.S.L converts a 32-bit or 64-bit signed
+integer, respectively, in integer register _rs1_ into a floating-point
+number in floating-point register _rd_. FCVT.WU.S, FCVT.LU.S, FCVT.S.WU,
+and FCVT.S.LU variants convert to or from unsigned integer values. For
+XLEN>32, FCVT.W[U].S sign-extends the 32-bit result to the
+destination register width. FCVT.L[U].S and FCVT.S.L[U] are RV64-only
+instructions. If the rounded result is not representable in the
+destination format, it is clipped to the nearest value and the invalid
+flag is set. <<int_conv>> gives the range of valid inputs
+for FCVT._int_.S and the behavior for invalid inputs.
+(((floating-point, conversion)))
+
+All floating-point to integer and integer to floating-point conversion
+instructions round according to the _rm_ field. A floating-point
+register can be initialized to floating-point positive zero using
+FCVT.S.W _rd_, `x0`, which will never set any exception flags.
+
+[[int_conv]]
+.Domains of float-to-integer conversions and behavior for invalid inputs
+[%autowidth,float="center",align="center",cols="<,>,>,>,>",options="header",]
+|===
+| |FCVT.W.S |FCVT.WU.S |FCVT.L.S |FCVT.LU.S
+|Minimum valid input (after rounding) |−2^31^ |0
+|−2^63^ |0
+
+|Maximum valid input (after rounding) |2^31^−1
+|2^32^−1 |2^63^−1 |2^64^−1
+
+|Output for out-of-range negative input |−2^31^ |0
+|−2^63^ |0
+
+|Output for -{inf} |−2^31^ |0
+|−2^63^ |0
+
+|Output for out-of-range positive input |2^31^−1
+|2^32^−1 |2^63^−1 |2^64^−1
+
+|Output for +{inf} or NaN |2^31^−1
+|2^32^−1 |2^63^−1 |2^64^−1
+|===
+
+All floating-point conversion instructions set the Inexact exception
+flag if the rounded result differs from the operand value and the
+Invalid exception flag is not set.
+
+include::images/wavedrom/spfloat-cn-cmp.edn[]
+[[fcvt]]
+//.SP float convert and move
+
+Floating-point to floating-point sign-injection instructions, FSGNJ.S,
+FSGNJN.S, and FSGNJX.S, produce a result that takes all bits except the
+sign bit from _rs1_. For FSGNJ, the result's sign bit is _rs2_'s sign
+bit; for FSGNJN, the result's sign bit is the opposite of _rs2_'s sign
+bit; and for FSGNJX, the sign bit is the XOR of the sign bits of _rs1_
+and _rs2_. Sign-injection instructions do not set floating-point
+exception flags, nor do they canonicalize NaNs. Note, FSGNJ.S _rx, ry,
+ry_ moves _ry_ to _rx_ (assembler pseudoinstruction FMV.S _rx, ry_);
+FSGNJN.S _rx, ry, ry_ moves the negation of _ry_ to _rx_ (assembler
+pseudoinstruction FNEG.S _rx, ry_); and FSGNJX.S _rx, ry, ry_ moves the absolute value of _ry_ to _rx_ (assembler pseudoinstruction FABS.S _rx,
+ry_).
+
+include::images/wavedrom/spfloat-sign-inj.edn[]
+[[inj]]
+
+[NOTE]
+====
+The sign-injection instructions provide floating-point MV, ABS, and NEG, as well as supporting a few other operations, including the IEEE
+`copySign` operation and sign manipulation in transcendental math function libraries. Although MV, ABS, and NEG only need a single register operand, whereas FSGNJ instructions need two, it is unlikely most microarchitectures would add optimizations to benefit from the reduced number of register reads for these relatively infrequent instructions. Even in this case, a microarchitecture can simply detect when both source registers are the same for FSGNJ instructions and only read a single copy.
+====
+
+Instructions are provided to move bit patterns between the
+floating-point and integer registers. FMV.X.W moves the single-precision value in floating-point register _rs1_ represented in IEEE 754-2008 encoding to the lower 32 bits of integer register _rd_. The bits are not modified in the transfer, and in particular, the payloads of non-canonical NaNs are preserved. For RV64, the higher 32 bits of the destination register are filled with copies of the floating-point number's sign bit.
+
+FMV.W.X moves the single-precision value encoded in IEEE 754-2008
+standard encoding from the lower 32 bits of integer register _rs1_ to
+the floating-point register _rd_. The bits are not modified in the
+transfer, and in particular, the payloads of non-canonical NaNs are
+preserved.
+
+[NOTE]
+====
+The FMV.W.X and FMV.X.W instructions were previously called FMV.S.X and FMV.X.S. The use of W is more consistent with their semantics as an instruction that moves 32 bits without interpreting them. This became clearer after defining NaN-boxing. To avoid disturbing existing code, both the W and S versions will be supported by tools.
+====
+
+include::images/wavedrom/spfloat-mv.edn[]
+[[spfloat-mv]]
+//.SP floating point move
+
+[NOTE]
+====
+The base floating-point ISA was defined so as to allow implementations
+to employ an internal recoding of the floating-point format in registers to simplify handling of subnormal values and possibly to reduce functional unit latency. To this end, the F extension avoids
+representing integer values in the floating-point registers by defining conversion and comparison operations that read and write the integer register file directly. This also removes many of the common cases where explicit moves between integer and floating-point registers are required, reducing instruction count and critical paths for common mixed-format code sequences.
+====
+
+=== Single-Precision Floating-Point Compare Instructions
+
+Floating-point compare instructions (FEQ.S, FLT.S, FLE.S) perform the
+specified comparison between floating-point registers
+(_rs1_ = _rs2_, _rs1_ < _rs2_,
+_rs1_ {le} _rs2_) writing 1 to the integer register _rd_ if the
+condition holds, and 0 otherwise.
+
+FLT.S and FLE.S perform what the IEEE 754-2008 standard refers to as
+_signaling_ comparisons: that is, they set the invalid operation
+exception flag if either input is NaN. FEQ.S performs a _quiet_
+comparison: it only sets the invalid operation exception flag if either input is a signaling NaN. For all three instructions, the result is 0 if either operand is NaN.
+
+include::images/wavedrom/spfloat-comp.edn[]
+[[spfloat-comp]]
+//.SP floating point compare
+
+[NOTE]
+====
+The F extension provides a {le} comparison, whereas the
+base ISAs provide a {ge} branch comparison. Because
+{le} can be synthesized from {ge} and
+vice-versa, there is no performance implication to this inconsistency,
+but it is nevertheless an unfortunate incongruity in the ISA.
+====
+
+=== Single-Precision Floating-Point Classify Instruction
+
+The FCLASS.S instruction examines the value in floating-point register
+_rs1_ and writes to integer register _rd_ a 10-bit mask that indicates
+the class of the floating-point number. The format of the mask is
+described in <<fclass>>. The corresponding bit in _rd_ will
+be set if the property is true and clear otherwise. All other bits in
+_rd_ are cleared. Note that exactly one bit in _rd_ will be set.
+FCLASS.S does not set the floating-point exception flags.
+(((floating-point, classification)))
+
+include::images/wavedrom/spfloat-classify.edn[]
+[[spfloat-classify]]
+//.SP floating point classify
+
+[[fclass]]
+.Format of result of FCLASS instruction.
+[%autowidth,float="center",align="center",cols="^,<",options="header",]
+|===
+|_rd_ bit |Meaning
+|0 |_rs1_ is −{inf}.
+|1 |_rs1_ is a negative normal number.
+|2 |_rs1_ is a negative subnormal number.
+|3 |_rs1_ is −0.
+|4 |_rs1_ is +0.
+|5 |_rs1_ is a positive subnormal number.
+|6 |_rs1_ is a positive normal number.
+|7 |_rs1_ is +{inf}.
+|8 |_rs1_ is a signaling NaN.
+|9 |_rs1_ is a quiet NaN.
+|===
diff --git a/src/f.tex b/src/f.tex
deleted file mode 100644
index c1854f0..0000000
--- a/src/f.tex
+++ /dev/null
@@ -1,801 +0,0 @@
-\chapter{``F'' Standard Extension for Single-Precision Floating-Point,
-Version 2.2}
-\label{sec:single-float}
-
-This chapter describes the standard instruction-set extension for
-single-precision floating-point, which is named ``F'' and adds
-single-precision floating-point computational instructions compliant
-with the IEEE 754-2008 arithmetic standard~\cite{ieee754-2008}.
-
-
-\section{F Register State}
-
-The F extension adds 32 floating-point registers, {\tt f0}--{\tt f31},
-each 32 bits wide, and a floating-point control and status register
-{\tt fcsr}, which contains the operating mode and exception status of the
-floating-point unit. This additional state is shown in
-Figure~\ref{fprs}. We use the term FLEN to describe the width of the
-floating-point registers in the RISC-V ISA, and FLEN=32 for the F
-single-precision floating-point extension. Most floating-point
-instructions operate on values in the floating-point register file.
-Floating-point load and store instructions transfer floating-point
-values between registers and memory. Instructions to transfer values
-to and from the integer register file are also provided.
-
-\begin{figure}[htbp]
-{\footnotesize
-\begin{center}
-\begin{tabular}{p{2in}}
-\instbitrange{FLEN-1}{0} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f0\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f1\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f2\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f3\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f4\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f5\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f6\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f7\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f8\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f9\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f10\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f11\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f12\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f13\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f14\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f15\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f16\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f17\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f18\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f19\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f20\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f21\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f22\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f23\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f24\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f25\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f26\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f27\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f28\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f29\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f30\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ f31\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{c}{FLEN} \\
-
-\instbitrange{31}{0} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{fcsr}} \\ \cline{1-1}
-\multicolumn{1}{c}{32} \\
-\end{tabular}
-\end{center}
-}
-\caption{RISC-V standard F extension single-precision floating-point state.}
-\label{fprs}
-\end{figure}
-
-\begin{commentary}
-We considered a unified register file for both integer and
-floating-point values as this simplifies software register allocation
-and calling conventions, and reduces total user state. However, a
-split organization increases the total number of registers accessible
-with a given instruction width, simplifies provision of enough regfile
-ports for wide superscalar issue, supports decoupled
-floating-point-unit architectures, and simplifies use of internal
-floating-point encoding techniques. Compiler support and calling
-conventions for split register file architectures are well understood,
-and using dirty bits on floating-point register file state can reduce
-context-switch overhead.
-\end{commentary}
-
-\clearpage
-
-\section{Floating-Point Control and Status Register}
-
-The floating-point control and status register, {\tt fcsr}, is a RISC-V
-control and status register (CSR). It is a 32-bit read/write register that
-selects the dynamic rounding mode for floating-point arithmetic operations and
-holds the accrued exception flags, as shown in Figure~\ref{fcsr}.
-
-\begin{figure*}
-{\footnotesize
-\begin{center}
-\begin{tabular}{K@{}E@{}ccccc}
-\instbitrange{31}{8} &
-\instbitrange{7}{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{{\em Reserved}} &
-\multicolumn{1}{c|}{Rounding Mode ({\tt frm})} &
-\multicolumn{5}{c|}{Accrued Exceptions ({\tt fflags})} \\
-\hline
-\multicolumn{1}{c}{} &
-\multicolumn{1}{c|}{} &
-\multicolumn{1}{c|}{NV} &
-\multicolumn{1}{c|}{DZ} &
-\multicolumn{1}{c|}{OF} &
-\multicolumn{1}{c|}{UF} &
-\multicolumn{1}{c|}{NX} \\
-\cline{3-7}
-24 & 3 & 1 & 1 & 1 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Floating-point control and status register.}
-\label{fcsr}
-\end{figure*}
-
-The {\tt fcsr} register can be read and written with the FRCSR and
-FSCSR instructions, which are assembler pseudoinstructions built on the
-underlying CSR access instructions. FRCSR reads {\tt fcsr} by copying
-it into integer register {\em rd}. FSCSR swaps the value in {\tt
- fcsr} by copying the original value into integer register {\em rd},
-and then writing a new value obtained from integer register {\em rs1}
-into {\tt fcsr}.
-
-The fields within the {\tt fcsr} can also be accessed individually
-through different CSR addresses, and separate assembler pseudoinstructions are
-defined for these accesses. The FRRM instruction reads the Rounding
-Mode field {\tt frm} and copies it into the least-significant three
-bits of integer register {\em rd}, with zero in all other bits. FSRM
-swaps the value in {\tt frm} by copying the original value into
-integer register {\em rd}, and then writing a new value obtained from
-the three least-significant bits of integer register {\em rs1} into
-{\tt frm}. FRFLAGS and FSFLAGS are defined analogously for the
-Accrued Exception Flags field {\tt fflags}.
-
-Bits 31--8 of the {\tt fcsr} are reserved for other standard extensions,
-including the ``L'' standard extension for decimal floating-point. If
-these extensions are not present, implementations shall ignore writes to
-these bits and supply a zero value when read. Standard software should
-preserve the contents of these bits.
-
-Floating-point operations use either a static rounding mode encoded in the
-instruction, or a dynamic rounding mode held in {\tt frm}. Rounding modes are
-encoded as shown in Table~\ref{rm}. A value of 111 in the instruction's {\em
-rm} field selects the dynamic rounding mode held in {\tt frm}. If {\tt frm}
-is set to an invalid value (101--111), any subsequent attempt to execute
-a floating-point operation with a dynamic rounding mode will raise an illegal
-instruction exception. Some instructions, including widening conversions,
-have the {\em rm} field but are nevertheless unaffected by the rounding mode;
-software should set their {\em rm} field to RNE (000).
-
-\begin{commentary}
-The C99 language standard effectively mandates the provision of a
-dynamic rounding mode register. In typical implementations, writes to
-the dynamic rounding mode CSR state will serialize the pipeline.
-
-Static rounding modes are used to implement specialized arithmetic
-operations that often have to switch frequently between different
-rounding modes.
-\end{commentary}
-\newpage
-
-\begin{table}[htp]
-\begin{small}
-\begin{center}
-\begin{tabular}{ccl}
-\hline
-\multicolumn{1}{|c|}{Rounding Mode} &
-\multicolumn{1}{c|}{Mnemonic} &
-\multicolumn{1}{c|}{Meaning} \\
-\hline
-\multicolumn{1}{|c|}{000} &
-\multicolumn{1}{l|}{RNE} &
-\multicolumn{1}{l|}{Round to Nearest, ties to Even}\\
-\hline
-\multicolumn{1}{|c|}{001} &
-\multicolumn{1}{l|}{RTZ} &
-\multicolumn{1}{l|}{Round towards Zero}\\
-\hline
-\multicolumn{1}{|c|}{010} &
-\multicolumn{1}{l|}{RDN} &
-\multicolumn{1}{l|}{Round Down (towards $-\infty$)}\\
-\hline
-\multicolumn{1}{|c|}{011} &
-\multicolumn{1}{l|}{RUP} &
-\multicolumn{1}{l|}{Round Up (towards $+\infty$)}\\
-\hline
-\multicolumn{1}{|c|}{100} &
-\multicolumn{1}{l|}{RMM} &
-\multicolumn{1}{l|}{Round to Nearest, ties to Max Magnitude}\\
-\hline
-\multicolumn{1}{|c|}{101} &
-\multicolumn{1}{l|}{} &
-\multicolumn{1}{l|}{\em Invalid. Reserved for future use.}\\
-\hline
-\multicolumn{1}{|c|}{110} &
-\multicolumn{1}{l|}{} &
-\multicolumn{1}{l|}{\em Invalid. Reserved for future use.}\\
-\hline
-\multicolumn{1}{|c|}{111} &
-\multicolumn{1}{l|}{DYN} &
-\multicolumn{1}{l|}{In instruction's {\em rm} field, selects dynamic rounding mode;}\\
-\multicolumn{1}{|c|}{} &
-\multicolumn{1}{l|}{} &
-\multicolumn{1}{l|}{In Rounding Mode register, {\em Invalid}.}\\
-\hline
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Rounding mode encoding.}
-\label{rm}
-\end{table}
-
-The accrued exception flags indicate the exception conditions that
-have arisen on any floating-point arithmetic instruction since the
-field was last reset by software, as shown in Table~\ref{bitdef}.
-
-\begin{table}[htp]
-\begin{small}
-\begin{center}
-\begin{tabular}{cl}
-\hline
-\multicolumn{1}{|c|}{Flag Mnemonic} &
-\multicolumn{1}{c|}{Flag Meaning} \\
-\hline
-\multicolumn{1}{|c|}{NV} &
-\multicolumn{1}{c|}{Invalid Operation}\\
-\hline
-\multicolumn{1}{|c|}{DZ} &
-\multicolumn{1}{c|}{Divide by Zero}\\
-\hline
-\multicolumn{1}{|c|}{OF} &
-\multicolumn{1}{c|}{Overflow}\\
-\hline
-\multicolumn{1}{|c|}{UF} &
-\multicolumn{1}{c|}{Underflow}\\
-\hline
-\multicolumn{1}{|c|}{NX} &
-\multicolumn{1}{c|}{Inexact}\\
-\hline
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Accrued exception flag encoding.}
-\label{bitdef}
-\end{table}
-
-\begin{commentary}
-As allowed by the standard, we do not support traps on floating-point
-exceptions in the base ISA, but instead require explicit checks of the flags
-in software. We considered adding branches controlled directly by the
-contents of the floating-point accrued exception flags, but ultimately chose
-to omit these instructions to keep the ISA simple.
-\end{commentary}
-
-\section{NaN Generation and Propagation}
-
-Except when otherwise stated, if the result of a floating-point operation is
-NaN, it is the canonical NaN. The canonical NaN has a positive sign and all
-significand bits clear except the MSB, a.k.a. the quiet bit. For
-single-precision floating-point, this corresponds to the pattern {\tt
-0x7fc00000}.
-
-\begin{commentary}
-We considered propagating NaN payloads, as is recommended by the standard,
-but this decision would have increased hardware cost. Moreover, since this
-feature is optional in the standard, it cannot be used in portable code.
-
-Implementors are free to provide a NaN payload propagation scheme as
-a nonstandard extension enabled by a nonstandard operating mode. However, the
-canonical NaN scheme described above must always be supported and should be
-the default mode.
-\end{commentary}
-
-\begin{commentary}
-We require implementations to return the standard-mandated default
-values in the case of exceptional conditions, without any further
-intervention on the part of user-level software (unlike the Alpha ISA
-floating-point trap barriers). We believe full hardware handling of
-exceptional cases will become more common, and so wish to avoid
-complicating the user-level ISA to optimize other approaches.
-Implementations can always trap to machine-mode software handlers to
-provide exceptional default values.
-\end{commentary}
-
-\section{Subnormal Arithmetic}
-
-Operations on subnormal numbers are handled in accordance with the IEEE
-754-2008 standard.
-
-In the parlance of the IEEE standard, tininess is detected after rounding.
-
-\begin{commentary}
-Detecting tininess after rounding results in fewer spurious underflow signals.
-\end{commentary}
-
-\section{Single-Precision Load and Store Instructions}
-
-Floating-point loads and stores use the same base+offset addressing
-mode as the integer base ISA, with a base address in register {\em
- rs1} and a 12-bit signed byte offset. The FLW instruction loads a
-single-precision floating-point value from memory into floating-point
-register {\em rd}. FSW stores a single-precision value from
-floating-point register {\em rs2} to memory.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{width} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-offset[11:0] & base & W & dest & LOAD-FP \\
-\end{tabular}
-\end{center}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{O@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:5]} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{width} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-offset[11:5] & src & base & W & offset[4:0] & STORE-FP \\
-\end{tabular}
-\end{center}
-
-FLW and FSW are only guaranteed to execute atomically if the effective address
-is naturally aligned.
-
-FLW and FSW do not modify the bits being transferred; in particular, the
-payloads of non-canonical NaNs are preserved.
-
-\section{Single-Precision Floating-Point Computational Instructions}
-\label{sec:single-float-compute}
-
-Floating-point arithmetic instructions with one or two source operands use the
-R-type format with the OP-FP major opcode. FADD.S and FMUL.S perform
-single-precision floating-point addition and multiplication respectively,
-between {\em rs1} and {\em rs2}. FSUB.S performs the single-precision
-floating-point subtraction of {\em rs2} from {\em rs1}. FDIV.S performs the
-single-precision floating-point division of {\em rs1} by {\em rs2}. FSQRT.S
-computes the square root of {\em rs1}. In each case, the result is written to
-{\em rd}.
-
-The 2-bit floating-point format field {\em fmt} is encoded as shown in
-Table~\ref{tab:fmt}. It is set to {\em S} (00) for all instructions in
-the F extension.
-
-\begin{table}[htp]
-\begin{small}
-\begin{center}
-\begin{tabular}{|c|c|l|}
-\hline
-{\em fmt} field &
-Mnemonic &
-Meaning \\
-\hline
-00 & S & 32-bit single-precision \\
-01 & D & 64-bit double-precision \\
-10 & H & 16-bit half-precision \\
-11 & Q & 128-bit quad-precision \\
-\hline
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Format field encoding.}
-\label{tab:fmt}
-\end{table}
-
-All floating-point operations that perform rounding can select the
-rounding mode using the {\em rm} field with the encoding shown in
-Table~\ref{rm}.
-
-Floating-point minimum-number and maximum-number instructions FMIN.S and
-FMAX.S write, respectively, the smaller or larger of {\em rs1} and {\em rs2}
-to {\em rd}. For the purposes of these instructions only, the value $-0.0$ is
-considered to be less than the value $+0.0$. If both inputs are NaNs, the
-result is the canonical NaN. If only one operand is a NaN, the result is the
-non-NaN operand. Signaling NaN inputs raise the invalid operation exception,
-even when the result is not NaN.
-
-\begin{commentary}
-Note that in version 2.2 of the F extension, the FMIN.S and FMAX.S
-instructions were amended to implement the proposed IEEE 754-201x
-minimumNumber and maximumNumber operations, rather than the IEEE 754-2008
-minNum and maxNum operations. These operations differ in their handling of
-signaling NaNs.
-\end{commentary}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FADD/FSUB & S & src2 & src1 & RM & dest & OP-FP \\
-FMUL/FDIV & S & src2 & src1 & RM & dest & OP-FP \\
-FSQRT & S & 0 & src & RM & dest & OP-FP \\
-FMIN-MAX & S & src2 & src1 & MIN/MAX & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-Floating-point fused multiply-add instructions require a new standard
-instruction format. R4-type instructions specify three source
-registers ({\em rs1}, {\em rs2}, and {\em rs3}) and a destination
-register ({\em rd}). This format is only used by the floating-point
-fused multiply-add instructions. FMADD.S multiplies the values in {\em
-rs1} and {\em rs2}, adds the value in {\em rs3}, and writes the final
-result to {\em rd}. FMADD.S computes {\em (rs1$\times$rs2)+rs3}.
-FMSUB.S multiplies the values in {\em rs1} and {\em rs2}, subtracts
-the value in {\em rs3}, and writes the final result to {\em rd}.
-FMSUB.S computes {\em (rs1$\times$rs2)-rs3}. FNMSUB.S multiplies the
-values in {\em rs1} and {\em rs2}, negates the product, adds the value
-in {\em rs3}, and writes the final result to {\em rd}. FNMSUB.S
-computes {\em -(rs1$\times$rs2)+rs3}. FNMADD.S multiplies the values
-in {\em rs1} and {\em rs2}, negates the product, subtracts the value
-in {\em rs3}, and writes the final result to {\em rd}. FNMADD.S
-computes {\em -(rs1$\times$rs2)-rs3}.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{rs3} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-src3 & S & src2 & src1 & RM & dest & F[N]MADD/F[N]MSUB \\
-\end{tabular}
-\end{center}
-
-\begin{commentary}
- The fused multiply-add (FMA) instructions consume a large part of the
- 32-bit instruction encoding space. Some alternatives considered were
- to restrict FMA to only use dynamic rounding modes, but static
- rounding modes are useful in code that exploits the lack of product
- rounding. Another alternative would have been to use rd to provide
- rs3, but this would require additional move instructions in some
- common sequences. The current design still leaves a large portion of
- the 32-bit encoding space open while avoiding having FMA be
- non-orthogonal.
-\end{commentary}
-
-The fused multiply-add instructions must raise the invalid operation exception
-when the multiplicands are $\infty$ and zero, even when the addend is a quiet
-NaN.
-\begin{commentary}
-The IEEE 754-2008 standard permits, but does not require, raising the
-invalid exception for the operation \mbox{$\infty\times 0\ +$ qNaN}.
-\end{commentary}
-
-\section{Single-Precision Floating-Point Conversion and Move \mbox{Instructions}}
-
-Floating-point-to-integer and integer-to-floating-point conversion
-instructions are encoded in the OP-FP major opcode space.
-FCVT.W.S or FCVT.L.S converts a floating-point number
-in floating-point register {\em rs1} to a signed 32-bit or 64-bit
-integer, respectively, in integer register {\em rd}. FCVT.S.W
-or FCVT.S.L converts a 32-bit or 64-bit signed integer,
-respectively, in integer register {\em rs1} into a floating-point
-number in floating-point register {\em rd}. FCVT.WU.S,
-FCVT.LU.S, FCVT.S.WU, and FCVT.S.LU variants
-convert to or from unsigned integer values.
-For XLEN$>32$, FCVT.W[U].S sign-extends the 32-bit result to the
-destination register width.
-FCVT.L[U].S and FCVT.S.L[U] are RV64-only instructions.
-If the rounded result is not representable in the destination format,
-it is clipped to the nearest value and the invalid flag is set.
-Table~\ref{tab:int_conv} gives the range of valid inputs for FCVT.{\em int}.S
-and the behavior for invalid inputs.
-
-\begin{table}[htp]
-\begin{small}
-\begin{center}
-\begin{tabular}{|l|r|r|r|r|}
-\hline
- & FCVT.W.S & FCVT.WU.S & FCVT.L.S & FCVT.LU.S \\
-\hline
-Minimum valid input (after rounding) & $-2^{31}$ & 0 & $-2^{63}$ & 0 \\
-Maximum valid input (after rounding) & $2^{31}-1$ & $2^{32}-1$ & $2^{63}-1$ & $2^{64}-1$ \\
-\hline
-Output for out-of-range negative input & $-2^{31}$ & 0 & $-2^{63}$ & 0 \\
-Output for $-\infty$ & $-2^{31}$ & 0 & $-2^{63}$ & 0 \\
-Output for out-of-range positive input & $2^{31}-1$ & $2^{32}-1$ & $2^{63}-1$ & $2^{64}-1$ \\
-Output for $+\infty$ or NaN & $2^{31}-1$ & $2^{32}-1$ & $2^{63}-1$ & $2^{64}-1$ \\
-\hline
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Domains of float-to-integer conversions and behavior for invalid inputs.}
-\label{tab:int_conv}
-\end{table}
-
-All floating-point to integer and integer to floating-point conversion
-instructions round according to the {\em rm} field. A floating-point register
-can be initialized to floating-point positive zero using FCVT.S.W {\em rd},
-{\tt x0}, which will never raise any exceptions.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCVT.{\em int}.{\em fmt} & S & W[U]/L[U] & src & RM & dest & OP-FP \\
-FCVT.{\em fmt}.{\em int} & S & W[U]/L[U] & src & RM & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-Floating-point to floating-point sign-injection instructions, FSGNJ.S,
-FSGNJN.S, and FSGNJX.S, produce a result that takes all bits except
-the sign bit from {\em rs1}. For FSGNJ, the result's sign bit is {\em
- rs2}'s sign bit; for FSGNJN, the result's sign bit is the opposite
-of {\em rs2}'s sign bit; and for FSGNJX, the sign bit is the XOR of
-the sign bits of {\em rs1} and {\em rs2}. Sign-injection instructions
-do not set floating-point exception flags, nor do they canonicalize
-NaNs. Note, FSGNJ.S {\em rx, ry,
- ry} moves {\em ry} to {\em rx} (assembler pseudoinstruction FMV.S {\em rx,
- ry}); FSGNJN.S {\em rx, ry, ry} moves the negation of {\em ry} to
-{\em rx} (assembler pseudoinstruction FNEG.S {\em rx, ry}); and FSGNJX.S {\em rx,
- ry, ry} moves the absolute value of {\em ry} to {\em rx} (assembler
-pseudoinstruction FABS.S {\em rx, ry}).
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FSGNJ & S & src2 & src1 & J[N]/JX & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-\begin{commentary}
-The sign-injection instructions
-provide floating-point MV, ABS, and NEG,
-as well as supporting a few other operations, including the IEEE copySign
-operation and sign manipulation in transcendental math function
-libraries. Although MV, ABS, and NEG only need a single register
-operand, whereas FSGNJ instructions need two, it is unlikely most
-microarchitectures would add optimizations to benefit from the reduced
-number of register reads for these relatively infrequent instructions.
-Even in this case, a microarchitecture can simply detect when both
-source registers are the same for FSGNJ instructions and only read a
-single copy.
-\end{commentary}
-
-Instructions are provided to move bit patterns between the
-floating-point and integer registers. FMV.X.W moves the
-single-precision value in floating-point register {\em rs1}
-represented in IEEE 754-2008 encoding to the lower 32 bits of integer
-register {\em rd}. For RV64, the higher 32 bits of the destination
-register are filled with copies of the floating-point number's sign
-bit.
-
-FMV.W.X moves the single-precision value encoded in IEEE
-754-2008 standard encoding from the lower 32 bits of integer register
-{\em rs1} to the floating-point register {\em rd}. The bits are not
-modified in the transfer, and in particular, the payloads of
-non-canonical NaNs are preserved.
-
-\begin{commentary}
-The FMV.W.X and FMV.X.W instructions were previously called FMV.S.X
-and FMV.X.S. The use of W is more consistent with their semantics as
-an instruction that moves 32 bits without interpreting them. This
-became clearer after defining NaN-boxing. To avoid disturbing
-existing code, both the W and S versions will be supported by tools.
-\end{commentary}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FMV.X.W & S & 0 & src & 000 & dest & OP-FP \\
-FMV.W.X & S & 0 & src & 000 & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-\begin{commentary}
-The base floating-point ISA was defined so as to allow implementations
-to employ an internal recoding of the floating-point format in
-registers to simplify handling of subnormal values and possibly to
-reduce functional unit latency. To this end, the base ISA avoids
-representing integer values in the floating-point registers by
-defining conversion and comparison operations that read and write the
-integer register file directly. This also removes many of the common
-cases where explicit moves between integer and floating-point
-registers are required, reducing instruction count and critical paths
-for common mixed-format code sequences.
-\end{commentary}
-
-\section{Single-Precision Floating-Point Compare Instructions}
-
-Floating-point compare instructions (FEQ.S, FLT.S, FLE.S) perform the
-specified comparison between floating-point registers ($\mbox{\em rs1}
-= \mbox{\em rs2}$, $\mbox{\em rs1} < \mbox{\em rs2}$, $\mbox{\em rs1} \leq
-\mbox{\em rs2}$) writing 1 to the integer register {\em rd} if the condition
-holds, and 0 otherwise.
-
-FLT.S and FLE.S perform what the IEEE 754-2008 standard refers to as {\em
-signaling} comparisons: that is, an Invalid Operation exception is raised if
-either input is NaN. FEQ.S performs a {\em quiet} comparison: only signaling
-NaN inputs cause an Invalid Operation exception. For all three instructions,
-the result is 0 if either operand is NaN.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCMP & S & src2 & src1 & EQ/LT/LE & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-\section{Single-Precision Floating-Point Classify Instruction}
-
-The FCLASS.S instruction examines the value in floating-point register {\em
-rs1} and writes to integer register {\em rd} a 10-bit mask that indicates
-the class of the floating-point number. The format of the mask is
-described in Table~\ref{tab:fclass}. The corresponding bit in {\em rd} will
-be set if the property is true and clear otherwise. All other bits in
-{\em rd} are cleared. Note that exactly one bit in {\em rd} will be set.
-FCLASS.S does not set the floating-point exception flags.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCLASS & S & 0 & src & 001 & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-\begin{table}[htp]
-\begin{small}
-\begin{center}
-\begin{tabular}{|c|l|}
-\hline
-{\em rd} bit &
-Meaning \\
-\hline
-0 & {\em rs1} is $-\infty$. \\
-1 & {\em rs1} is a negative normal number. \\
-2 & {\em rs1} is a negative subnormal number. \\
-3 & {\em rs1} is $-0$. \\
-4 & {\em rs1} is $+0$. \\
-5 & {\em rs1} is a positive subnormal number. \\
-6 & {\em rs1} is a positive normal number. \\
-7 & {\em rs1} is $+\infty$. \\
-8 & {\em rs1} is a signaling NaN. \\
-9 & {\em rs1} is a quiet NaN. \\
-\hline
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Format of result of FCLASS instruction.}
-\label{tab:fclass}
-\end{table}
diff --git a/src/figs/PLIC-block-diagram.pdf b/src/figs/PLIC-block-diagram.pdf
deleted file mode 100644
index c6ece1a..0000000
--- a/src/figs/PLIC-block-diagram.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/PLIC-interrupt-flow.pdf b/src/figs/PLIC-interrupt-flow.pdf
deleted file mode 100644
index 7ba4117..0000000
--- a/src/figs/PLIC-interrupt-flow.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/halimps.pdf b/src/figs/halimps.pdf
deleted file mode 100644
index 2cc5a58..0000000
--- a/src/figs/halimps.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/halmode.pdf b/src/figs/halmode.pdf
deleted file mode 100644
index afa441b..0000000
--- a/src/figs/halmode.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_addrpo.pdf b/src/figs/litmus_addrpo.pdf
deleted file mode 100644
index ad15fb3..0000000
--- a/src/figs/litmus_addrpo.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_addrpo.pdf_t b/src/figs/litmus_addrpo.pdf_t
deleted file mode 100644
index 2dcc621..0000000
--- a/src/figs/litmus_addrpo.pdf_t
+++ /dev/null
@@ -1,49 +0,0 @@
-\begin{picture}(0,0)%
-\includegraphics{figs/litmus_addrpo.pdf}%
-\end{picture}%
-%
-% Generated by graphviz version 2.36.0 (20140111.2315)
-% Title: G
-% Pages: 1
-%
-\setlength{\unitlength}{3947sp}%
-%
-\begingroup\makeatletter\ifx\SetFigFont\undefined%
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{#1}{#2pt}%
- \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \selectfont}%
-\fi\endgroup%
-\begin{picture}(3628,1984)(-14,-1133)
-% eiid0
-\put(821,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}a: Ry=1}%
-}}}}
-% eiid1
-\put(821,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}c: Wx=t}%
-}}}}
-% eiid2
-\put(2981,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}d: Rx=t}%
-}}}}
-% eiid3
-\put(2981,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}e: Rt=$v$}%
-}}}}
-% eiid4
-\put(2981,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}f: Wy=1}%
-}}}}
-\put( 1, 240){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.000,0.392,0.000}fence}%
-}}}}
-\put(461, 240){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1742,284){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(2561, 250){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}addr}%
-}}}}
-\put(3011, 250){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(3185,-400){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(2731,-529){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}po}%
-}}}}
-\put(1743,20){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\end{picture}%
diff --git a/src/figs/litmus_datacoirfi.pdf b/src/figs/litmus_datacoirfi.pdf
deleted file mode 100644
index 6497bc0..0000000
--- a/src/figs/litmus_datacoirfi.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_datacoirfi.pdf_t b/src/figs/litmus_datacoirfi.pdf_t
deleted file mode 100644
index 24655ea..0000000
--- a/src/figs/litmus_datacoirfi.pdf_t
+++ /dev/null
@@ -1,61 +0,0 @@
-\begin{picture}(0,0)%
-\includegraphics{figs/litmus_datacoirfi.pdf}%
-\end{picture}%
-%
-% Generated by graphviz version 2.36.0 (20140111.2315)
-% Title: G
-% Pages: 1
-%
-\setlength{\unitlength}{3947sp}%
-%
-\begingroup\makeatletter\ifx\SetFigFont\undefined%
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{#1}{#2pt}%
- \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \selectfont}%
-\fi\endgroup%
-\begin{picture}(3447,3604)(-14,-2753)
-% eiid0
-\put(821,-616){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}a: Wx=1}%
-}}}}
-% eiid1
-\put(821,-1426){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}c: Wy=1}%
-}}}}
-% eiid2
-\put(2981,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}d: Ry=1}%
-}}}}
-% eiid3
-\put(2981,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}e: Wz=1}%
-}}}}
-% eiid4
-\put(2981,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}f: Wz=1}%
-}}}}
-% eiid5
-\put(2981,-1831){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}g: Rz=1}%
-}}}}
-% eiid6
-\put(2981,-2641){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}h: Rx=0}%
-}}}}
-\put( 1,-990){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.000,0.392,0.000}fence}%
-}}}}
-\put(460,-990){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1739,-325){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(2601,225){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}data}%
-}}}}
-\put(3031,225){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(2741,-485){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,1}co}%
-}}}}
-\put(3031,-485){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(2821,-1339){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(2561,-2105){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}addr}%
-}}}}
-\put(3031,-2105){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1743,-1340){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\end{picture}%
diff --git a/src/figs/litmus_datarfi.pdf b/src/figs/litmus_datarfi.pdf
deleted file mode 100644
index 5cb25c3..0000000
--- a/src/figs/litmus_datarfi.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_datarfi.pdf_t b/src/figs/litmus_datarfi.pdf_t
deleted file mode 100644
index 7120e66..0000000
--- a/src/figs/litmus_datarfi.pdf_t
+++ /dev/null
@@ -1,56 +0,0 @@
-\begin{picture}(0,0)%
-\includegraphics{figs/litmus_datarfi.pdf}%
-\end{picture}%
-%
-% Generated by graphviz version 2.36.0 (20140111.2315)
-% Title: G
-% Pages: 1
-%
-\setlength{\unitlength}{3947sp}%
-%
-\begingroup\makeatletter\ifx\SetFigFont\undefined%
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{#1}{#2pt}%
- \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \selectfont}%
-\fi\endgroup%
-\begin{picture}(3886,2794)(-14,-1943)
-% eiid0
-\put(821,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}a: Wx=1}%
-}}}}
-% eiid1
-\put(821,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}c: Wy=1}%
-}}}}
-% eiid2
-\put(2981,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}d: Ry=1}%
-}}}}
-% eiid3
-\put(2981,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}e: Wz=1}%
-}}}}
-% eiid4
-\put(2981,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}f: Rz=1}%
-}}}}
-% eiid5
-\put(2981,-1831){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}g: Rx=0}%
-}}}}
-\put( 1,-575){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.000,0.392,0.000}fence}%
-}}}}
-\put(460,-575){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1739,-122){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(2581,250){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}data}%
-}}}}
-\put(3011,250){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(3540,-121){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(2821,-769){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(2561,-1295){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}addr}%
-}}}}
-\put(3031 ,-1295){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(2043,-732){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\end{picture}%
diff --git a/src/figs/litmus_lb_lrsc.pdf b/src/figs/litmus_lb_lrsc.pdf
deleted file mode 100644
index 3aeafed..0000000
--- a/src/figs/litmus_lb_lrsc.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_lb_lrsc.pdf_t b/src/figs/litmus_lb_lrsc.pdf_t
deleted file mode 100644
index 2cb417e..0000000
--- a/src/figs/litmus_lb_lrsc.pdf_t
+++ /dev/null
@@ -1,50 +0,0 @@
-\begin{picture}(0,0)%
-\includegraphics{figs/litmus_lb_lrsc.pdf}%
-\end{picture}%
-%
-% Generated by graphviz version 2.38.0 (20140413.2041)
-% Title: G
-% Pages: 1
-%
-\setlength{\unitlength}{3947sp}%
-%
-\begingroup\makeatletter\ifx\SetFigFont\undefined%
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{#1}{#2pt}%
- \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \selectfont}%
-\fi\endgroup%
-\begin{picture}(3104,2794)(-11,-1943)
-% eiid0
-\put(481,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}a: Rx=0}%
-}}}}
-% eiid1
-\put(481,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}b: Rz*=0}%
-}}}}
-% eiid2
-\put(481,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}c: Wz*=0}%
-}}}}
-% eiid3
-\put(481,-1831){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}d: Wy=0}%
-}}}}
-% eiid4
-\put(2641,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}e: Ry=0}%
-}}}}
-% eiid5
-\put(2641,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}f: Wx=0}%
-}}}}
-\put(261,281){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}po}%
-}}}}
-\put(646,40){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}data ppo}%
-}}}}
-\put(85,-529){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510} ppo}%
-}}}}
-\put(85,-1339){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}data ppo}%
-}}}}
-\put(1418,-538){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(2680,281){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}data\,ppo}%
-}}}}
-\put(1400,350){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\end{picture}%
diff --git a/src/figs/litmus_mp_fenceww_fri_rfi_addr.pdf b/src/figs/litmus_mp_fenceww_fri_rfi_addr.pdf
deleted file mode 100644
index 37c676d..0000000
--- a/src/figs/litmus_mp_fenceww_fri_rfi_addr.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_mp_fenceww_fri_rfi_addr.pdf_t b/src/figs/litmus_mp_fenceww_fri_rfi_addr.pdf_t
deleted file mode 100644
index 6df2213..0000000
--- a/src/figs/litmus_mp_fenceww_fri_rfi_addr.pdf_t
+++ /dev/null
@@ -1,56 +0,0 @@
-\begin{picture}(0,0)%
-\includegraphics{figs/litmus_mp_fenceww_fri_rfi_addr.pdf}%
-\end{picture}%
-%
-% Generated by graphviz version 2.38.0 (20140413.2041)
-% Title: G
-% Pages: 1
-%
-\setlength{\unitlength}{3947sp}%
-%
-\begingroup\makeatletter\ifx\SetFigFont\undefined%
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{#1}{#2pt}%
- \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \selectfont}%
-\fi\endgroup%
-\begin{picture}(3727,2632)(-14,-1781)
-% eiid0
-\put(821,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}a: Wx=1}%
-}}}}
-% eiid1
-\put(821,-157){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}c: Wy=1}%
-}}}}
-% eiid2
-\put(2981,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}d: Ry=1}%
-}}}}
-% eiid3
-\put(2981,-157){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}e: Wy=2}%
-}}}}
-% eiid4
-\put(2981,-913){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}f: Ry=2}%
-}}}}
-% eiid5
-\put(2981,-1669){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}i: Rx=0}%
-}}}}
-\put( 1,349){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.000,0.392,0.000}fence}%
-}}}}
-\put(461,349){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1742,331){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(1686,-47){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,1}co}%
-}}}}
-\put(2461,280){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\put(2621,280){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(2770,-550){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(3011,-1163){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}addr}%
-}}}}
-\put(3411,-1163){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1741,-550){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\end{picture}%
diff --git a/src/figs/litmus_ppoca.pdf b/src/figs/litmus_ppoca.pdf
deleted file mode 100644
index 7aadd1f..0000000
--- a/src/figs/litmus_ppoca.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_ppoca.pdf_t b/src/figs/litmus_ppoca.pdf_t
deleted file mode 100644
index 9e6a06d..0000000
--- a/src/figs/litmus_ppoca.pdf_t
+++ /dev/null
@@ -1,58 +0,0 @@
-\begin{picture}(0,0)%
-\includegraphics{figs/litmus_ppoca.pdf}%
-\end{picture}%
-%
-% Generated by graphviz version 2.36.0 (20140111.2315)
-% Title: G
-% Pages: 1
-%
-\setlength{\unitlength}{3947sp}%
-%
-\begingroup\makeatletter\ifx\SetFigFont\undefined%
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{#1}{#2pt}%
- \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \selectfont}%
-\fi\endgroup%
-\begin{picture}(3886,2794)(-14,-1943)
-% eiid0
-\put(821,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}a: Wx=1}%
-}}}}
-% eiid1
-\put(821,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}c: Wy=1}%
-}}}}
-% eiid2
-\put(2981,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}d: Ry=1}%
-}}}}
-% eiid3
-\put(2981,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}e: Wz=1}%
-}}}}
-% eiid4
-\put(2981,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}f: Rz=1}%
-}}}}
-% eiid5
-\put(2981,-1831){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}g: Rx=0}%
-}}}}
-\put(0,-625){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.000,0.392,0.000}fence}%
-}}}}
-\put(441,-625){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1739,-122){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(2641,225){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ctrl}%
-}}}}
-\put(3020,225){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(3520,-1000){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ctrl}%
-}}}}
-\put(3100,-544){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ctrl}%
-}}}}
-\put(2800,-600){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(2561,-1295){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}addr}%
-}}}}
-\put(3020,-1295){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1743,-782){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\end{picture}%
diff --git a/src/figs/litmus_rsw.pdf b/src/figs/litmus_rsw.pdf
deleted file mode 100644
index 4c35d73..0000000
--- a/src/figs/litmus_rsw.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_rsw.pdf_t b/src/figs/litmus_rsw.pdf_t
deleted file mode 100644
index 2393619..0000000
--- a/src/figs/litmus_rsw.pdf_t
+++ /dev/null
@@ -1,61 +0,0 @@
-\begin{picture}(0,0)%
-\includegraphics{figs/litmus_rsw.pdf}%
-\end{picture}%
-%
-% Generated by graphviz version 2.38.0 (20140413.2041)
-% Title: G
-% Pages: 1
-%
-\setlength{\unitlength}{3947sp}%
-%
-\begingroup\makeatletter\ifx\SetFigFont\undefined%
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{#1}{#2pt}%
- \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \selectfont}%
-\fi\endgroup%
-\begin{picture}(4187,2308)(-14,-1457)
-% eiid0
-\put(821,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}a: Wx=1}%
-}}}}
-% eiid1
-\put(821,-49){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}c: Wy=1}%
-}}}}
-% eiid2
-\put(2261,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}d: Ry=1}%
-}}}}
-% eiid3
-\put(2261,-49){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}g: Rz=$v$}%
-}}}}
-% eiid4
-\put(2261,-697){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}h: Rz=$v$}%
-}}}}
-% eiid5
-\put(2261,-1345){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}k: Rx=0}%
-}}}}
-% eiid6
-\put(3701,-373){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0} Wz=$v$}%
-}}}}
-\put( 1,173){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.000,0.392,0.000}fence}%
-}}}}
-\put(501,173){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1376,363){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(1541,173){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}addr}%
-}}}}
-\put(1941,173){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(2041,-279){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}po}%
-}}}}
-\put(1541,-1123){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}addr}%
-}}}}
-\put(1941,-1123){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1347,-294){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\put(2844,-126){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(2844,-440){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\end{picture}%
diff --git a/src/figs/litmus_sample.pdf b/src/figs/litmus_sample.pdf
deleted file mode 100644
index a12a6ec..0000000
--- a/src/figs/litmus_sample.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_sample.pdf_t b/src/figs/litmus_sample.pdf_t
deleted file mode 100644
index bcf40a2..0000000
--- a/src/figs/litmus_sample.pdf_t
+++ /dev/null
@@ -1,52 +0,0 @@
-\begin{picture}(0,0)%
-\includegraphics{figs/litmus_sample.pdf}%
-\end{picture}%
-%
-% Generated by graphviz version 2.38.0 (20140413.2041)
-% Title: G
-% Pages: 1
-%
-\setlength{\unitlength}{3947sp}%
-%
-\begingroup\makeatletter\ifx\SetFigFont\undefined%
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{#1}{#2pt}%
- \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \selectfont}%
-\fi\endgroup%
-\begin{picture}(2410,2794)(-14,-1943)
-% eiid0
-\put(720,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}a: Wx=1}%
-}}}}
-% eiid1
-\put(720,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}b: Wx=2}%
-}}}}
-% eiid2
-\put(720,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}c: Rx=1}%
-}}}}
-% eiid3
-\put(720,-1831){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}d: Wx=3}%
-}}}}
-% eiid4
-\put(1944, -8){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}e: Wx=4}%
-}}}}
-% eiid5
-\put(1944,-818){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}f: Wx=5}%
-}}}}
-\put(837,272){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,1}co}%
-}}}}
-\put(1251,-121){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(382,282){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,1}co}%
-}}}}
-\put(1217,-931){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,1}co}%
-}}}}
-\put( 1,-121){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\put(560,-763){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\put(560,-1339){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\put(1724,-566){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,1}co}%
-}}}}
-\end{picture}%
diff --git a/src/figs/litmus_sb_fwd.pdf b/src/figs/litmus_sb_fwd.pdf
deleted file mode 100644
index 432dd9a..0000000
--- a/src/figs/litmus_sb_fwd.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_sb_fwd.pdf_t b/src/figs/litmus_sb_fwd.pdf_t
deleted file mode 100644
index 2eb0d6e..0000000
--- a/src/figs/litmus_sb_fwd.pdf_t
+++ /dev/null
@@ -1,52 +0,0 @@
-\begin{picture}(0,0)%
-\includegraphics{figs/litmus_sb_fwd.pdf}%
-\end{picture}%
-%
-% Generated by graphviz version 2.38.0 (20140413.2041)
-% Title: G
-% Pages: 1
-%
-\setlength{\unitlength}{3947sp}%
-%
-\begingroup\makeatletter\ifx\SetFigFont\undefined%
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{#1}{#2pt}%
- \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \selectfont}%
-\fi\endgroup%
-\begin{picture}(3447,1984)(-14,-1133)
-% eiid0
-\put(821,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}a: Wx=1}%
-}}}}
-% eiid1
-\put(821,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}b: Rx=1}%
-}}}}
-% eiid2
-\put(821,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}d: Ry=0}%
-}}}}
-% eiid3
-\put(2981,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}e: Wy=1}%
-}}}}
-% eiid4
-\put(2981,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}f: Ry=1}%
-}}}}
-% eiid5
-\put(2981,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}h: Rx=0}%
-}}}}
-\put(661,281){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put( 1,-485){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.000,0.392,0.000}fence}%
-}}}}
-\put(450,-485){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1539,-122){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\put(3021,281){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(3061,-485){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.000,0.392,0.000}fence}%
-}}}}
-\put(3511,-485){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(2103,-122){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1.000,0.627,0.251}fr}%
-}}}}
-\end{picture}%
diff --git a/src/figs/litmus_subsumption.pdf b/src/figs/litmus_subsumption.pdf
deleted file mode 100644
index 89c85ef..0000000
--- a/src/figs/litmus_subsumption.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/litmus_subsumption.pdf_t b/src/figs/litmus_subsumption.pdf_t
deleted file mode 100644
index 12a543d..0000000
--- a/src/figs/litmus_subsumption.pdf_t
+++ /dev/null
@@ -1,49 +0,0 @@
-\begin{picture}(0,0)%
-\includegraphics{figs/litmus_subsumption.pdf}%
-\end{picture}%
-%
-% Generated by graphviz version 2.38.0 (20140413.2041)
-% Title: G
-% Pages: 1
-%
-\setlength{\unitlength}{3947sp}%
-%
-\begingroup\makeatletter\ifx\SetFigFont\undefined%
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{#1}{#2pt}%
- \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \selectfont}%
-\fi\endgroup%
-\begin{picture}(3447,1984)(-14,-1133)
-% eiid0
-\put(821,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}a: Wx=3}%
-}}}}
-% eiid1
-\put(821,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}c: Wy=1}%
-}}}}
-% eiid3
-\put(2981,-211){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}e: Wx=1}%
-}}}}
-% eiid2
-\put(2981,599){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}d: Ry=1}%
-}}}}
-% eiid4
-\put(2981,-1021){\makebox(0,0)[b]{\smash{{\SetFigFont{8}{9.6}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}f: Wx=2}%
-}}}}
-\put( -40, 190){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.000,0.392,0.000}fence}%
-}}}}
-\put(450, 190){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(1673,380){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,1}co}%
-}}}}
-\put(1742, 44){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{1,0,0}rf}%
-}}}}
-\put(2261, 230){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}data}%
-}}}}
-\put(2650, 230){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\put(2420,-485){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,1}co}%
-}}}}
-\put(2630,-485){\makebox(0,0)[lb]{\smash{{\SetFigFont{11}{13.2}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0.294,0.000,0.510}ppo}%
-}}}}
-\end{picture}%
diff --git a/src/figs/privimps.pdf b/src/figs/privimps.pdf
deleted file mode 100644
index 9ed591b..0000000
--- a/src/figs/privimps.pdf
+++ /dev/null
Binary files differ
diff --git a/src/figs/virtimps.pdf b/src/figs/virtimps.pdf
deleted file mode 100644
index 7b98872..0000000
--- a/src/figs/virtimps.pdf
+++ /dev/null
Binary files differ
diff --git a/src/fraclmul.adoc b/src/fraclmul.adoc
new file mode 100644
index 0000000..32e9b81
--- /dev/null
+++ b/src/fraclmul.adoc
@@ -0,0 +1,175 @@
+=== Fractional Lmul example
+
+This appendix presents a non-normative example to help explain where
+compilers can make good use of the fractional LMUL feature.
+
+Consider the following (admittedly contrived) loop written in C:
+
+[source,c]
+----
+void add_ref(long N,
+ signed char *restrict c_c, signed char *restrict c_a, signed char *restrict c_b,
+ long *restrict l_c, long *restrict l_a, long *restrict l_b,
+ long *restrict l_d, long *restrict l_e, long *restrict l_f,
+ long *restrict l_g, long *restrict l_h, long *restrict l_i,
+ long *restrict l_j, long *restrict l_k, long *restrict l_l,
+ long *restrict l_m) {
+ long i;
+ for (i = 0; i < N; i++) {
+ c_c[i] = c_a[i] + c_b[i]; // Note this 'char' addition that creates a mixed type situation
+ l_c[i] = l_a[i] + l_b[i];
+ l_f[i] = l_d[i] + l_e[i];
+ l_i[i] = l_g[i] + l_h[i];
+ l_l[i] = l_k[i] + l_j[i];
+ l_m[i] += l_m[i] + l_c[i] + l_f[i] + l_i[i] + l_l[i];
+ }
+}
+----
+
+The example loop has a high register pressure due to the many input variables
+and temporaries required. The compiler realizes there are two datatypes within
+the loop: an 8-bit 'char' and a 64-bit 'long *'. Without fractional LMUL, the
+compiler would be forced to use LMUL=1 for the 8-bit computation and LMUL=8 for
+the 64-bit computation(s), to have equal number of elements on all computations
+within the same loop iteration. Under LMUL=8, only 4 registers are available
+to the register allocator. Given the large number of 64-bit variables and
+temporaries required in this loop, the compiler ends up generating a lot of
+spill code. The code below demonstrates this effect:
+
+----
+.LBB0_4: # %vector.body
+ # =>This Inner Loop Header: Depth=1
+ add s9, a2, s6
+ vsetvli s1, zero, e8,m1,ta,mu
+ vle8.v v25, (s9)
+ add s1, a3, s6
+ vle8.v v26, (s1)
+ vadd.vv v25, v26, v25
+ add s1, a1, s6
+ vse8.v v25, (s1)
+ add s9, a5, s10
+ vsetvli s1, zero, e64,m8,ta,mu
+ vle64.v v8, (s9)
+ add s1, a6, s10
+ vle64.v v16, (s1)
+ add s1, a7, s10
+ vle64.v v24, (s1)
+ add s1, s3, s10
+ vle64.v v0, (s1)
+ sd a0, -112(s0)
+ ld a0, -128(s0)
+ vs8r.v v0, (a0) # Spill LMUL=8
+ add s9, t6, s10
+ add s11, t5, s10
+ add ra, t2, s10
+ add s1, t3, s10
+ vle64.v v0, (s9)
+ ld s9, -136(s0)
+ vs8r.v v0, (s9) # Spill LMUL=8
+ vle64.v v0, (s11)
+ ld s9, -144(s0)
+ vs8r.v v0, (s9) # Spill LMUL=8
+ vle64.v v0, (ra)
+ ld s9, -160(s0)
+ vs8r.v v0, (s9) # Spill LMUL=8
+ vle64.v v0, (s1)
+ ld s1, -152(s0)
+ vs8r.v v0, (s1) # Spill LMUL=8
+ vadd.vv v16, v16, v8
+ ld s1, -128(s0)
+ vl8r.v v8, (s1) # Reload LMUL=8
+ vadd.vv v8, v8, v24
+ ld s1, -136(s0)
+ vl8r.v v24, (s1) # Reload LMUL=8
+ ld s1, -144(s0)
+ vl8r.v v0, (s1) # Reload LMUL=8
+ vadd.vv v24, v0, v24
+ ld s1, -128(s0)
+ vs8r.v v24, (s1) # Spill LMUL=8
+ ld s1, -152(s0)
+ vl8r.v v0, (s1) # Reload LMUL=8
+ ld s1, -160(s0)
+ vl8r.v v24, (s1) # Reload LMUL=8
+ vadd.vv v0, v0, v24
+ add s1, a4, s10
+ vse64.v v16, (s1)
+ add s1, s2, s10
+ vse64.v v8, (s1)
+ vadd.vv v8, v8, v16
+ add s1, t4, s10
+ ld s9, -128(s0)
+ vl8r.v v16, (s9) # Reload LMUL=8
+ vse64.v v16, (s1)
+ add s9, t0, s10
+ vadd.vv v8, v8, v16
+ vle64.v v16, (s9)
+ add s1, t1, s10
+ vse64.v v0, (s1)
+ vadd.vv v8, v8, v0
+ vsll.vi v16, v16, 1
+ vadd.vv v8, v8, v16
+ vse64.v v8, (s9)
+ add s6, s6, s7
+ add s10, s10, s8
+ bne s6, s4, .LBB0_4
+----
+
+If instead of using LMUL=1 for the 8-bit computation, the compiler is allowed
+to use a fractional LMUL=1/2, then the 64-bit computations can be performed
+using LMUL=4 (note that the same ratio of 64-bit elements and 8-bit elements is
+preserved as in the previous example). Now the compiler has 8 available
+registers to perform register allocation, resulting in no spill code, as
+shown in the loop below:
+
+----
+.LBB0_4: # %vector.body
+ # =>This Inner Loop Header: Depth=1
+ add s9, a2, s6
+ vsetvli s1, zero, e8,mf2,ta,mu // LMUL=1/2 !
+ vle8.v v25, (s9)
+ add s1, a3, s6
+ vle8.v v26, (s1)
+ vadd.vv v25, v26, v25
+ add s1, a1, s6
+ vse8.v v25, (s1)
+ add s9, a5, s10
+ vsetvli s1, zero, e64,m4,ta,mu // LMUL=4
+ vle64.v v28, (s9)
+ add s1, a6, s10
+ vle64.v v8, (s1)
+ vadd.vv v28, v8, v28
+ add s1, a7, s10
+ vle64.v v8, (s1)
+ add s1, s3, s10
+ vle64.v v12, (s1)
+ add s1, t6, s10
+ vle64.v v16, (s1)
+ add s1, t5, s10
+ vle64.v v20, (s1)
+ add s1, a4, s10
+ vse64.v v28, (s1)
+ vadd.vv v8, v12, v8
+ vadd.vv v12, v20, v16
+ add s1, t2, s10
+ vle64.v v16, (s1)
+ add s1, t3, s10
+ vle64.v v20, (s1)
+ add s1, s2, s10
+ vse64.v v8, (s1)
+ add s9, t4, s10
+ vadd.vv v16, v20, v16
+ add s11, t0, s10
+ vle64.v v20, (s11)
+ vse64.v v12, (s9)
+ add s1, t1, s10
+ vse64.v v16, (s1)
+ vsll.vi v20, v20, 1
+ vadd.vv v28, v8, v28
+ vadd.vv v28, v28, v12
+ vadd.vv v28, v28, v16
+ vadd.vv v28, v28, v20
+ vse64.v v28, (s11)
+ add s6, s6, s7
+ add s10, s10, s8
+ bne s6, s4, .LBB0_4
+----
diff --git a/src/gmaps.tex b/src/gmaps.tex
deleted file mode 100644
index a00ce65..0000000
--- a/src/gmaps.tex
+++ /dev/null
@@ -1,75 +0,0 @@
-\chapter{RV32/64G Instruction Set Listings}
-
-One goal of the RISC-V project is that it be used as a stable software
-development target. For this purpose, we define a combination of a
-base ISA (RV32I or RV64I) plus selected standard extensions (IMAFD) as
-a ``general-purpose'' ISA, and we use the abbreviation G for the IMAFD
-combination of instruction-set extensions. This chapter presents
-opcode maps and instruction-set listings for RV32G and RV64G.
-
-\input{opcode-map}
-
-Table~\ref{opcodemap} shows a map of the major opcodes for RVG. Major
-opcodes with 3 or more lower bits set are reserved for instruction
-lengths greater than 32 bits. Opcodes marked as {\em reserved} should
-be avoided for custom instruction-set extensions as they might be used
-by future standard extensions. Major opcodes marked as {\em custom-0}
-and {\em custom-1} will be avoided by future standard extensions and
-are recommended for use by custom instruction-set extensions within
-the base 32-bit instruction format. The opcodes marked {\em
- custom-2/rv128} and {\em custom-3/rv128} are reserved for future use
-by RV128, but will otherwise be avoided for standard extensions and so
-can also be used for custom instruction-set extensions in RV32 and
-RV64.
-
-We believe RV32G and RV64G provide simple but complete instruction
-sets for a broad range of general-purpose computing. The optional
-compressed instruction set described in Chapter~\ref{compressed} can
-be added (forming RV32GC and RV64GC) to improve performance, code
-size, and energy efficiency, though with some additional hardware
-complexity.
-
-As we move beyond IMAFDC into further instruction-set extensions, the
-added instructions tend to be more domain-specific and only provide
-benefits to a restricted class of applications, e.g., for multimedia
-or security. Unlike most commercial ISAs, the RISC-V ISA design
-clearly separates the base ISA and broadly applicable standard
-extensions from these more specialized additions.
-Chapter~\ref{extensions} has a more extensive discussion of ways to
-add extensions to the RISC-V ISA.
-
-\input{instr-table}
-
-\FloatBarrier
-Table~\ref{rvgcsrnames} lists the CSRs that have
-currently been allocated CSR addresses. The timers, counters, and
-floating-point CSRs are the only CSRs defined in this specification.
-
-\begin{table}[htb!]
-\begin{center}
-\begin{tabular}{|l|l|l|l|}
-\hline
-Number & Privilege & Name & Description \\
-\hline
-\multicolumn{4}{|c|}{Floating-Point Control and Status Registers} \\
-\hline
-\tt 0x001 & Read/write &\tt fflags & Floating-Point Accrued Exceptions. \\
-\tt 0x002 & Read/write &\tt frm & Floating-Point Dynamic Rounding Mode. \\
-\tt 0x003 & Read/write &\tt fcsr & Floating-Point Control and Status
-Register ({\tt frm} + {\tt fflags}). \\
-\hline
-\multicolumn{4}{|c|}{Counters and Timers} \\
-\hline
-\tt 0xC00 & Read-only &\tt cycle & Cycle counter for RDCYCLE instruction. \\
-\tt 0xC01 & Read-only &\tt time & Timer for RDTIME instruction. \\
-\tt 0xC02 & Read-only &\tt instret & Instructions-retired counter for RDINSTRET instruction. \\
-\tt 0xC80 & Read-only &\tt cycleh & Upper 32 bits of {\tt cycle}, RV32I only. \\
-\tt 0xC81 & Read-only &\tt timeh & Upper 32 bits of {\tt time}, RV32I only. \\
-\tt 0xC82 & Read-only &\tt instreth & Upper 32 bits of {\tt instret}, RV32I only. \\
-\hline
-\end{tabular}
-\end{center}
-\caption{RISC-V control and status register (CSR) address map.}
-\label{rvgcsrnames}
-\end{table}
-
diff --git a/src/history.tex b/src/history.tex
deleted file mode 100644
index 0e6e816..0000000
--- a/src/history.tex
+++ /dev/null
@@ -1,403 +0,0 @@
-\chapter{History and Acknowledgments}
-\label{history}
-
-\section{``Why Develop a new ISA?'' Rationale from Berkeley Group}
-
-We developed RISC-V to support our own needs in research and
-education, where our group is particularly interested in actual
-hardware implementations of research ideas (we have completed eleven
-different silicon fabrications of RISC-V since the first edition of
-this specification), and in providing real implementations for
-students to explore in classes (RISC-V processor RTL designs have been
-used in multiple undergraduate and graduate classes at Berkeley). In
-our current research, we are especially interested in the move towards
-specialized and heterogeneous accelerators, driven by the power
-constraints imposed by the end of conventional transistor scaling. We
-wanted a highly flexible and extensible base ISA around which to build
-our research effort.
-
-A question we have been repeatedly asked is ``Why develop a new ISA?''
-The biggest obvious benefit of using an existing commercial ISA is the
-large and widely supported software ecosystem, both development tools
-and ported applications, which can be leveraged in research and
-teaching. Other benefits include the existence of large amounts of
-documentation and tutorial examples. However, our experience of using
-commercial instruction sets for research and teaching is that these
-benefits are smaller in practice, and do not outweigh the
-disadvantages:
-
-\begin{itemize}
-\item {\bf Commercial ISAs are proprietary.} Except for SPARC V8,
- which is an open IEEE standard~\cite{sparcieee1994}, most owners of
- commercial ISAs carefully guard their intellectual property and do
- not welcome freely available competitive implementations. This is
- much less of an issue for academic research and teaching using only
- software simulators, but has been a major concern for groups wishing
- to share actual RTL implementations. It is also a major concern for
- entities who do not want to trust the few sources of commercial ISA
- implementations, but who are prohibited from creating their own
- clean room implementations. We cannot guarantee that all RISC-V
- implementations will be free of third-party patent infringements,
- but we can guarantee we will not attempt to sue a RISC-V
- implementor.
-
-\item {\bf Commercial ISAs are only popular in certain market
- domains.} The most obvious examples at time of writing are that
- the ARM architecture is not well supported in the server space, and
- the Intel x86 architecture (or for that matter, almost every other
- architecture) is not well supported in the mobile space, though both
- Intel and ARM are attempting to enter each other's market segments.
- Another example is ARC and Tensilica, which provide extensible cores
- but are focused on the embedded space. This market segmentation
- dilutes the benefit of supporting a particular commercial ISA as in
- practice the software ecosystem only exists for certain domains, and
- has to be built for others.
-
-\item {\bf Commercial ISAs come and go.} Previous research
- infrastructures have been built around commercial ISAs that are no
- longer popular (SPARC, MIPS) or even no longer in production
- (Alpha). These lose the benefit of an active software ecosystem,
- and the lingering intellectual property issues around the ISA and
- supporting tools interfere with the ability of interested third
- parties to continue supporting the ISA. An open ISA might also lose
- popularity, but any interested party can continue using and
- developing the ecosystem.
-
-\item {\bf Popular commercial ISAs are complex.} The dominant
- commercial ISAs (x86 and ARM) are both very complex to implement in
- hardware to the level of supporting common software stacks and
- operating systems. Worse, nearly all the complexity is due to bad,
- or at least outdated, ISA design decisions rather than features that
- truly improve efficiency.
-
-\item {\bf Commercial ISAs alone are not enough to bring up
- applications.} Even if we expend the effort to implement a
- commercial ISA, this is not enough to run existing applications for
- that ISA. Most applications need a complete ABI (application binary
- interface) to run, not just the user-level ISA. Most ABIs rely on
- libraries, which in turn rely on operating system support. To run an
- existing operating system requires implementing the supervisor-level
- ISA and device interfaces expected by the OS. These are usually
- much less well-specified and considerably more complex to
- implement than the user-level ISA.
-
-\item {\bf Popular commercial ISAs were not designed for extensibility.} The
- dominant commercial ISAs were not particularly designed for
- extensibility, and as a consequence have added considerable
- instruction encoding complexity as their instruction sets have
- grown. Companies such as Tensilica (acquired by Cadence) and ARC
- (acquired by Synopsys) have built ISAs and toolchains around
- extensibility, but have focused on embedded applications rather than
- general-purpose computing systems.
-
-\item {\bf A modified commercial ISA is a new ISA.} One of our main
- goals is to support architecture research, including major ISA
- extensions. Even small extensions diminish the benefit of using a
- standard ISA, as compilers have to be modified and applications
- rebuilt from source code to use the extension. Larger extensions
- that introduce new architectural state also require modifications to
- the operating system. Ultimately, the modified commercial ISA
- becomes a new ISA, but carries along all the legacy baggage of the
- base ISA.
-\end{itemize}
-
-Our position is that the ISA is perhaps the most important interface
-in a computing system, and there is no reason that such an important
-interface should be proprietary. The dominant commercial ISAs are
-based on instruction-set concepts that were already well known over 30
-years ago. Software developers should be able to target an open
-standard hardware target, and commercial processor designers should
-compete on implementation quality.
-
-We are far from the first to contemplate an open ISA design suitable
-for hardware implementation. We also considered other existing open
-ISA designs, of which the closest to our goals was the OpenRISC
-architecture~\cite{openriscarch}. We decided against adopting the
-OpenRISC ISA for several technical reasons:
-
-\begin{itemize}
-\item OpenRISC has condition codes and branch delay slots, which
- complicate higher performance implementations.
-\item OpenRISC uses a fixed 32-bit encoding and 16-bit immediates,
- which precludes a denser instruction encoding and limits space for
- later expansion of the ISA.
-\item OpenRISC does not support the 2008 revision to the IEEE 754
- floating-point standard.
-\item The OpenRISC 64-bit design had not been completed when we began.
-\end{itemize}
-
-By starting from a clean slate, we could design an ISA that met all of
-our goals, though of course, this took far more effort than we had
-planned at the outset. We have now invested considerable effort in
-building up the RISC-V ISA infrastructure, including documentation,
-compiler tool chains, operating system ports, reference ISA
-simulators, FPGA implementations, efficient ASIC implementations,
-architecture test suites, and teaching materials. Since the last
-edition of this manual, there has been considerable uptake of the
-RISC-V ISA in both academia and industry, and we have created the
-non-profit RISC-V Foundation to protect and promote the standard. The
-RISC-V Foundation website at \url{https://riscv.org} contains the latest
-information on the Foundation membership and various open-source
-projects using RISC-V.
-
-
-\section{History from Revision 1.0 of ISA manual}
-
-The RISC-V ISA and instruction-set manual builds upon several earlier
-projects. Several aspects of the supervisor-level machine and the
-overall format of the manual date back to the T0 (Torrent-0) vector
-microprocessor project at UC Berkeley and ICSI, begun in 1992. T0 was
-a vector processor based on the MIPS-II ISA, with Krste Asanovi\'{c}
-as main architect and RTL designer, and Brian Kingsbury and Bertrand
-Irrisou as principal VLSI implementors. David Johnson at ICSI was a
-major contributor to the T0 ISA design, particularly supervisor mode,
-and to the manual text. John Hauser also provided considerable
-feedback on the T0 ISA design.
-
-The Scale (Software-Controlled Architecture for Low Energy) project at
-MIT, begun in 2000, built upon the T0 project infrastructure, refined
-the supervisor-level interface, and moved away from the MIPS scalar
-ISA by dropping the branch delay slot. Ronny Krashinsky and
-Christopher Batten were the principal architects of the Scale
-Vector-Thread processor at MIT, while Mark Hampton ported the
-GCC-based compiler infrastructure and tools for Scale.
-
-A lightly edited version of the T0 MIPS scalar processor specification
-(MIPS-6371) was used in teaching a new version of the MIT 6.371
-Introduction to VLSI Systems class in the Fall 2002 semester, with
-Chris Terman and Krste Asanovi\'{c} as lecturers. Chris Terman
-contributed most of the lab material for the class (there was no
-TA!). The 6.371 class evolved into the trial 6.884 Complex Digital
-Design class at MIT, taught by Arvind and Krste Asanovi\'{c} in Spring
-2005, which became a regular Spring class 6.375. A reduced version of
-the Scale MIPS-based scalar ISA, named SMIPS, was used in 6.884/6.375.
-Christopher Batten was the TA for the early offerings of these classes
-and developed a considerable amount of documentation and lab material
-based around the SMIPS ISA. This same SMIPS lab material was adapted
-and enhanced by TA Yunsup Lee for the UC Berkeley Fall 2009 CS250 VLSI
-Systems Design class taught by John Wawrzynek, Krste Asanovi\'{c}, and
-John Lazzaro.
-
-The Maven (Malleable Array of Vector-thread ENgines) project was a
-second-generation vector-thread architecture. Its design was led by
-Christopher Batten when he was an Exchange Scholar at UC Berkeley starting
-in summer 2007. Hidetaka Aoki, a visiting industrial fellow from
-Hitachi, gave considerable feedback on the early Maven ISA and
-microarchitecture design. The Maven infrastructure was based on the
-Scale infrastructure but the Maven ISA moved further away from the
-MIPS ISA variant defined in Scale, with a unified floating-point and
-integer register file. Maven was designed to support experimentation
-with alternative data-parallel accelerators. Yunsup Lee was the main
-implementor of the various Maven vector units, while Rimas Avi\v{z}ienis
-was the main implementor of the various Maven scalar units.
-Yunsup Lee and Christopher Batten ported GCC to work with the new
-Maven ISA. Christopher Celio provided the initial definition of a
-traditional vector instruction set (``Flood'') variant of Maven.
-
-Based on experience with all these previous projects, the RISC-V ISA
-definition was begun in Summer 2010, with Andrew Waterman, Yunsup Lee,
-Krste Asanovi\'{c}, and David Patterson as principal designers.
-An initial version of the RISC-V
-32-bit instruction subset was used in the UC Berkeley Fall 2010 CS250
-VLSI Systems Design class, with Yunsup Lee as TA. RISC-V is a clean
-break from the earlier MIPS-inspired designs. John Hauser contributed
-to the floating-point ISA definition, including the sign-injection
-instructions and a register encoding scheme that permits
-internal recoding of floating-point values.
-
-\section{History from Revision 2.0 of ISA manual}
-
-Multiple implementations of RISC-V processors have been completed,
-including several silicon fabrications, as shown in
-Figure~\ref{silicon}.
-
-\begin{table*}[!h]
-\begin{center}
-\begin{tabular}{|l|r|l|l|}
-\hline
-\multicolumn{1}{|c|}{Name} & \multicolumn{1}{|c|}{Tapeout Date} & \multicolumn{1}{|c|}{Process} & \multicolumn{1}{|c|}{ISA} \\ \hline
-\hline
-Raven-1 & May 29, 2011 & ST 28nm FDSOI & RV64G1\_Xhwacha1 \\ \hline
-EOS14 & April 1, 2012 & IBM 45nm SOI & RV64G1p1\_Xhwacha2 \\ \hline
-EOS16 & August 17, 2012 & IBM 45nm SOI & RV64G1p1\_Xhwacha2 \\ \hline
-Raven-2 & August 22, 2012 & ST 28nm FDSOI & RV64G1p1\_Xhwacha2 \\ \hline
-EOS18 & February 6, 2013 & IBM 45nm SOI & RV64G1p1\_Xhwacha2 \\ \hline
-EOS20 & July 3, 2013 & IBM 45nm SOI & RV64G1p99\_Xhwacha2 \\ \hline
-Raven-3 & September 26, 2013 & ST 28nm SOI & RV64G1p99\_Xhwacha2 \\ \hline
-EOS22 & March 7, 2014 & IBM 45nm SOI & RV64G1p9999\_Xhwacha3 \\ \hline
-\end{tabular}
-\end{center}
-\vspace{-0.15in}
-\caption{Fabricated RISC-V testchips.}
-\label{silicon}
-\end{table*}
-
-The first RISC-V processors to be fabricated were written in Verilog and
-manufactured in a pre-production \wunits{28}{nm} FDSOI technology from
-ST as the Raven-1 testchip in 2011. Two cores were developed by Yunsup
-Lee and Andrew Waterman, advised by Krste Asanovi\'{c}, and fabricated
-together: 1) an RV64 scalar core with error-detecting flip-flops, and 2)
-an RV64 core with an attached 64-bit floating-point vector unit. The
-first microarchitecture was informally known as ``TrainWreck'', due to
-the short time available to complete the design with immature design
-libraries.
-
-Subsequently, a clean microarchitecture for an in-order decoupled RV64
-core was developed by Andrew Waterman, Rimas Avi\v{z}ienis, and Yunsup
-Lee, advised by Krste Asanovi\'{c}, and, continuing the railway theme,
-was codenamed ``Rocket'' after George Stephenson's successful steam
-locomotive design. Rocket was written in Chisel, a new hardware
-design language developed at UC Berkeley. The IEEE floating-point
-units used in Rocket were developed by John Hauser, Andrew
-Waterman, and Brian Richards.
-Rocket has since been refined and developed further, and has been
-fabricated two more times in \wunits{28}{nm} FDSOI (Raven-2, Raven-3),
-and five times in IBM \wunits{45}{nm} SOI technology (EOS14, EOS16,
-EOS18, EOS20, EOS22) for a photonics project. Work is ongoing to make
-the Rocket design available as a parameterized RISC-V processor
-generator.
-
-EOS14--EOS22 chips include early versions of Hwacha, a 64-bit IEEE
-floating-point vector unit, developed by Yunsup Lee, Andrew Waterman,
-Huy Vo, Albert Ou, Quan Nguyen, and Stephen Twigg, advised by Krste
-Asanovi\'{c}. EOS16--EOS22 chips include dual cores with a
-cache-coherence protocol developed by Henry Cook and Andrew Waterman,
-advised by Krste Asanovi\'{c}. EOS14 silicon has successfully run at
-\wunits{1.25}{GHz}. EOS16 silicon suffered from a bug in the IBM pad
-libraries. EOS18 and EOS20 have successfully run at \wunits{1.35}{GHz}.
-
-Contributors to the Raven testchips include Yunsup Lee, Andrew Waterman,
-Rimas Avi\v{z}ienis, Brian Zimmer, Jaehwa Kwak, Ruzica Jevti\'{c},
-Milovan Blagojevi\'{c}, Alberto Puggelli, Steven Bailey, Ben Keller,
-Pi-Feng Chiu, Brian Richards, Borivoje Nikoli\'{c}, and Krste
-Asanovi\'{c}.
-
-Contributors to the EOS testchips include Yunsup Lee, Rimas
-Avi\v{z}ienis, Andrew Waterman, Henry Cook, Huy Vo, Daiwei Li, Chen Sun,
-Albert Ou, Quan Nguyen, Stephen Twigg, Vladimir Stojanovi\'{c}, and
-Krste Asanovi\'{c}.
-
-Andrew Waterman and Yunsup Lee developed the C++ ISA simulator
-``Spike'', used as a golden model in development and named after the
-golden spike used to celebrate completion of the US transcontinental
-railway. Spike has been made available as a BSD open-source project.
-
-Andrew Waterman completed a Master's thesis with a preliminary design
-of the RISC-V compressed instruction set~\cite{waterman-ms}.
-
-Various FPGA implementations of the RISC-V have been completed,
-primarily as part of integrated demos for the Par Lab project research
-retreats. The largest FPGA design has 3 cache-coherent RV64IMA
-processors running a research operating system. Contributors to the
-FPGA implementations include Andrew Waterman, Yunsup Lee, Rimas
-Avi\v{z}ienis, and Krste Asanovi\'{c}.
-
-RISC-V processors have been used in several classes at UC Berkeley.
-Rocket was used in the Fall 2011 offering of CS250 as a basis for class
-projects, with Brian Zimmer as TA. For the undergraduate CS152 class in
-Spring 2012, Christopher Celio used Chisel to write a suite of educational
-RV32 processors, named ``Sodor'' after the island on which ``Thomas the
-Tank Engine'' and friends live. The suite includes a microcoded core,
-an unpipelined core, and 2, 3, and 5-stage pipelined cores, and is
-publicly available under a BSD license. The suite was subsequently
-updated and used again in CS152 in Spring 2013, with Yunsup Lee as TA,
-and in Spring 2014, with Eric Love as TA.
-Christopher Celio also developed an out-of-order RV64 design known as BOOM
-(Berkeley Out-of-Order Machine), with accompanying pipeline
-visualizations, that was used in the CS152 classes. The CS152 classes
-also used cache-coherent versions of the Rocket core developed by Andrew
-Waterman and Henry Cook.
-
-Over the summer of 2013, the RoCC (Rocket Custom Coprocessor)
-interface was defined to simplify adding custom accelerators to the
-Rocket core. Rocket and the RoCC interface were used extensively in
-the Fall 2013 CS250 VLSI class taught by Jonathan Bachrach, with
-several student accelerator projects built to the RoCC interface. The
-Hwacha vector unit has been rewritten as a RoCC coprocessor.
-
-Two Berkeley undergraduates, Quan Nguyen and Albert Ou, have
-successfully ported Linux to run on RISC-V in Spring 2013.
-
-Colin Schmidt successfully completed an LLVM backend for RISC-V 2.0 in
-January 2014.
-
-Darius Rad at Bluespec contributed soft-float ABI support to the GCC port in
-March 2014.
-
-John Hauser contributed the definition of the floating-point classification
-instructions.
-
-We are aware of several other RISC-V core implementations, including
-one in Verilog by Tommy Thorn, and one in Bluespec by Rishiyur Nikhil.
-
-\section*{Acknowledgments}
-
-Thanks to Christopher F. Batten, Preston Briggs, Christopher Celio, David
-Chisnall, Stefan Freudenberger, John Hauser, Ben Keller, Rishiyur
-Nikhil, Michael Taylor, Tommy Thorn, and Robert Watson for comments on
-the draft ISA version 2.0 specification.
-
-\section{History from Revision 2.1}
-
-Uptake of the RISC-V ISA has been very rapid since the introduction of
-the frozen version 2.0 in May 2014, with too much activity to record
-in a short history section such as this. Perhaps the most important
-single event was the formation of the non-profit RISC-V Foundation in
-August 2015. The Foundation will now take over stewardship of the
-official RISC-V ISA standard, and the official website {\tt riscv.org}
-is the best place to obtain news and updates on the RISC-V standard.
-
-\section*{Acknowledgments}
-
-Thanks to Scott Beamer, Allen J. Baum, Christopher Celio, David Chisnall,
-Paul Clayton, Palmer Dabbelt, Jan Gray, Michael Hamburg, and John
-Hauser for comments on the version 2.0 specification.
-
-\section{History from Revision 2.2}
-
-
-\section*{Acknowledgments}
-
-Thanks to Jacob Bachmeyer, Alex Bradbury, David Horner, Stefan O'Rear,
-and Joseph Myers for comments on the version 2.1 specification.
-
-\section{History for Revision 2.3}
-
-Uptake of RISC-V continues at breakneck pace.
-
-John Hauser and Andrew Waterman contributed a hypervisor ISA extension
-based upon a proposal from Paolo Bonzini.
-
-Daniel Lustig, Arvind, Krste Asanovi\'{c}, Shaked Flur, Paul Loewenstein, Yatin
-Manerkar, Luc Maranget, Margaret Martonosi, Vijayanand Nagarajan, Rishiyur
-Nikhil, Jonas Oberhauser, Christopher Pulte, Jose Renau, Peter Sewell, Susmit
-Sarkar, Caroline Trippel, Muralidaran Vijayaraghavan, Andrew Waterman, Derek
-Williams, Andrew Wright, and Sizhuo Zhang contributed the memory consistency
-model.
-
-\section{Funding}
-
-Development of the RISC-V architecture and implementations has been
-partially funded by the following sponsors.
-\begin{itemize}
-
-\item {\bf Par Lab:} Research supported by Microsoft (Award \#024263) and Intel (Award
- \#024894) funding and by matching funding by U.C. Discovery
- (Award \#DIG07-10227). Additional support came from Par Lab
- affiliates Nokia, NVIDIA, Oracle, and Samsung.
-
-\item {\bf Project Isis:} DoE Award DE-SC0003624.
-
-\item {\bf ASPIRE Lab}: DARPA PERFECT program, Award
- HR0011-12-2-0016. DARPA POEM program Award HR0011-11-C-0100. The
- Center for Future Architectures Research (C-FAR), a STARnet center
- funded by the Semiconductor Research Corporation. Additional
- support from ASPIRE industrial sponsor, Intel, and ASPIRE
- affiliates, Google, Hewlett Packard Enterprise, Huawei, Nokia,
- NVIDIA, Oracle, and Samsung.
-
-\end{itemize}
-
-The content of this paper does not necessarily reflect the position or the
-policy of the US government and no official endorsement should be
-inferred.
diff --git a/src/hypervisor.adoc b/src/hypervisor.adoc
new file mode 100644
index 0000000..3b662ea
--- /dev/null
+++ b/src/hypervisor.adoc
@@ -0,0 +1,2599 @@
+[[hypervisor]]
+== "H" Extension for Hypervisor Support, Version 1.0
+
+This chapter describes the RISC-V hypervisor extension, which
+virtualizes the supervisor-level architecture to support the efficient
+hosting of guest operating systems atop a type-1 or type-2 hypervisor.
+The hypervisor extension changes supervisor mode into
+_hypervisor-extended supervisor mode_ (HS-mode, or _hypervisor mode_ for
+short), where a hypervisor or a hosting-capable operating system runs.
+The hypervisor extension also adds another stage of address translation,
+from _guest physical addresses_ to supervisor physical addresses, to
+virtualize the memory and memory-mapped I/O subsystems for a guest
+operating system. HS-mode acts the same as S-mode, but with additional
+instructions and CSRs that control the new stage of address translation
+and support hosting a guest OS in virtual S-mode (VS-mode). Regular
+S-mode operating systems can execute without modification either in
+HS-mode or as VS-mode guests.
+
+In HS-mode, an OS or hypervisor interacts with the machine through the
+same SBI as an OS normally does from S-mode. An HS-mode hypervisor is
+expected to implement the SBI for its VS-mode guest.
+
+The hypervisor extension depends on an "I" base integer ISA with 32
+`x` registers (RV32I or RV64I), not RV32E or RV64E, which have only 16 `x`
+registers. CSR `mtval` must not be read-only zero, and standard
+page-based address translation must be supported, either Sv32 for RV32,
+or a minimum of Sv39 for RV64.
+
+The hypervisor extension is enabled by setting bit 7 in the `misa` CSR,
+which corresponds to the letter H. RISC-V harts that implement the
+hypervisor extension are encouraged not to hardwire `misa`[7], so that
+the extension may be disabled.
+
+[NOTE]
+====
+The baseline privileged architecture is designed to simplify the use of
+classic virtualization techniques, where a guest OS is run at
+user-level, as the few privileged instructions can be easily detected
+and trapped. The hypervisor extension improves virtualization
+performance by reducing the frequency of these traps.
+
+The hypervisor extension has been designed to be efficiently emulable on
+platforms that do not implement the extension, by running the hypervisor
+in S-mode and trapping into M-mode for hypervisor CSR accesses and to
+maintain shadow page tables. The majority of CSR accesses for type-2
+hypervisors are valid S-mode accesses so need not be trapped.
+Hypervisors can support nested virtualization analogously.
+====
+
+=== Privilege Modes
+
+The current _virtualization mode_, denoted V, indicates whether the hart
+is currently executing in a guest. When V=1, the hart is either in
+virtual S-mode (VS-mode), or in virtual U-mode (VU-mode) atop a guest OS
+running in VS-mode. When V=0, the hart is either in M-mode, in HS-mode,
+or in U-mode atop an OS running in HS-mode. The virtualization mode also
+indicates whether two-stage address translation is active (V=1) or
+inactive (V=0). <<HPrivModes>> lists the
+possible privilege modes of a RISC-V hart with the hypervisor extension.
+
+<<<
+
+[[HPrivModes]]
+.Privilege modes with the hypervisor extension.
+[float="center",align="center",cols="~,~,~,~,~"]
+|===
+^|Virtualization +
+Mode (V) ^|Nominal Privilege |Abbreviation |Name |Two-Stage Translation
+
+^|0 +
+0 +
+0
+^| U +
+S +
+M
+|U-mode +
+HS-mode +
+M-mode
+|User mode +
+Hypervisor-extended supervisor mode +
+Machine mode
+|Off +
+Off +
+Off
+^|1 +
+1
+^|U +
+S
+|VU-mode +
+VS-mode
+|Virtual user mode +
+Virtual supervisor mode
+|On +
+On
+|===
+
+For privilege modes U and VU, the _nominal privilege mode_ is U, and for
+privilege modes HS and VS, the nominal privilege mode is S.
+
+HS-mode is more privileged than VS-mode, and VS-mode is more privileged
+than VU-mode. VS-mode interrupts are globally disabled when executing in
+U-mode.
+
+[NOTE]
+====
+This description does not consider the possibility of U-mode or VU-mode
+interrupts and will be revised if an extension for user-level interrupts
+is adopted.
+====
+
+=== Hypervisor and Virtual Supervisor CSRs
+
+An OS or hypervisor running in HS-mode uses the supervisor CSRs to
+interact with the exception, interrupt, and address-translation
+subsystems. Additional CSRs are provided to HS-mode, but not to VS-mode,
+to manage two-stage address translation and to control the behavior of a
+VS-mode guest: `hstatus`, `hedeleg`, `hideleg`, `hvip`, `hip`, `hie`,
+`hgeip`, `hgeie`, `henvcfg`, `henvcfgh`, `hcounteren`, `htimedelta`,
+`htimedeltah`, `htval`, `htinst`, and `hgatp`.
+
+Furthermore, several _virtual supervisor_ CSRs (VS CSRs) are replicas of
+the normal supervisor CSRs. For example, `vsstatus` is the VS CSR that
+duplicates the usual `sstatus` CSR.
+
+When V=1, the VS CSRs substitute for the corresponding supervisor CSRs,
+taking over all functions of the usual supervisor CSRs except as
+specified otherwise. Instructions that normally read or modify a
+supervisor CSR shall instead access the corresponding VS CSR. When V=1,
+an attempt to read or write a VS CSR directly by its own separate CSR
+address causes a virtual-instruction exception. (Attempts from U-mode
+cause an illegal-instruction exception as usual.) The VS CSRs can be
+accessed as themselves only from M-mode or HS-mode.
+
+While V=1, the normal HS-level supervisor CSRs that are replaced by VS
+CSRs retain their values but do not affect the behavior of the machine
+unless specifically documented to do so. Conversely, when V=0, the VS
+CSRs do not ordinarily affect the behavior of the machine other than
+being readable and writable by CSR instructions.
+
+Some standard supervisor CSRs (`senvcfg`, `scounteren`, and `scontext`,
+possibly others) have no matching VS CSR. These supervisor CSRs continue
+to have their usual function and accessibility even when V=1, except
+with VS-mode and VU-mode substituting for HS-mode and U-mode. Hypervisor
+software is expected to manually swap the contents of these registers as
+needed.
+
+[NOTE]
+====
+Matching VS CSRs exist only for the supervisor CSRs that must be
+duplicated, which are mainly those that get automatically written by
+traps or that impact instruction execution immediately after trap entry
+and/or right before SRET, when software alone is unable to swap a CSR at
+exactly the right moment. Currently, most supervisor CSRs fall into this
+category, but future ones might not.
+====
+
+In this chapter, we use the term _HSXLEN_ to refer to the effective XLEN
+when executing in HS-mode, and _VSXLEN_ to refer to the effective XLEN
+when executing in VS-mode.
+
+[[sec:hstatus]]
+==== Hypervisor Status (`hstatus`) Register
+
+The `hstatus` register is an HSXLEN-bit read/write register formatted as
+shown in <<hstatusreg-rv32>> when HSXLEN=32
+and <<hstatusreg>> when HSXLEN=64. The `hstatus`
+register provides facilities analogous to the `mstatus` register for
+tracking and controlling the exception behavior of a VS-mode guest.
+
+[[hstatusreg-rv32]]
+.Hypervisor status register (`hstatus`) when HSXLEN=32
+[wavedrom,, svg]
+....
+{reg: [
+ {bits: 5, name: 'WPRI'},
+ {bits: 1, name: 'VSBE'},
+ {bits: 1, name: 'GVA'},
+ {bits: 1, name: 'SPV'},
+ {bits: 1, name: 'SPVP'},
+ {bits: 1, name: 'HU'},
+ {bits: 2, name: 'WPRI'},
+ {bits: 6, name: 'VGEIN'},
+ {bits: 2, name: 'WPRI'},
+ {bits: 1, name: 'VTVM'},
+ {bits: 1, name: 'VTW'},
+ {bits: 1, name: 'VTSR'},
+ {bits: 9, name: 'WPRI'},
+], config:{lanes: 2, hspace:1024}}
+....
+
+[[hstatusreg]]
+.Hypervisor status register (`hstatus`) when HSXLEN=64.
+[wavedrom,, svg]
+....
+{reg: [
+ {bits: 5, name: 'WPRI'},
+ {bits: 1, name: 'VSBE'},
+ {bits: 1, name: 'GVA'},
+ {bits: 1, name: 'SPV'},
+ {bits: 1, name: 'SPVP'},
+ {bits: 1, name: 'HU'},
+ {bits: 2, name: 'WPRI'},
+ {bits: 6, name: 'VGEIN'},
+ {bits: 2, name: 'WPRI'},
+ {bits: 1, name: 'VTVM'},
+ {bits: 1, name: 'VTW'},
+ {bits: 1, name: 'VTSR'},
+ {bits: 9, name: 'WPRI'},
+ {bits: 2, name: 'VSXL'},
+ {bits: 14, name: 'WPRI'},
+ {bits: 2, name: 'HUPMM'},
+ {bits: 14, name: 'WPRI'},
+], config:{lanes: 4, hspace:1024}}
+....
+
+The VSXL field controls the effective XLEN for VS-mode (known as
+VSXLEN), which may differ from the XLEN for HS-mode (HSXLEN). When
+HSXLEN=32, the VSXL field does not exist, and VSXLEN=32. When HSXLEN=64,
+VSXL is a *WARL* field that is encoded the same as the MXL field of `misa`,
+shown in <<misabase>>. In particular, an
+implementation may make VSXL be a read-only field whose value always
+ensures that VSXLEN=HSXLEN.
+
+If HSXLEN is changed from 32 to a wider width, and if field VSXL is not
+restricted to a single value, it gets the value corresponding to the
+widest supported width not wider than the new HSXLEN.
+
+The `hstatus` fields VTSR, VTW, and VTVM are defined analogously to the
+`mstatus` fields TSR, TW, and TVM, but affect execution only in VS-mode,
+and cause virtual-instruction exceptions instead of illegal-instruction
+exceptions. When VTSR=1, an attempt in VS-mode to execute SRET raises a
+virtual-instruction exception. When VTW=1 (and assuming `mstatus`.TW=0),
+an attempt in VS-mode to execute WFI raises a virtual-instruction
+exception if the WFI does not complete within an
+implementation-specific, bounded time limit. An implementation may have
+WFI always raise a virtual-instruction exception in VS-mode when VTW=1
+(and `mstatus`.TW=0), even if there are pending globally-disabled
+interrupts when the instruction is executed. When VTVM=1, an attempt in
+VS-mode to execute SFENCE.VMA or SINVAL.VMA or to access CSR `satp`
+raises a virtual-instruction exception.
+
+The VGEIN (Virtual Guest External Interrupt Number) field selects a
+guest external interrupt source for VS-level external interrupts. VGEIN
+is a *WLRL* field that must be able to hold values between zero and the
+maximum guest external interrupt number (known as GEILEN), inclusive.
+When VGEIN=0, no guest external interrupt source is selected for
+VS-level external interrupts. GEILEN may be zero, in which case VGEIN
+may be read-only zero. Guest external interrupts are explained in
+<<hgeinterruptregs>>, and the use of VGEIN is covered
+further in <<hinterruptregs>>.
+
+Field HU (Hypervisor in U-mode) controls whether the virtual-machine
+load/store instructions, HLV, HLVX, and HSV, can be used also in U-mode.
+When HU=1, these instructions can be executed in U-mode the same as in
+HS-mode. When HU=0, all hypervisor instructions cause an
+illegal-instruction exception in U-mode.
+
+[NOTE]
+====
+The HU bit allows a portion of a hypervisor to be run in U-mode for
+greater protection against software bugs, while still retaining access
+to a virtual machine’s memory.
+====
+
+The SPV bit (Supervisor Previous Virtualization mode) is written by the
+implementation whenever a trap is taken into HS-mode. Just as the SPP
+bit in `sstatus` is set to the (nominal) privilege mode at the time of
+the trap, the SPV bit in `hstatus` is set to the value of the
+virtualization mode V at the time of the trap. When an SRET instruction
+is executed when V=0, V is set to SPV.
+
+When V=1 and a trap is taken into HS-mode, bit SPVP (Supervisor Previous
+Virtual Privilege) is set to the nominal privilege mode at the time of
+the trap, the same as `sstatus`.SPP. But if V=0 before a trap, SPVP is
+left unchanged on trap entry. SPVP controls the effective privilege of
+explicit memory accesses made by the virtual-machine load/store
+instructions, HLV, HLVX, and HSV.
+
+[NOTE]
+====
+Without SPVP, if instructions HLV, HLVX, and HSV looked instead to
+`sstatus`.SPP for the effective privilege of their memory accesses,
+then, even with HU=1, U-mode could not access virtual machine memory at
+VS-level, because to enter U-mode using SRET always leaves SPP=0. Unlike
+SPP, field SPVP is untouched by transitions back-and-forth between
+HS-mode and U-mode.
+====
+
+Field GVA (Guest Virtual Address) is written by the implementation
+whenever a trap is taken into HS-mode. For any trap (breakpoint, address
+misaligned, access fault, page fault, or guest-page fault) that writes a
+guest virtual address to `stval`, GVA is set to 1. For any other trap
+into HS-mode, GVA is set to 0.
+
+[NOTE]
+====
+For breakpoint and memory access traps that write a nonzero value to
+`stval`, GVA is redundant with field SPV (the two bits are set the same)
+except when the explicit memory access of an HLV, HLVX, or HSV
+instruction causes a fault. In that case, SPV=0 but GVA=1.
+====
+
+The VSBE bit is a *WARL* field that controls the endianness of explicit memory
+accesses made from VS-mode. If VSBE=0, explicit load and store memory
+accesses made from VS-mode are little-endian, and if VSBE=1, they are
+big-endian. VSBE also controls the endianness of all implicit accesses
+to VS-level memory management data structures, such as page tables. An
+implementation may make VSBE a read-only field that always specifies the
+same endianness as HS-mode.
+
+==== Hypervisor Trap Delegation (`hedeleg` and `hideleg`) Registers
+
+Register `hedeleg` is a 64-bit read/write register, formatted as shown in
+<<hedelegreg>>.
+Register `hideleg` is an HSXLEN-bit read/write register, formatted as shown in
+<<hidelegreg>>.
+By default, all traps at
+any privilege level are handled in M-mode, though M-mode usually uses
+the `medeleg` and `mideleg` CSRs to delegate some traps to HS-mode. The
+`hedeleg` and `hideleg` CSRs allow these traps to be further delegated
+to a VS-mode guest; their layout is the same as `medeleg` and `mideleg`.
+
+[[hedelegreg]]
+.Hypervisor exception delegation register (`hedeleg`).
+include::images/bytefield/hedelegreg.edn[]
+
+[[hidelegreg]]
+.Hypervisor interrupt delegation register (`hideleg`).
+include::images/bytefield/hidelegreg.edn[]
+
+A synchronous trap that has been delegated to HS-mode (using `medeleg`)
+is further delegated to VS-mode if V=1 before the trap and the
+corresponding `hedeleg` bit is set. Each bit of `hedeleg` shall be
+either writable or read-only zero. Many bits of `hedeleg` are required
+specifically to be writable or zero, as enumerated in
+<<hedeleg-bits>>. Bit 0, corresponding to
+instruction address-misaligned exceptions, must be writable if
+IALIGN=32.
+
+[NOTE]
+====
+Requiring that certain bits of `hedeleg` be writable reduces some of the
+burden on a hypervisor to handle variations of implementation.
+====
+
+When XLEN=32, `hedelegh` is a 32-bit read/write register
+that aliases bits 63:32 of `hedeleg`.
+Register `hedelegh` does not exist when XLEN=64.
+
+An interrupt that has been delegated to HS-mode (using `mideleg`) is
+further delegated to VS-mode if the corresponding `hideleg` bit is set.
+Among bits 15:0 of `hideleg`, bits 10, 6, and 2 (corresponding to the
+standard VS-level interrupts) are writable, and bits 12, 9, 5, and 1
+(corresponding to the standard S-level interrupts) are read-only zeros.
+
+When a virtual supervisor external interrupt (code 10) is delegated to
+VS-mode, it is automatically translated by the machine into a supervisor
+external interrupt (code 9) for VS-mode, including the value written to
+`vscause` on an interrupt trap. Likewise, a virtual supervisor timer
+interrupt (6) is translated into a supervisor timer interrupt (5) for
+VS-mode, and a virtual supervisor software interrupt (2) is translated
+into a supervisor software interrupt (1) for VS-mode. Similar
+translations may or may not be done for platform interrupt
+causes (codes 16 and above).
+
+[[hedeleg-bits]]
+.Bits of `hedeleg` that must be writable or must be read-only zero.
+[%autowidth,float="center",align="center",cols=">,<,<",options="header"]
+|===
+|Bit |Attribute |Corresponding Exception
+|0 +
+1 +
+2 +
+3 +
+4 +
+5 +
+6 +
+7 +
+8 +
+9 +
+10 +
+11 +
+12 +
+13 +
+15 +
+16 +
+18 +
+19 +
+20 +
+21 +
+22 +
+23
+|(See text) +
+Writable +
+Writable +
+Writable +
+Writable +
+Writable +
+Writable +
+Writable +
+Writable +
+Read-only 0 +
+Read-only 0 +
+Read-only 0 +
+Writable +
+Writable +
+Writable +
+Read-only 0 +
+Writable +
+Writable +
+Read-only 0 +
+Read-only 0 +
+Read-only 0 +
+Read-only 0
+|Instruction address misaligned +
+Instruction access fault +
+Illegal instruction +
+Breakpoint +
+Load address misaligned +
+Load access fault +
+Store/AMO address misaligned +
+Store/AMO access fault +
+Environment call from U-mode or VU-mode +
+Environment call from HS-mode +
+Environment call from VS-mode +
+Environment call from M-mode +
+Instruction page fault +
+Load page fault +
+Store/AMO page fault +
+Double trap +
+Software check +
+Hardware error +
+Instruction guest-page fault +
+Load guest-page fault +
+Virtual instruction +
+Store/AMO guest-page fault
+|===
+
+[[hinterruptregs]]
+==== Hypervisor Interrupt (`hvip`, `hip`, and `hie`) Registers
+
+Register `hvip` is an HSXLEN-bit read/write register that a hypervisor
+can write to indicate virtual interrupts intended for VS-mode. Bits of
+`hvip` that are not writable are read-only zeros.
+
+[[hvipreg]]
+.Hypervisor virtual-interrupt-pending register(`hvip`).
+include::images/bytefield/hvipreg.edn[]
+
+The standard portion (bits 15:0) of `hvip` is formatted as shown in
+<<hvipreg-standard>>. Bits VSEIP, VSTIP,
+and VSSIP of `hvip` are writable. Setting VSEIP=1 in `hvip` asserts a
+VS-level external interrupt; setting VSTIP asserts a VS-level timer
+interrupt; and setting VSSIP asserts a VS-level software interrupt.
+
+[[hvipreg-standard]]
+.Standard portion (bits 15:0) of `hvip`.
+include::images/bytefield/hvipreg-standard.edn[]
+
+Registers `hip` and `hie` are HSXLEN-bit read/write registers that
+supplement HS-level’s `sip` and `sie` respectively. The `hip` register
+indicates pending VS-level and hypervisor-specific interrupts, while
+`hie` contains enable bits for the same interrupts.
+
+[[hipreg]]
+.Hypervisor interrupt-pending register (`hip`).
+include::images/bytefield/hipreg.edn[]
+
+[[hiereg]]
+.Hypervisor interrupt-enable register (`hie`).
+include::images/bytefield/hiereg.edn[]
+
+For each writable bit in `sie`, the corresponding bit shall be read-only
+zero in both `hip` and `hie`. Hence, the nonzero bits in `sie` and `hie`
+are always mutually exclusive, and likewise for `sip` and `hip`.
+
+[NOTE]
+====
+The active bits of `hip` and `hie` cannot be placed in HS-level’s `sip`
+and `sie` because doing so would make it impossible for software to
+emulate the hypervisor extension on platforms that do not implement it
+in hardware.
+====
+
+An interrupt _i_ will trap to HS-mode whenever all of the following are
+true: (a) either the current operating mode is HS-mode and the SIE bit
+in the `sstatus` register is set, or the current operating mode has less
+privilege than HS-mode; (b) bit _i_ is set in both `sip` and `sie`, or
+in both `hip` and `hie`; and (c) bit _i_ is not set in `hideleg`.
+
+If bit _i_ of `sie` is read-only zero, the same bit in register `hip`
+may be writable or may be read-only. When bit _i_ in `hip` is writable,
+a pending interrupt _i_ can be cleared by writing 0 to this bit. If
+interrupt _i_ can become pending in `hip` but bit _i_ in `hip` is
+read-only, then either the interrupt can be cleared by clearing bit _i_
+of `hvip`, or the implementation must provide some other mechanism for
+clearing the pending interrupt (which may involve a call to the
+execution environment).
+
+A bit in `hie` shall be writable if the corresponding interrupt can ever
+become pending in `hip`. Bits of `hie` that are not writable shall be
+read-only zero.
+
+The standard portions (bits 15:0) of registers `hip` and `hie` are
+formatted as shown in <<hipreg-standard>> and <<hiereg-standard>> respectively.
+
+[[hipreg-standard]]
+.Standard portion (bits 15:0) of `hip`.
+include::images/bytefield/hipreg-standard.edn[]
+
+[[hiereg-standard]]
+.Standard portion (bits 15:0) of `hie`.
+include::images/bytefield/hiereg-standard.edn[]
+
+
+Bits `hip`.SGEIP and `hie`.SGEIE are the interrupt-pending and
+interrupt-enable bits for guest external interrupts at supervisor level
+(HS-level). SGEIP is read-only in `hip`, and is 1 if and only if the
+bitwise logical-AND of CSRs `hgeip` and `hgeie` is nonzero in any bit.
+(See <<hgeinterruptregs>>.)
+
+Bits `hip`.VSEIP and `hie`.VSEIE are the interrupt-pending and
+interrupt-enable bits for VS-level external interrupts. VSEIP is
+read-only in `hip`, and is the logical-OR of these interrupt sources:
+
+* bit VSEIP of `hvip`;
+* the bit of `hgeip` selected by `hstatus`.VGEIN; and
+* any other platform-specific external interrupt signal directed to
+VS-level.
+
+Bits `hip`.VSTIP and `hie`.VSTIE are the interrupt-pending and
+interrupt-enable bits for VS-level timer interrupts. VSTIP is read-only
+in `hip`, and is the logical-OR of `hvip`.VSTIP and any other
+platform-specific timer interrupt signal directed to VS-level.
+
+Bits `hip`.VSSIP and `hie`.VSSIE are the interrupt-pending and
+interrupt-enable bits for VS-level software interrupts. VSSIP in `hip`
+is an alias (writable) of the same bit in `hvip`.
+
+Multiple simultaneous interrupts destined for HS-mode are handled in the
+following decreasing priority order: SEI, SSI, STI, SGEI, VSEI, VSSI,
+VSTI, LCOFI.
+
+[[hgeinterruptregs]]
+==== Hypervisor Guest External Interrupt Registers (`hgeip` and `hgeie`)
+
+The `hgeip` register is an HSXLEN-bit read-only register, formatted as
+shown in <<hgeipreg>>, that indicates pending guest
+external interrupts for this hart. The `hgeie` register is an HSXLEN-bit
+read/write register, formatted as shown in
+<<hgeiereg>>, that contains enable bits for the
+guest external interrupts at this hart. Guest external interrupt number
+_i_ corresponds with bit _i_ in both `hgeip` and `hgeie`.
+
+[[hgeipreg]]
+.Hypervisor guest external interrupt-pending register (`hgeip`).
+include::images/bytefield/hgeipreg.edn[]
+
+
+[[hgeiereg]]
+.Hypervisor guest external interrupt-enable register (`hgeie`).
+include::images/bytefield/hgeiereg.edn[]
+
+Guest external interrupts represent interrupts directed to individual
+virtual machines at VS-level. If a RISC-V platform supports placing a
+physical device under the direct control of a guest OS with minimal
+hypervisor intervention (known as _pass-through_ or _direct assignment_
+between a virtual machine and the physical device), then, in such
+circumstance, interrupts from the device are intended for a specific
+virtual machine. Each bit of `hgeip` summarizes _all_ pending interrupts
+directed to one virtual hart, as collected and reported by an interrupt
+controller. To distinguish specific pending interrupts from multiple
+devices, software must query the interrupt controller.
+
+[NOTE]
+====
+Support for guest external interrupts requires an interrupt controller
+that can collect virtual-machine-directed interrupts separately from
+other interrupts.
+====
+
+The number of bits implemented in `hgeip` and `hgeie` for guest external
+interrupts is UNSPECIFIED and may be zero. This number is known as _GEILEN_. The
+least-significant bits are implemented first, apart from bit 0. Hence,
+if GEILEN is nonzero, bits GEILEN:1 shall be writable in `hgeie`, and
+all other bit positions shall be read-only zeros in both `hgeip` and
+`hgeie`.
+
+[NOTE]
+====
+The set of guest external interrupts received and handled at one
+physical hart may differ from those received at other harts. Guest
+external interrupt number _i_ at one physical hart is typically expected
+not to be the same as guest external interrupt _i_ at any other hart.
+For any one physical hart, the maximum number of virtual harts that may
+directly receive guest external interrupts is limited by GEILEN. The
+maximum this number can be for any implementation is 31 for RV32 and 63
+for RV64, per physical hart.
+
+A hypervisor is always free to _emulate_ devices for any number of
+virtual harts without being limited by GEILEN. Only direct pass-through
+(direct assignment) of interrupts is affected by the GEILEN limit, and
+the limit is on the number of virtual harts receiving such interrupts,
+not the number of distinct interrupts received. The number of distinct
+interrupts a single virtual hart may receive is determined by the
+interrupt controller.
+====
+
+Register `hgeie` selects the subset of guest external interrupts that
+cause a supervisor-level (HS-level) guest external interrupt. The enable
+bits in `hgeie` do not affect the VS-level external interrupt signal
+selected from `hgeip` by `hstatus`.VGEIN.
+
+[[sec:henvcfg]]
+==== Hypervisor Environment Configuration Register (`henvcfg`)
+
+The `henvcfg` CSR is a 64-bit read/write register, formatted
+as shown in <<henvcfg>>, that controls
+certain characteristics of the execution environment when virtualization
+mode V=1.
+
+[[henvcfg]]
+.Hypervisor environment configuration register (`henvcfg`).
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'FIOM'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'LPE'},
+ {bits: 1, name: 'SSE'},
+ {bits: 2, name: 'CBIE'},
+ {bits: 1, name: 'CBCFE'},
+ {bits: 1, name: 'CBZE'},
+ {bits: 24, name: 'WPRI'},
+ {bits: 2, name: 'PMM'},
+ {bits: 25, name: 'WPRI'},
+ {bits: 1, name: 'DTE'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'ADUE'},
+ {bits: 1, name: 'PBMTE'},
+ {bits: 1, name: 'STCE'},
+], config:{lanes: 4, hspace:1024}}
+....
+
+If bit FIOM (Fence of I/O implies Memory) is set to one in `henvcfg`,
+FENCE instructions executed when V=1 are modified so the requirement to
+order accesses to device I/O implies also the requirement to order main
+memory accesses. <<henvcfg-FIOM>> details the modified
+interpretation of FENCE instruction bits PI, PO, SI, and SO when FIOM=1
+and V=1.
+
+Similarly, when FIOM=1 and V=1, if an atomic instruction that accesses a
+region ordered as device I/O has its _aq_ and/or _rl_ bit set, then that
+instruction is ordered as though it accesses both device I/O and memory.
+
+[[henvcfg-FIOM]]
+.Modified interpretation of FENCE predecessor and successor sets when FIOM=1 and virtualization mode V=1.
+[%autowidth,float="center",align="center",cols="^,<",options="header"]
+|===
+|Instruction bit |Meaning when set
+|PI +
+PO
+|Predecessor device input and memory reads (PR implied) +
+Predecessor device output and memory writes (PW implied)
+|SI +
+SO
+|Successor device input and memory reads (SR implied) +
+Successor device output and memory writes (SW implied)
+|===
+
+The PBMTE bit controls whether the Svpbmt extension is available for use
+in VS-stage address translation. When PBMTE=1, Svpbmt is available for
+VS-stage address translation. When PBMTE=0, the implementation behaves
+as though Svpbmt were not implemented for VS-stage address translation.
+If Svpbmt is not implemented, PBMTE is read-only zero.
+
+If the Svadu extension is implemented, the ADUE bit controls whether hardware
+updating of PTE A/D bits is enabled for VS-stage address translation.
+When ADUE=1, hardware updating of PTE A/D bits is enabled during VS-stage
+address translation, and the implementation behaves as though the Svade
+extension were not implemented for VS-mode address translation.
+When ADUE=0, the implementation behaves as though Svade were implemented for
+VS-stage address translation.
+If Svadu is not implemented, ADUE is read-only zero.
+
+The definition of the STCE field is furnished by the Sstc extension.
+
+The definition of the CBZE field is furnished by the Zicboz extension.
+
+The definitions of the CBCFE and CBIE fields are furnished by the Zicbom extension.
+
+The definition of the PMM field is furnished by the Ssnpm extension.
+
+The Zicfilp extension adds the `LPE` field in `henvcfg`. When the `LPE` field
+is set to 1, the Zicfilp extension is enabled in VS-mode. When the `LPE` field
+is 0, the Zicfilp extension is not enabled in VS-mode and the following rules
+apply to VS-mode:
+
+* The hart does not update the `ELP` state; it remains as `NO_LP_EXPECTED`.
+* The `LPAD` instruction operates as a no-op.
+
+The Zicfiss extension adds the `SSE` field in `henvcfg`. If the `SSE` field is
+set to 1, the Zicfiss extension is activated in VS-mode. When the `SSE` field is
+0, the Zicfiss extension remains inactive in VS-mode, and the following rules
+apply when `V=1`:
+
+* 32-bit Zicfiss instructions will revert to their behavior as defined by Zimop.
+* 16-bit Zicfiss instructions will revert to their behavior as defined by Zcmop.
+* The `pte.xwr=010b` encoding in VS-stage page tables becomes reserved.
+* The `senvcfg.SSE` field will read as zero and is read-only.
+* When `menvcfg.SSE` is one, `SSAMOSWAP.W/D` raises a virtual-instruction
+ exception.
+
+The Ssdbltrp extension adds the double-trap-enable (`DTE`) field in `henvcfg`.
+When `henvcfg.DTE` is zero, the implementation behaves as though Ssdbltrp is not
+implemented for VS-mode and the `vsstatus.SDT` bit is read-only zero.
+
+When XLEN=32, `henvcfgh` is a
+32-bit read/write register that aliases bits 63:32
+of `henvcfg`. Register `henvcfgh` does not exist when
+XLEN=64.
+
+==== Hypervisor Counter-Enable (`hcounteren`) Register
+
+The counter-enable register `hcounteren` is a 32-bit register that
+controls the availability of the hardware performance monitoring
+counters to the guest virtual machine.
+
+.Hypervisor counter-enable register (`hcounteren`).
+include::images/bytefield/hcounterenreg.edn[]
+
+When the CY, TM, IR, or HPM__n__ bit in the `hcounteren` register is
+clear, attempts to read the `cycle`, `time`, `instret`, or
+`hpmcounter` _n_ register while V=1 will cause a virtual-instruction
+exception if the same bit in `mcounteren` is 1. When one of these bits
+is set, access to the corresponding register is permitted when V=1,
+unless prevented for some other reason. In VU-mode, a counter is not
+readable unless the applicable bits are set in both `hcounteren` and
+`scounteren`.
+
+`hcounteren` must be implemented. However, any of the bits may be
+read-only zero, indicating reads to the corresponding counter will cause
+an exception when V=1. Hence, they are effectively *WARL* fields.
+
+==== Hypervisor Time Delta (`htimedelta`) Register
+
+The `htimedelta` CSR is a 64-bit read/write register that contains the delta
+between the value of the `time` CSR and the value returned in VS-mode or
+VU-mode. That is, reading the `time` CSR in VS or VU mode returns the
+sum of the contents of `htimedelta` and the actual value of `time`.
+
+[NOTE]
+====
+Because overflow is ignored when summing `htimedelta` and `time`, large
+values of `htimedelta` may be used to represent negative time offsets.
+====
+
+.Hypervisor time delta register.
+include::images/bytefield/htimedelta.edn[]
+
+When XLEN=32, `htimedeltah` is a 32-bit read/write register
+that aliases bits 63:32 of `htimedelta`.
+Register `htimedeltah` does not exist when XLEN=64.
+
+If the `time` CSR is implemented, `htimedelta` (and `htimedeltah` for XLEN=32)
+must be implemented.
+
+==== Hypervisor Trap Value (`htval`) Register
+
+The `htval` register is an HSXLEN-bit read/write register formatted as
+shown in <<htvalreg>>. When a trap is taken into
+HS-mode, `htval` is written with additional exception-specific
+information, alongside `stval`, to assist software in handling the trap.
+
+[[htvalreg]]
+.Hypervisor trap value register (`htval`).
+include::images/bytefield/htvalreg.edn[]
+
+When a guest-page-fault trap is taken into HS-mode, `htval` is written
+with either zero or the guest physical address that faulted, shifted
+right by 2 bits. For other traps, `htval` is set to zero, but a future
+standard or extension may redefine `htval's` setting for other traps.
+
+A guest-page fault may arise due to an implicit memory access during
+first-stage (VS-stage) address translation, in which case a guest
+physical address written to `htval` is that of the implicit memory
+access that faulted—for example, the address of a VS-level page table
+entry that could not be read. (The guest physical address corresponding
+to the original virtual address is unknown when VS-stage translation
+fails to complete.) Additional information is provided in CSR `htinst`
+to disambiguate such situations.
+
+Otherwise, for misaligned loads and stores that cause guest-page faults,
+a nonzero guest physical address in `htval` corresponds to the faulting
+portion of the access as indicated by the virtual address in `stval`.
+For instruction guest-page faults on systems with variable-length
+instructions, a nonzero `htval` corresponds to the faulting portion of
+the instruction as indicated by the virtual address in `stval`.
+
+[NOTE]
+====
+A guest physical address written to `htval` is shifted right by 2 bits
+to accommodate addresses wider than the current XLEN. For RV32, the
+hypervisor extension permits guest physical addresses as wide as 34
+bits, and `htval` reports bits 33:2 of the address. This shift-by-2
+encoding of guest physical addresses matches the encoding of physical
+addresses in PMP address registers (<<pmp>>) and in
+page table entries (<<sv32>>, <<sv39>>, <<sv48>>, and <<sv57>>).
+
+If the least-significant two bits of a faulting guest physical address
+are needed, these bits are ordinarily the same as the least-significant
+two bits of the faulting virtual address in `stval`. For faults due to
+implicit memory accesses for VS-stage address translation, the
+least-significant two bits are instead zeros. These cases can be
+distinguished using the value provided in register `htinst`.
+====
+
+`htval` is a *WARL* register that must be able to hold zero and may be capable
+of holding only an arbitrary subset of other 2-bit-shifted guest
+physical addresses, if any.
+
+[NOTE]
+====
+Unless it has reason to assume otherwise (such as a platform standard),
+software that writes a value to `htval` should read back from `htval` to
+confirm the stored value.
+====
+
+==== Hypervisor Trap Instruction (`htinst`) Register
+
+The `htinst` register is an HSXLEN-bit read/write register formatted as
+shown in <<htinstreg>>. When a trap is taken into
+HS-mode, `htinst` is written with a value that, if nonzero, provides
+information about the instruction that trapped, to assist software in
+handling the trap. The values that may be written to `htinst` on a trap
+are documented in <<tinst-vals>>.
+
+[[htinstreg]]
+.Hypervisor trap instruction (`htinst`) register.
+include::images/bytefield/htinstreg.edn[]
+
+`htinst` is a *WARL* register that need only be able to hold the values that
+the implementation may automatically write to it on a trap.
+
+[[hgatp]]
+==== Hypervisor Guest Address Translation and Protection (`hgatp`) Register
+
+The `hgatp` register is an HSXLEN-bit read/write register, formatted as
+shown in <<rv32hgatp>> for HSXLEN=32 and
+<<rv64hgatp>> for HSXLEN=64, which controls
+G-stage address translation and protection, the second stage of
+two-stage translation for guest virtual addresses (see
+<<two-stage-translation>>). Similar to CSR `satp`, this
+register holds the physical page number (PPN) of the guest-physical root
+page table; a virtual machine identifier (VMID), which facilitates
+address-translation fences on a per-virtual-machine basis; and the MODE
+field, which selects the address-translation scheme for guest physical
+addresses. When `mstatus`.TVM=1, attempts to read or write `hgatp` while
+executing in HS-mode will raise an illegal-instruction exception.
+
+[[rv32hgatp]]
+.Hypervisor guest address translation and protection register `hgatp` when HSXLEN=32.
+include::images/bytefield/rv32hgatp.edn[]
+
+[[rv64hgatp]]
+.Hypervisor guest address translation and protection register `hgatp` when HSXLEN=64 for MODE values Bare, Sv39x4, Sv48x4, and Sv57x4.
+include::images/bytefield/rv64hgatp.edn[]
+
+<<hgatp-mode>> shows the encodings of the MODE field when
+HSXLEN=32 and HSXLEN=64. When MODE=Bare, guest physical addresses are
+equal to supervisor physical addresses, and there is no further memory
+protection for a guest virtual machine beyond the physical memory
+protection scheme described in <<pmp>>. In this
+case, software must write zero to the remaining fields in `hgatp`.
+Attempting to select MODE=Bare with a nonzero pattern in the remaining fields
+has an UNSPECIFIED effect on the value that the remaining fields assume and an
+UNSPECIFIED effect on G-stage address translation and protection behavior.
+
+When HSXLEN=32, the only other valid setting for MODE is Sv32x4, which
+is a modification of the usual Sv32 paged virtual-memory scheme,
+extended to support 34-bit guest physical addresses. When HSXLEN=64,
+modes Sv39x4, Sv48x4, and Sv57x4 are defined as modifications of the
+Sv39, Sv48, and Sv57 paged virtual-memory schemes. All of these paged
+virtual-memory schemes are described in
+<<guest-addr-translation>>.
+
+The remaining MODE settings when HSXLEN=64 are reserved for future use
+and may define different interpretations of the other fields in `hgatp`.
+
+[[hgatp-mode]]
+.Encoding of `hgatp` MODE field.
+[%autowidth,float="center",align="center",cols="^,^,<",options="header"]
+|===
+3+|HSXLEN=32
+|Value |Name |Description
+|0 +
+1
+|Bare +
+Sv32x4
+|No translation or protection. +
+Page-based 34-bit virtual addressing (2-bit extension of
+Sv32).
+3+s|HSXLEN=64
+|Value |Name |Description
+|0 +
+1-7 +
+8 +
+9 +
+10 +
+11-15
+|Bare +
+— +
+Sv39x4 +
+Sv48x4 +
+Sv57x4 +
+—
+|No translation or protection. +
+_Reserved_ +
+Page-based 41-bit virtual addressing (2-bit extension of
+Sv39). +
+Page-based 50-bit virtual addressing (2-bit extension of
+Sv48). +
+Page-based 59-bit virtual addressing (2-bit extension of
+Sv57). +
+_Reserved_
+|===
+
+Implementations are not required to support all defined MODE settings
+when HSXLEN=64.
+
+A write to `hgatp` with an unsupported MODE value is not ignored as it
+is for `satp`. Instead, the fields of `hgatp` are *WARL* in the normal way,
+when so indicated.
+
+As explained in <<guest-addr-translation>>, for the
+paged virtual-memory schemes (Sv32x4, Sv39x4, Sv48x4, and Sv57x4), the
+root page table is 16 KiB and must be aligned to a 16-KiB boundary. In
+these modes, the lowest two bits of the physical page number (PPN) in
+`hgatp` always read as zeros. An implementation that supports only the
+defined paged virtual-memory schemes and/or Bare may make PPN[1:0]
+read-only zero.
+
+The number of VMID bits is UNSPECIFIED and may be zero. The number of implemented
+VMID bits, termed _VMIDLEN_, may be determined by writing one to every
+bit position in the VMID field, then reading back the value in `hgatp`
+to see which bit positions in the VMID field hold a one. The
+least-significant bits of VMID are implemented first: that is, if
+VMIDLEN > 0, VMID[VMIDLEN-1:0] is writable. The maximal
+value of VMIDLEN, termed VMIDMAX, is 7 for Sv32x4 or 14 for Sv39x4,
+Sv48x4, and Sv57x4.
+
+The `hgatp` register is considered _active_ for the purposes of the
+address-translation algorithm _unless_ the effective privilege mode is U
+and `hstatus`.HU=0.
+
+[NOTE]
+====
+This definition simplifies the implementation of speculative execution
+of HLV, HLVX, and HSV instructions.
+====
+
+Note that writing `hgatp` does not imply any ordering constraints
+between page-table updates and subsequent G-stage address translations.
+If the new virtual machine’s guest physical page tables have been
+modified, or if a VMID is reused, it may be necessary to execute an
+HFENCE.GVMA instruction (see <<hfence.vma>>) before or
+after writing `hgatp`.
+
+[[vsstatus]]
+==== Virtual Supervisor Status (`vsstatus`) Register
+
+The `vsstatus` register is a VSXLEN-bit read/write register that is
+VS-mode’s version of supervisor register `sstatus`, formatted as shown
+in <<vsstatusreg-rv32>> when VSXLEN=32 and
+<<vsstatusreg>> when VSXLEN=64. When V=1,
+`vsstatus` substitutes for the usual `sstatus`, so instructions that
+normally read or modify `sstatus` actually access `vsstatus` instead.
+
+[[vsstatusreg-rv32]]
+.Virtual supervisor status (`vsstatus`) register when VSXLEN=32.
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SIE'},
+ {bits: 3, name: 'WPRI'},
+ {bits: 1, name: 'SPIE'},
+ {bits: 1, name: 'UBE'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SPP'},
+ {bits: 2, name: 'VS[1:0]'},
+ {bits: 2, name: 'WPRI'},
+ {bits: 2, name: 'FS[1:0]'},
+ {bits: 2, name: 'XS[1:0]'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SUM'},
+ {bits: 1, name: 'MXR'},
+ {bits: 3, name: 'WPRI'},
+ {bits: 1, name: 'SPELP'},
+ {bits: 1, name: 'SDT'},
+ {bits: 6, name: 'WPRI'},
+ {bits: 1, name: 'SD'},
+], config:{lanes: 2, hspace:1024}}
+....
+
+[[vsstatusreg]]
+.Virtual supervisor status (`vsstatus`) register when VSXLEN=64.
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SIE'},
+ {bits: 3, name: 'WPRI'},
+ {bits: 1, name: 'SPIE'},
+ {bits: 1, name: 'UBE'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SPP'},
+ {bits: 2, name: 'VS[1:0]'},
+ {bits: 2, name: 'WPRI'},
+ {bits: 2, name: 'FS[1:0]'},
+ {bits: 2, name: 'XS[1:0]'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SUM'},
+ {bits: 1, name: 'MXR'},
+ {bits: 3, name: 'WPRI'},
+ {bits: 1, name: 'SPELP'},
+ {bits: 1, name: 'SDT'},
+ {bits: 7, name: 'WPRI'},
+ {bits: 2, name: 'UXL[1:0]'},
+ {bits: 29, name: 'WPRI'},
+ {bits: 1, name: 'SD'},
+], config:{lanes: 4, hspace:1024}}
+....
+
+The UXL field controls the effective XLEN for VU-mode, which may differ
+from the XLEN for VS-mode (VSXLEN). When VSXLEN=32, the UXL field does
+not exist, and VU-mode XLEN=32. When VSXLEN=64, UXL is a *WARL* field that is
+encoded the same as the MXL field of `misa`, shown in <<misabase>>. In particular, an implementation may make UXL be a read-only copy of field VSXL of `hstatus`, forcing VU-mode XLEN=VSXLEN.
+
+If VSXLEN is changed from 32 to a wider width, and if field UXL is not
+restricted to a single value, it gets the value corresponding to the
+widest supported width not wider than the new VSXLEN.
+
+When V=1, both `vsstatus`.FS and the HS-level `sstatus`.FS are in
+effect. Attempts to execute a floating-point instruction when either
+field is 0 (Off) raise an illegal-instruction exception. Modifying the
+floating-point state when V=1 causes both fields to be set to 3 (Dirty).
+
+[NOTE]
+====
+For a hypervisor to benefit from the extension context status, it must
+have its own copy in the HS-level `sstatus`, maintained independently of
+a guest OS running in VS-mode. While a version of the extension context
+status obviously must exist in `vsstatus` for VS-mode, a hypervisor
+cannot rely on this version being maintained correctly, given that
+VS-level software can change `vsstatus`.FS arbitrarily. If the HS-level
+`sstatus`.FS were not independently active and maintained by the
+hardware in parallel with `vsstatus`.FS while V=1, hypervisors would
+always be forced to conservatively swap all floating-point state when
+context-switching between virtual machines.
+====
+
+Similarly, when V=1, both `vsstatus`.VS and the HS-level `sstatus`.VS
+are in effect. Attempts to execute a vector instruction when either
+field is 0 (Off) raise an illegal-instruction exception. Modifying the
+vector state when V=1 causes both fields to be set to 3 (Dirty).
+
+Read-only fields SD and XS summarize the extension context status as it
+is visible to VS-mode only. For example, the value of the HS-level
+`sstatus`.FS does not affect `vsstatus`.SD.
+
+An implementation may make field UBE be a read-only copy of
+`hstatus`.VSBE.
+
+When V=0, `vsstatus` does not directly affect the behavior of the
+machine, unless a virtual-machine load/store (HLV, HLVX, or HSV) or the
+MPRV feature in the `mstatus` register is used to execute a load or
+store _as though_ V=1.
+
+The Zicfilp extension adds the `SPELP` field that holds the previous `ELP`, and
+is updated as specified in <<ZICFILP_FORWARD_TRAPS>>. The `SPELP` field is
+encoded as follows:
+
+* 0 - `NO_LP_EXPECTED` - no landing pad instruction expected.
+* 1 - `LP_EXPECTED` - a landing pad instruction is expected.
+
+The Ssdbltrp adds an S-mode-disable-trap (`SDT`) field extension to address
+double trap (See <<supv-double-trap>>) in VS-mode.
+
+==== Virtual Supervisor Interrupt (`vsip` and `vsie`) Registers
+
+The `vsip` and `vsie` registers are VSXLEN-bit read/write registers that
+are VS-mode’s versions of supervisor CSRs `sip` and `sie`, formatted as
+shown in <<vsipreg>> and <<vsiereg>>
+respectively. When V=1, `vsip` and `vsie` substitute for the usual `sip`
+and `sie`, so instructions that normally read or modify `sip`/`sie`
+actually access `vsip`/`vsie` instead. However, interrupts directed to
+HS-level continue to be indicated in the HS-level `sip` register, not in
+`vsip`, when V=1.
+
+[[vsipreg]]
+.Virtual supervisor interrupt-pending register (`vsip`).
+include::images/bytefield/vsipreg.edn[]
+
+[[vsiereg]]
+.Virtual supervisor interrupt-enable register (`vsie`).
+include::images/bytefield/vsiereg.edn[]
+
+The standard portions (bits 15:0) of registers `vsip` and `vsie` are
+formatted as shown in <<vsipreg-standard>>
+and <<vsiereg-standard>> respectively.
+
+[[vsipreg-standard]]
+.Standard portion (bits 15:0) of `vsip`.
+include::images/bytefield/vsipreg-standard.edn[]
+
+[[vsiereg-standard]]
+.Standard portion (bits 15:0) of `vsie`.
+include::images/bytefield/vsiereg-standard.edn[]
+
+Extension Shlcofideleg supports delegating LCOFI interrupts to VS-mode.
+If the Shlcofideleg extension is implemented, `hideleg` bit 13 is
+writable; otherwise, it is read-only zero.
+When bit 13 of `hideleg` is zero, `vsip`.LCOFIP and `vsie`.LCOFIE
+are read-only zeros.
+Else, `vsip`.LCOFIP and `vsie`.LCOFIE are aliases of `sip`.LCOFIP
+and `sie`.LCOFIE.
+
+When bit 10 of `hideleg` is zero, `vsip`.SEIP and `vsie`.SEIE are
+read-only zeros. Else, `vsip`.SEIP and `vsie`.SEIE are aliases of
+`hip`.VSEIP and `hie`.VSEIE.
+
+When bit 6 of `hideleg` is zero, `vsip`.STIP and `vsie`.STIE are
+read-only zeros. Else, `vsip`.STIP and `vsie`.STIE are aliases of
+`hip`.VSTIP and `hie`.VSTIE.
+
+When bit 2 of `hideleg` is zero, `vsip`.SSIP and `vsie`.SSIE are
+read-only zeros. Else, `vsip`.SSIP and `vsie`.SSIE are aliases of
+`hip`.VSSIP and `hie`.VSSIE.
+
+==== Virtual Supervisor Trap Vector Base Address (`vstvec`) Register
+
+The `vstvec` register is a VSXLEN-bit read/write register that is
+VS-mode’s version of supervisor register `stvec`, formatted as shown in
+<<vstvecreg>>. When V=1, `vstvec` substitutes for
+the usual `stvec`, so instructions that normally read or modify `stvec`
+actually access `vstvec` instead. When V=0, `vstvec` does not directly
+affect the behavior of the machine.
+
+[[vstvecreg]]
+.Virtual supervisor trap vector base address register `vstvec`.
+include::images/bytefield/vstvecreg.edn[]
+
+==== Virtual Supervisor Scratch (`vsscratch`) Register
+
+The `vsscratch` register is a VSXLEN-bit read/write register that is
+VS-mode’s version of supervisor register `sscratch`, formatted as shown
+in <<vsscratchreg>>. When V=1, `vsscratch`
+substitutes for the usual `sscratch`, so instructions that normally read
+or modify `sscratch` actually access `vsscratch` instead. The contents
+of `vsscratch` never directly affect the behavior of the machine.
+
+[[vsscratchreg]]
+.Virtual supervisor scratch register `vsscratch`.
+include::images/bytefield/vsscratchreg.edn[]
+
+==== Virtual Supervisor Exception Program Counter (`vsepc`) Register
+
+The `vsepc` register is a VSXLEN-bit read/write register that is
+VS-mode’s version of supervisor register `sepc`, formatted as shown in
+<<vsepcreg>>. When V=1, `vsepc` substitutes for the
+usual `sepc`, so instructions that normally read or modify `sepc`
+actually access `vsepc` instead. When V=0, `vsepc` does not directly
+affect the behavior of the machine.
+
+`vsepc` is a *WARL* register that must be able to hold the same set of values
+that `sepc` can hold.
+
+[[vsepcreg]]
+.Virtual supervisor exception program counter (`vsepc`).
+include::images/bytefield/vsepcreg.edn[]
+
+==== Virtual Supervisor Cause (`vscause`) Register
+
+The `vscause` register is a VSXLEN-bit read/write register that is
+VS-mode’s version of supervisor register `scause`, formatted as shown in
+<<vscausereg>>. When V=1, `vscause` substitutes
+for the usual `scause`, so instructions that normally read or modify
+`scause` actually access `vscause` instead. When V=0, `vscause` does not
+directly affect the behavior of the machine.
+
+`vscause` is a *WLRL* register that must be able to hold the same set of
+values that `scause` can hold.
+
+[[vscausereg]]
+.Virtual supervisor cause register (`vscause`).
+include::images/bytefield/vscausereg.edn[]
+
+==== Virtual Supervisor Trap Value (`vstval`) Register
+
+The `vstval` register is a VSXLEN-bit read/write register that is
+VS-mode’s version of supervisor register `stval`, formatted as shown in
+<<vstvalreg>>. When V=1, `vstval` substitutes for
+the usual `stval`, so instructions that normally read or modify `stval`
+actually access `vstval` instead. When V=0, `vstval` does not directly
+affect the behavior of the machine.
+
+`vstval` is a *WARL* register that must be able to hold the same set of values
+that `stval` can hold.
+
+[[vstvalreg]]
+.Virtual supervisor trap value register (`vstval`).
+include::images/bytefield/vstvalreg.edn[]
+
+==== Virtual Supervisor Address Translation and Protection (`vsatp`) Register
+
+The `vsatp` register is a VSXLEN-bit read/write register that is
+VS-mode’s version of supervisor register `satp`, formatted as shown in
+<<rv32vsatpreg>> for VSXLEN=32 and <<rv64vsatpreg>> for VSXLEN=64. When V=1,
+`vsatp` substitutes for the usual `satp`, so instructions that normally
+read or modify `satp` actually access `vsatp` instead. `vsatp` controls
+VS-stage address translation, the first stage of two-stage translation
+for guest virtual addresses (see
+<<two-stage-translation>>).
+
+[[rv32vsatpreg]]
+.Virtual supervisor address translation and protection `vsatp` register when VSXLEN=32.
+include::images/bytefield/rv32vsatpreg.edn[]
+
+[[rv64vsatpreg]]
+.Virtual supervisor address translation and protection `vsatp` register when VSXLEN=64.
+include::images/bytefield/rv64vsatpreg.edn[]
+
+The `vsatp` register is considered _active_ for the purposes of the
+address-translation algorithm _unless_ the effective privilege mode is U
+and `hstatus`.HU=0. However, even when `vsatp` is active, VS-stage
+page-table entries’ A bits must not be set as a result of speculative
+execution, unless the effective privilege mode is VS or VU.
+
+[NOTE]
+====
+In particular, virtual-machine load/store (HLV, HLVX, or HSV)
+instructions that are mispredicted must not cause VS-stage
+A bits to be set.
+====
+
+When V=0, a write to `vsatp` with an unsupported MODE value is either
+ignored as it is for `satp`, or the fields of `vsatp` are treated as *WARL* in
+the normal way. However, when V=1, a write to `satp` with an unsupported
+MODE value _is_ ignored and no write to `vsatp` is effected.
+
+When V=0, `vsatp` does not directly affect the behavior of the machine,
+unless a virtual-machine load/store (HLV, HLVX, or HSV) or the MPRV
+feature in the `mstatus` register is used to execute a load or store _as
+though_ V=1.
+
+=== Hypervisor Instructions
+
+The hypervisor extension adds virtual-machine load and store
+instructions and two privileged fence instructions.
+
+==== Hypervisor Virtual-Machine Load and Store Instructions
+
+include::images/wavedrom/hypv-virt-load-and-store.edn[]
+
+The hypervisor virtual-machine load and store instructions are valid
+only in M-mode or HS-mode, or in U-mode when `hstatus`.HU=1. Each
+instruction performs an explicit memory access with an effective privilege mode
+of VS or VU. The effective privilege mode of the explicit memory access is VU
+when `hstatus`.SPVP=0, and VS when `hstatus`.SPVP=1. As usual for VS-mode and
+VU-mode, two-stage address translation is applied, and
+the HS-level `sstatus`.SUM is ignored. HS-level `sstatus`.MXR makes
+execute-only pages readable by explicit loads for both stages of address translation
+(VS-stage and G-stage), whereas `vsstatus`.MXR affects only the first
+translation stage (VS-stage).
+
+For every RV32I or RV64I load instruction, LB, LBU, LH, LHU, LW, LWU,
+and LD, there is a corresponding virtual-machine load instruction:
+HLV.B, HLV.BU, HLV.H, HLV.HU, HLV.W, HLV.WU, and HLV.D. For every RV32I
+or RV64I store instruction, SB, SH, SW, and SD, there is a corresponding
+virtual-machine store instruction: HSV.B, HSV.H, HSV.W, and HSV.D.
+Instructions HLV.WU, HLV.D, and HSV.D are not valid for RV32, of course.
+
+Instructions HLVX.HU and HLVX.WU are the same as HLV.HU and HLV.WU,
+except that _execute_ permission takes the place of _read_ permission
+during address translation. That is, the memory being read must be
+executable in both stages of address translation, but read permission is
+not required. For the supervisor physical address that results from
+address translation, the supervisor physical memory attributes must
+grant both _execute_ and _read_ permissions. (The _supervisor physical
+memory attributes_ are the machine’s physical memory attributes as
+modified by physical memory protection, <<pmp>>, for
+supervisor level.)
+
+[NOTE]
+====
+HLVX cannot override machine-level physical memory protection (PMP), so
+attempting to read memory that PMP designates as execute-only still
+results in an access-fault exception.
+
+Although HLVX instructions’ explicit memory accesses require execute
+permissions, they still raise the same exceptions as other load
+instructions, rather than raising fetch exceptions instead.
+====
+
+HLVX.WU is valid for RV32, even though LWU and HLV.WU are not. (For
+RV32, HLVX.WU can be considered a variant of HLV.W, as sign extension is
+irrelevant for 32-bit values.)
+
+Attempts to execute a virtual-machine load/store instruction (HLV, HLVX,
+or HSV) when V=1 cause a virtual-instruction exception. Attempts to execute
+one of these same instructions from U-mode when `hstatus`.HU=0 cause an
+illegal-instruction exception.
+
+[[hfence.vma]]
+==== Hypervisor Memory-Management Fence Instructions
+
+include::images/wavedrom/hypv-mm-fence.edn[]
+
+The hypervisor memory-management fence instructions, HFENCE.VVMA and
+HFENCE.GVMA, perform a function similar to SFENCE.VMA
+(<<sfence.vma>>), except applying to the
+VS-level memory-management data structures controlled by CSR `vsatp`
+(HFENCE.VVMA) or the guest-physical memory-management data structures
+controlled by CSR `hgatp` (HFENCE.GVMA). Instruction SFENCE.VMA applies
+only to the memory-management data structures controlled by the current
+`satp` (either the HS-level `satp` when V=0 or `vsatp` when V=1).
+
+HFENCE.VVMA is valid only in M-mode or HS-mode. Its effect is much the
+same as temporarily entering VS-mode and executing SFENCE.VMA. Executing
+an HFENCE.VVMA guarantees that any previous stores already visible to
+the current hart are ordered before all implicit reads by that hart done
+for VS-stage address translation for instructions that
+
+* are subsequent to the HFENCE.VVMA, and
+* execute when `hgatp`.VMID has the same setting as it did when
+HFENCE.VVMA executed.
+
+Implicit reads need not be ordered when `hgatp`.VMID is different than
+at the time HFENCE.VVMA executed. If operand __rs1__≠`x0`, it specifies a single guest virtual address, and if operand __rs2__≠`x0`, it specifies a single guest address-space identifier (ASID).
+
+[NOTE]
+====
+An HFENCE.VVMA instruction applies only to a single virtual machine,
+identified by the setting of `hgatp`.VMID when HFENCE.VVMA executes.
+====
+
+When __rs2__≠`x0`, bits XLEN-1:ASIDMAX of the value held
+in _rs2_ are reserved for future standard use. Until their use is
+defined by a standard extension, they should be zeroed by software and
+ignored by current implementations. Furthermore, if
+ASIDLEN < ASIDMAX, the implementation shall ignore bits
+ASIDMAX-1:ASIDLEN of the value held in _rs2_.
+
+[NOTE]
+====
+Simpler implementations of HFENCE.VVMA can ignore the guest virtual
+address in _rs1_ and the guest ASID value in _rs2_, as well as
+`hgatp`.VMID, and always perform a global fence for the VS-level memory
+management of all virtual machines, or even a global fence for all
+memory-management data structures.
+====
+
+Neither `mstatus`.TVM nor `hstatus`.VTVM causes HFENCE.VVMA to trap.
+
+HFENCE.GVMA is valid only in HS-mode when `mstatus`.TVM=0, or in M-mode
+(irrespective of `mstatus`.TVM). Executing an HFENCE.GVMA instruction
+guarantees that any previous stores already visible to the current hart
+are ordered before all implicit reads by that hart done for G-stage
+address translation for instructions that follow the HFENCE.GVMA. If
+operand __rs1__≠`x0`, it specifies a single guest
+physical address, shifted right by 2 bits, and if operand
+__rs2__≠`x0`, it specifies a single virtual machine
+identifier (VMID).
+
+[NOTE]
+====
+Conceptually, an implementation might contain two address-translation
+caches: one that maps guest virtual addresses to guest physical
+addresses, and another that maps guest physical addresses to supervisor
+physical addresses. HFENCE.GVMA need not flush the former cache, but it
+must flush entries from the latter cache that match the HFENCE.GVMA’s
+address and VMID arguments.
+
+More commonly, implementations contain address-translation caches that
+map guest virtual addresses directly to supervisor physical addresses,
+removing a level of indirection. For such implementations, any entry
+whose guest virtual address maps to a guest physical address that
+matches the HFENCE.GVMA’s address and VMID arguments must be flushed.
+Selectively flushing entries in this fashion requires tagging them with
+the guest physical address, which is costly, and so a common technique
+is to flush all entries that match the HFENCE.GVMA’s VMID argument,
+regardless of the address argument.
+
+***
+
+Like for a guest physical address written to `htval` on a trap, a guest
+physical address specified in _rs1_ is shifted right by 2 bits to
+accommodate addresses wider than the current XLEN.
+====
+
+When __rs2__≠`x0`, bits XLEN-1:VMIDMAX of the value held
+in _rs2_ are reserved for future standard use. Until their use is
+defined by a standard extension, they should be zeroed by software and
+ignored by current implementations. Furthermore, if
+VMIDLEN < VMIDMAX, the implementation shall ignore bits
+VMIDMAX-1:VMIDLEN of the value held in _rs2_.
+
+[NOTE]
+====
+Simpler implementations of HFENCE.GVMA can ignore the guest physical
+address in _rs1_ and the VMID value in _rs2_ and always perform a global
+fence for the guest-physical memory management of all virtual machines,
+or even a global fence for all memory-management data structures.
+====
+
+If `hgatp`.MODE is changed for a given VMID, an HFENCE.GVMA with
+_rs1_=`x0` (and _rs2_ set to either `x0` or the VMID) must be executed
+to order subsequent guest translations with the MODE change—even if the
+old MODE or new MODE is Bare.
+
+Attempts to execute HFENCE.VVMA or HFENCE.GVMA when V=1 cause a
+virtual-instruction exception, while attempts to do the same in U-mode cause an
+illegal-instruction exception. Attempting to execute HFENCE.GVMA in HS-mode
+when `mstatus`.TVM=1 also causes an illegal-instruction exception.
+
+=== Machine-Level CSRs
+
+The hypervisor extension augments or modifies machine CSRs `mstatus`,
+`mstatush`, `mideleg`, `mip`, and `mie`, and adds CSRs `mtval2` and
+`mtinst`.
+
+==== Machine Status (`mstatus` and `mstatush`) Registers
+
+The hypervisor extension adds two fields, MPV and GVA, to the
+machine-level `mstatus` or `mstatush` CSR, and modifies the behavior of
+several existing `mstatus` fields.
+<<hypervisor-mstatus>> shows the modified
+`mstatus` register when the hypervisor extension is implemented and
+MXLEN=64. When MXLEN=32, the hypervisor extension adds MPV and GVA not
+to `mstatus` but to `mstatush`.
+<<hypervisor-mstatush>> shows the
+`mstatush` register when the hypervisor extension is implemented and
+MXLEN=32.
+
+[[hypervisor-mstatus]]
+.Machine status (`mstatus`) register for RV64 when the hypervisor extension is implemented.
+include::images/bytefield/hypv-mstatus.edn[]
+
+[[hypervisor-mstatush]]
+.Additional machine status (`mstatush`) register for RV32 when the hypervisor extension is implemented. The format of `mstatus` is unchanged for RV32.
+include::images/bytefield/hypv-mstatush.edn[]
+
+The MPV bit (Machine Previous Virtualization Mode) is written by the
+implementation whenever a trap is taken into M-mode. Just as the MPP
+field is set to the (nominal) privilege mode at the time of the trap,
+the MPV bit is set to the value of the virtualization mode V at the time
+of the trap. When an MRET instruction is executed, the virtualization
+mode V is set to MPV, unless MPP=3, in which case V remains 0.
+
+Field GVA (Guest Virtual Address) is written by the implementation
+whenever a trap is taken into M-mode. For any trap (breakpoint, address
+misaligned, access fault, page fault, or guest-page fault) that writes a
+guest virtual address to `mtval`, GVA is set to 1. For any other trap
+into M-mode, GVA is set to 0.
+
+The TSR and TVM fields of `mstatus` affect execution only in HS-mode,
+not in VS-mode. The TW field affects execution in all modes except
+M-mode.
+
+Setting TVM=1 prevents HS-mode from accessing `hgatp` or executing
+HFENCE.GVMA or HINVAL.GVMA, but has no effect on accesses to `vsatp` or
+instructions HFENCE.VVMA or HINVAL.VVMA.
+
+[NOTE]
+====
+TVM exists in `mstatus` to allow machine-level software to modify the
+address translations managed by a supervisor-level OS, usually for the
+purpose of inserting another stage of address translation below that
+controlled by the OS. The instruction traps enabled by TVM=1 permit
+machine level to co-opt both `satp` and `hgatp` and substitute _shadow
+page tables_ that merge the OS’s chosen page translations with M-level’s
+lower-stage translations, all without the OS being aware. M-level
+software needs this ability not only to emulate the hypervisor extension
+if not already supported, but also to emulate any future RISC-V
+extensions that may modify or add address translation stages, perhaps,
+for example, to improve support for nested hypervisors, i.e., running
+hypervisors atop other hypervisors.
+
+However, setting TVM=1 does not cause traps for accesses to `vsatp` or
+instructions HFENCE.VVMA or HINVAL.VVMA, or for any actions taken in
+VS-mode, because M-level software is not expected to need to involve
+itself in VS-stage address translation. For virtual machines, it should
+be sufficient, and in all likelihood faster as well, to leave VS-stage
+address translation alone and merge all other translation stages into
+G-stage shadow page tables controlled by `hgatp`. This assumption does
+place some constraints on possible future RISC-V extensions that current
+machines will be able to emulate efficiently.
+====
+
+The hypervisor extension changes the behavior of the Modify Privilege
+field, MPRV, of `mstatus`. When MPRV=0, translation and protection
+behave as normal. When MPRV=1, explicit memory accesses are translated
+and protected, and endianness is applied, as though the current
+virtualization mode were set to MPV and the current nominal privilege
+mode were set to MPP. <<h-mprv>> enumerates the cases.
+
+[[h-mprv]]
+.Effect of MPRV on the translation and protection of explicit memory accesses.
+[float="center",align="center",cols="^15,^10,^10,<70",options="header"]
+|===
+|MPRV |MPV |MPP |Effect
+|0 |- |- |Normal access; current privilege mode applies.
+
+|1 |0 |0 |U-level access with HS-level translation and protection only.
+
+|1 |0 |1 |HS-level access with HS-level translation and protection only.
+
+|1 |- |3 |M-level access with no translation.
+
+|1 |1 |0 |VU-level access with two-stage translation and protection. The
+HS-level MXR bit makes any executable page readable. `vsstatus`.MXR
+makes readable those pages marked executable at the VS translation
+stage, but only if readable at the guest-physical translation stage.
+
+|1 |1 |1 |VS-level access with two-stage translation and protection. The
+HS-level MXR bit makes any executable page readable. `vsstatus`.MXR
+makes readable those pages marked executable at the VS translation
+stage, but only if readable at the guest-physical translation stage.
+`vsstatus`.SUM applies instead of the HS-level SUM bit.
+|===
+
+MPRV does not affect the virtual-machine load/store instructions, HLV,
+HLVX, and HSV. The explicit loads and stores of these instructions
+always act as though V=1 and the nominal privilege mode were
+`hstatus`.SPVP, overriding MPRV.
+
+The `mstatus` register is a superset of the HS-level `sstatus` register
+but is not a superset of `vsstatus`.
+
+==== Machine Interrupt Delegation (`mideleg`) Register
+
+When the hypervisor extension is implemented, bits 10, 6, and 2 of
+`mideleg` (corresponding to the standard VS-level interrupts) are each
+read-only one. Furthermore, if any guest external interrupts are
+implemented (GEILEN is nonzero), bit 12 of `mideleg` (corresponding to
+supervisor-level guest external interrupts) is also read-only one.
+VS-level interrupts and guest external interrupts are always delegated
+past M-mode to HS-mode.
+
+For bits of `mideleg` that are zero, the corresponding bits in
+`hideleg`, `hip`, and `hie` are read-only zeros.
+
+==== Machine Interrupt (`mip` and `mie`) Registers
+
+The hypervisor extension gives registers `mip` and `mie` additional
+active bits for the hypervisor-added interrupts. <<hypervisor-mipreg-standard>> and <<hypervisor-miereg-standard>> show the
+standard portions (bits 15:0) of registers `mip` and `mie` when the
+hypervisor extension is implemented.
+
+[[hypervisor-mipreg-standard]]
+.Standard portion (bits 15:0) of `mip`.
+include::images/bytefield/hypv-mipreg-standard.edn[]
+
+[[hypervisor-miereg-standard]]
+.Standard portion (bits 15:0) of `mie`.
+include::images/bytefield/hypv-miereg-standard.edn[]
+
+Bits SGEIP, VSEIP, VSTIP, and VSSIP in `mip` are aliases for the same
+bits in hypervisor CSR `hip`, while SGEIE, VSEIE, VSTIE, and VSSIE in
+`mie` are aliases for the same bits in `hie`.
+
+==== Machine Second Trap Value (`mtval2`) Register
+
+The `mtval2` register is an MXLEN-bit read/write register formatted as
+shown in <<mtval2reg>>. When a trap is taken into
+M-mode, `mtval2` is written with additional exception-specific
+information, alongside `mtval`, to assist software in handling the trap.
+
+[[mtval2reg]]
+.Machine second trap value register (`mtval2`).
+include::images/bytefield/mtval2reg.edn[]
+
+
+When a guest-page-fault trap is taken into M-mode, `mtval2` is written
+with either zero or the guest physical address that faulted, shifted
+right by 2 bits. For other traps, `mtval2` is set to zero, but a future
+standard or extension may redefine `mtval2's` setting for other traps.
+
+If a guest-page fault is due to an implicit memory access during
+first-stage (VS-stage) address translation, a guest physical address
+written to `mtval2` is that of the implicit memory access that faulted.
+Additional information is provided in CSR `mtinst` to disambiguate such
+situations.
+
+Otherwise, for misaligned loads and stores that cause guest-page faults,
+a nonzero guest physical address in `mtval2` corresponds to the faulting
+portion of the access as indicated by the virtual address in `mtval`.
+For instruction guest-page faults on systems with variable-length
+instructions, a nonzero `mtval2` corresponds to the faulting portion of
+the instruction as indicated by the virtual address in `mtval`.
+
+`mtval2` is a *WARL* register that must be able to hold zero and may be
+capable of holding only an arbitrary subset of other 2-bit-shifted guest
+physical addresses, if any.
+
+The Ssdbltrap extension (See <<ssdbltrp>>) requires the implementation of
+the `mtval2` CSR.
+
+==== Machine Trap Instruction (`mtinst`) Register
+
+The `mtinst` register is an MXLEN-bit read/write register formatted as
+shown in <<mtinstreg>>. When a trap is taken into
+M-mode, `mtinst` is written with a value that, if nonzero, provides
+information about the instruction that trapped, to assist software in
+handling the trap. The values that may be written to `mtinst` on a trap
+are documented in <<tinst-vals>>.
+
+[[mtinstreg]]
+.Machine trap instruction (`mtinst`) register.
+include::images/bytefield/mtinstreg.edn[]
+
+`mtinst` is a *WARL* register that need only be able to hold the values that
+the implementation may automatically write to it on a trap.
+
+[[two-stage-translation]]
+=== Two-Stage Address Translation
+
+Whenever the current virtualization mode V is 1, two-stage address
+translation and protection is in effect. For any virtual memory access,
+the original virtual address is converted in the first stage by VS-level
+address translation, as controlled by the `vsatp` register, into a
+_guest physical address_. The guest physical address is then converted
+in the second stage by guest physical address translation, as controlled
+by the `hgatp` register, into a supervisor physical address. The two
+stages are known also as VS-stage and G-stage translation. Although
+there is no option to disable two-stage address translation when V=1,
+either stage of translation can be effectively disabled by zeroing the
+corresponding `vsatp` or `hgatp` register.
+
+The `vsstatus` field MXR, which makes execute-only pages readable by explicit loads, only
+overrides VS-stage page protection. Setting MXR at VS-level does not
+override guest-physical page protections. Setting MXR at HS-level,
+however, overrides both VS-stage and G-stage execute-only permissions.
+
+When V=1, memory accesses that would normally bypass address translation
+are subject to G-stage address translation alone. This includes memory
+accesses made in support of VS-stage address translation, such as reads
+and writes of VS-level page tables.
+
+Machine-level physical memory protection applies to supervisor physical
+addresses and is in effect regardless of virtualization mode.
+
+[[guest-addr-translation]]
+==== Guest Physical Address Translation
+
+The mapping of guest physical addresses to supervisor physical addresses
+is controlled by CSR `hgatp` (<<hgatp>>).
+
+When the address translation scheme selected by the MODE field of
+`hgatp` is Bare, guest physical addresses are equal to supervisor
+physical addresses without modification, and no memory protection
+applies in the trivial translation of guest physical addresses to
+supervisor physical addresses.
+
+When `hgatp`.MODE specifies a translation scheme of Sv32x4, Sv39x4,
+Sv48x4, or Sv57x4, G-stage address translation is a variation on the
+usual page-based virtual address translation scheme of Sv32, Sv39, Sv48,
+or Sv57, respectively. In each case, the size of the incoming address is
+widened by 2 bits (to 34, 41, 50, or 59 bits). To accommodate the
+2 extra bits, the root page table (only) is expanded by a factor of four
+to be 16 KiB instead of the usual 4 KiB. Matching its larger size, the
+root page table also must be aligned to a 16 KiB boundary instead of the
+usual 4 KiB page boundary. Except as noted, all other aspects of Sv32,
+Sv39, Sv48, or Sv57 are adopted unchanged for G-stage translation.
+Non-root page tables and all page table entries (PTEs) have the same
+formats as documented in <<sv32>>, <<sv39>>, <<sv48>>, and <<sv57>>.
+
+For Sv32x4, an incoming guest physical address is partitioned into a
+virtual page number (VPN) and page offset as shown in
+<<sv32x4va>>. This partitioning is identical to
+that for an Sv32 virtual address as depicted in
+<<sv32va>>, except with 2 more bits at the
+high end in VPN[1]. (Note that the fields of a partitioned guest
+physical address also correspond one-for-one with the structure that
+Sv32 assigns to a physical address, depicted in
+<<sv32va>>.)
+
+[[sv32x4va]]
+.Sv32x4 virtual address (guest physical address).
+include::images/bytefield/sv32x4va.edn[]
+
+For Sv39x4, an incoming guest physical address is partitioned as shown
+in <<sv39x4va>>. This partitioning is identical to that for an Sv39 virtual address as depicted in <<sv39va>>, except with 2 more bits at the
+high end in VPN[2]. Address bits 63:41 must all be zeros, or else a
+guest-page-fault exception occurs.
+
+[[sv39x4va]]
+.Sv39x4 virtual address (guest physical address).
+include::images/bytefield/sv39x4va.edn[]
+
+For Sv48x4, an incoming guest physical address is partitioned as shown
+in <<sv48x4va>>. This partitioning is identical to
+that for an Sv48 virtual address as depicted in
+<<sv48va>>, except with 2 more bits at the
+high end in VPN[3]. Address bits 63:50 must all be zeros, or else a
+guest-page-fault exception occurs.
+
+[[sv48x4va]]
+.Sv48x4 virtual address (guest physical address).
+include::images/bytefield/sv48x4va.edn[]
+
+For Sv57x4, an incoming guest physical address is partitioned as shown
+in <<sv57x4va>>. This partitioning is identical to
+that for an Sv57 virtual address as depicted in
+<<sv57va>>, except with 2 more bits at the
+high end in VPN[4]. Address bits 63:59 must all be zeros, or else a
+guest-page-fault exception occurs.
+
+[[sv57x4va]]
+.Sv57x4 virtual address (guest physical address).
+include::images/bytefield/sv57x4va.edn[]
+
+[NOTE]
+====
+The page-based G-stage address translation scheme for RV32, Sv32x4, is
+defined to support a 34-bit guest physical address so that an RV32
+hypervisor need not be limited in its ability to virtualize real 32-bit
+RISC-V machines, even those with 33-bit or 34-bit physical addresses.
+This may include the possibility of a machine virtualizing itself, if it
+happens to use 33-bit or 34-bit physical addresses. Multiplying the size
+and alignment of the root page table by a factor of four is the cheapest
+way to extend Sv32 to cover a 34-bit address. The possible wastage of
+12 KiB for an unnecessarily large root page table is expected to be of
+negligible consequence for most (maybe all) real uses.
+
+A consistent ability to virtualize machines having as much as four times
+the physical address space as virtual address space is believed to be of
+some utility also for RV64. For a machine implementing 39-bit virtual
+addresses (Sv39), for example, this allows the hypervisor extension to
+support up to a 41-bit guest physical address space without either
+necessitating hardware support for 48-bit virtual addresses (Sv48) or
+falling back to emulating the larger address space using shadow page
+tables.
+====
+
+The conversion of an Sv32x4, Sv39x4, Sv48x4, or Sv57x4 guest physical
+address is accomplished with the same algorithm used for Sv32, Sv39,
+Sv48, or Sv57, as presented in
+<<sv32algorithm>>, except that:
+
+* `hgatp` substitutes for the usual `satp`;
+* for the translation to begin, the effective privilege mode must be
+VS-mode or VU-mode;
+* when checking the U bit, the current privilege mode is always taken to
+be U-mode; and
+* guest-page-fault exceptions are raised instead of regular page-fault
+exceptions.
+
+For G-stage address translation, all memory accesses (including those
+made to access data structures for VS-stage address translation) are
+considered to be user-level accesses, as though executed in U-mode.
+Access type permissions—readable, writable, or executable—are checked
+during G-stage translation the same as for VS-stage translation. For a
+memory access made to support VS-stage address translation (such as to
+read/write a VS-level page table), permissions and the need to set A
+and/or D bits at the G-stage level are checked as though for an implicit
+load or store, not for the original access type. However, any exception
+is always reported for the original access type (instruction, load, or
+store/AMO).
+
+The G bit in all G-stage PTEs is currently not used. Until
+its use is defined by a standard extension, it should be cleared by
+software for forward compatibility, and must be ignored by hardware.
+
+[NOTE]
+====
+G-stage address translation uses the identical format for PTEs as
+regular address translation, even including the U bit, due to the
+possibility of sharing some (or all) page tables between G-stage
+translation and regular HS-level address translation. Regardless of
+whether this usage will ever become common, we chose not to preclude it.
+====
+
+==== Guest-Page Faults
+
+Guest-page-fault traps may be delegated from M-mode to HS-mode under the
+control of CSR `medeleg`, but cannot be delegated to other privilege
+modes. On a guest-page fault, CSR `mtval` or `stval` is written with the
+faulting guest virtual address as usual, and `mtval2` or `htval` is
+written either with zero or with the faulting guest physical address,
+shifted right by 2 bits. CSR `mtinst` or `htinst` may also be written
+with information about the faulting instruction or other reason for the
+access, as explained in <<tinst-vals>>.
+
+When an instruction fetch or a misaligned memory access straddles a page
+boundary, two different address translations are involved. When a
+guest-page fault occurs in such a circumstance, the faulting virtual
+address written to `mtval`/`stval` is the same as would be required for
+a regular page fault. Thus, the faulting virtual address may be a
+page-boundary address that is higher than the instruction's original
+virtual address, if the byte at that page boundary is among the accessed
+bytes.
+
+When a guest-page fault is not due to an implicit memory access for
+VS-stage address translation, a nonzero guest physical address written
+to `mtval2`/`htval` shall correspond to the exact virtual address
+written to `mtval`/`stval`.
+
+[[hyp-mm-fences]]
+==== Memory-Management Fences
+
+The behavior of the SFENCE.VMA instruction is affected by the current
+virtualization mode V. When V=0, the virtual-address argument is an
+HS-level virtual address, and the ASID argument is an HS-level ASID. The
+instruction orders stores only to HS-level address-translation
+structures with subsequent HS-level address translations.
+
+When V=1, the virtual-address argument to SFENCE.VMA is a guest virtual
+address within the current virtual machine, and the ASID argument is a
+VS-level ASID within the current virtual machine. The current virtual
+machine is identified by the VMID field of CSR `hgatp`, and the
+effective ASID can be considered to be the combination of this VMID with
+the VS-level ASID. The SFENCE.VMA instruction orders stores only to the
+VS-level address-translation structures with subsequent VS-stage address
+translations for the same virtual machine, i.e., only when `hgatp`.VMID
+is the same as when the SFENCE.VMA executed.
+
+Hypervisor instructions HFENCE.VVMA and HFENCE.GVMA provide additional
+memory-management fences to complement SFENCE.VMA. These instructions
+are described in <<hfence.vma>>.
+
+<<pmp-vmem>> discusses the intersection between
+physical memory protection (PMP) and page-based address translation. It
+is noted there that, when PMP settings are modified in a manner that
+affects either the physical memory that holds page tables or the
+physical memory to which page tables point, M-mode software must
+synchronize the PMP settings with the virtual memory system. For
+HS-level address translation, this is accomplished by executing in
+M-mode an SFENCE.VMA instruction with _rs1_=`x0` and _rs2_=`x0`, after
+the PMP CSRs are written. Synchronization with G-stage and VS-stage data
+structures is also needed. Executing an HFENCE.GVMA instruction with
+_rs1_=`x0` and _rs2_=`x0` suffices to flush all G-stage or VS-stage
+address-translation cache entries that have cached PMP settings
+corresponding to the final translated supervisor physical address. An
+HFENCE.VVMA instruction is not required.
+
+Similarly, if the setting of the PBMTE or ADUE bits in `menvcfg` are changed, an
+HFENCE.GVMA instruction with _rs1_=`x0` and _rs2_=`x0` suffices to synchronize
+with respect to the altered interpretation of G-stage and VS-stage PTEs' PBMT
+and A/D bit fields, respectively.
+
+By contrast, if the PBMTE or ADUE bits in `henvcfg` are changed, executing an
+HFENCE.VVMA with _rs1_=`x0` and _rs2_=`x0` suffices to synchronize with
+respect to the altered interpretation of VS-stage PTEs' PBMT and A/D bit fields
+for the currently active VMID.
+
+NOTE: No mechanism is provided to atomically change `vsatp` and `hgatp`
+together. Hence, to prevent speculative execution causing one guest's
+VS-stage translations to be cached under another guest's VMID, world-switch
+code should zero `vsatp`, then swap `hgatp`, then finally write the new
+`vsatp` value. Similarly, if `henvcfg`.PBMTE/ADUE need be world-switched, they
+should be switched after zeroing `vsatp` but before writing the new `vsatp`
+value, obviating the need to execute an HFENCE.VVMA instruction.
+
+=== Traps
+
+[[sec:hcauses]]
+==== Trap Cause Codes
+
+The hypervisor extension augments the trap cause encoding.
+<<hcauses>> lists the possible M-mode and HS-mode
+trap cause codes when the hypervisor extension is implemented. Codes are
+added for VS-level interrupts (interrupts 2, 6, 10), for
+supervisor-level guest external interrupts (interrupt 12), for
+virtual-instruction exceptions (exception 22), and for guest-page faults
+(exceptions 20, 21, 23). Furthermore, environment calls from VS-mode are
+assigned cause 10, whereas those from HS-mode or S-mode use cause 9 as
+usual.
+
+[[hcauses]]
+.Machine and supervisor cause register (`mcause` and `scause`) values when the hypervisor extension is implemented.
+[%autowidth,float="center",align="center",cols=">,>,<",options="header"]
+|===
+|Interrupt |Exception Code |Description
+|1 +
+1 +
+1 +
+1
+|0 +
+1 +
+2 +
+3
+|_Reserved_ +
+Supervisor software interrupt +
+Virtual supervisor software interrupt +
+Machine software interrupt
+|1 +
+1 +
+1 +
+1
+|4 +
+5 +
+6 +
+7
+|_Reserved_ +
+Supervisor timer interrupt +
+Virtual supervisor timer interrupt +
+Machine timer interrupt
+|1 +
+1 +
+1 +
+1
+|8 +
+9 +
+10 +
+11
+|_Reserved_ +
+Supervisor external interrupt +
+Virtual supervisor external interrupt +
+Machine external interrupt
+|1 +
+1 +
+1 +
+1
+|12 +
+13 +
+14-15 +
+&#8805;16
+|Supervisor guest external interrupt +
+_Reserved for counter-overflow interrupt_ +
+_Reserved_ +
+_Designated for platform use_
+|0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+|0 +
+1 +
+2 +
+3 +
+4 +
+5 +
+6 +
+7 +
+8 +
+9 +
+10 +
+11 +
+12 +
+13 +
+14 +
+15 +
+16 +
+17 +
+18 +
+19 +
+20 +
+21 +
+22 +
+23 +
+24-31 +
+32-47 +
+48-63 +
+&#8805;64
+|Instruction address misaligned +
+Instruction access fault +
+Illegal instruction +
+Breakpoint +
+Load address misaligned +
+Load access fault +
+Store/AMO address misaligned +
+Store/AMO access fault +
+Environment call from U-mode or VU-mode +
+Environment call from HS-mode +
+Environment call from VS-mode +
+Environment call from M-mode +
+Instruction page fault +
+Load page fault +
+_Reserved_ +
+Store/AMO page fault +
+Double trap +
+_Reserved_ +
+Software check +
+Hardware error +
+Instruction guest-page fault +
+Load guest-page fault +
+Virtual instruction +
+Store/AMO guest-page fault +
+_Designated for custom use_ +
+_Reserved_ +
+_Designated for custom use_ +
+_Reserved_
+|===
+
+HS-mode and VS-mode ECALLs use different cause values so they can be
+delegated separately.
+
+When V=1, a virtual-instruction exception (code 22) is normally raised
+instead of an illegal-instruction exception if the attempted instruction
+is _HS-qualified_ but is prevented from executing when V=1 either due to
+insufficient privilege or because the instruction is expressly disabled
+by a supervisor or hypervisor CSR such as `scounteren` or `hcounteren`.
+An instruction is _HS-qualified_ if it would be valid to execute in
+HS-mode (for some values of the instruction's register operands),
+assuming fields TSR and TVM of CSR `mstatus` are both zero.
+
+A special rule applies for CSR instructions that access 32-bit high-half
+CSRs such as `cycleh` and `htimedeltah`. When V=1 and
+XLEN=32, an invalid attempt to access a high-half CSR
+raises a virtual-instruction
+exception instead of an illegal-instruction exception if the same CSR
+instruction for the corresponding _low-half_ CSR (e.g.`cycle` or
+`htimedelta`) is HS-qualified.
+
+[NOTE]
+====
+When XLEN>32, an attempt to access a high-half CSR
+always raises an illegal-instruction exception.
+====
+
+Specifically, a virtual-instruction exception is raised for the
+following cases:
+
+* in VS-mode, attempts to access a non-high-half counter CSR when the
+corresponding bit in `hcounteren` is 0 and the same bit in `mcounteren`
+is 1;
+* in VS-mode, if XLEN=32, attempts to access a high-half counter CSR
+when the corresponding bit in `hcounteren` is 0 and the same bit in
+`mcounteren` is 1;
+* in VU-mode, attempts to access a non-high-half counter CSR when the
+corresponding bit in either `hcounteren` or `scounteren` is 0 and the
+same bit in `mcounteren` is 1;
+* in VU-mode, if XLEN=32, attempts to access a high-half counter CSR
+when the corresponding bit in either `hcounteren` or `scounteren` is 0
+and the same bit in `mcounteren` is 1;
+* in VS-mode or VU-mode, attempts to execute a hypervisor instruction
+(HLV, HLVX, HSV, or HFENCE);
+* in VS-mode or VU-mode, attempts to access an implemented non-high-half
+hypervisor CSR or VS CSR when the same access (read/write) would be
+allowed in HS-mode, assuming `mstatus`.TVM=0;
+* in VS-mode or VU-mode, if XLEN=32, attempts to access an implemented
+high-half hypervisor CSR or high-half VS CSR when the same access
+(read/write) to the CSR"s low-half partner would be allowed in HS-mode,
+assuming `mstatus`.TVM=0;
+* in VU-mode, attempts to execute WFI when `mstatus`.TW=0, or to execute
+a supervisor instruction (SRET or SFENCE);
+* in VU-mode, attempts to access an implemented non-high-half supervisor
+CSR when the same access (read/write) would be allowed in HS-mode,
+assuming `mstatus`.TVM=0;
+* in VU-mode, if XLEN=32, attempts to access an implemented high-half
+supervisor CSR when the same access to the CSR's low-half partner would
+be allowed in HS-mode, assuming `mstatus`.TVM=0;
+* in VS-mode, attempts to execute WFI when `hstatus`.VTW=1 and
+`mstatus`.TW=0, unless the instruction completes within an
+implementation-specific, bounded time;
+* in VS-mode, attempts to execute SRET when `hstatus`.VTSR=1; and
+* in VS-mode, attempts to execute an SFENCE.VMA or SINVAL.VMA
+instruction or to access `satp`, when `hstatus`.VTVM=1.
+
+Other extensions to the RISC-V Privileged Architecture may add to the
+set of circumstances that cause a virtual-instruction exception when
+V=1.
+
+On a virtual-instruction trap, `mtval` or `stval` is written the same as
+for an illegal-instruction trap.
+
+[NOTE]
+====
+It is not unusual that hypervisors must emulate the instructions that
+raise virtual-instruction exceptions, to support nested hypervisors or
+for other reasons. Machine level is expected ordinarily to delegate
+virtual-instruction traps directly to HS-level, whereas
+illegal-instruction traps are likely to be processed first in M-mode before
+being conditionally delegated (by software) to HS-level. Consequently,
+virtual-instruction traps are expected typically to be handled faster
+than illegal-instruction traps.
+
+When not emulating the trapping instruction, a hypervisor should convert
+a virtual-instruction trap into an illegal-instruction exception for the
+guest virtual machine.
+
+***
+
+Because TSR and TVM in `mstatus` are intended to impact only S-mode
+(HS-mode), they are ignored for determining exceptions in VS-mode.
+====
+
+Fields FS and VS in registers `sstatus` and `vsstatus` deviate from the usual
+_HS-qualified_ rule.
+If an instruction is prevented from executing because FS or VS is zero in
+either `sstatus` or `vsstatus`, the exception raised is always an
+illegal-instruction exception, never a virtual-instruction exception.
+
+[NOTE]
+====
+Early implementations of the H extension treated FS and VS in `sstatus` and
+`vsstatus` specially this way, and the behavior has been codified to maintain
+compatibility for software.
+====
+
+<<<
+
+[[HSyncExcPrio]]
+.Synchronous exception priority when the hypervisor extension is implemented.
+[%autowidth,float="center",align="center",cols="<,>,<",options="header"]
+|===
+|Priority |Exc.Code |Description
+|_Highest_ |3 |Instruction address breakpoint
+
+| .>|12, 20, 1 |During instruction address translation: +
+&#160;&#160;&#160;First encountered page fault, guest-page fault, or access
+fault
+
+| .>|1 |With physical address for instruction: +
+&#160;&#160;&#160;Instruction access fault
+
+| |2 +
+22 +
+0 +
+8, 9, 10, 11 +
+3 +
+3|Illegal instruction +
+Virtual instruction +
+Instruction address misaligned +
+Environment call +
+Environment break +
+&#160;&#160;&#160;Load/store/AMO address breakpoint
+
+| .>|4,6 |Optionally: +
+&#160;&#160;&#160;Load/store/AMO address misaligned
+
+| .>|13, 15, 21, 23, 5, 7 |During address translation for an explicit memory access: +
+&#160;&#160;&#160;First encountered page fault, guest-page fault,
+or access fault
+
+| .>|5, 7 |With physical address for an explicit memory access: +
+&#160;&#160;&#160;Load/store/AMO access fault
+
+.>|_Lowest_ .>|4, 6 |If not higher priority: +
+&#160;&#160;&#160;Load/store/AMO address misaligned
+|===
+
+If an instruction may raise multiple synchronous exceptions, the
+decreasing priority order of <<HSyncExcPrio>>
+indicates which exception is taken and reported in `mcause` or `scause`.
+
+==== Trap Entry
+
+When a trap occurs in HS-mode or U-mode, it goes to M-mode, unless
+delegated by `medeleg` or `mideleg`, in which case it goes to HS-mode.
+When a trap occurs in VS-mode or VU-mode, it goes to M-mode, unless
+delegated by `medeleg` or `mideleg`, in which case it goes to HS-mode,
+unless further delegated by `hedeleg` or `hideleg`, in which case it
+goes to VS-mode.
+
+When a trap is taken into M-mode, virtualization mode V gets set to 0,
+and fields MPV and MPP in `mstatus` (or `mstatush`) are set according to
+<<h-mpp>>. A trap into M-mode also writes fields GVA,
+MPIE, and MIE in `mstatus`/`mstatush` and writes CSRs `mepc`, `mcause`,
+`mtval`, `mtval2`, and `mtinst`.
+
+[[h-mpp]]
+.Value of `mstatus`/`mstatush` fields MPV and MPP after a trap into M-mode. Upon trap return, MPV is ignored when MPP=3.
+[%autowidth,float="center",align="center",cols="<,^,^",options="header"]
+|===
+|Previous Mode |MPV |MPP
+|U-mode +
+HS-mode +
+M-mode|0 +
+0 +
+0|0 +
+1 +
+3
+|VU-mode +
+VS-mode|1 +
+1|0 +
+1
+|===
+
+When a trap is taken into HS-mode, virtualization mode V is set to 0,
+and `hstatus`.SPV and `sstatus`.SPP are set according to
+<<h-spp>>. If V was 1 before the trap, field SPVP in
+`hstatus` is set the same as `sstatus`.SPP; otherwise, SPVP is left
+unchanged. A trap into HS-mode also writes field GVA in `hstatus`,
+fields SPIE and SIE in `sstatus`, and CSRs `sepc`, `scause`, `stval`,
+`htval`, and `htinst`.
+
+[[h-spp]]
+.Value of `hstatus` field SPV and `sstatus` field SPP after a trap into HS-mode.
+[%autowidth,float="center",align="center",cols="<,^,^",options="header"]
+|===
+|Previous Mode |SPV |SPP
+|U-mode +
+HS-mode + |0 +
+0 |0 +
+1
+|VU-mode +
+VS-mode|1 +
+1 |0 +
+1
+|===
+
+When a trap is taken into VS-mode, `vsstatus`.SPP is set according to
+<<h-vspp>>. Register `hstatus` and the HS-level
+`sstatus` are not modified, and the virtualization mode V remains 1. A
+trap into VS-mode also writes fields SPIE and SIE in `vsstatus` and
+writes CSRs `vsepc`, `vscause`, and `vstval`.
+
+[[h-vspp]]
+.Value of `vsstatus` field SPP after a trap into VS-mode.
+[%autowidth,float="center",align="center",cols="<,^",options="header"]
+|===
+|Previous Mode |SPP
+|VU-mode +
+VS-mode |0 +
+1
+|===
+
+[[tinst-vals]]
+==== Transformed Instruction or Pseudoinstruction for `mtinst` or `htinst`
+
+On any trap into M-mode or HS-mode, one of these values is written
+automatically into the appropriate trap instruction CSR, `mtinst` or
+`htinst`:
+
+* zero;
+* a transformation of the trapping instruction;
+* a custom value (allowed only if the trapping instruction is
+non-standard); or
+* a special pseudoinstruction.
+
+Except when a pseudoinstruction value is required (described later), the
+value written to `mtinst` or `htinst` may always be zero, indicating
+that the hardware is providing no information in the register for this
+particular trap.
+
+[NOTE]
+====
+The value written to the trap instruction CSR serves two purposes. The
+first is to improve the speed of instruction emulation in a trap
+handler, partly by allowing the handler to skip loading the trapping
+instruction from memory, and partly by obviating some of the work of
+decoding and executing the instruction. The second purpose is to supply,
+via pseudoinstructions, additional information about guest-page-fault
+exceptions caused by implicit memory accesses done for VS-stage address
+translation.
+
+A _transformation_ of the trapping instruction is written instead of
+simply a copy of the original instruction in order to minimize the
+burden for hardware yet still provide to a trap handler the information
+needed to emulate the instruction. An implementation may at any time
+reduce its effort by substituting zero in place of the transformed
+instruction.
+====
+
+On an interrupt, the value written to the trap instruction register is
+always zero. On a synchronous exception, if a nonzero value is written,
+one of the following shall be true about the value:
+
+* Bit 0 is `1`, and replacing bit 1 with `1` makes the value into a
+valid encoding of a standard instruction.
++
+In this case, the instruction that trapped is the same kind as indicated
+by the register value, and the register value is the transformation of
+the trapping instruction, as defined later. For example, if bits 1:0 are
+binary `11` and the register value is the encoding of a standard LW
+(load word) instruction, then the trapping instruction is LW, and the
+register value is the transformation of the trapping LW instruction.
+* Bit 0 is `1`, and replacing bit 1 with `1` makes the value into an
+instruction encoding that is explicitly designated for a custom
+instruction (_not_ an unused reserved encoding).
++
+This is a _custom value_. The instruction that trapped is a non-standard
+instruction. The interpretation of a custom value is not otherwise
+specified by this standard.
+* The value is one of the special pseudoinstructions defined later, all
+of which have bits 1:0 equal to `00`.
+
+These three cases exclude a large number of other possible values, such
+as all those having bits 1:0 equal to binary `10`. A future standard or
+extension may define additional cases, thus allowing values that are
+currently excluded. Software may safely treat an unrecognized value in a
+trap instruction register the same as zero.
+
+[NOTE]
+====
+To be forward-compatible with future revisions of this standard,
+software that interprets a nonzero value from `mtinst` or `htinst` must
+fully verify that the value conforms to one of the cases listed above.
+For instance, for RV64, discovering that bits 6:0 of `mtinst` are
+`0000011` and bits 14:12 are `010` is not sufficient to establish that
+the first case applies and the trapping instruction is a standard LW
+instruction; rather, software must also confirm that bits 63:32 of
+`mtinst` are all zeros. A future standard might define new values for
+64-bit `mtinst` that are nonzero in bits 63:32 yet may coincidentally
+have in bits 31:0 the same bit patterns as standard RV64 instructions.
+
+***
+
+Unlike for standard instructions, there is no requirement that the
+instruction encoding of a custom value be of the same ``kind'' as the
+instruction that trapped (or even have any correlation with the trapping
+instruction).
+====
+
+<<tinst-values>> shows the values that may be
+automatically written to the trap instruction register for each standard
+exception cause. For exceptions that prevent the fetching of an
+instruction, only zero or a pseudoinstruction value may be written. A
+custom value may be automatically written only if the instruction that
+traps is non-standard. A future standard or extension may permit other
+values to be written, chosen from the set of allowed values established
+earlier.
+
+<<<
+
+[[tinst-values]]
+.Values that may be automatically written to the trap instruction (`mtinst` or `htinst`) register on an exception trap.
+[float="center",align="center",cols="2,^,^,^,^",options="header"]
+|===
+<.>|Exception
+^.>|Zero
+|Transformed +
+Standard +
+Instruction
+^.>|Custom Value
+^.>|Pseudoinstruction Value
+|Instruction address misaligned |Yes |No |Yes |No
+|Instruction access fault +
+Illegal instruction +
+Breakpoint +
+Virtual instruction
+|Yes +
+Yes +
+Yes +
+Yes
+|No +
+No +
+No +
+No +
+|No +
+No +
+Yes +
+Yes
+|No +
+No +
+No +
+No
+|Load address misaligned +
+Load access fault +
+Store/AMO address misaligned +
+Store/AMO access fault
+|Yes +
+Yes +
+Yes +
+Yes
+|Yes +
+Yes +
+Yes +
+Yes
+|Yes +
+Yes +
+Yes +
+Yes
+|No +
+No +
+No +
+No
+|Environment call |Yes |No |Yes |No
+|Instruction page fault +
+Load page fault +
+Store/AMO page fault
+|Yes +
+Yes +
+Yes
+|No +
+Yes +
+Yes
+|No +
+Yes +
+Yes
+|No +
+No +
+No
+|Instruction guest-page fault +
+Load guest-page fault +
+Store/AMO guest-page fault
+|Yes +
+Yes +
+Yes
+|No +
+Yes +
+Yes
+|No +
+Yes +
+Yes
+|Yes +
+Yes +
+Yes
+|===
+
+As enumerated in the table, a synchronous exception may write to the
+trap instruction register a standard transformation of the trapping
+instruction only for exceptions that arise from explicit memory accesses
+(from loads, stores, and AMO instructions). Accordingly, standard
+transformations are currently defined only for these memory-access
+instructions. If a synchronous trap occurs for a standard instruction
+for which no transformation has been defined, the trap instruction
+register shall be written with zero (or, under certain circumstances,
+with a special pseudoinstruction value).
+
+For a standard load instruction that is not a compressed instruction and
+is one of LB, LBU, LH, LHU, LW, LWU, LD, FLW, FLD, FLQ, or FLH, the
+transformed instruction has the format shown in
+<<transformedloadinst>>.
+
+[[transformedloadinst]]
+.Transformed load instruction (LB, LBU, LH, LHU, LW, LWU, LD, FLW, FLD, FLQ, or FLH). Fields funct3, rd, and opcode are the same as the trapping load instruction.
+include::images/wavedrom/transformedloadinst.edn[]
+
+For a standard store instruction that is not a compressed instruction
+and is one of SB, SH, SW, SD, FSW, FSD, FSQ, or FSH, the transformed
+instruction has the format shown in
+<<transformedstoreinst>>.
+
+[[transformedstoreinst]]
+.Transformed store instruction (SB, SH, SW, SD, FSW, FSD, FSQ, or FSH). Fields rs2, funct3, and opcode are the same as the trapping store instruction.
+include::images/wavedrom/transformedstoreinst.edn[]
+
+For a standard atomic instruction (load-reserved, store-conditional, or AMO instruction), the transformed instruction has the format shown in <<transformedatomicinst>>.
+
+[[transformedatomicinst]]
+.Transformed atomic instruction (load-reserved, store-conditional, or AMO instruction). All fields are the same as the trapping instruction except bits 19:15, Addr. Offset.
+include::images/wavedrom/transformedatomicinst.edn[]
+
+For a standard virtual-machine load/store instruction (HLV, HLVX, or HSV), the transformed instruction has the format shown in <<transformedvmaccessinst>>.
+
+[[transformedvmaccessinst]]
+.Transformed virtual-machine load/store instruction (HLV, HLVX, HSV). All fields are the same as the trapping instruction except bits 19:15, Addr. Offset
+include::images/wavedrom/transformedvmaccessinst.edn[]
+
+In all the transformed instructions above, the Addr. Offset field that
+replaces the instruction’s rs1 field in bits 19:15 is the positive
+difference between the faulting virtual address (written to `mtval` or
+`stval`) and the original virtual address. This difference can be
+nonzero only for a misaligned memory access. Note also that, for basic
+loads and stores, the transformations replace the instruction’s
+immediate offset fields with zero.
+
+For a standard compressed instruction (16-bit size), the transformed
+instruction is found as follows:
+
+. Expand the compressed instruction to its 32-bit equivalent.
+. Transform the 32-bit equivalent instruction.
+. Replace bit 1 with a `0`.
+
+Bits 1:0 of a transformed standard instruction will be binary `01` if
+the trapping instruction is compressed and `11` if not.
+[NOTE]
+====
+In decoding the contents of `mtinst` or `htinst`, once software has
+determined that the register contains the encoding of a standard basic
+load (LB, LBU, LH, LHU, LW, LWU, LD, FLW, FLD, FLQ, or FLH) or basic
+store (SB, SH, SW, SD, FSW, FSD, FSQ, or FSH), it is not necessary to
+confirm also that the immediate offset fields (31:25, and 24:20 or 11:7)
+are zeros. The knowledge that the register’s value is the encoding of a
+basic load/store is sufficient to prove that the trapping instruction is
+of the same kind.
+
+A future version of this standard may add information to the fields that
+are currently zeros. However, for backwards compatibility, any such
+information will be for performance purposes only and can safely be
+ignored.
+====
+
+For guest-page faults, the trap instruction register is written with a
+special pseudoinstruction value if: (a) the fault is caused by an
+implicit memory access for VS-stage address translation, and (b) a
+nonzero value (the faulting guest physical address) is written to
+`mtval2` or `htval`. If both conditions are met, the value written to
+`mtinst` or `htinst` must be taken from
+<<pseudoinsts>>; zero is not allowed.
+
+[[pseudoinsts]]
+.Special pseudoinstruction values for guest-page faults. The RV32 values are used when VSXLEN=32, and the RV64 values when VSXLEN=64.
+[%autowidth,float="center",align="center",cols="<,<",options="header"]
+|===
+|Value |Meaning
+|`0x00002000` +
+`0x00002020`
+|32-bit read for VS-stage address translation (RV32) +
+32-bit write for VS-stage address translation (RV32)
+
+|`0x00003000` +
+`0x00003020`
+|64-bit read for VS-stage address translation (RV64) +
+64-bit write for VS-stage address translation (RV64)
+|===
+
+The defined pseudoinstruction values are designed to correspond closely
+with the encodings of basic loads and stores, as illustrated by
+<<pseudoinsts-basis>>.
+
+[[pseudoinsts-basis]]
+.Standard instructions corresponding to the special pseudoinstructions of <<pseudoinsts>>.
+[%autowidth,float="center",align="center",cols="<,<",options="header"]
+|===
+|Encoding |Instruction
+|`0x00002003` +
+`0x00002023`
+|`lw x0,0(x0)` +
+`sw x0,0(x0)`
+
+|`0x00003003` +
+`0x00003023`
+|`ld x0,0(x0)` +
+`sd x0,0(x0)`
+|===
+
+A _write_ pseudoinstruction (`0x00002020` or `0x00003020`) is used for
+the case that the machine is attempting automatically to update bits A
+and/or D in VS-level page tables. All other implicit memory accesses for
+VS-stage address translation will be reads. If a machine never
+automatically updates bits A or D in VS-level page tables (leaving this
+to software), the _write_ case will never arise. The fact that such a
+page table update must actually be atomic, not just a simple write, is
+ignored for the pseudoinstruction.
+
+[NOTE]
+====
+If the conditions that necessitate a pseudoinstruction value can ever
+occur for M-mode, then `mtinst` cannot be entirely read-only zero; and
+likewise for HS-mode and `htinst`. However, in that case, the trap
+instruction registers may minimally support only values 0 and
+`0x00002000` or `0x00003000`, and possibly `0x00002020` or `0x00003020`,
+requiring as few as one or two flip-flops in hardware, per register.
+
+***
+
+There is no harm here in ignoring the atomicity requirement for page
+table updates, because a hypervisor is not expected in these
+circumstances to emulate an implicit memory access that fails. Rather,
+the hypervisor is given enough information about the faulting access to
+be able to make the memory accessible (e.g. by restoring a missing page
+of virtual memory) before resuming execution by retrying the faulting
+instruction.
+====
+
+==== Trap Return
+
+The MRET instruction is used to return from a trap taken into M-mode.
+MRET first determines what the new privilege mode will be according to
+the values of MPP and MPV in `mstatus` or `mstatush`, as encoded in
+<<h-mpp>>. MRET then in `mstatus`/`mstatush` sets
+MPV=0, MPP=0, MIE=MPIE, and MPIE=1. Lastly, MRET sets the privilege mode
+as previously determined, and sets `pc`=`mepc`.
+
+The SRET instruction is used to return from a trap taken into HS-mode or
+VS-mode. Its behavior depends on the current virtualization mode.
+
+When executed in M-mode or HS-mode (i.e., V=0), SRET first determines
+what the new privilege mode will be according to the values in
+`hstatus`.SPV and `sstatus`.SPP, as encoded in
+<<h-spp>>. SRET then sets `hstatus`.SPV=0, and in
+`sstatus` sets SPP=0, SIE=SPIE, and SPIE=1. Lastly, SRET sets the
+privilege mode as previously determined, and sets `pc`=`sepc`.
+
+When executed in VS-mode (i.e., V=1), SRET sets the privilege mode
+according to <<h-vspp>>, in `vsstatus` sets SPP=0,
+SIE=SPIE, and SPIE=1, and lastly sets `pc`=`vsepc`.
+
+If the Ssdbltrp extension is implemented, when `SRET` is executed in HS-mode,
+if the new privilege mode is VU, the `SRET` instruction sets `vsstatus.SDT`
+to 0. When executed in VS-mode, `vsstatus.SDT` is set to 0.
diff --git a/src/hypervisor.tex b/src/hypervisor.tex
deleted file mode 100644
index 98a54ac..0000000
--- a/src/hypervisor.tex
+++ /dev/null
@@ -1,1474 +0,0 @@
-\chapter{Hypervisor Extension, Version 0.2-draft}
-\label{hypervisor}
-
-This chapter describes the RISC-V hypervisor extension, which virtualizes the
-supervisor-level architecture to support the efficient hosting of guest
-operating systems atop a type-1 or type-2 hypervisor.
-The hypervisor extension changes supervisor mode into
-{\em hypervisor-extended supervisor mode} (HS-mode, or {\em hypervisor
-mode} for short), where a hypervisor or a hosting-capable operating system
-runs. The hypervisor extension also adds another level of address translation,
-from {\em guest physical addresses} to supervisor physical addresses,
-to virtualize the
-memory and memory-mapped I/O subsystems for a guest operating system. HS-mode
-acts the same as S-mode, but with additional instructions and CSRs that control
-the new level of address translation and support hosting a guest OS in virtual
-S-mode (VS-mode).
-Regular S-mode operating systems can execute without modification either in
-HS-mode or as VS-mode guests.
-
-In HS-mode, an OS or hypervisor interacts with the machine through the same
-SBI as an OS normally does from S-mode. An HS-mode hypervisor is expected to
-implement the SBI for its VS-mode guest.
-
-The hypervisor extension is enabled by setting bit 7 in the {\tt misa} CSR,
-which corresponds to the letter H. When {\tt misa}[7] is clear, the hart
-behaves as though this extension were not implemented, and attempts to use
-hypervisor CSRs or instructions raise an illegal instruction exception.
-Implementations that include the hypervisor extension are encouraged
-not to hardwire {\tt misa}[7], so that the extension may be disabled.
-
-\begin{commentary}
-This draft is based on earlier proposals by John Hauser and Paolo Bonzini.
-\end{commentary}
-
-\begin{commentary}
-The baseline privileged architecture is designed to simplify the use of classic
-virtualization techniques, where a guest OS is run at user-level, as
-the few privileged instructions can be easily detected and trapped.
-The hypervisor extension improves virtualization performance by
-reducing the frequency of these traps.
-
-The hypervisor extension has been designed to be efficiently
-emulable on platforms that do not implement the extension, by running
-the hypervisor in S-mode and trapping into M-mode for hypervisor CSR accesses
-and to maintain shadow page tables. The majority of CSR accesses for
-type-2 hypervisors are valid S-mode accesses so need not be trapped.
-Hypervisors can support nested virtualization analogously.
-\end{commentary}
-
-\section{Privilege Modes}
-
-The current {\em virtualization mode}, denoted V, indicates whether the hart
-is currently executing in a guest.
-When V=1, the hart is either in virtual S-mode (VS-mode), or in virtual U-mode
-(VU-mode) under a guest OS running in VS-mode.
-When V=0, the hart is either in M-mode, in HS-mode, or in U-mode under an OS
-running in HS-mode.
-The virtualization mode also indicates whether two-level address translation
-is active (V=1) or inactive (V=0). Table~\ref{h-operating-modes} lists the
-possible operating modes of a RISC-V hart with the hypervisor extension.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|c|c||l|l|l|}
- \hline
- Virtualization & Privilege & \multirow{2}{*}{Abbreviation} & \multirow{2}{*}{Name} & Two-Level \\
- Mode (V) & Encoding & & & Translation \\ \hline
- 0 & 0 & U-mode & User mode & Off \\
- 0 & 1 & HS-mode & Hypervisor-extended supervisor mode & Off \\
- 0 & 3 & M-mode & Machine mode & Off \\
- \hline
- 1 & 0 & VU-mode & Virtual user mode & On \\
- 1 & 1 & VS-mode & Virtual supervisor mode & On \\
- \hline
- \end{tabular}
-\end{center}
-\caption{Operating modes with the hypervisor extension.}
-\label{h-operating-modes}
-\end{table*}
-
-\section{Hypervisor CSRs}
-
-An OS or hypervisor running in HS-mode uses the supervisor CSRs to interact with the exception,
-interrupt, and address-translation subsystems.
-Additional CSRs are provided to HS-mode, but not to VS-mode, to manage
-two-level address translation and to control the behavior of a VS-mode guest:
-{\tt hstatus}, {\tt hedeleg}, {\tt hideleg}, and {\tt hgatp}.
-
-Additionally, several {\em background} supervisor CSRs are copies of one of
-the existing {\em foreground} supervisor CSRs. For example, the {\tt
-bsstatus} CSR is the background copy of the foreground {\tt sstatus} CSR.
-When transitioning between virtualization modes (V=0 to V=1, or vice-versa),
-the implementation swaps the background supervisor CSRs with their foreground
-counterparts. When V=0, the background supervisor CSRs contain VS-mode's
-version of those CSRs, and the foreground supervisor CSRs contain
-HS-mode's version. When V=1, the background supervisor CSRs contain HS-mode's
-version, and the foreground supervisor CSRs contain VS-mode's
-version. The background registers are accessible to HS-mode, but not to
-VS-mode.
-
-\begin{commentary}
-The swapping of foreground and background supervisor registers can be
-implemented either by physically copying bits or by dynamically changing the
-CSR addresses of hardware registers.
-The CSR addresses of the background supervisor registers have been aligned with
-their foreground counterparts to minimize the cost of swapping registers simply
-by changing their addresses.
-\end{commentary}
-
-In this section, we use the term {\em HSXLEN} to refer to the effective XLEN
-when executing in HS-mode.
-
-\subsection{Hypervisor Status Register ({\tt hstatus})}
-
-The {\tt hstatus} register is an HSXLEN-bit read/write register
-formatted as shown in Figure~\ref{hstatusreg}. The {\tt hstatus}
-register provides facilities analogous to the {\tt mstatus} register
-that track and control the exception behavior of a VS-mode guest.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{ScccRccccFc}
-\\
-\instbitrange{HSXLEN-1}{23} &
-\instbit{22} &
-\instbit{21} &
-\instbit{20} &
-\instbitrange{19}{11} &
-\instbit{10} &
-\instbit{9} &
-\instbit{8} &
-\instbit{7} &
-\instbitrange{6}{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{\wpri} &
-\multicolumn{1}{c|}{VTSR} &
-\multicolumn{1}{c|}{VTW} &
-\multicolumn{1}{c|}{VTVM} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPV} &
-\multicolumn{1}{c|}{STL} &
-\multicolumn{1}{c|}{SP2P} &
-\multicolumn{1}{c|}{SP2V} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPRV} \\
-\hline
-HSXLEN-23 & 1 & 1 & 1 & 9 & 1 & 1 & 1 & 1 & 6 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Hypervisor-mode status register ({\tt hstatus}).}
-\label{hstatusreg}
-\end{figure*}
-
-The {\tt hstatus} fields VTSR, VTW, and VTVM are defined analogously to the
-{\tt mstatus} fields TSR, TW, and TVM, but affect the trapping behavior of the
-SRET, WFI, and virtual-memory management instructions only when V=1.
-
-The SPV bit (Supervisor Previous Virtualization Mode) is written by the implementation
-whenever a trap is taken into HS-mode. Just as the SPP bit in {\tt sstatus} is set to the privilege
-mode at the time of the trap, the SPV bit in {\tt hstatus} is set to the value of the virtualization
-mode V at the time of the trap. When an SRET instruction is executed when V=0,
-V is set to SPV.
-
-When a trap is taken into HS-mode, bits SP2V and SP2P are set to the values
-that SPV and the HS-level SPP had before the trap.
-(Before the trap, the HS-level SPP is {\tt sstatus}.SPP if V=0, or
-{\tt bsstatus}.SPP if V=1.)
-When an SRET instruction is executed when V=0, the reverse assignments occur:
-after SPV and {\tt sstatus}.SPP have supplied the new virtualization and
-privilege modes, they are written with SP2V and SP2P, respectively.
-
-The STL bit (Supervisor Translation Level), which indicates which address-translation level
-caused an access-fault or page-fault exception, is also written by the implementation whenever a trap
-is taken into HS-mode.
-On an access or page fault due to guest physical address translation, STL is
-set to 1.
-For any other trap into HS-mode, STL is set to 0.
-
-The SPRV bit modifies the privilege with which loads and stores execute when
-not in M-mode.
-When SPRV=0, translation and protection behave as normal. When SPRV=1,
-load and store memory addresses are translated and protected as though
-the current virtualization mode were set to {\tt hstatus}.SPV and the current
-privilege mode were set to the HS-level SPP ({\tt sstatus}.SPP when V=0, or
-{\tt bsstatus}.SPP when V=1).
-Table~\ref{h-sprv} enumerates the cases.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|c|c|c||p{4.7in}|}
- \hline
- SPRV & SPV & SPP & Effect \\ \hline \hline
- 0 & -- & -- & Normal access; current privilege and virtualization modes apply. \\ \hline
- 1 & 0 & 0 & U-level access with HS-level translation and protection only. \\ \hline
- 1 & 0 & 1 & HS-level access with HS-level translation and protection only. \\ \hline
- 1 & 1 & 0 & VU-level access with two-level translation and protection. The HS-level MXR bit makes any executable page readable. The VS-level MXR makes readable those pages marked executable at the VS translation level only if readable at the guest-physical translation level. \\ \hline
- 1 & 1 & 1 & VS-level access with two-level translation and protection. The HS-level MXR bit makes any executable page readable. The VS-level MXR makes readable those pages marked executable at the VS translation level only if readable at the guest-physical translation level. The VS-level SUM bit applies instead of HS-level SUM. \\ \hline
- \end{tabular}
-\end{center}
-\caption{Effect on load and store translation and protection under SPRV.}
-\label{h-sprv}
-\end{table*}
-
-\begin{commentary}
-For simplicity, SPRV is in effect even when in U-mode, VS-mode, or VU-mode, but
-in normal use will only be enabled for short sequences in HS-mode.
-\end{commentary}
-
-\subsection{Hypervisor Trap Delegation Registers ({\tt hedeleg} and {\tt hideleg})}
-
-By default, all traps at any privilege level are handled in M-mode, though
-M-mode usually uses the {\tt medeleg} and {\tt mideleg} CSRs to delegate
-some traps to HS-mode. The {\tt hedeleg} and {\tt hideleg} CSRs allow these
-traps to be further delegated to a VS-mode guest; their layout is the same
-as {\tt medeleg} and {\tt mideleg}.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}U}
-\instbitrange{HSXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{Synchronous Exceptions (\warl)} \\
-\hline
-HSXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Hypervisor Exception Delegation Register {\tt hedeleg}.}
-\label{hedelegreg}
-\end{figure}
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}U}
-\instbitrange{HSXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{Interrupts (\warl)} \\
-\hline
-HSXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Hypervisor Interrupt Delegation Register {\tt hideleg}.}
-\label{hidelegreg}
-\end{figure}
-
-The {\tt hedeleg} and {\tt hideleg} registers are only active when V=1. When
-V=1, a trap that has been delegated to HS-mode (using {\tt medeleg} or {\tt
-mideleg}) is further delegated to VS-mode if the corresponding {\tt hedeleg} or
-{\tt hideleg} bit is set. If the N extension for user-mode interrupts
-is implemented, the VS-mode guest may further delegate the interrupt
-to VU-mode by setting the corresponding bit in {\tt sedeleg} or {\tt sideleg}.
-
-When V=0 and the N extension for user-mode interrupts is implemented, a trap
-that has been delegated to HS-mode can be further delegated to U-mode by
-setting the corresponding bit in {\tt sedeleg} or {\tt sideleg}.
-
-When an access-fault or page-fault exception is caused by guest physical
-address translation, the trap is not delegated beyond HS-mode, regardless of
-the setting of {\tt hedeleg}.
-
-\subsection{Hypervisor Guest Address Translation and Protection Register ({\tt hgatp})}
-\label{sec:hgatp}
-
-The {\tt hgatp} register is an HSXLEN-bit read/write register, formatted as
-shown in Figure~\ref{rv32hgatp} for HSXLEN=32 and Figure~\ref{rv64hgatp} for
-HSXLEN=64, which controls guest physical address translation and protection.
-Similar to CSR {\tt satp}, this register holds the physical page number (PPN)
-of the guest-physical root page table; a virtual machine identifier (VMID),
-which facilitates address-translation fences on a per-virtual-machine basis;
-and the MODE field, which selects the address-translation scheme for guest
-physical addresses.
-When {\tt mstatus}.TVM=1, attempts to read or write {\tt hgatp} while executing
-in HS-mode will raise an illegal instruction exception.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{cY@{}E@{}K}
-\instbit{31} &
-\instbitrange{30}{29} &
-\instbitrange{28}{22} &
-\instbitrange{21}{0} \\
-\hline
-\multicolumn{1}{|c|}{MODE} &
-\multicolumn{1}{|c|}{0 (\warl)} &
-\multicolumn{1}{|c|}{VMID (\warl)} &
-\multicolumn{1}{|c|}{PPN (\warl)} \\
-\hline
-1 & 2 & 7 & 22 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{RV32 Hypervisor guest address translation and protection register
-{\tt hgatp}.}
-\label{rv32hgatp}
-\end{figure}
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}S@{}Y@{}E@{}K}
-\instbitrange{63}{60} &
-\instbitrange{59}{58} &
-\instbitrange{57}{44} &
-\instbitrange{43}{0} \\
-\hline
-\multicolumn{1}{|c|}{MODE (\warl)} &
-\multicolumn{1}{|c|}{0 (\warl)} &
-\multicolumn{1}{|c|}{VMID (\warl)} &
-\multicolumn{1}{|c|}{PPN (\warl)} \\
-\hline
-4 & 2 & 14 & 44 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{RV64 Hypervisor guest address translation and protection register
-{\tt hgatp}, for MODE values Bare, Sv39x4, and Sv48x4.}
-\label{rv64hgatp}
-\end{figure}
-
-Table~\ref{tab:hgatp-mode} shows the encodings of the MODE field for RV32 and
-RV64.
-When MODE=Bare, guest physical addresses are equal to supervisor physical
-addresses, and there is no further memory protection for a guest virtual
-machine beyond the physical memory protection scheme described in
-Section~\ref{sec:pmp}.
-In this case, the remaining fields in {\tt hgatp} have no effect.
-
-For RV32, the only other valid setting for MODE is Sv32x4, which is a
-modification of the usual Sv32 paged virtual-memory scheme, extended to support
-34-bit guest physical addresses.
-For RV64, modes Sv39x4 and Sv48x4 are defined as modifications of the Sv39 and
-Sv48 paged virtual-memory schemes.
-All these paged virtual-memory schemes are described in
-Section~\ref{sec:guest-addr-translation}.
-An additional RV64 scheme, Sv57x4, may be defined in a later version of this
-specification.
-
-The remaining MODE settings for RV64 are reserved for future use and may define
-different interpretations of the other fields in {\tt hgatp}.
-
-RV64 implementations are not required to support all defined RV64 MODE
-settings.
-(However, a write to {\tt hgatp} with an unsupported MODE value is not ignored
-as it is for {\tt satp}.)
-
-\begin{table}[h]
-\begin{center}
-\begin{tabular}{|c|c|l|}
-\hline
-\multicolumn{3}{|c|}{RV32} \\
-\hline
-Value & Name & Description \\
-\hline
-0 & Bare & No translation or protection. \\
-1 & Sv32x4 & Page-based 34-bit virtual addressing (2-bit extension of Sv32). \\
-\hline \hline
-\multicolumn{3}{|c|}{RV64} \\
-\hline
-Value & Name & Description \\
-\hline
-0 & Bare & No translation or protection. \\
-1--7 & --- & {\em Reserved} \\
-8 & Sv39x4 & Page-based 41-bit virtual addressing (2-bit extension of Sv39). \\
-9 & Sv48x4 & Page-based 50-bit virtual addressing (2-bit extension of Sv48). \\
-10 & {\em Sv57x4} & {\em Reserved for page-based 59-bit virtual addressing.} \\
-11--15 & --- & {\em Reserved} \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Encoding of {\tt hgatp} MODE field.}
-\label{tab:hgatp-mode}
-\end{table}
-
-As explained in Section~\ref{sec:guest-addr-translation}, for the paged
-virtual-memory schemes (Sv32x4, Sv39x4, and Sv48x4), the root page table is
-16~KiB and must be aligned to a 16-KiB boundary.
-In these modes, the lowest two bits of the physical page number (PPN) in
-{\tt hgatp} are ignored.
-An implementation that supports only the defined paged virtual-memory schemes
-and/or Bare may hardwire PPN[1:0] to zero.
-
-The number of supervisor physical address bits is implementation-defined; any
-unimplemented address bits are hardwired to zero in {\tt hgatp}.PPN.
-The number of VMID bits is also implementation-defined and may be zero.
-The number of implemented VMID bits, termed {\mbox {\em VMIDLEN}}, may be
-determined by writing one to every bit position in the VMID field, then reading
-back the value in {\tt hgatp} to see which bit positions in the VMID field hold
-a one.
-The least-significant bits of VMID are implemented first:
-that is, if VMIDLEN~$>$~0, VMID[VMIDLEN-1:0] is writable.
-The maximal value of VMIDLEN, termed VMIDMAX, is 7 for Sv32x4 or 14 for Sv39x4
-and Sv48x4.
-
-Note that writing {\tt hgatp} does not imply any ordering constraints between
-page-table updates and subsequent guest physical address translations.
-If the new virtual machine's guest physical page tables have been modified, it
-may be necessary to execute an HFENCE.GVMA instruction
-(see Section~\ref{sec:hfence.vma}) before or after writing {\tt hgatp}.
-
-\subsection{Background Supervisor Status Register ({\tt bsstatus})}
-
-The {\tt bsstatus} register is an HSXLEN-bit read/write register formatted as
-shown in Figure~\ref{bsstatusreg}. When V=0, the {\tt bsstatus} register
-holds VS-mode's version of several fields of the {\tt sstatus}
-register: UXL, MXR, SUM, FS, SPP, SPIE, and SIE. When V=1, {\tt bsstatus}
-holds HS-mode's version of these fields. When transitioning between
-virtualization modes (V=0 to V=1, or vice-versa), the implementation swaps
-these fields in {\tt bsstatus} with their counterparts in {\tt sstatus}. The
-other fields in {\tt sstatus} are unchanged.
-
-When V=1, both {\tt bsstatus}.FS and {\tt sstatus}.FS are in effect. Attempts
-to execute a floating-point instruction when either field is 0 (Off) raise an
-illegal-instruction exception. Modifying the floating-point state when V=1
-causes both fields to be set to 3 (Dirty).
-
-When V=0, {\tt bsstatus} does not directly affect the behavior of the machine,
-unless the MPRV feature in the {\tt mstatus} register or the SPRV feature
-in the {\tt hstatus} register is used to execute a load or store
-{\em as though} V=1.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{McEccc}
-\\
-\instbitrange{HSXLEN-1}{34} &
-\instbitrange{33}{32} &
-\instbitrange{31}{20} &
-\instbit{19} &
-\instbit{18} &
- \\
-\hline
-\multicolumn{1}{|c|}{\wpri} &
-\multicolumn{1}{c|}{UXL} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{MXR} &
-\multicolumn{1}{c|}{SUM} &
- \\
-\hline
-HSXLEN-34 & 2 & 12 & 1 & 1 & \\
-\end{tabular}
-\begin{tabular}{cFFYcWcFcc}
-\\
-&
-\instbitrange{17}{15} &
-\instbitrange{14}{13} &
-\instbitrange{12}{9} &
-\instbit{8} &
-\instbitrange{7}{6} &
-\instbit{5} &
-\instbitrange{4}{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
- &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{FS[1:0]} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPP} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SIE} &
-\multicolumn{1}{c|}{\wpri} \\
-\hline
- & 3 & 2 & 4 & 1 & 2 & 1 & 3 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Background supervisor status register ({\tt bsstatus}) for RV64 and RV128.}
-\label{bsstatusreg}
-\end{figure*}
-
-\subsection{Background Supervisor Interrupt Registers ({\tt bsip} and {\tt bsie})}
-
-The {\tt bsip} register is an HSXLEN-bit read/write register formatted as shown
-in Figure~\ref{bsipreg}. When V=0, the {\tt bsip} register holds VS-mode's
-version of the {\tt sip} register. When V=1, {\tt bsip} holds
-HS-mode's version of the {\tt sip} register. When transitioning between
-virtualization modes (V=0 to V=1, or vice-versa), the implementation swaps the
-defined fields of {\tt bsip} with their counterparts in {\tt sip}. The
-other fields in {\tt sip} are unchanged.
-
-\note{AW: Need to describe how {\tt bsip}.SEIP interacts with PLIC. I think {\tt bsip}.SEIP should purely be a read-write storage bit to emulate the PLIC for VS-mode; the PLIC should not be wired into {\tt bsip}.SEIP.}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{TcFcFcc}
-\instbitrange{HSXLEN-1}{10} &
-\instbit{9} &
-\instbitrange{8}{6} &
-\instbit{5} &
-\instbitrange{4}{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{\wpri} &
-\multicolumn{1}{c|}{SEIP} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{STIP} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SSIP} &
-\multicolumn{1}{c|}{\wpri} \\
-\hline
-HSXLEN-10 & 1 & 3 & 1 & 3 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Background supervisor interrupt-pending register ({\tt bsip}).}
-\label{bsipreg}
-\end{figure*}
-
-The {\tt bsie} register is an HSXLEN-bit read/write register formatted as shown
-in Figure~\ref{bsiereg}. When V=0, the {\tt bsie} register holds VS-mode's
-version of the {\tt sie} register. When V=1, {\tt bsie} holds
-HS-mode's version of the {\tt sie} register. When transitioning between
-virtualization modes (V=0 to V=1, or vice-versa), the implementation swaps the
-defined fields of {\tt bsie} with their counterparts in {\tt sie}. The
-other fields in {\tt sie} are unchanged.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{TcFcFcc}
-\instbitrange{HSXLEN-1}{10} &
-\instbit{9} &
-\instbitrange{8}{6} &
-\instbit{5} &
-\instbitrange{4}{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{\wpri} &
-\multicolumn{1}{c|}{SEIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{STIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SSIE} &
-\multicolumn{1}{c|}{\wpri} \\
-\hline
-HSXLEN-10 & 1 & 3 & 1 & 3 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Background supervisor interrupt-enable register ({\tt bsie}).}
-\label{bsiereg}
-\end{figure*}
-
-When V=0, {\tt bsip} and {\tt bsie} do not affect the behavior of the machine.
-When V=1, they hold the active interrupt-pending and interrupt-enable bits,
-respectively, for HS-mode; if any bit position holds a 1 in both registers, an
-interrupt will be taken.
-
-\begin{commentary}
-The {\tt bsip} and {\tt bsie} CSRs do not hold copies of the user-mode
-interrupt fields. The expectation is that the context-switch code
-will swap the {\tt uip} and {\tt uie} CSRs
-along with the other user-mode interrupt
-registers ({\tt ustatus}, {\tt utvec}, etc.) if that feature is enabled.
-\end{commentary}
-
-\subsection{Background Supervisor Trap Vector Base Address Register ({\tt bstvec})}
-
-The {\tt bstvec} register is an HSXLEN-bit read/write register formatted as shown
-in Figure~\ref{bstvecreg}. When V=0, the {\tt bstvec} register holds VS-mode's
-version of the {\tt stvec} register. When V=1, {\tt bstvec}
-holds HS-mode's version of the {\tt stvec} register. When transitioning between
-virtualization modes (V=0 to V=1, or vice-versa), the implementation swaps the
-contents of {\tt bstvec} and {\tt stvec}.
-
-When V=0, {\tt bstvec} does not directly affect the behavior of the machine. When V=1,
-it controls the value to which the {\tt pc} will be set upon a trap into
-HS-mode.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{J@{}R}
-\instbitrange{HSXLEN-1}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{BASE[HSXLEN-1:2] (\warl)} &
-\multicolumn{1}{c|}{MODE (\warl)} \\
-\hline
-HSXLEN-2 & 2 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Background supervisor trap vector base address register ({\tt bstvec}).}
-\label{bstvecreg}
-\end{figure*}
-
-\subsection{Background Supervisor Scratch Register ({\tt bsscratch})}
-
-The {\tt bsscratch} register is an HSXLEN-bit read/write register formatted as shown
-in Figure~\ref{bsscratchreg}. When V=0, the {\tt bsscratch} register holds
-VS-mode's version of the {\tt sscratch} register. When V=1, {\tt bsscratch}
-holds HS-mode's version of the {\tt sscratch} register. When transitioning between
-virtualization modes (V=0 to V=1, or vice-versa), the implementation swaps the
-contents of {\tt bsscratch} and {\tt sscratch}.
-
-Typically, {\tt bsscratch} is used to hold a pointer to the hart-local
-hypervisor context (when V=1) or supervisor context (when V=0). The
-contents of {\tt bsscratch} do not directly affect the behavior of
-the machine.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{HSXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt bsscratch} \\
-\hline
-HSXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Background supervisor scratch register ({\tt bsscratch}).}
-\label{bsscratchreg}
-\end{figure*}
-
-\subsection{Background Supervisor Exception Program Counter ({\tt bsepc})}
-
-The {\tt bsepc} register is an HSXLEN-bit read/write register formatted as shown
-in Figure~\ref{bsepcreg}. When V=0, the {\tt bsepc} register holds
-VS-mode's version of the {\tt sepc} register. When V=1, {\tt bsepc}
-holds HS-mode's version of the {\tt sepc} register. When transitioning between
-virtualization modes (V=0 to V=1, or vice-versa), the implementation swaps the
-contents of {\tt bsepc} and {\tt sepc}.
-
-The contents of {\tt bsepc} do not directly affect the behavior of
-the machine.
-
-{\tt bsepc} is a \warl\ register that must be able to hold the same set of
-values that {\tt sepc} can hold.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{HSXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt bsepc} \\
-\hline
-HSXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Background supervisor exception program counter ({\tt bsepc}).}
-\label{bsepcreg}
-\end{figure*}
-
-\subsection{Background Supervisor Cause Register ({\tt bscause})}
-
-The {\tt bscause} register is an HSXLEN-bit read/write register formatted as shown
-in Figure~\ref{bscausereg}. When V=0, the {\tt bscause} register holds
-VS-mode's version of the {\tt scause} register. When V=1, {\tt bscause}
-holds HS-mode's version of the {\tt scause} register. When transitioning between
-virtualization modes (V=0 to V=1, or vice-versa), the implementation swaps the
-contents of {\tt bscause} and {\tt scause}.
-
-The contents of {\tt bscause} do not directly affect the behavior of
-the machine.
-
-{\tt bscause} is a \wlrl\ register that must be able to hold the same set of
-values that {\tt scause} can hold.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{c@{}U}
-\instbit{HSXLEN-1} &
-\instbitrange{HSXLEN-2}{0} \\
-\hline
-\multicolumn{1}{|c|}{Interrupt} &
-\multicolumn{1}{c|}{Exception Code (\wlrl)} \\
-\hline
-1 & HSXLEN-1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Background supervisor cause register ({\tt bscause}).}
-\label{bscausereg}
-\end{figure*}
-
-\subsection{Background Supervisor Trap Value Register ({\tt bstval})}
-
-The {\tt bstval} register is an HSXLEN-bit read/write register formatted as shown
-in Figure~\ref{bstvalreg}. When V=0, the {\tt bstval} register holds
-VS-mode's version of the {\tt stval} register. When V=1, {\tt bstval}
-holds HS-mode's version of the {\tt stval} register. When transitioning between
-virtualization modes (V=0 to V=1, or vice-versa), the implementation swaps the
-contents of {\tt bstval} and {\tt stval}.
-
-The contents of {\tt bstval} do not directly affect the behavior of
-the machine.
-
-{\tt bstval} is a \warl\ register that must be able to hold the same set of
-values that {\tt stval} can hold.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{HSXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt bstval} \\
-\hline
-HSXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Background supervisor trap value register ({\tt bstval}).}
-\label{bstvalreg}
-\end{figure*}
-
-\subsection{Background Supervisor Address Translation and Protection Register ({\tt bsatp})}
-
-The {\tt bsatp} register is an HSXLEN-bit read/write register formatted as shown
-in Figure~\ref{rv32bsatpreg} for RV32 and Figure~\ref{rv64bsatpreg} for RV64.
-When V=0, the {\tt bsatp} register holds VS-mode's version of the
-{\tt satp} register. When V=1, {\tt bsatp} holds HS-mode's version of the
-{\tt satp} register. When transitioning between virtualization modes (V=0 to
-V=1, or vice-versa), the implementation swaps the contents of {\tt bsatp} and
-{\tt satp}.
-
-{\tt bsatp} does not directly affect the behavior of the machine, unless the
-MPRV feature in the {\tt mstatus} register or the SPRV feature in the
-{\tt hstatus} register is used to execute a load or store {\em as though} V is
-the opposite of its actual setting.
-The interpretation of the MODE, ASID, and PPN
-fields is the same as for {\tt satp}.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{c@{}E@{}K}
-\instbit{31} &
-\instbitrange{30}{22} &
-\instbitrange{21}{0} \\
-\hline
-\multicolumn{1}{|c|}{MODE (\warl)} &
-\multicolumn{1}{|c|}{ASID (\warl)} &
-\multicolumn{1}{|c|}{PPN (\warl)} \\
-\hline
-1 & 9 & 22 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{RV32 background supervisor address translation and protection register {\tt bsatp}.}
-\label{rv32bsatpreg}
-\end{figure}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}S@{}T@{}U}
-\instbitrange{63}{60} &
-\instbitrange{59}{44} &
-\instbitrange{43}{0} \\
-\hline
-\multicolumn{1}{|c|}{MODE (\warl)} &
-\multicolumn{1}{|c|}{ASID (\warl)} &
-\multicolumn{1}{|c|}{PPN (\warl)} \\
-\hline
-4 & 16 & 44 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{RV64 background supervisor address translation and protection register {\tt bsatp}, for MODE
-values Bare, Sv39, and Sv48.}
-\label{rv64bsatpreg}
-\end{figure*}
-
-\section{Hypervisor Instructions}
-
-The hypervisor extension adds two new privileged fence instructions.
-
-\subsection{Hypervisor Memory-Management Fence Instructions}
-\label{sec:hfence.vma}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{O@{}R@{}R@{}F@{}R@{}S}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct7} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-HFENCE.GVMA & vmid & gaddr & PRIV & 0 & SYSTEM \\
-HFENCE.BVMA & asid & vaddr & PRIV & 0 & SYSTEM \\
-\end{tabular}
-\end{center}
-
-The hypervisor memory-management fence instructions, HFENCE.GVMA and
-HFENCE.BVMA, are valid only in HS-mode when {\tt mstatus}.TVM=0, or in M-mode
-(irrespective of {\tt mstatus}.TVM).
-These instructions perform a function similar to SFENCE.VMA
-(Section~\ref{sec:sfence.vma}), except applying to the guest-physical
-memory-management data structures controlled by CSR {\tt hgatp} (HFENCE.GVMA)
-or the VS-level memory-management data structures controlled by CSR {\tt bsatp}
-(HFENCE.BVMA).
-Instruction SFENCE.VMA applies only to the memory-management data structures
-controlled by the foreground {\tt satp}.
-
-If an HFENCE.BVMA instruction executes without trapping, its effect is much the
-same as temporarily entering VS-mode (with the usual swapping of foreground and
-background supervisor registers) and executing SFENCE.VMA.
-Executing an HFENCE.BVMA guarantees that any stores in the instruction stream
-prior to the HFENCE.BVMA are ordered before implicit references to VS-level
-memory-management data structures when those implicit references
-\begin{compactitem}
-\item
-are subsequent to the HFENCE.BVMA, and
-\item
-occur when {\tt hgatp}.VMID has the same setting as it did when HFENCE.BVMA
-executed.
-\end{compactitem}
-Implicit references need not be ordered when {\tt hgatp}.VMID is different than
-at the time HFENCE.BVMA executed.
-If operand {\em rs1}$\neq${\tt x0}, it specifies a single guest virtual
-address, and if operand {\em rs2}$\neq${\tt x0}, it specifies a single guest
-address-space identifier
-(ASID).
-
-\begin{commentary}
-An HFENCE.BVMA instruction applies only to a single virtual machine, identified
-by the setting of {\tt hgatp}.VMID when HFENCE.BVMA executes.
-\end{commentary}
-
-When {\em rs2}$\neq${\tt x0}, bits XLEN-1:ASIDMAX of the value held in {\em
-rs2} are reserved for future use and should be zeroed by software and ignored
-by current implementations.
-Furthermore, if ASIDLEN~$<$~ASIDMAX, the implementation shall ignore bits
-ASIDMAX-1:ASIDLEN of the value held in {\em rs2}.
-
-\begin{commentary}
-Simpler implementations of HFENCE.BVMA can ignore the guest virtual address in
-{\em rs1} and the guest ASID value in {\em rs2}, as well as {\tt hgatp}.VMID,
-and always perform a global fence for the VS-level memory management of all
-virtual machines, or even a global fence for all memory-management data
-structures.
-\end{commentary}
-
-Executing an HFENCE.GVMA instruction guarantees that any stores in the
-instruction stream prior to the HFENCE.GVMA are ordered before all implicit
-references to guest-physical memory-management data structures subsequent to
-the HFENCE.GVMA.
-If operand {\em rs1}$\neq${\tt x0}, it specifies a single guest physical
-address, shifted right by 2~bits, and if operand {\em rs2}$\neq${\tt x0}, it
-specifies a single virtual machine identifier (VMID).
-
-\begin{commentary}
-For HFENCE.GVMA, a guest physical address specified in {\em rs1} is shifted
-right by 2~bits to accommodate addresses wider than the current XLEN.
-For RV32, the hypervisor extension permits guest physical addresses as wide as
-34 bits, and {\em rs1} specifies bits 33:2 of such an address.
-This shift-by-2 encoding of guest physical addresses matches the encoding of
-physical addresses in PMP address registers (Section~\ref{sec:pmp}) and in page
-table entries (Sections \ref{sec:sv32}, \ref{sec:sv39}, and~\ref{sec:sv48}).
-\end{commentary}
-
-When {\em rs2}$\neq${\tt x0}, bits XLEN-1:VMIDMAX of the value held in {\em
-rs2} are reserved for future use and should be zeroed by software and ignored
-by current implementations.
-Furthermore, if VMIDLEN~$<$~VMIDMAX, the implementation shall ignore bits
-VMIDMAX-1:VMIDLEN of the value held in {\em rs2}.
-
-\begin{commentary}
-Simpler implementations of HFENCE.GVMA can ignore the guest physical address in
-{\em rs1} and the VMID value in {\em rs2} and always perform a global fence for
-the guest-physical memory management of all virtual machines, or even a global
-fence for all memory-management data structures.
-\end{commentary}
-
-\section{Machine-Level CSRs}
-
-The hypervisor extension augments the {\tt mstatus} CSR.
-
-\subsection{Machine Status Register ({\tt mstatus})}
-
-The hypervisor extension adds two fields to the machine-mode {\tt mstatus} CSR,
-MPV and MTL,
-and modifies the behavior of several existing fields.
-Figure~\ref{hypervisor-mstatus} shows the {\tt mstatus} register when the
-hypervisor extension is provided.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{cRccYccccccc}
-\\
-\instbit{MXLEN-1} &
-\instbitrange{MXLEN-2}{36} &
-\instbitrange{35}{34} &
-\instbitrange{33}{32} &
-\instbitrange{31}{23} &
-\instbit{22} &
-\instbit{21} &
-\instbit{20} &
-\instbit{19} &
-\instbit{18} &
-\instbit{17} &
- \\
-\hline
-\multicolumn{1}{|c|}{SD} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SXL[1:0]} &
-\multicolumn{1}{c|}{UXL[1:0]} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{TSR} &
-\multicolumn{1}{c|}{TW} &
-\multicolumn{1}{c|}{TVM} &
-\multicolumn{1}{c|}{MXR} &
-\multicolumn{1}{c|}{SUM} &
-\multicolumn{1}{c|}{MPRV} &
- \\
-\hline
-1 & MXLEN-37 & 2 & 2 & 9 & 1 & 1 & 1 & 1 & 1 & 1 & \\
-\end{tabular}
-\begin{tabular}{ccccccccccccccc}
-\\
-&
-\instbitrange{16}{15} &
-\instbitrange{14}{13} &
-\instbitrange{12}{11} &
-\instbit{10} &
-\instbit{9} &
-\instbit{8} &
-\instbit{7} &
-\instbit{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
- &
-\multicolumn{1}{|c|}{XS[1:0]} &
-\multicolumn{1}{c|}{FS[1:0]} &
-\multicolumn{1}{c|}{MPP[1:0]} &
-\multicolumn{1}{c|}{MPV} &
-\multicolumn{1}{c|}{MTL} &
-\multicolumn{1}{c|}{SPP} &
-\multicolumn{1}{c|}{MPIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPIE} &
-\multicolumn{1}{c|}{UPIE} &
-\multicolumn{1}{c|}{MIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SIE} &
-\multicolumn{1}{c|}{UIE} \\
-\hline
- & 2 & 2 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine-mode status register ({\tt mstatus}) for RV64 and RV128.}
-\label{hypervisor-mstatus}
-\end{figure*}
-
-The MPV bit (Machine Previous Virtualization Mode) is written by the implementation
-whenever a trap is taken into M-mode. Just as the MPP bit is set to the privilege
-mode at the time of the trap, the MPV bit is set to the value of the virtualization
-mode V at the time of the trap. When an MRET instruction is executed, the
-virtualization mode V is set to MPV, unless MPP=3, in which case V remains 0.
-
-The MTL bit (Machine Translation Level), which indicates which address-translation level
-caused an access-fault or page-fault exception, is also written by the implementation whenever a trap
-is taken into M-mode.
-On an access or page fault due to guest physical address translation, MTL is
-set to 1.
-For any other trap into M-mode, MTL is set to 0.
-
-The SXL field controls the value of XLEN for HS-mode.
-The UXL field controls the value of XLEN for VS-mode or U-mode when V=0, or for
-VU-mode when V=1.
-
-The TSR and TVM fields only affect execution in HS-mode.
-
-The TW field affects execution in all modes except M-mode.
-
-The hypervisor extension changes the behavior of the the Modify Privilege
-field, MPRV. When MPRV=0, translation and protection behave as normal. When
-MPRV=1, loads and stores are translated and protected as though the current
-privilege mode were set to MPP and the current virtualization mode were set to
-MPV. Table~\ref{h-mprv} enumerates the cases.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|c|c|c||p{4.5in}|}
- \hline
- MPRV & MPV & MPP & Effect \\ \hline \hline
- 0 & -- & -- & Normal access; current privilege and virtualization modes apply. \\ \hline
- 1 & 0 & 0 & U-level access with HS-level translation and protection only. \\ \hline
- 1 & 0 & 1 & HS-level access with HS-level translation and protection only. \\ \hline
- 1 & -- & 3 & M-level access with no translation. \\ \hline
- 1 & 1 & 0 & VU-level access with two-level translation and protection. The HS-level MXR bit makes any executable page readable. The VS-level MXR makes readable those pages marked executable at the VS translation level only if readable at the guest-physical translation level. \\ \hline
- 1 & 1 & 1 & VS-level access with two-level translation and protection. The HS-level MXR bit makes any executable page readable. The VS-level MXR makes readable those pages marked executable at the VS translation level only if readable at the guest-physical translation level. The VS-level SUM bit applies instead of HS-level SUM. \\ \hline
- \end{tabular}
-\end{center}
-\caption{Effect on load and store translation and protection under MPRV. When MPRV=1, MPP$\neq$3, and {\tt hstatus}.SPRV=1, the effective privilege is further modified: {\tt hstatus}.SPV applies instead of MPV, and the HS-level SPP applies instead of MPP.}
-\label{h-mprv}
-\end{table*}
-
-The {\tt mstatus} register is a superset of the foreground {\tt sstatus}
-register;
-modifying a field in {\tt sstatus} modifies the homonymous field in {\tt
-mstatus}, and vice-versa.
-
-\section{Two-Level Address Translation}
-\label{sec:two-level-translation}
-
-Whenever the current virtualization mode V is 1 (and assuming both
-{\tt mstatus}.MPRV=0 and {\tt hstatus}.SPRV=0), two-level address translation
-and protection is in effect.
-For any virtual memory access, the original virtual address is first converted
-by VS-level address translation, as controlled by the VS-level {\tt satp}
-register, into a {\em guest physical address}.
-The guest physical address is then converted by guest physical address
-translation, as controlled by the {\tt hgatp} register, into a supervisor
-physical address.
-Although there is no option to disable two-level address translation when V=1,
-either level of translation can be effectively disabled by zeroing the
-corresponding {\tt satp} or {\tt hgatp} register.
-
-The VS-level MXR setting, which makes execute-only pages readable, only
-overrides VS-level page protection.
-Setting MXR at VS-level does not override guest-physical page protections.
-Setting MXR at HS-level, however, overrides both VS-level and guest-physical
-execute-only permissions.
-
-When V=1, memory accesses that would normally bypass address translation are
-subject to guest physical address translation alone.
-This includes memory accesses made in support of VS-level address translation,
-such as reads and writes of VS-level page tables.
-
-Machine-level physical memory protection applies to supervisor physical
-addresses and is in effect regardless of virtualization mode.
-
-\subsection{Guest Physical Address Translation}
-\label{sec:guest-addr-translation}
-
-The mapping of guest physical addresses to supervisor physical addresses is
-controlled by CSR {\tt hgatp} (Section~\ref{sec:hgatp}).
-
-When the address translation scheme selected by the MODE field of {\tt hgatp}
-is Bare, guest physical addresses are equal to supervisor physical addresses
-without modification, and no memory protection applies in the trivial
-translation of guest physical addresses to supervisor physical addresses.
-
-When {\tt hgatp}.MODE specifies a translation scheme of Sv32x4, Sv39x4, or
-Sv48x4, guest physical address translation is a variation on the usual
-page-based virtual address translation scheme of Sv32, Sv39, or Sv48,
-respectively.
-In each case, the size of the incoming address is widened by 2~bits (to 34, 41,
-or 50 bits).
-To accommodate the 2~extra bits, the root page table (only) is expanded by a
-factor of four to be 16~KiB instead of the usual 4~KiB.
-Matching its larger size, the root page table also must be aligned to a 16~KiB
-boundary instead of the usual 4~KiB page boundary.
-Except as noted, all other aspects of Sv32, Sv39, or Sv48 are adopted unchanged
-for guest physical address translation.
-Non-root page tables and all page table entries (PTEs) have the same formats as
-documented in Sections \ref{sec:sv32}, \ref{sec:sv39}, and~\ref{sec:sv48}.
-
-For Sv32x4, an incoming guest physical address is partitioned into a virtual
-page number (VPN) and page offset as shown in Figure~\ref{sv32x4va}.
-This partitioning is identical to that for an Sv32 virtual address as depicted
-in Figure~\ref{sv32va} (page~\pageref{sv32va}), except with 2 more bits at the
-high end in VPN[1].
-(Note that the fields of a partitioned guest physical address also correspond
-one-for-one with the structure that Sv32 assigns to a physical address,
-depicted in Figure~\ref{rv32va}.)
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}E@{}O@{}E}
-\instbitrange{33}{22} &
-\instbitrange{21}{12} &
-\instbitrange{11}{0} \\
-\hline
-\multicolumn{1}{|c|}{VPN[1]} &
-\multicolumn{1}{c|}{VPN[0]} &
-\multicolumn{1}{c|}{page offset} \\
-\hline
-12 & 10 & 12 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv32x4 virtual address (guest physical address).}
-\label{sv32x4va}
-\end{figure*}
-
-For Sv39x4, an incoming guest physical address is partitioned as shown in
-Figure~\ref{sv39x4va}.
-This partitioning is identical to that for an Sv39 virtual address as depicted
-in Figure~\ref{sv39va} (page~\pageref{sv39va}), except with 2 more bits at the
-high end in VPN[2].
-Address bits 63:41 must all be zeros, or else a page-fault exception occurs,
-attributed to guest physical address translation.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}E@{}O@{}O@{}O}
-\instbitrange{40}{30} &
-\instbitrange{29}{21} &
-\instbitrange{20}{12} &
-\instbitrange{11}{0} \\
-\hline
-\multicolumn{1}{|c|}{VPN[2]} &
-\multicolumn{1}{c|}{VPN[1]} &
-\multicolumn{1}{c|}{VPN[0]} &
-\multicolumn{1}{c|}{page offset} \\
-\hline
-11 & 9 & 9 & 12 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv39x4 virtual address (guest physical address).}
-\label{sv39x4va}
-\end{figure*}
-
-For Sv48x4, an incoming guest physical address is partitioned as shown in
-Figure~\ref{sv48x4va}.
-This partitioning is identical to that for an Sv48 virtual address as depicted
-in Figure~\ref{sv48va} (page~\pageref{sv48va}), except with 2 more bits at the
-high end in VPN[3].
-Address bits 63:50 must all be zeros, or else a page-fault exception occurs,
-attributed to guest physical address translation.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}E@{}O@{}O@{}O@{}O}
-\instbitrange{49}{39} &
-\instbitrange{38}{30} &
-\instbitrange{29}{21} &
-\instbitrange{20}{12} &
-\instbitrange{11}{0} \\
-\hline
-\multicolumn{1}{|c|}{VPN[3]} &
-\multicolumn{1}{c|}{VPN[2]} &
-\multicolumn{1}{c|}{VPN[1]} &
-\multicolumn{1}{c|}{VPN[0]} &
-\multicolumn{1}{c|}{page offset} \\
-\hline
-11 & 9 & 9 & 9 & 12 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv48x4 virtual address (guest physical address).}
-\label{sv48x4va}
-\end{figure*}
-
-\begin{commentary}
-The page-based guest physical address translation scheme for RV32, Sv32x4, is
-defined to support a 34-bit guest physical address so that an RV32 hypervisor
-need not be limited in its ability to virtualize real 32-bit RISC-V machines,
-even those with 33-bit or 34-bit physical addresses.
-This may include the possibility of a machine virtualizing itself, if it
-happens to use 33-bit or 34-bit physical addresses.
-Multiplying the size and alignment of the root page table by a factor of four
-is the cheapest way to extend Sv32 to cover a 34-bit address.
-The possible wastage of 12~KiB for an unnecessarily large root page table is
-expected to be of negligible consequence for most (maybe all) real uses.
-
-A consistent ability to virtualize machines having as much as four times the
-physical address space as virtual address space is believed to be of some
-utility also for RV64.
-For a machine supporting 39-bit virtual addresses (Sv39), for example, this
-allows the hypervisor extension to support up to a 41-bit physical address
-space without either necessitating hardware support for 48-bit virtual
-addresses (Sv48) or falling back to emulating the larger address space with
-shadow page tables.
-\end{commentary}
-
-The conversion of an Sv32x4, Sv39x4, or Sv48x4 guest physical address is
-accomplished with the same algorithm used for Sv32, Sv39, or Sv48, as presented
-in Section~\ref{sv32algorithm}, except that:
-\begin{compactitem}
-\item
-in step~1, $a = \mbox{{\tt hgatp}.PPN}\times\mbox{PAGESIZE}$;
-\item
-the current privilege mode is always taken to be U-mode; and
-\item
-instead of {\tt mstatus}.MXR, the HS-level MXR applies (usually in
-{\tt bsstatus}).
-\end{compactitem}
-
-For guest physical address translation, all memory accesses (including those
-made to access data structures for VS-level address translation) are considered
-to be user-level accesses, as though executed in U-mode.
-Access type permissions---readable, writable, or executable---are checked
-during guest physical address translation the same as for VS-level address
-translation.
-For a memory access made to support VS-level address translation (such as to
-read/write a VS-level page table), permissions are checked as though for a load
-or store, not for the original access type.
-However, any exception is always reported for the original access type
-(instruction, load, or store/AMO).
-
-Access faults and page faults raised by guest physical address translation are
-treated as HS-level exceptions for the purpose of exception delegation, so are
-not delegated to VS-mode, regardless of the setting of the {\tt hedeleg}
-register.
-
-\subsection{Memory-Management Fences}
-
-The behavior of the SFENCE.VMA instruction is affected by the current
-virtualization mode V. When V=0, the virtual-address argument is an HS-level
-virtual address, and the ASID argument is an HS-level ASID.
-The instruction orders stores only to HS-level address-translation structures
-with subsequent HS-level address translations.
-
-When V=1, the virtual-address argument to SFENCE.VMA is a guest virtual
-address within the current virtual machine, and the ASID argument is a VS-level
-ASID within the current virtual machine.
-The current virtual machine is identified by the VMID field of CSR {\tt hgatp},
-and the effective ASID can be considered to be the combination of this VMID
-with the VS-level ASID.
-The SFENCE.VMA instruction orders stores only to the VS-level
-address-translation structures with subsequent VS-level address translations
-for the same virtual machine, i.e., only when {\tt hgatp}.VMID is the same as
-when the SFENCE.VMA executed.
-
-Hypervisor instructions HFENCE.GVMA and HFENCE.BVMA provide additional
-memory-management fences to complement SFENCE.VMA.
-These instructions are described in Section~\ref{sec:hfence.vma}.
-
-Section~\ref{pmp-vmem} discusses the intersection between physical memory
-protection (PMP) and page-based address translation.
-It is noted there that, when PMP settings are modified in a manner that affects
-either the physical memory that holds page tables or the physical memory to
-which page tables point, M-mode software must synchronize the PMP settings with
-the virtual memory system.
-For HS-level address translation, this is accomplished by executing in M-mode
-an SFENCE.VMA instruction with {\em rs1}={\tt x0} and {\em rs2}={\tt x0}, after
-the PMP CSRs are written.
-If guest physical address translation is in use, synchronization with its data
-structures is also needed.
-When PMP settings are modified in a manner that affects either the physical
-memory that holds guest-physical page tables or the physical memory to which
-guest-physical page tables point, an HFENCE.GVMA instruction with
-{\em rs1}={\tt x0} and {\em rs2}={\tt x0} must be executed in M-mode after the
-PMP CSRs are written.
-An HFENCE.BVMA instruction is not required.
-
-
-\clearpage
-
-\section{Base ISA Control}
-
-The {\tt mstatus} field SXL determines XLEN for HS-mode.
-
-When executing in VS-mode, XLEN is determined by the the UXL field of the
-background register {\tt bsstatus}. Because {\tt bsstatus} is swapped with
-{\tt sstatus} when transitioning from VS-mode into HS-mode or M-mode, HS-mode
-and M-mode can modify VS-mode's XLEN via the UXL field of the foreground
-register {\tt sstatus}.
-
-When executing in U-mode or VU-mode, XLEN is determined by the UXL field of the
-foreground register {\tt sstatus}.
-
-\begin{commentary}
-HS-mode controls U-mode's XLEN the same way it controls VS-mode's XLEN, via
-{\tt sstatus}.UXL.
-\end{commentary}
-
-\section{Traps}
-
-The hypervisor extension augments the environment-call exception cause
-encoding. Environment calls from HS-mode use cause 9, whereas environment
-calls from VS-mode use cause 10. Table~\ref{hcauses} lists the
-possible M-mode and HS-mode exception codes when the hypervisor extension is
-present.
-
-\begin{commentary}
-HS-mode and VS-mode ECALLs use different cause values so they can be delegated
-separately.
-\end{commentary}
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|r|r|l|l|}
-
- \hline
- Interrupt & Exception Code & Description \\
- \hline
- 1 & 0 & User software interrupt \\
- 1 & 1 & Supervisor software interrupt \\
- 1 & 2 & {\em Reserved} \\
- 1 & 3 & Machine software interrupt \\
- 1 & 4 & User timer interrupt \\
- 1 & 5 & Supervisor timer interrupt \\
- 1 & 6 & {\em Reserved} \\
- 1 & 7 & Machine timer interrupt \\
- 1 & 8 & User external interrupt \\
- 1 & 9 & Supervisor external interrupt \\
- 1 & 10 & {\em Reserved} \\
- 1 & 11 & Machine external interrupt \\
- 1 & $\ge$12 & {\em Reserved} \\ \hline
- 0 & 0 & Instruction address misaligned \\
- 0 & 1 & Instruction access fault \\
- 0 & 2 & Illegal instruction \\
- 0 & 3 & Breakpoint \\
- 0 & 4 & Load address misaligned \\
- 0 & 5 & Load access fault \\
- 0 & 6 & Store/AMO address misaligned \\
- 0 & 7 & Store/AMO access fault \\
- 0 & 8 & Environment call from U-mode or VU-mode \\
- 0 & 9 & Environment call from HS-mode \\
- 0 & 10 & Environment call from VS-mode \\
- 0 & 11 & Environment call from M-mode \\
- 0 & 12 & Instruction page fault \\
- 0 & 13 & Load page fault \\
- 0 & 14 & {\em Reserved} \\
- 0 & 15 & Store/AMO page fault \\
- 0 & $\ge$16 & {\em Reserved} \\
- \hline
-\end{tabular}
-\end{center}
-\caption{Supervisor and machine cause register ({\tt scause} and {\tt mcause}) values when the hypervisor extension is enabled.}
-\label{hcauses}
-\end{table*}
-
-When a trap occurs in HS-mode or U-mode, it goes to M-mode, unless
-delegated by {\tt medeleg} or {\tt mideleg}, in which case it goes to HS-mode.
-If the N extension for user-mode interrupts is implemented, then U-mode
-traps destined for HS-mode may be further delegated to U-mode using the {\tt
-sedeleg} and {\tt sideleg} CSRs.
-
-When a trap occurs in VS-mode or VU-mode, it goes to M-mode, unless
-delegated by {\tt medeleg} or {\tt mideleg}, in which case it goes to HS-mode,
-unless further delegated by {\tt hedeleg} or {\tt hideleg}, in which case it
-goes to VS-mode. If the N extension for user-mode interrupts is implemented,
-then VU-mode traps destined for VS-mode may be further delegated to VU-mode
-using the {\tt sedeleg} and {\tt sideleg} CSRs.
-
-When a trap is taken into M-mode, the following occurs: first, if the
-virtualization mode V was 1, the contents of the background supervisor
-registers are swapped with their foreground counterparts. Then, {\tt
-mstatus}.MPV and {\tt mstatus}.MPP are set according to Table~\ref{h-mpp}.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|l|c|c|}
- \hline
- Previous Mode & MPV & MPP \\ \hline
- U-mode & 0 & 0 \\
- HS-mode & 0 & 1 \\
- M-mode & 0 & 3 \\ \hline
- VU-mode & 1 & 0 \\
- VS-mode & 1 & 1 \\ \hline
-\end{tabular}
-\end{center}
-\caption{Value of {\tt mstatus} fields MPV and MPP after a trap into M-mode.
-Upon trap return, MPV is ignored when MPP=3.}
-\label{h-mpp}
-\end{table*}
-
-When a trap is taken into HS-mode, the following occurs: first, if the
-virtualization mode V was 1, the contents of the background supervisor
-registers are swapped with their foreground counterparts.
-Then, {\tt hstatus}.SP2V is set to {\tt hstatus}.SPV, {\tt hstatus}.SP2P is set
-to {\tt sstatus}.SPP, and lastly {\tt hstatus}.SPV and {\tt sstatus}.SPP are
-set according to Table~\ref{h-spp}.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|l|c|c|}
- \hline
- Previous Mode & SPV & SPP \\ \hline
- U-mode & 0 & 0 \\
- HS-mode & 0 & 1 \\ \hline
- VU-mode & 1 & 0 \\
- VS-mode & 1 & 1 \\ \hline
-\end{tabular}
-\end{center}
-\caption{Value of {\tt hstatus} field SPV and {\tt sstatus} field SPP after a trap into HS-mode.}
-\label{h-spp}
-\end{table*}
-
-When a trap is taken into VS-mode, {\tt sstatus}.SPP is set according to
-Table~\ref{h-vspp}.
-Bits SP2V, SP2P, and SPV of {\tt hstatus} are not modified, and the current
-virtualization state V remains 1.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|l|c|c|}
- \hline
- Previous Mode & SPP \\ \hline
- VU-mode & 0 \\
- VS-mode & 1 \\ \hline
-\end{tabular}
-\end{center}
-\caption{Value of {\tt sstatus} field SPP after a trap into VS-mode.}
-\label{h-vspp}
-\end{table*}
-
-\section{Trap Return}
-
-The MRET instruction is used to return from a trap taken into M-mode.
-MRET sets the privilege mode according to the values of MPP and MPV in
-{\tt mstatus}, as encoded in Table~\ref{h-mpp}.
-MRET then in {\tt mstatus} sets MPV=0, MPP=0, MIE=MPIE, and MPIE=1, and also
-sets {\tt pc}={\tt mepc}.
-Finally, if the new virtualization mode V=1, the contents of the background
-supervisor registers are swapped with their foreground counterparts.
-
-The SRET instruction is used to return from a trap taken into HS-mode or
-VS-mode. Its behavior depends on the current virtualization mode.
-
-When executed in M-mode or HS-mode (i.e., V=0), SRET sets the virtualization
-and privilege modes according to the values in {\tt hstatus}.SPV and
-{\tt sstatus}.SPP, as encoded in Table~\ref{h-spp}.
-SRET then sets {\tt hstatus}.SPV={\tt hstatus}.SP2V,
-{\tt sstatus}.SPP={\tt hstatus}.SP2P, {\tt hstatus}.SP2V=0,
-{\tt hstatus}.SP2P=0, {\tt sstatus}.SIE={\tt sstatus}.SPIE,
-{\tt sstatus}.SPIE=1, and {\tt pc}={\tt sepc}.
-Finally, if the new virtualization mode V=1, the contents of the background
-supervisor registers are swapped with their foreground counterparts.
-
-When executed in VS-mode (i.e., V=1), SRET sets the privilege mode according to
-Table~\ref{h-vspp}, then in {\tt sstatus} sets SPP=0, SIE=SPIE, and SPIE=1, and
-lastly sets {\tt pc}={\tt sepc}.
diff --git a/src/images/.gitignore b/src/images/.gitignore
new file mode 100644
index 0000000..43c67b5
--- /dev/null
+++ b/src/images/.gitignore
@@ -0,0 +1 @@
+stem*.svg
diff --git a/src/images/backpage.png b/src/images/backpage.png
new file mode 100644
index 0000000..cc4317d
--- /dev/null
+++ b/src/images/backpage.png
Binary files differ
diff --git a/src/images/base-unpriv-reg-state.png b/src/images/base-unpriv-reg-state.png
new file mode 100644
index 0000000..6ee8589
--- /dev/null
+++ b/src/images/base-unpriv-reg-state.png
Binary files differ
diff --git a/src/images/bytefield/counteren.edn b/src/images/bytefield/counteren.edn
new file mode 100644
index 0000000..1fceba1
--- /dev/null
+++ b/src/images/bytefield/counteren.edn
@@ -0,0 +1,30 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-height 45)
+(def row-header-fn nil)
+(def boxes-per-row 32)
+(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "1" "2" "" "3" "" "4" "" "5" "6" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "28" "" "29" "" "30" "" "31"])})
+
+(draw-box "HPM31" {:span 2})
+(draw-box "HPM30" {:span 2})
+(draw-box "HPM29" {:span 2})
+(draw-box "..." {:span 17})
+(draw-box "HPM5" {:span 2})
+(draw-box "HPM4" {:span 2})
+(draw-box "HPM3" {:span 2})
+(draw-box "IR" {:span 1})
+(draw-box "TM" {:span 1})
+(draw-box "CY" {:span 1})
+
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "23" {:span 17 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+----
diff --git a/src/images/bytefield/counterinh.edn b/src/images/bytefield/counterinh.edn
new file mode 100644
index 0000000..48ebc10
--- /dev/null
+++ b/src/images/bytefield/counterinh.edn
@@ -0,0 +1,30 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-height 45)
+(def row-header-fn nil)
+(def boxes-per-row 32)
+(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "1" "2" "" "3" "" "4" "" "5" "6" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "28" "" "29" "" "30" "" "31"])})
+
+(draw-box "HPM31" {:span 2})
+(draw-box "HPM30" {:span 2})
+(draw-box "HPM29" {:span 2})
+(draw-box "..." {:span 17})
+(draw-box "HPM5" {:span 2})
+(draw-box "HPM4" {:span 2})
+(draw-box "HPM3" {:span 2})
+(draw-box "IR" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "CY" {:span 1})
+
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "23" {:span 17 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+----
diff --git a/src/images/bytefield/cust-sys-instr.edn b/src/images/bytefield/cust-sys-instr.edn
new file mode 100644
index 0000000..a4ce653
--- /dev/null
+++ b/src/images/bytefield/cust-sys-instr.edn
@@ -0,0 +1,80 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-height 35 )
+(def row-header-fn nil)
+(def left-margin 0)
+(def right-margin 40)
+(def boxes-per-row 32)
+(draw-column-headers {:height 24 :font-size 20 :labels (reverse ["" "" "" "" "" "" "" "0" "" "6" "7" "" "11" "12" "" "14" "15" "" "" "" "" "" "" "" "" "25" "26" "" "" "" "" "31"])})
+
+(draw-box "funct6" {:span 6})
+(draw-box "custom" {:span 10})
+(draw-box "funct3" {:span 3})
+(draw-box "custom" {:span 3})
+(draw-box "opcode" {:span 3})
+(draw-box (text "Recommended Purpose" {}) {:span 7 :text-anchor "middle" :borders {}})
+
+(draw-box "6" {:span 6 :borders {}})
+(draw-box "11" {:span 10 :borders {}})
+(draw-box "3" {:span 3 :borders {}})
+(draw-box "5" {:span 3 :borders {}})
+(draw-box "7" {:span 3 :borders {}})
+(draw-box nil {:span 7 :borders {}})
+
+(draw-box "100011" {:span 6 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 10 :borders {}})
+(draw-box "0" {:span 3 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 3 :borders {}})
+(draw-box "SYSTEM" {:span 3 :borders {}})
+(draw-box (text "Unprivileged or User-Level" {}) {:span 7 :text-anchor "middle" :borders {}})
+
+(draw-box "110011" {:span 6 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 10 :borders {}})
+(draw-box "0" {:span 3 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 3 :borders {}})
+(draw-box "SYSTEM" {:span 3 :borders {}})
+(draw-box (text "Unprivileged or User-Level" {}) {:span 7 :text-anchor "middle" :borders {}})
+
+(draw-box "100111" {:span 6 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 10 :borders {}})
+(draw-box "0" {:span 3 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 3 :borders {}})
+(draw-box "SYSTEM" {:span 3 :borders {}})
+(draw-box (text " Supervisor-Level" {}) {:span 7 :text-anchor "middle" :borders {}})
+
+(draw-box "110111" {:span 6 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 10 :borders {}})
+(draw-box "0" {:span 3 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 3 :borders {}})
+(draw-box "SYSTEM" {:span 3 :borders {}})
+(draw-box (text "Supervisor-Level" {}) {:span 7 :text-anchor "middle" :borders {}})
+
+(draw-box "101011" {:span 6 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 10 :borders {}})
+(draw-box "0" {:span 3 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 3 :borders {}})
+(draw-box "SYSTEM" {:span 3 :borders {}})
+(draw-box (text "Hypervisor-Level" {}) {:span 7 :text-anchor "middle" :borders {}})
+
+(draw-box "111011" {:span 6 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 10 :borders {}})
+(draw-box "0" {:span 3 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 3 :borders {}})
+(draw-box "SYSTEM" {:span 3 :borders {}})
+(draw-box (text "Hypervisor-Level" {}) {:span 7 :text-anchor "middle" :borders {}})
+
+(draw-box "101111" {:span 6 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 10 :borders {}})
+(draw-box "0" {:span 3 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 3 :borders {}})
+(draw-box "SYSTEM" {:span 3 :borders {}})
+(draw-box (text "Machine-Level" {}) {:span 7 :text-anchor "middle" :borders {}})
+
+(draw-box "111111" {:span 6 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 10 :borders {}})
+(draw-box "0" {:span 3 :borders {}})
+(draw-box (text "custom" {:font-style "italic"}) {:span 3 :borders {}})
+(draw-box "SYSTEM" {:span 3 :borders {}})
+(draw-box (text "Machine-Level" {}) {:span 7 :text-anchor "middle" :borders {}})
+----
diff --git a/src/images/bytefield/epcreg.edn b/src/images/bytefield/epcreg.edn
new file mode 100644
index 0000000..567db54
--- /dev/null
+++ b/src/images/bytefield/epcreg.edn
@@ -0,0 +1,16 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "SXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "sepc" {:span 32})
+
+(draw-box "SXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/hcounterenreg.edn b/src/images/bytefield/hcounterenreg.edn
new file mode 100644
index 0000000..71a195b
--- /dev/null
+++ b/src/images/bytefield/hcounterenreg.edn
@@ -0,0 +1,43 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "31" {:span 2 :borders {}})
+(draw-box "30" {:span 2 :borders {}})
+(draw-box "29" {:span 2 :borders {}})
+(draw-box "28" {:span 10 :text-anchor "start" :borders {}})
+(draw-box "6" {:span 7 :text-anchor "end" :borders {}})
+(draw-box "5" {:span 2 :borders {}})
+(draw-box "4" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "2" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "HPM31" {:font-size 20 :span 2})
+(draw-box "HPM30" {:font-size 20 :span 2})
+(draw-box "HPM29" {:font-size 20 :span 2})
+(draw-box "..." {:span 17})
+(draw-box "HPM5" {:span 2})
+(draw-box "HPM4" {:span 2})
+(draw-box "HPM3" {:span 2})
+(draw-box "IR" )
+(draw-box "TM" )
+(draw-box "CY" )
+
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "23" {:span 17 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+----
diff --git a/src/images/bytefield/hedelegreg.edn b/src/images/bytefield/hedelegreg.edn
new file mode 100644
index 0000000..48c452c
--- /dev/null
+++ b/src/images/bytefield/hedelegreg.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "63" {:span 16 :text-anchor "start" :borders{}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders{}})
+
+(draw-box "Synchronous Exceptions" {:span 18 :text-anchor "end" :borders{:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" { :font-weight "bold" :font-size 24}) {:span 14 :text-anchor "start" :borders{:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "64" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/hgeiereg.edn b/src/images/bytefield/hgeiereg.edn
new file mode 100644
index 0000000..76540e1
--- /dev/null
+++ b/src/images/bytefield/hgeiereg.edn
@@ -0,0 +1,16 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+(draw-column-headers {:height 24 :font-size 24 :labels (reverse ["0" "1" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "HSXLEN-1" ""])})
+
+(draw-box "Guest External Interrupts" {:span 18 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 13 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated}})
+(draw-box "0" )
+(draw-box "HSXLEN" {:font-size 24 :span 31 :borders {}})
+(draw-box "1" {:borders {}})
+----
diff --git a/src/images/bytefield/hgeipreg.edn b/src/images/bytefield/hgeipreg.edn
new file mode 100644
index 0000000..d821c76
--- /dev/null
+++ b/src/images/bytefield/hgeipreg.edn
@@ -0,0 +1,15 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+(draw-column-headers {:height 24 :font-size 24 :labels (reverse ["0" "1" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "HSXLEN-1" ""])})
+
+(draw-box "Guest External Interrupts" {:span 31})
+(draw-box "0" )
+(draw-box "HSXLEN" {:span 31 :borders {}})
+(draw-box "1" {:borders {}})
+----
diff --git a/src/images/bytefield/hidelegreg.edn b/src/images/bytefield/hidelegreg.edn
new file mode 100644
index 0000000..a5730ec
--- /dev/null
+++ b/src/images/bytefield/hidelegreg.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "HSXLEN-1" {:span 16 :text-anchor "start" :borders{}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders{}})
+
+(draw-box "Interrupts" {:span 16 :text-anchor "end" :borders{:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" { :font-weight "bold" :font-size 24}) {:span 16 :text-anchor "start" :borders{:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "HSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/hiereg-standard.edn b/src/images/bytefield/hiereg-standard.edn
new file mode 100644
index 0000000..d1b79cb
--- /dev/null
+++ b/src/images/bytefield/hiereg-standard.edn
@@ -0,0 +1,43 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "15" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "13" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "12" {:span 4 :borders {}})
+(draw-box "11" {:span 4 :borders {}})
+(draw-box "10" {:span 4 :borders {}})
+(draw-box "9" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "7" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "6" {:span 4 :borders {}})
+(draw-box "5" {:borders {}})
+(draw-box "3" {:borders {}})
+(draw-box "2" {:span 4 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "0" {:span 4})
+(draw-box "SGEIE" {:span 4})
+(draw-box "0" {:span 4})
+(draw-box "VSEIE" {:span 4})
+(draw-box "0" {:span 4})
+(draw-box "VSTIE" {:span 4})
+(draw-box "0" {:span 2})
+(draw-box "VSSIE" {:span 4})
+(draw-box "0" {:span 2})
+
+(draw-box "3" {:span 4 :borders{}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "3" {:span 4 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+----
diff --git a/src/images/bytefield/hiereg.edn b/src/images/bytefield/hiereg.edn
new file mode 100644
index 0000000..a5730ec
--- /dev/null
+++ b/src/images/bytefield/hiereg.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "HSXLEN-1" {:span 16 :text-anchor "start" :borders{}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders{}})
+
+(draw-box "Interrupts" {:span 16 :text-anchor "end" :borders{:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" { :font-weight "bold" :font-size 24}) {:span 16 :text-anchor "start" :borders{:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "HSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/hipreg-standard.edn b/src/images/bytefield/hipreg-standard.edn
new file mode 100644
index 0000000..a746582
--- /dev/null
+++ b/src/images/bytefield/hipreg-standard.edn
@@ -0,0 +1,43 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "15" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "13" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "12" {:span 4 :borders {}})
+(draw-box "11" {:span 4 :borders {}})
+(draw-box "10" {:span 4 :borders {}})
+(draw-box "9" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "7" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "6" {:span 4 :borders {}})
+(draw-box "5" {:borders {}})
+(draw-box "3" {:borders {}})
+(draw-box "2" {:span 4 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "0" {:span 4})
+(draw-box "SGEIP" {:span 4})
+(draw-box "0" {:span 4})
+(draw-box "VSEIP" {:span 4})
+(draw-box "0" {:span 4})
+(draw-box "VSTIP" {:span 4})
+(draw-box "0" {:span 2})
+(draw-box "VSSIP" {:span 4})
+(draw-box "0" {:span 2})
+
+(draw-box "3" {:span 4 :borders{}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "3" {:span 4 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+----
diff --git a/src/images/bytefield/hipreg.edn b/src/images/bytefield/hipreg.edn
new file mode 100644
index 0000000..a5730ec
--- /dev/null
+++ b/src/images/bytefield/hipreg.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "HSXLEN-1" {:span 16 :text-anchor "start" :borders{}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders{}})
+
+(draw-box "Interrupts" {:span 16 :text-anchor "end" :borders{:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" { :font-weight "bold" :font-size 24}) {:span 16 :text-anchor "start" :borders{:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "HSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/hpmevents.edn b/src/images/bytefield/hpmevents.edn
new file mode 100644
index 0000000..8556b8b
--- /dev/null
+++ b/src/images/bytefield/hpmevents.edn
@@ -0,0 +1,47 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40)
+(def row-header-fn nil)
+(def left-margin 40)
+(def right-margin 40)
+(def boxes-per-row 32)
+(draw-column-headers {:height 26 :font-size 24 :labels (reverse ["" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "0" "" "" "" "" "" "" "" "" "" "" "" "" "63"])})
+
+(draw-box "mcycle" {:span 14})
+(draw-box nil {:span 4 :borders {}})
+(draw-box nil {:span 14 :borders {}})
+
+(draw-box "minstret" {:span 14})
+(draw-box nil {:span 4 :borders {}})
+(draw-box nil {:span 14 :borders {}})
+
+(draw-box nil {:span 14 :borders {}})
+(draw-box nil {:span 4 :borders {}})
+(draw-box "63" {:span 7 :text-anchor "start" :borders{}})
+(draw-box "0" {:span 7 :text-anchor "end" :borders{}})
+
+(draw-box "mhpmcounter3" {:span 14})
+(draw-box nil {:span 4 :borders {}})
+(draw-box "mhpmevent3" {:span 14})
+
+(draw-box "mhpmcounter4" {:span 14})
+(draw-box nil {:span 4 :borders {}})
+(draw-box "mhpmevent4" {:span 14})
+
+(draw-box "⋮" {:span 14 :borders {}})
+(draw-box nil {:span 4 :borders {}})
+(draw-box "⋮" {:span 14 :borders {}})
+
+(draw-box "mhpmcounter30" {:span 14})
+(draw-box nil {:span 4 :borders {}})
+(draw-box "mhpmevent30" {:span 14})
+
+(draw-box "mhpmcounter31" {:span 14})
+(draw-box nil {:span 4 :borders {}})
+(draw-box "mhpmevent31" {:span 14})
+
+(draw-box "64" {:span 14 :borders {}})
+(draw-box nil {:span 4 :borders {}})
+(draw-box "64" {:span 14 :borders {}})
+----
diff --git a/src/images/bytefield/htimedelta.edn b/src/images/bytefield/htimedelta.edn
new file mode 100644
index 0000000..6853c65
--- /dev/null
+++ b/src/images/bytefield/htimedelta.edn
@@ -0,0 +1,16 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "63" {:span 31 :text-anchor "start" :borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "htimedelta" {:font-size 20 :span 32})
+
+(draw-box "64" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/htimedeltah.edn b/src/images/bytefield/htimedeltah.edn
new file mode 100644
index 0000000..aab3ef4
--- /dev/null
+++ b/src/images/bytefield/htimedeltah.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 22}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 200)
+(def right-margin 200)
+(def boxes-per-row 32)
+
+(draw-box "31" {:span 31 :text-anchor "start" :borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "htimedelta" {:font-size 20 :span 32})
+(draw-box "htimedeltah" {:font-size 20 :span 32})
+
+(draw-box "32" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/htinstreg.edn b/src/images/bytefield/htinstreg.edn
new file mode 100644
index 0000000..6d830ea
--- /dev/null
+++ b/src/images/bytefield/htinstreg.edn
@@ -0,0 +1,16 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "HSXLEN-1" {:span 31 :text-anchor "start" :borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "htinst" {:font-size 20 :span 32})
+
+(draw-box "HSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/htvalreg.edn b/src/images/bytefield/htvalreg.edn
new file mode 100644
index 0000000..31b81d3
--- /dev/null
+++ b/src/images/bytefield/htvalreg.edn
@@ -0,0 +1,16 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "HSXLEN-1" {:span 31 :text-anchor "start" :borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "htval" {:font-size 20 :span 32})
+
+(draw-box "HSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/hvipreg-standard.edn b/src/images/bytefield/hvipreg-standard.edn
new file mode 100644
index 0000000..969c342
--- /dev/null
+++ b/src/images/bytefield/hvipreg-standard.edn
@@ -0,0 +1,37 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "15" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "11" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "10" {:span 4 :borders {}})
+(draw-box "9" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "7" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "6" {:span 4 :borders {}})
+(draw-box "5" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "3" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "2" {:span 4 :borders {}})
+(draw-box "1" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+
+(draw-box "0" {:span 8})
+(draw-box "VSEIP" {:span 4})
+(draw-box "0" {:span 4})
+(draw-box "VSTIP" {:span 4})
+(draw-box "0" {:span 4})
+(draw-box "VSSIP" {:span 4})
+(draw-box "0" {:span 4})
+
+(draw-box "5" {:span 8 :borders{}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "3" {:span 4 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "3" {:span 4 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "2" {:span 4 :borders {}})
+----
diff --git a/src/images/bytefield/hvipreg.edn b/src/images/bytefield/hvipreg.edn
new file mode 100644
index 0000000..735068d
--- /dev/null
+++ b/src/images/bytefield/hvipreg.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "HSXLEN-1" {:span 16 :text-anchor "start" :borders{}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders{}})
+
+(draw-box "Virtual Interrupts" {:span 18 :text-anchor "end" :borders{:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" { :font-weight "bold" :font-size 24}) {:span 14 :text-anchor "start" :borders{:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "HSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/hypv-miereg-standard.edn b/src/images/bytefield/hypv-miereg-standard.edn
new file mode 100644
index 0000000..820faee
--- /dev/null
+++ b/src/images/bytefield/hypv-miereg-standard.edn
@@ -0,0 +1,58 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "15" {:borders {}})
+(draw-box "14" {:borders {}})
+(draw-box "13" {:span 3 :borders {}})
+(draw-box "12" {:span 2 :borders {}})
+(draw-box "11" {:span 2 :borders {}})
+(draw-box "10" {:span 3 :borders {}})
+(draw-box "9" {:span 2 :borders {}})
+(draw-box "8" {:span 2 :borders {}})
+(draw-box "7" {:span 2 :borders {}})
+(draw-box "6" {:span 2 :borders {}})
+(draw-box "5" {:span 2 :borders {}})
+(draw-box "4" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "0" {:span 2 :borders {}})
+
+(draw-box "0" {:span 2})
+(draw-box "LCOFIE" {:span 3})
+(draw-box "SGEIE" {:span 2})
+(draw-box "MEIE" {:span 2})
+(draw-box "VSEIE" {:span 3})
+(draw-box "SEIE" {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "MTIE" {:span 2})
+(draw-box "VSTIE" {:span 2})
+(draw-box "STIE" {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "MSIE" {:span 2})
+(draw-box "VSSIE" {:span 2})
+(draw-box "SSIE" {:span 2})
+(draw-box "0" {:span 2})
+
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+----
diff --git a/src/images/bytefield/hypv-mipreg-standard.edn b/src/images/bytefield/hypv-mipreg-standard.edn
new file mode 100644
index 0000000..968bfb2
--- /dev/null
+++ b/src/images/bytefield/hypv-mipreg-standard.edn
@@ -0,0 +1,58 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "15" {:borders {}})
+(draw-box "14" {:borders {}})
+(draw-box "13" {:span 3 :borders {}})
+(draw-box "12" {:span 2 :borders {}})
+(draw-box "11" {:span 2 :borders {}})
+(draw-box "10" {:span 3 :borders {}})
+(draw-box "9" {:span 2 :borders {}})
+(draw-box "8" {:span 2 :borders {}})
+(draw-box "7" {:span 2 :borders {}})
+(draw-box "6" {:span 2 :borders {}})
+(draw-box "5" {:span 2 :borders {}})
+(draw-box "4" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "0" {:span 2 :borders {}})
+
+(draw-box "0" {:span 2})
+(draw-box "LCOFIP" {:span 3})
+(draw-box "SGEIP" {:span 2})
+(draw-box "MEIP" {:span 2})
+(draw-box "VSEIP" {:span 3})
+(draw-box "SEIP" {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "MTIP" {:span 2})
+(draw-box "VSTIP" {:span 2})
+(draw-box "STIP" {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "MSIP" {:span 2})
+(draw-box "VSSIP" {:span 2})
+(draw-box "SSIP" {:span 2})
+(draw-box "0" {:span 2})
+
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+----
diff --git a/src/images/bytefield/hypv-mstatus.edn b/src/images/bytefield/hypv-mstatus.edn
new file mode 100644
index 0000000..3dc0861
--- /dev/null
+++ b/src/images/bytefield/hypv-mstatus.edn
@@ -0,0 +1,129 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "63" {:span 3 :borders {}})
+(draw-box "62" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "40" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "39" {:span 3 :borders {}})
+(draw-box "38" {:span 3 :borders {}})
+(draw-box "37" {:span 3 :borders {}})
+(draw-box "36" {:span 3 :borders {}})
+(draw-box "35" {:span 2 :borders {}})
+(draw-box "34" {:span 2 :borders {}})
+(draw-box "33" {:span 2 :borders {}})
+(draw-box "32" {:span 2 :borders {}})
+(draw-box nil {:borders {}})
+
+(draw-box "SD" {:span 3})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 8})
+(draw-box "MPV" {:span 3})
+(draw-box "GVA" {:span 3})
+(draw-box "MBE" {:span 3})
+(draw-box "SBE" {:span 3})
+(draw-box "SXL[1:0]" {:span 4})
+(draw-box "UXL[1:0]" {:span 4})
+(draw-box nil {:borders {:top :border-unrelated :bottom :border-unrelated}})
+
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "23" {:span 8 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "2" {:span 4 :borders {}})
+(draw-box "2" {:span 4 :borders {}})
+(draw-box nil {:borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+
+(draw-box nil {:borders {}})
+(draw-box "31" {:span 3 :text-align "start" :borders {}})
+(draw-box "23" {:span 3 :text-align "end" :borders {}})
+(draw-box "22" {:span 3 :borders {}})
+(draw-box "21" {:span 3 :borders {}})
+(draw-box "20" {:span 3 :borders {}})
+(draw-box "19" {:span 3 :borders {}})
+(draw-box "18" {:span 3 :borders {}})
+(draw-box "17" {:span 3 :borders {}})
+(draw-box "16" {:span 2 :borders {}})
+(draw-box "15" {:borders {}})
+(draw-box "14" {:span 2 :borders {}})
+(draw-box "13" {:borders {}})
+(draw-box nil {:borders {}})
+
+(draw-box nil {:borders {:top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 6})
+(draw-box "TSR" {:span 3})
+(draw-box "TW" {:span 3})
+(draw-box "TVM" {:span 3})
+(draw-box "MXR" {:span 3})
+(draw-box "SUM" {:span 3})
+(draw-box "MPRV" {:span 3})
+(draw-box "XS[1:0]" {:span 3})
+(draw-box "FS[1:0]" {:span 3})
+(draw-box nil {:borders {:top :border-unrelated :bottom :border-unrelated}})
+
+(draw-box nil {:borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box nil {:borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+
+(draw-box nil {:borders {}})
+(draw-box "12" {:borders {}})
+(draw-box nil {:borders {}})
+(draw-box "11" {:borders {}})
+(draw-box "10" {:borders {}})
+(draw-box nil {:borders {}})
+(draw-box "9" {:borders {}})
+(draw-box "8" {:span 2 :borders {}})
+(draw-box "7" {:span 3 :borders {}})
+(draw-box "6" {:span 2 :borders {}})
+(draw-box "5" {:span 3 :borders {}})
+(draw-box "4" {:span 3 :borders {}})
+(draw-box "3" {:span 3 :borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "0" {:span 3 :borders {}})
+
+(draw-box nil {:borders {:top :border-unrelated :bottom :border-unrelated}})
+(draw-box "MPP[1:0]" {:span 3})
+(draw-box "VS[1:0]" {:span 3})
+(draw-box "SPP" {:span 2})
+(draw-box "MPIE" {:span 3})
+(draw-box "UBE" {:span 2})
+(draw-box "SPIE" {:span 3})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 3})
+(draw-box "MIE" {:span 3})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 3})
+(draw-box "SIE" {:span 3})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 3})
+
+(draw-box nil {:borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+
+----
diff --git a/src/images/bytefield/hypv-mstatush.edn b/src/images/bytefield/hypv-mstatush.edn
new file mode 100644
index 0000000..58d650b
--- /dev/null
+++ b/src/images/bytefield/hypv-mstatush.edn
@@ -0,0 +1,32 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "31" {:span 8 :text-anchor "start" :borders {}})
+(draw-box "8" {:span 8 :text-anchor "end" :borders {}})
+(draw-box "7" {:span 3 :borders {}})
+(draw-box "6" {:span 3 :borders {}})
+(draw-box "5" {:span 3 :borders {}})
+(draw-box "4" {:span 3 :borders {}})
+(draw-box "3" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 16})
+(draw-box "MPV" {:span 3})
+(draw-box "GVA" {:span 3})
+(draw-box "MBE" {:span 3})
+(draw-box "SBE" {:span 3})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 4})
+
+(draw-box "24" {:span 16 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "4" {:span 4 :borders {}})
+----
diff --git a/src/images/bytefield/marchid.edn b/src/images/bytefield/marchid.edn
new file mode 100644
index 0000000..dafe5b5
--- /dev/null
+++ b/src/images/bytefield/marchid.edn
@@ -0,0 +1,14 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-height 35 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "" "" "" "" "" "" "" """" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "MXLEN-1" ""])})
+
+(draw-box "Architecture ID" {:span 32 :vertical-align "middle"})
+
+(draw-box "MXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mcausereg.edn b/src/images/bytefield/mcausereg.edn
new file mode 100644
index 0000000..f0117eb
--- /dev/null
+++ b/src/images/bytefield/mcausereg.edn
@@ -0,0 +1,20 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 200)
+(def right-margin 200)
+(def boxes-per-row 32)
+
+(draw-box "MXLEN-1" {:span 4 :borders {}})
+(draw-box "MXLEN-2" {:span 14 :borders {} :text-anchor "start"})
+(draw-box "0" {:span 14 :borders {} :text-anchor "end"})
+
+(draw-box "Interrupt" {:span 4})
+(draw-box "Exception Code " {:span 15 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WLRL)" {:font-weight "bold"}) {:span 13 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "MXLEN-1" {:font-size 24 :span 28 :borders {}})
+----
diff --git a/src/images/bytefield/mconfigptrreg.edn b/src/images/bytefield/mconfigptrreg.edn
new file mode 100644
index 0000000..8c427bf
--- /dev/null
+++ b/src/images/bytefield/mconfigptrreg.edn
@@ -0,0 +1,13 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 200)
+(def right-margin 200)
+(def boxes-per-row 32)
+(draw-column-headers {:height 26 :font-size 24 :labels (reverse ["0" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "MXLEN-1" ""])})
+
+(draw-box "mconfigptr" {:span 32})
+(draw-box "MXLEN" {:font-size 24 :span 32 :borders {}})
+----
diff --git a/src/images/bytefield/medeleg.edn b/src/images/bytefield/medeleg.edn
new file mode 100644
index 0000000..a63156d
--- /dev/null
+++ b/src/images/bytefield/medeleg.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 35)
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+
+(draw-box "63" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "Synchronous Exceptions" {:font-size 18 :span 18 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold"}) {:font-size 18 :span 14 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "64" {:font-size 24 :span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mepcreg.edn b/src/images/bytefield/mepcreg.edn
new file mode 100644
index 0000000..de38623
--- /dev/null
+++ b/src/images/bytefield/mepcreg.edn
@@ -0,0 +1,15 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+
+(draw-box "MXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "mepc" {:span 32})
+(draw-box "MXLEN" {:font-size 24 :span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mhartid.edn b/src/images/bytefield/mhartid.edn
new file mode 100644
index 0000000..6934d74
--- /dev/null
+++ b/src/images/bytefield/mhartid.edn
@@ -0,0 +1,14 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-height 35 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "" "" "" "" "" "" "" """" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "MXLEN-1" ""])})
+
+(draw-box "Hart ID" {:span 32 :vertical-align "middle"})
+
+(draw-box "MXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mideleg.edn b/src/images/bytefield/mideleg.edn
new file mode 100644
index 0000000..e6073e3
--- /dev/null
+++ b/src/images/bytefield/mideleg.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+
+(draw-box "MXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "Interrupts" {:font-size 18 :span 17 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold"}) {:font-size 18 :span 15 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "MXLEN" {:font-size 24 :span 32 :borders {}})
+----
diff --git a/src/images/bytefield/miereg-standard.edn b/src/images/bytefield/miereg-standard.edn
new file mode 100644
index 0000000..680fb1c
--- /dev/null
+++ b/src/images/bytefield/miereg-standard.edn
@@ -0,0 +1,42 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 12}])
+(def row-height 30 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 16)
+(draw-column-headers {:labels (reverse ["0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "10" "11" "12" "13" "14" "15"])})
+
+(draw-box "0" {:span 2})
+(draw-box (text "LCOFIE" {:font-size 10}) {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "MEIE" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "SEIE" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "MTIE" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "STIE" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "MSIE" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "SSIE" {:span 1})
+(draw-box "0" {:span 1})
+
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+----
diff --git a/src/images/bytefield/mimpid.edn b/src/images/bytefield/mimpid.edn
new file mode 100644
index 0000000..2a955ef
--- /dev/null
+++ b/src/images/bytefield/mimpid.edn
@@ -0,0 +1,14 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-height 35 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "" "" "" "" "" "" "" """" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "MXLEN-1" ""])})
+
+(draw-box "Implementation" {:span 32})
+
+(draw-box "MXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mipreg-standard.edn b/src/images/bytefield/mipreg-standard.edn
new file mode 100644
index 0000000..e32e302
--- /dev/null
+++ b/src/images/bytefield/mipreg-standard.edn
@@ -0,0 +1,42 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 12}])
+(def row-height 30 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 16)
+(draw-column-headers {:labels (reverse ["0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "10" "11" "12" "13" "14" "15"])})
+
+(draw-box "0" {:span 2})
+(draw-box (text "LCOFIP" {:font-size 10}) {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "MEIP" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "SEIP" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "MTIP" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "STIP" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "MSIP" {:span 1})
+(draw-box "0" {:span 1})
+(draw-box "SSIP" {:span 1})
+(draw-box "0" {:span 1})
+
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+----
diff --git a/src/images/bytefield/misareg.edn b/src/images/bytefield/misareg.edn
new file mode 100644
index 0000000..ff445c3
--- /dev/null
+++ b/src/images/bytefield/misareg.edn
@@ -0,0 +1,27 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 16}])
+(def row-height 30 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+
+(draw-box "MXLEN-1" {:span 6 :borders {}})
+(draw-box "MXLEN-2" {:span 6 :borders {}})
+(draw-box "MXLEN-3" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "26" {:borders {}})
+(draw-box "25" {:span 7 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 7 :text-anchor "end" :borders {}})
+
+(draw-box "MXL[1:0]" {:span 6 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold"}) {:span 6 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated}})
+(draw-box "0" {:span 3 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold"}) {:span 3 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "Extensions[25:0]" {:span 7 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold"}) {:span 7 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "2" {:span 12 :borders {}})
+(draw-box "MXLEN-28" {:span 6 :borders {}})
+(draw-box "26" {:span 14 :borders {}})
+----
diff --git a/src/images/bytefield/mncause.edn b/src/images/bytefield/mncause.edn
new file mode 100644
index 0000000..0b56e9b
--- /dev/null
+++ b/src/images/bytefield/mncause.edn
@@ -0,0 +1,16 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+(draw-column-headers {:height 24 :font-size 24 :labels (reverse ["0" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "MXLEN-2" "" "" "" "MXLEN-1" ""])})
+
+(draw-box "Interrupt" {:span 4})
+(draw-box (text "Exception Code" {:font-size 24}) {:span 14 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 14 :text-anchor "start" :borders {:top :border-unrelated :right :border-unrelated :bottom :border-unrelated}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "MXLEN-1" {:font-size 24 :span 28 :borders {}})
+----
diff --git a/src/images/bytefield/mnepc.edn b/src/images/bytefield/mnepc.edn
new file mode 100644
index 0000000..37a84e9
--- /dev/null
+++ b/src/images/bytefield/mnepc.edn
@@ -0,0 +1,14 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+(draw-column-headers {:height 24 :font-size 24 :labels (reverse ["0" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "MXLEN-1" ""])})
+
+(draw-box (text "mnepc " {:font-size 24}) {:span 16 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)"{:font-weight "bold" :font-size 24}) {:span 16 :text-anchor "start" :borders {:top :border-unrelated :right :border-unrelated :bottom :border-unrelated}})
+(draw-box "MXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mnscratch.edn b/src/images/bytefield/mnscratch.edn
new file mode 100644
index 0000000..79294f8
--- /dev/null
+++ b/src/images/bytefield/mnscratch.edn
@@ -0,0 +1,13 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+(draw-column-headers {:height 24 :font-size 24 :labels (reverse ["0" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "MXLEN-1" ""])})
+
+(draw-box (text "mnscratch" {:font-size 24}) {:span 32})
+(draw-box "MXLEN" {:font-size 24 :span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mnstatus.edn b/src/images/bytefield/mnstatus.edn
new file mode 100644
index 0000000..8a5f39d
--- /dev/null
+++ b/src/images/bytefield/mnstatus.edn
@@ -0,0 +1,33 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 35)
+(draw-column-headers {:height 24 :font-size 24 :labels (reverse ["0" "" "" "2" "" "3" "4" "" "" "6" "" "" "7" "" "" "8" "" "" "9" "" "" "10" "" "11" "" "" "12" "13" "" "" "" "" "" "MXLEN-1" ""])})
+
+(draw-box (text "Reserved" {:font-style "italic" :font-size 24}) {:span 8})
+(draw-box (text "MNPP" {:font-size 24}) {:span 2 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 20}) {:span 2 :text-anchor "start" :borders {:top :border-unrelated :right :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "Reserved" {:font-style "italic" :font-size 24}) {:span 3})
+(draw-box (text "MNPELP" {:font-style "italic" :font-size 20}) {:span 3})
+(draw-box (text "Reserved" {:font-style "italic" :font-size 20}) {:span 3})
+(draw-box (text "MNPV" {:font-size 24}) {:span 2 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 20}) {:span 2 :text-anchor "start" :borders {:top :border-unrelated :right :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "Reserved" {:font-style "italic" :font-size 24}) {:span 4})
+(draw-box "NMIE" {:span 2})
+(draw-box (text "Reserved" {:font-style "italic" :font-size 24}) {:span 4})
+
+(draw-box "MXLEN-13" {:span 8 :borders {}})
+(draw-box "2" {:span 4 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "3" {:span 4 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 4 :borders {}})
+
+----
diff --git a/src/images/bytefield/mscratch.edn b/src/images/bytefield/mscratch.edn
new file mode 100644
index 0000000..3148240
--- /dev/null
+++ b/src/images/bytefield/mscratch.edn
@@ -0,0 +1,16 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+
+(draw-box "MXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "mscratch" {:font-size 18 :span 32})
+
+(draw-box "MXLEN" {:font-size 24 :span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mtime.edn b/src/images/bytefield/mtime.edn
new file mode 100644
index 0000000..811ef47
--- /dev/null
+++ b/src/images/bytefield/mtime.edn
@@ -0,0 +1,13 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 200)
+(def right-margin 200)
+(def boxes-per-row 32)
+(draw-column-headers {:height 24 :font-size 24 :labels (reverse ["0" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "63"])})
+
+(draw-box "mtime" {:span 32})
+(draw-box "64" {:font-size 24 :span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mtimecmp.edn b/src/images/bytefield/mtimecmp.edn
new file mode 100644
index 0000000..89773ad
--- /dev/null
+++ b/src/images/bytefield/mtimecmp.edn
@@ -0,0 +1,13 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 200)
+(def right-margin 200)
+(def boxes-per-row 32)
+(draw-column-headers {:height 26 :font-size 24 :labels (reverse ["0" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "63"])})
+
+(draw-box "mtimecmp" {:span 32})
+(draw-box "64" {:font-size 24 :span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mtinstreg.edn b/src/images/bytefield/mtinstreg.edn
new file mode 100644
index 0000000..2ee51c6
--- /dev/null
+++ b/src/images/bytefield/mtinstreg.edn
@@ -0,0 +1,14 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "MXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+(draw-box "mtinst" {:span 32})
+(draw-box "MXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mtval2reg.edn b/src/images/bytefield/mtval2reg.edn
new file mode 100644
index 0000000..2d64f27
--- /dev/null
+++ b/src/images/bytefield/mtval2reg.edn
@@ -0,0 +1,14 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "MXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+(draw-box "mtval2" {:span 32})
+(draw-box "MXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mtvalreg.edn b/src/images/bytefield/mtvalreg.edn
new file mode 100644
index 0000000..a74226e
--- /dev/null
+++ b/src/images/bytefield/mtvalreg.edn
@@ -0,0 +1,13 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 200)
+(def right-margin 200)
+(def boxes-per-row 32)
+(draw-column-headers {:height 26 :font-size 24 :labels (reverse ["0" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "MXLEN-1" ""])})
+
+(draw-box "mtval" {:span 32})
+(draw-box "MXLEN" {:font-size 24 :span 32 :borders {}})
+----
diff --git a/src/images/bytefield/mtvec.edn b/src/images/bytefield/mtvec.edn
new file mode 100644
index 0000000..c625d40
--- /dev/null
+++ b/src/images/bytefield/mtvec.edn
@@ -0,0 +1,18 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-height 35 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "" "" "" "" "" "" "1" "2" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "MXLEN-1" ""])})
+
+(draw-box "BASE[MXLEN-1:2]" {:span 12 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold"}) {:span 12 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "MODE" {:span 4 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold"}) {:span 4 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "MXLEN-2" {:span 24 :borders {}})
+(draw-box "2" {:span 8 :borders {}})
+----
diff --git a/src/images/bytefield/mvendorid.edn b/src/images/bytefield/mvendorid.edn
new file mode 100644
index 0000000..588470d
--- /dev/null
+++ b/src/images/bytefield/mvendorid.edn
@@ -0,0 +1,15 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-height 35 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+(draw-column-headers {:height 20 :font-size 18 :labels (reverse ["0" "" "" "" "" "" "6" "7" """" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "31"])})
+(draw-box "Bank" {:span 25 :vertical-align "middle"})
+(draw-box "Offset" {:span 7})
+
+(draw-box "25" {:span 25 :borders {}})
+(draw-box "7" {:span 7 :borders{}})
+----
diff --git a/src/images/bytefield/pmp-rv32.edn b/src/images/bytefield/pmp-rv32.edn
new file mode 100644
index 0000000..420eb76
--- /dev/null
+++ b/src/images/bytefield/pmp-rv32.edn
@@ -0,0 +1,79 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-header-fn nil)
+(def boxes-per-row 20)
+(def left-margin 200)
+(def right-margin 200)
+
+(draw-box "31" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "24" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "23" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "16" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "15" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "8" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "7" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+(draw-box nil {:span 4 :text-anchor "start" :borders {}})
+
+(draw-box "pmp3cfg" {:span 4})
+(draw-box "pmp2cfg" {:span 4})
+(draw-box "pmp1cfg" {:span 4})
+(draw-box "pmp0cfg" {:span 4})
+(draw-box "pmpcfg0" {:span 4 :borders {}})
+
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box nil {:span 4 :borders {}})
+
+(draw-box "31" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "24" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "23" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "16" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "15" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "8" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "7" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+(draw-box nil {:span 4 :text-anchor "start" :borders {}})
+
+(draw-box "pmp7cfg" {:span 4})
+(draw-box "pmp6cfg" {:span 4})
+(draw-box "pmp5cfg" {:span 4})
+(draw-box "pmp4cfg" {:span 4})
+(draw-box "pmpcfg1" {:span 4 :borders {}})
+
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box nil {:span 4 :borders {}})
+
+(draw-box nil {:span 20 :borders {}})
+(draw-box nil {:span 8 :borders {}})
+(draw-box "⋮" {:span 12 :text-anchor "start" :borders {}})
+(draw-box nil {:span 20 :borders {}})
+
+(draw-box "31" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "24" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "23" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "16" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "15" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "8" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "7" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+(draw-box nil {:span 4 :text-anchor "start" :borders {}})
+
+(draw-box "pmp63cfg" {:span 4})
+(draw-box "pmp62cfg" {:span 4})
+(draw-box "pmp61cfg" {:span 4})
+(draw-box "pmp60cfg" {:span 4})
+(draw-box "pmpcfg15" {:span 4 :borders {}})
+
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box nil {:span 4 :borders {}})
+----
diff --git a/src/images/bytefield/pmp-rv64.edn b/src/images/bytefield/pmp-rv64.edn
new file mode 100644
index 0000000..42dbbf1
--- /dev/null
+++ b/src/images/bytefield/pmp-rv64.edn
@@ -0,0 +1,131 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 22}])
+(def row-header-fn nil)
+(def boxes-per-row 40)
+(def left-margin 200)
+(def right-margin 200)
+(def row-height 50)
+
+(draw-box "63" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "56" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "55" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "48" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "47" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "40" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "39" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "32" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "31" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "24" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "23" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "16" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "15" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "8" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "7" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+(draw-box nil {:span 8 :text-anchor "start" :borders {}})
+
+(draw-box "pmp7cfg" {:span 4})
+(draw-box "pmp6cfg" {:span 4})
+(draw-box "pmp5cfg" {:span 4})
+(draw-box "pmp4cfg" {:span 4})
+(draw-box "pmp3cfg" {:span 4})
+(draw-box "pmp2cfg" {:span 4})
+(draw-box "pmp1cfg" {:span 4})
+(draw-box "pmp0cfg" {:span 4})
+(draw-box "pmpcfg0" {:span 4 :borders {}})
+(draw-box nil {:span 4 :borders {}})
+
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box nil {:span 8 :borders {}})
+
+(draw-box "63" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "56" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "55" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "48" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "47" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "40" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "39" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "32" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "31" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "24" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "23" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "16" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "15" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "8" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "7" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+(draw-box nil {:span 8 :text-anchor "start" :borders {}})
+
+(draw-box "pmp15cfg" {:span 4})
+(draw-box "pmp14cfg" {:span 4})
+(draw-box "pmp13cfg" {:span 4})
+(draw-box "pmp12cfg" {:span 4})
+(draw-box "pmp11cfg" {:span 4})
+(draw-box "pmp10cfg" {:span 4})
+(draw-box "pmp9cfg" {:span 4})
+(draw-box "pmp8cfg" {:span 4})
+(draw-box "pmpcfg2" {:span 4 :borders {}})
+(draw-box nil {:span 4 :borders {}})
+
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box nil {:span 8 :borders {}})
+
+(draw-box nil {:span 40 :borders {}})
+(draw-box nil {:span 16 :borders {}})
+(draw-box "⋮" {:span 24 :text-anchor "start" :borders {}})
+(draw-box nil {:span 40 :borders {}})
+
+(draw-box "63" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "56" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "55" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "48" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "47" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "40" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "39" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "32" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "31" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "24" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "23" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "16" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "15" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "8" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "7" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+(draw-box nil {:span 8 :text-anchor "start" :borders {}})
+
+(draw-box "pmp63cfg" {:span 4})
+(draw-box "pmp62cfg" {:span 4})
+(draw-box "pmp61cfg" {:span 4})
+(draw-box "pmp60cfg" {:span 4})
+(draw-box "pmp59cfg" {:span 4})
+(draw-box "pmp58cfg" {:span 4})
+(draw-box "pmp57cfg" {:span 4})
+(draw-box "pmp56cfg" {:span 4})
+(draw-box "pmpcfg14" {:span 4 :borders {}})
+(draw-box nil {:span 4 :borders {}})
+
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box nil {:span 8 :borders {}})
+----
diff --git a/src/images/bytefield/pmpaddr-rv32.edn b/src/images/bytefield/pmpaddr-rv32.edn
new file mode 100644
index 0000000..7d9bc96
--- /dev/null
+++ b/src/images/bytefield/pmpaddr-rv32.edn
@@ -0,0 +1,15 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 200)
+(def right-margin 200)
+(def boxes-per-row 32)
+(draw-column-headers {:height 24 :font-size 24 :labels (reverse ["0" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "31"])})
+
+(draw-box "address[33:2]" {:span 16 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-size 24 :font-weight "bold"}) {:span 16 :text-anchor "start" :borders{:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "32" {:font-size 24 :span 32 :borders {}})
+----
diff --git a/src/images/bytefield/pmpaddr-rv64.edn b/src/images/bytefield/pmpaddr-rv64.edn
new file mode 100644
index 0000000..672eb69
--- /dev/null
+++ b/src/images/bytefield/pmpaddr-rv64.edn
@@ -0,0 +1,18 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 50 )
+(def row-header-fn nil)
+(def left-margin 200)
+(def right-margin 200)
+(def boxes-per-row 32)
+(draw-column-headers {:height 24 :font-size 24 :labels (reverse ["0" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "53" "" "" "" "" "54" "" "" "63"])})
+
+(draw-box "0" {:span 4 :text-anchor "end" :borders{:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-size 24 :font-weight "bold"}) {:span 4 :text-anchor "start" :borders{:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "address[55:2]" {:span 12 :text-anchor "end" :borders{:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-size 24 :font-weight "bold"}) {:span 12 :text-anchor "start" :borders{:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "10" {:font-size 24 :span 8 :borders {}})
+(draw-box "54" {:font-size 24 :span 24 :borders {}})
+----
diff --git a/src/images/bytefield/pmpcfg.edn b/src/images/bytefield/pmpcfg.edn
new file mode 100644
index 0000000..9b010c4
--- /dev/null
+++ b/src/images/bytefield/pmpcfg.edn
@@ -0,0 +1,32 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 100)
+(def right-margin 100)
+(def boxes-per-row 32)
+
+(draw-box "7" {:span 5 :borders {}})
+(draw-box "6" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "5" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "4" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "3" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "2" {:span 5 :borders {}})
+(draw-box "1" {:span 5 :borders {}})
+(draw-box "0" {:span 5 :borders {}})
+
+(draw-box "L" {:span 5})
+(draw-box "0" {:span 6})
+(draw-box "A" {:span 6})
+(draw-box "X" {:span 5})
+(draw-box "W" {:span 5})
+(draw-box "R" {:span 5})
+
+(draw-box "1" {:span 5 :borders {}})
+(draw-box "2" {:span 6 :borders {}})
+(draw-box "2" {:span 6 :borders {}})
+(draw-box "1" {:span 5 :borders {}})
+(draw-box "1" {:span 5 :borders {}})
+(draw-box "1" {:span 5 :borders {}})
+----
diff --git a/src/images/bytefield/priv-instr-set.edn b/src/images/bytefield/priv-instr-set.edn
new file mode 100644
index 0000000..b8e6d3b
--- /dev/null
+++ b/src/images/bytefield/priv-instr-set.edn
@@ -0,0 +1,279 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40)
+(def row-header-fn nil)
+(def boxes-per-row 32)
+
+(draw-box "31" {:span 4 :text-anchor "start" :borders{}})
+(draw-box "27" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "26" {:borders {}})
+(draw-box "25" {:borders {}})
+(draw-box "24" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "20" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "19" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "15" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "14" {:borders {}})
+(draw-box nil {:borders {}})
+(draw-box "12" {:borders {}})
+(draw-box "11" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "7" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "6" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+(draw-box nil {:span 5 :borders {}})
+
+(draw-box "funct7" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "funct3" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "opcode" {:span 4})
+(draw-box " R-type" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "imm[11:0]" {:span 12})
+(draw-box "rs1" {:span 4})
+(draw-box "funct3" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "opcode" {:span 4})
+(draw-box " I-type" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+(draw-box (text "Trap-Return Instructions" {:font-weight "bold" :font-size 24}) {:span 27 :borders {}})
+(draw-box nil {:span 5 :borders {}})
+
+(draw-box "0001000" {:span 8})
+(draw-box "00010" {:span 4})
+(draw-box "00000" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " SRET" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0011000" {:span 8})
+(draw-box "00010" {:span 4})
+(draw-box "00000" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " MRET" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0111000" {:span 8})
+(draw-box "00010" {:span 4})
+(draw-box "00000" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " MNRET" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+(draw-box (text "Interrupt-Management Instructions" {:font-weight "bold" :font-size 24}) {:span 27 :borders {}})
+(draw-box nil {:span 5 :borders {}})
+
+(draw-box "0001000" {:span 8})
+(draw-box "00101" {:span 4})
+(draw-box "00000" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "WFI" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+(draw-box (text "Control Transfer Records Management Instructions" {:font-weight "bold" :font-size 24}) {:span 27 :borders {}})
+(draw-box nil {:span 5 :borders {}})
+
+(draw-box "0001000" {:span 8})
+(draw-box "00100" {:span 4})
+(draw-box "00000" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "SCTRCLR" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+(draw-box (text "Supervisor Memory-Management Instructions" {:font-weight "bold" :font-size 24}) {:span 27 :borders {}})
+(draw-box nil {:span 5 :borders {}})
+
+(draw-box "0001001" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "SFENCE.VMA" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+(draw-box (text "Hypervisor Memory-Management Instructions" {:font-weight "bold" :font-size 24}) {:span 27 :borders {}})
+(draw-box nil {:span 5 :borders {}})
+
+(draw-box "0010001" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HFENCE.VVMA" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110001" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HFENCE.GVMA" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+(draw-box (text "Hypervisor Virtual-Machine Load and Store Instructions" {:font-weight "bold" :font-size 24}) {:span 27 :borders {}})
+(draw-box nil {:span 5 :borders {}})
+
+(draw-box "0110000" {:span 8})
+(draw-box "00000" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HLV.B" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110000" {:span 8})
+(draw-box "00001" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HLV.BU" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110010" {:span 8})
+(draw-box "00000" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HLV.H" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110010" {:span 8})
+(draw-box "00001" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HLV.HU" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110100" {:span 8})
+(draw-box "00000" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HLV.W" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110010" {:span 8})
+(draw-box "00011" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HLVX.HU" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110100" {:span 8})
+(draw-box "00011" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HLVX.WU" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110001" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HSV.B" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110011" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HSV.H" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110101" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box "HSV.W" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+(draw-box (text "Hypervisor Virtual-Machine Load and Store Instructions, RV64 only" {:font-weight "bold" :font-size 24}) {:span 27 :borders {}})
+(draw-box nil {:span 5 :borders {}})
+
+(draw-box "0110100" {:span 8})
+(draw-box "00001" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " HLV.WU" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110110" {:span 8})
+(draw-box "00000" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "rd" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " HLV.D" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110111" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "100" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " HSV.D" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+(draw-box (text "Svinval Memory-Management Extension" {:font-weight "bold" :font-size 24}) {:span 27 :borders {}})
+(draw-box nil {:span 5 :borders {}})
+
+(draw-box "0001011" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " SINVAL.VMA" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0001100" {:span 8})
+(draw-box "00000" {:span 4})
+(draw-box "00000" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " SFENCE.W.INVAL" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0001100" {:span 8})
+(draw-box "00001" {:span 4})
+(draw-box "00000" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " SFENCE.INVAL.IR" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0010011" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " HINVAL.VVMA" {:span 5 :text-anchor "start" :borders {}})
+
+(draw-box "0110011" {:span 8})
+(draw-box "rs2" {:span 4})
+(draw-box "rs1" {:span 4})
+(draw-box "000" {:span 3})
+(draw-box "00000" {:span 4})
+(draw-box "1110011" {:span 4})
+(draw-box " HINVAL.GVMA" {:span 5 :text-anchor "start" :borders {}})
+----
diff --git a/src/images/bytefield/rv32hgatp.edn b/src/images/bytefield/rv32hgatp.edn
new file mode 100644
index 0000000..ff90565
--- /dev/null
+++ b/src/images/bytefield/rv32hgatp.edn
@@ -0,0 +1,30 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "31" {:span 3 :borders {}})
+(draw-box "30" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "29" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "28" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "22" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "21" {:span 7 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 8 :text-anchor "end" :borders {}})
+
+(draw-box "MODE" {:span 3})
+(draw-box "0" {:span 3 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 4 :text-anchor "start":borders {:right :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box "VMID" {:span 4 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 3 :text-anchor "start" :borders {:right :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box "PPN" {:span 7 :text-anchor "end":borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 8 :text-anchor "start" :borders {:right :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "2" {:span 7 :borders {}})
+(draw-box "7" {:span 7 :borders {}})
+(draw-box "22" {:span 15 :borders {}})
+----
diff --git a/src/images/bytefield/rv32satp.edn b/src/images/bytefield/rv32satp.edn
new file mode 100644
index 0000000..5d8552b
--- /dev/null
+++ b/src/images/bytefield/rv32satp.edn
@@ -0,0 +1,26 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "31" {:span 8 :borders {}})
+(draw-box "30" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "22" {:span 5 :text-anchor "end" :borders {}})
+(draw-box "21" {:span 8 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 8 :text-anchor "end" :borders {}})
+
+(draw-box "MODE" {:span 3 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 5 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "ASID" {:span 3 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 5 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "PPN" {:span 8 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 8 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "1" {:span 8 :borders {}})
+(draw-box "9" {:span 8 :borders {}})
+(draw-box "22" {:span 16 :borders {}})
+----
diff --git a/src/images/bytefield/rv32vsatpreg.edn b/src/images/bytefield/rv32vsatpreg.edn
new file mode 100644
index 0000000..2af138d
--- /dev/null
+++ b/src/images/bytefield/rv32vsatpreg.edn
@@ -0,0 +1,26 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "31" {:span 8 :borders {}})
+(draw-box "30" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "22" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "21" {:span 8 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 8 :text-anchor "end" :borders {}})
+
+(draw-box "Mode" {:span 4 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 4 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "ASID" {:span 4 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 4 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "PPN" {:span 8 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 8 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "1" {:span 8 :borders {}})
+(draw-box "9" {:span 8 :borders {}})
+(draw-box "22" {:span 16 :borders {}})
+----
diff --git a/src/images/bytefield/rv64hgatp.edn b/src/images/bytefield/rv64hgatp.edn
new file mode 100644
index 0000000..be294f5
--- /dev/null
+++ b/src/images/bytefield/rv64hgatp.edn
@@ -0,0 +1,32 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "63" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "60" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "59" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "58" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "57" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "44" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "43" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 5 :text-anchor "end" :borders {}})
+
+(draw-box "MODE" {:span 4 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 4 :text-anchor "start":borders {:right :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box "0" {:span 3 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 3 :text-anchor "start":borders {:right :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box "VMID" {:span 4 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 4 :text-anchor "start" :borders {:right :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box "PPN" {:span 5 :text-anchor "end":borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 5 :text-anchor "start" :borders {:right :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+
+(draw-box "4" {:span 8 :borders {}})
+(draw-box "2" {:span 6 :borders {}})
+(draw-box "14" {:span 8 :borders {}})
+(draw-box "44" {:span 10 :borders {}})
+----
diff --git a/src/images/bytefield/rv64satp.edn b/src/images/bytefield/rv64satp.edn
new file mode 100644
index 0000000..8da3490
--- /dev/null
+++ b/src/images/bytefield/rv64satp.edn
@@ -0,0 +1,27 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "63" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "60" {:span 5 :text-anchor "end" :borders {}})
+(draw-box "59" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "44" {:span 5 :text-anchor "end" :borders {}})
+(draw-box "43" {:span 6 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 6 :text-anchor "end" :borders {}})
+
+(draw-box "MODE" {:span 5 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 5 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "ASID" {:span 5 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 5 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "PPN" {:span 6 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 6 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "4" {:span 10 :borders {}})
+(draw-box "16" {:span 10 :borders {}})
+(draw-box "44" {:span 12 :borders {}})
+----
diff --git a/src/images/bytefield/rv64vsatpreg.edn b/src/images/bytefield/rv64vsatpreg.edn
new file mode 100644
index 0000000..73ad5de
--- /dev/null
+++ b/src/images/bytefield/rv64vsatpreg.edn
@@ -0,0 +1,27 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "63" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "60" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "59" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "44" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "43" {:span 8 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 8 :text-anchor "end" :borders {}})
+
+(draw-box "Mode" {:span 4 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 4 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "ASID" {:span 4 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 4 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "PPN" {:span 8 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 8 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "4" {:span 8 :borders {}})
+(draw-box "16" {:span 8 :borders {}})
+(draw-box "44" {:span 16 :borders {}})
+----
diff --git a/src/images/bytefield/rvc-instr-quad0.edn b/src/images/bytefield/rvc-instr-quad0.edn
new file mode 100644
index 0000000..5b95168
--- /dev/null
+++ b/src/images/bytefield/rvc-instr-quad0.edn
@@ -0,0 +1,90 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-height 35 )
+(def row-header-fn nil)
+(def left-margin 0)
+(def right-margin 40)
+(def boxes-per-row 23)
+(draw-column-headers {:labels (reverse ["" "" "" "" "" "" "" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "10" "11" "12" "13" "14" "15"])})
+(draw-box "000" {:span 3 :vertical-align "middle"})
+(draw-box "0" {:span 8})
+(draw-box "0" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box (text "Illegal instruction" {:font-style "italic"}) {:span 7 :text-anchor "start" :borders {}})
+
+(draw-box "000" {:span 3})
+(draw-box "uimm[5:4|9:6|2|3]" {:span 8})
+(draw-box (text "rd′" [:plain {:font-family "M+ 1p Fallback"}]) {:span 3})
+(draw-box "00" {:span 2})
+(draw-box (text "C.ADDI4SPN" :math [:sub "(RES, uimm=0)"]) {:span 7 :text-anchor "start" :borders {}})
+
+(draw-box "001" {:span 3})
+(draw-box "uimm[5:3]" {:span 3})
+(draw-box "rs1′" {:span 3})
+(draw-box (text "uimm[7:6]" {:font-size 16}) {:span 2})
+(draw-box "rd′" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box "C.FLD" {:span 7 :text-anchor "start" :borders {}})
+
+(draw-box "010" {:span 3})
+(draw-box "uimm[5:3]" {:span 3})
+(draw-box "rs1′" {:span 3})
+(draw-box (text "uimm[2|6]" {:font-size 16}) {:span 2})
+(draw-box "rd′" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box "C.LW" {:span 7 :text-anchor "start" :borders {}})
+
+(draw-box "011" {:span 3})
+(draw-box "uimm[5:3]" {:span 3})
+(draw-box "rs1′" {:span 3})
+(draw-box (text "uimm[2|6]" {:font-size 16}) {:span 2})
+(draw-box "rd′" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box (text "C.FLW" :math [:sub "(RV32)"]) {:span 7 :text-anchor "start" :borders {}})
+
+(draw-box "011" {:span 3})
+(draw-box "uimm[5:3]" {:span 3})
+(draw-box "rs1′" {:span 3})
+(draw-box (text "uimm[7:6]" {:font-size 16}) {:span 2})
+(draw-box "rd′" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box (text "C.LD" :math [:sub "(RV64)"]) {:span 7 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "---" {:span 11})
+(draw-box "00" {:span 2})
+(draw-box (text "Reserved" {:font-style "italic"}) {:span 7 :text-anchor "start" :borders {}})
+
+(draw-box "101" {:span 3})
+(draw-box "uimm[5:3]" {:span 3})
+(draw-box "rs1′" {:span 3})
+(draw-box (text "uimm[7:6]" {:font-size 16}) {:span 2})
+(draw-box "rs2′" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box "C.FSD" {:span 7 :text-anchor "start" :borders {}})
+
+(draw-box "110" {:span 3})
+(draw-box "uimm[5:3]" {:span 3})
+(draw-box "rs1′" {:span 3})
+(draw-box (text "uimm[2|6]" {:font-size 16}) {:span 2})
+(draw-box "rs2′" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box "C.SW" {:span 7 :text-anchor "start" :borders {}})
+
+(draw-box "111" {:span 3})
+(draw-box "uimm[5:3]" {:span 3})
+(draw-box "rs1′" {:span 3})
+(draw-box (text "uimm[2|6]" {:font-size 16}) {:span 2})
+(draw-box "rs2′" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box (text "C.FSW" :math [:sub "(RV32)"]) {:span 7 :text-anchor "start" :borders {}})
+
+(draw-box "111" {:span 3})
+(draw-box "uimm[5:3]" {:span 3})
+(draw-box "rs1′" {:span 3})
+(draw-box (text "uimm[7:6]" {:font-size 16}) {:span 2})
+(draw-box "rs2′" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box (text "C.SD" :math [:sub "(RV64)"]) {:span 7 :text-anchor "start" :borders {}})
+----
diff --git a/src/images/bytefield/rvc-instr-quad1.edn b/src/images/bytefield/rvc-instr-quad1.edn
new file mode 100644
index 0000000..a7aaacf
--- /dev/null
+++ b/src/images/bytefield/rvc-instr-quad1.edn
@@ -0,0 +1,173 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-weight "bold" :font-family "M+ 1p Fallback"}])
+(def row-height 50 )
+(def row-header-fn nil)
+(def left-margin 0)
+(def right-margin 0)
+(def boxes-per-row 19)
+(def box-width 70)
+(draw-column-headers {:labels (reverse ["" "" "" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "10" "11" "12" "13" "14" "15"])})
+
+(draw-box "000" {:span 3})
+(draw-box "imm[5]" {:span 1})
+(draw-box "0" {:span 5})
+(draw-box "imm[4:0]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box (text "C.NOP" :math [:sub "(HINT, imm≠0)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "000" {:span 3})
+(draw-box "imm[5]") {:span 1}
+(draw-box "rs1/rd≠0" {:span 5})
+(draw-box "imm[4:0]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box (text "C.ADDI" :math [:sub "(HINT, imm=0)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "001" {:span 3})
+(draw-box "imm[11|4|9:8|10|6|7|3:1|5]" {:span 11})
+(draw-box "01" {:span 2})
+(draw-box (text "C.JAL" :math [:sub "(RV32)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "001" {:span 3})
+(draw-box "imm[5]" {:span 1})
+(draw-box "rs1/rd≠0" {:span 5})
+(draw-box "imm[4:0]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box (text "C.ADDIW" :math [:sub "(RV64; RES, rd=0)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "010" {:span 3})
+(draw-box "imm[5]" {:span 1})
+(draw-box "rd̸=0" {:span 5})
+(draw-box "imm[4:0]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box (text "C.LI" :math [:sub "(HINT, rd=0)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "011" {:span 3})
+(draw-box "imm[9]" {:span 1})
+(draw-box "2" {:span 5})
+(draw-box "imm[4|6|8:7|5]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box (text "C.ADDI16SP" :math [:sub "(RES, imm=0)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "011" {:span 3})
+(draw-box (text "imm[17]" {:font-width 11}) {:span 1})
+(draw-box "rd≠{0, 2}" {:span 5})
+(draw-box "imm[16:12]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box (text "C.LUI" :math [:sub "(RES, imm=0; HINT, rd=0)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box (text "uimm[5]" {:font-width 11}) {:span 1})
+(draw-box "00" {:span 2})
+(draw-box "rs1ʹ/rdʹ" {:span 3})
+(draw-box "uimm[4:0]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box (text "C.SRLI" :math [:sub "(HINT, uimm=0)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box (text "uimm[5]" {:font-width 11}) {:span 1})
+(draw-box "01" {:span 2})
+(draw-box "rs1ʹ/rdʹ" {:span 3})
+(draw-box "uimm[4:0]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box (text "C.SRAI" :math [:sub "(HINT, uimm=0)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "imm[5]" {:span 1})
+(draw-box "10" {:span 2})
+(draw-box "rs1ʹ/rdʹ" {:span 3})
+(draw-box "imm[4:0]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box "C.ANDI" {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "0" {:span 1})
+(draw-box "11" {:span 2})
+(draw-box "rs1ʹ/rdʹ" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box "rs2′" {:span 3})
+(draw-box "01" {:span 2})
+(draw-box "C.SUB" {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "0" {:span 1})
+(draw-box "11" {:span 2})
+(draw-box "rs1ʹ/rdʹ" {:span 3})
+(draw-box "01" {:span 2})
+(draw-box "rs2′" {:span 3})
+(draw-box "01" {:span 2})
+(draw-box "C.XOR" {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "0" {:span 1})
+(draw-box "11" {:span 2})
+(draw-box "rs1ʹ/rdʹ" {:span 3})
+(draw-box "10" {:span 2})
+(draw-box "rs2′" {:span 3})
+(draw-box "01" {:span 2})
+(draw-box "C.OR" {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "0" {:span 1})
+(draw-box "11" {:span 2})
+(draw-box "rs1ʹ/rdʹ" {:span 3})
+(draw-box "11" {:span 2})
+(draw-box "rs2′" {:span 3})
+(draw-box "01" {:span 2})
+(draw-box "C.AND" {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "1" {:span 1})
+(draw-box "11" {:span 2})
+(draw-box "rs1ʹ/rdʹ" {:span 3})
+(draw-box "00" {:span 2})
+(draw-box "rs2′" {:span 3})
+(draw-box "01" {:span 2})
+(draw-box (text "C.SUBW" :math [:sub "(RV64; RV32 RES)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "1" {:span 1})
+(draw-box "11" {:span 2})
+(draw-box "rs1ʹ/rdʹ" {:span 3})
+(draw-box "01" {:span 2})
+(draw-box "rs2′" {:span 3})
+(draw-box "01" {:span 2})
+(draw-box (text "C.ADDW" :math [:sub "(RV64; RV32 RES)"]) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "1" {:span 1})
+(draw-box "11" {:span 2})
+(draw-box "---" {:span 3})
+(draw-box "10" {:span 2})
+(draw-box "---" {:span 3})
+(draw-box "01" {:span 2})
+(draw-box (text "Reserved" {:font-style "italic"}) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "1" {:span 1})
+(draw-box "11" {:span 2})
+(draw-box "---" {:span 3})
+(draw-box "11" {:span 2})
+(draw-box "---" {:span 3})
+(draw-box "01" {:span 2})
+(draw-box (text "Reserved" {:font-style "italic"}) {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "101" {:span 3})
+(draw-box "imm[11|4|9:8|10|6|7|3:1|5]" {:span 11})
+(draw-box "01" {:span 2})
+(draw-box "C.J" {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "110" {:span 3})
+(draw-box "imm[8|4:3]" {:span 3})
+(draw-box "rs1′" {:span 3})
+(draw-box "imm[7:6|2:1|5]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box "C.BEQZ" {:span 3 :text-anchor "start" :borders {}})
+
+(draw-box "111" {:span 3})
+(draw-box "imm[8|4:3]" {:span 3})
+(draw-box "rs1′" {:span 3})
+(draw-box "imm[7:6|2:1|5]" {:span 5})
+(draw-box "01" {:span 2})
+(draw-box "C.BNEZ" {:span 3 :text-anchor "start" :borders {}})
+----
diff --git a/src/images/bytefield/rvc-instr-quad2.edn b/src/images/bytefield/rvc-instr-quad2.edn
new file mode 100644
index 0000000..10471c0
--- /dev/null
+++ b/src/images/bytefield/rvc-instr-quad2.edn
@@ -0,0 +1,105 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback"}])
+(def row-height 50 )
+(def row-header-fn nil)
+(def left-margin 0)
+(def right-margin 40)
+(def boxes-per-row 22)
+(def box-width 70)
+(draw-column-headers {:labels (reverse ["" "" "" "" "" "" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "10" "11" "12" "13" "14" "15"])})
+
+(draw-box "000" {:span 3})
+(draw-box (text "nzuimm[5]" {:font-size 16}) {:span 1})
+(draw-box "rs1/rd≠0" {:span 5})
+(draw-box "nzuimm[4:0]" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box (text "C.SLLI" :math [:sub "(HINT, rd=0 or imm=0)"]) {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "001" {:span 3})
+(draw-box (text "uimm[5]" {:font-size 16}) {:span 1})
+(draw-box "rd" {:span 5})
+(draw-box "uimm[4:3|8:6]" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box "C.FLDSP" {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "010" {:span 3})
+(draw-box (text "uimm[5]" {:font-size 16}) {:span 1})
+(draw-box "rd≠0" {:span 5})
+(draw-box "uimm[4:2|7:6]" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box (text "C.LWSP" :math [:sub "(RES, rd=0)"]) {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "011" {:span 3})
+(draw-box (text "uimm[5]" {:font-size 16}) {:span 1})
+(draw-box "rd" {:span 5})
+(draw-box "uimm[4:2|7:6]" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box (text "C.FLWSP" :math [:sub "(RV32)"]) {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "011" {:span 3})
+(draw-box (text "uimm[5]" {:font-size 16}) {:span 1})
+(draw-box "rd≠0" {:span 5})
+(draw-box "uimm[4:3|8:6]" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box (text "C.LDSP" :math [:sub "(RV64; RES, rd=0)"]) {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "0" {:span 1})
+(draw-box "rs1≠0" {:span 5})
+(draw-box "0" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box (text "C.JR" :math [:sub "(RES, rs1=0)"]) {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "0" {:span 1})
+(draw-box "rd≠0" {:span 5})
+(draw-box "rs2≠0" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box (text "C.MV" :math [:sub "(HINT, rd=0)"]) {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "1" {:span 1})
+(draw-box "0" {:span 5})
+(draw-box "0" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box "C.EBREAK" {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "1" {:span 1})
+(draw-box "rs1≠0" {:span 5})
+(draw-box "0" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box "C.JALR" {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "100" {:span 3})
+(draw-box "1" {:span 1})
+(draw-box "rs1/rd≠0" {:span 5})
+(draw-box "rs2≠0" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box (text "C.ADD" :math [:sub "(HINT, rd=0)"]) {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "101" {:span 3})
+(draw-box "uimm[5:3|8:6]" {:span 6})
+(draw-box "rs2" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box "C.FSDSP" {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "110" {:span 3})
+(draw-box "uimm[5:2|7:6]" {:span 6})
+(draw-box "rs2" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box "C.SWSP" {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "111" {:span 3})
+(draw-box "uimm[5:2|7:6]" {:span 6})
+(draw-box "rs2" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box (text "C.FSWSP" :math [:sub "(RV32)"]) {:span 6 :text-anchor "start" :borders {}})
+
+(draw-box "111" {:span 3})
+(draw-box "uimm[5:3|8:6]" {:span 6})
+(draw-box "rs2" {:span 5})
+(draw-box "10" {:span 2})
+(draw-box (text "C.SDSP" :math [:sub "(RV64)"]) {:span 6 :text-anchor "start" :borders {}})
+----
diff --git a/src/images/bytefield/scausereg.edn b/src/images/bytefield/scausereg.edn
new file mode 100644
index 0000000..cbdcb91
--- /dev/null
+++ b/src/images/bytefield/scausereg.edn
@@ -0,0 +1,21 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "SXLEN-1" {:span 6 :borders {}})
+(draw-box "SXLEN-2" {:span 12 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 14 :text-anchor "end" :borders {}})
+
+(draw-box "Interrupt" {:span 6})
+(draw-box "Exception Code" {:span 12 :text-anchor "end":borders{:top :border-unrelated :bottom :border-unrelated :left :border-unrelated}})
+(draw-box (text "(WLRL)" {:font-weight "bold" :font-size 24}) {:span 14 :text-anchor "start" :borders{:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "1" {:span 6 :borders {}})
+(draw-box "SXLEN-1" {:span 26 :borders {}})
+
+----
diff --git a/src/images/bytefield/scounteren.edn b/src/images/bytefield/scounteren.edn
new file mode 100644
index 0000000..52e78e2
--- /dev/null
+++ b/src/images/bytefield/scounteren.edn
@@ -0,0 +1,43 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "31" {:span 3 :borders {}})
+(draw-box "30" {:span 3 :borders {}})
+(draw-box "29" {:span 3 :borders {}})
+(draw-box "28" {:span 7 :text-anchor "start" :borders {}})
+(draw-box "6" {:span 7 :text-anchor "end" :borders {}})
+(draw-box "5" {:span 2 :borders {}})
+(draw-box "4" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "2" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "HPM31" {:span 3})
+(draw-box "HPM30" {:span 3})
+(draw-box "HPM29" {:span 3})
+(draw-box "..." {:span 14})
+(draw-box "HPM5" {:span 2})
+(draw-box "HPM4" {:span 2})
+(draw-box "HPM3" {:span 2})
+(draw-box "IR" {:span 1})
+(draw-box "TM" {:span 1})
+(draw-box "CY" {:span 1})
+
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "23" {:span 14 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+(draw-box "1" {:span 1 :borders {}})
+----
diff --git a/src/images/bytefield/sie.edn b/src/images/bytefield/sie.edn
new file mode 100644
index 0000000..50be75e
--- /dev/null
+++ b/src/images/bytefield/sie.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "SXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "Interrupts" {:span 16 :text-anchor "end" :borders {:top :border-unrelated :left :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 16 :text-anchor "start" :borders {:top :border-unrelated :right :border-unrelated :bottom :border-unrelated}})
+
+(draw-box "SXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/siereg-standard.edn b/src/images/bytefield/siereg-standard.edn
new file mode 100644
index 0000000..4a1fba6
--- /dev/null
+++ b/src/images/bytefield/siereg-standard.edn
@@ -0,0 +1,49 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 7 :borders {}})
+(draw-box "15" {:text-anchor "start" :borders {}})
+(draw-box "14" {:text-anchor "end" :borders {}})
+(draw-box "13" {:span 2 :borders {}})
+(draw-box "12" {:text-anchor "start" :borders {}})
+(draw-box "10" {:text-anchor "end" :borders {}})
+(draw-box "9" {:span 2 :borders {}})
+(draw-box "8" {:text-anchor "start" :borders {}})
+(draw-box "6" {:text-anchor "end" :borders {}})
+(draw-box "5" {:span 2 :borders {}})
+(draw-box "4" {:text-anchor "start" :borders {}})
+(draw-box "2" {:text-anchor "end" :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "0" {:borders {}})
+(draw-box nil {:span 8 :borders {}})
+
+(draw-box nil {:span 7 :borders {}})
+(draw-box "0" {:span 2})
+(draw-box (text "LCOFIE" {:font-size 20}) {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "SEIE" {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "STIE" {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "SSIE" {:span 2})
+(draw-box "0")
+(draw-box nil {:span 8 :borders {}})
+
+(draw-box nil {:span 7 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box nil {:span 8 :borders {}})
+----
diff --git a/src/images/bytefield/sip.edn b/src/images/bytefield/sip.edn
new file mode 100644
index 0000000..50be75e
--- /dev/null
+++ b/src/images/bytefield/sip.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "SXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "Interrupts" {:span 16 :text-anchor "end" :borders {:top :border-unrelated :left :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 16 :text-anchor "start" :borders {:top :border-unrelated :right :border-unrelated :bottom :border-unrelated}})
+
+(draw-box "SXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/sipreg-standard.edn b/src/images/bytefield/sipreg-standard.edn
new file mode 100644
index 0000000..440fd8f
--- /dev/null
+++ b/src/images/bytefield/sipreg-standard.edn
@@ -0,0 +1,49 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 7 :borders {}})
+(draw-box "15" {:text-anchor "start" :borders {}})
+(draw-box "14" {:text-anchor "end" :borders {}})
+(draw-box "13" {:span 2 :borders {}})
+(draw-box "12" {:text-anchor "start" :borders {}})
+(draw-box "10" {:text-anchor "end" :borders {}})
+(draw-box "9" {:span 2 :borders {}})
+(draw-box "8" {:text-anchor "start" :borders {}})
+(draw-box "6" {:text-anchor "end" :borders {}})
+(draw-box "5" {:span 2 :borders {}})
+(draw-box "4" {:text-anchor "start" :borders {}})
+(draw-box "2" {:text-anchor "end" :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "0" {:borders {}})
+(draw-box nil {:span 8 :borders {}})
+
+(draw-box nil {:span 7 :borders {}})
+(draw-box "0" {:span 2})
+(draw-box (text "LCOFIP" {:font-size 20}) {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "SEIP" {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "STIP" {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "SSIP" {:span 2})
+(draw-box "0")
+(draw-box nil {:span 8 :borders {}})
+
+(draw-box nil {:span 7 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box nil {:span 8 :borders {}})
+----
diff --git a/src/images/bytefield/sscratch.edn b/src/images/bytefield/sscratch.edn
new file mode 100644
index 0000000..177660f
--- /dev/null
+++ b/src/images/bytefield/sscratch.edn
@@ -0,0 +1,16 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "SXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "sscratch" {:span 32})
+
+(draw-box "SXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/stvalreg.edn b/src/images/bytefield/stvalreg.edn
new file mode 100644
index 0000000..66c1e20
--- /dev/null
+++ b/src/images/bytefield/stvalreg.edn
@@ -0,0 +1,16 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "SXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "stval" {:span 32})
+
+(draw-box "SXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/stvec.edn b/src/images/bytefield/stvec.edn
new file mode 100644
index 0000000..8e1ce10
--- /dev/null
+++ b/src/images/bytefield/stvec.edn
@@ -0,0 +1,28 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "SXLEN-1" {:span 7 :text-anchor "start" :borders {}})
+(draw-box "2" {:span 7 :text-anchor "end" :borders {}})
+(draw-box "1" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 3 :text-anchor "end" :borders {}})
+(draw-box nil {:span 6 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "BASE[SXLEN-1:2]" {:span 7 :text-anchor "end" :borders {:top :border-unrelated :left :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 7 :text-anchor "start" :borders {:top :border-unrelated :right :border-unrelated :bottom :border-unrelated}})
+(draw-box "MODE" {:span 3 :text-anchor "end" :borders {:top :border-unrelated :left :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 3 :text-anchor "start" :borders {:top :border-unrelated :right :border-unrelated :bottom :border-unrelated}})
+(draw-box nil {:span 6 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "SXLEN-2" {:span 14 :borders {}})
+(draw-box "2" {:span 6 :borders {}})
+(draw-box nil {:span 6 :borders {}})
+----
diff --git a/src/images/bytefield/sv32pa.edn b/src/images/bytefield/sv32pa.edn
new file mode 100644
index 0000000..887d1d2
--- /dev/null
+++ b/src/images/bytefield/sv32pa.edn
@@ -0,0 +1,24 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "33" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "22" {:span 5 :text-anchor "end" :borders {}})
+(draw-box "21" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 5 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 6 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 6 :text-anchor "end" :borders {}})
+
+(draw-box "PPN[1]" {:span 10})
+(draw-box "PPN[0]" {:span 10})
+(draw-box "page offset" {:span 12})
+
+(draw-box "12" {:span 10 :borders {}})
+(draw-box "10" {:span 10 :borders {}})
+(draw-box "12" {:span 12 :borders {}})
+----
diff --git a/src/images/bytefield/sv32pte.edn b/src/images/bytefield/sv32pte.edn
new file mode 100644
index 0000000..9710587
--- /dev/null
+++ b/src/images/bytefield/sv32pte.edn
@@ -0,0 +1,48 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "31" {:span 6 :text-anchor "start" :borders {}})
+(draw-box "20" {:span 6 :text-anchor "end" :borders {}})
+(draw-box "19" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "10" {:span 5 :text-anchor "end" :borders {}})
+(draw-box "9" {:borders {}})
+(draw-box "8" {:borders {}})
+(draw-box "7" {:borders {}})
+(draw-box "6" {:borders {}})
+(draw-box "5" {:borders {}})
+(draw-box "4" {:borders {}})
+(draw-box "3" {:borders {}})
+(draw-box "2" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "PPN[1]" {:span 12})
+(draw-box "PPN[0]" {:span 10})
+(draw-box "RSW" {:span 2})
+(draw-box "D")
+(draw-box "A")
+(draw-box "G")
+(draw-box "U")
+(draw-box "X")
+(draw-box "W")
+(draw-box "R")
+(draw-box "V")
+
+(draw-box "12" {:span 12 :borders {}})
+(draw-box "10" {:span 10 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+----
diff --git a/src/images/bytefield/sv32va.edn b/src/images/bytefield/sv32va.edn
new file mode 100644
index 0000000..231f0cd
--- /dev/null
+++ b/src/images/bytefield/sv32va.edn
@@ -0,0 +1,24 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "31" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "22" {:span 5 :text-anchor "end" :borders {}})
+(draw-box "21" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 5 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 6 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 6 :text-anchor "end" :borders {}})
+
+(draw-box "VPN[1]" {:span 10})
+(draw-box "VPN[0]" {:span 10})
+(draw-box "page offset" {:span 12})
+
+(draw-box "10" {:span 10 :borders {}})
+(draw-box "10" {:span 10 :borders {}})
+(draw-box "12" {:span 12 :borders {}})
+----
diff --git a/src/images/bytefield/sv32x4va.edn b/src/images/bytefield/sv32x4va.edn
new file mode 100644
index 0000000..dcc1f3f
--- /dev/null
+++ b/src/images/bytefield/sv32x4va.edn
@@ -0,0 +1,30 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "33" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "22" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "21" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 4 :text-anchor "end" :borders {}})
+(draw-box nil {:span 6 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "VPN[1]" {:span 6})
+(draw-box "VPN[0]" {:span 6})
+(draw-box "page offset" {:span 8})
+(draw-box nil {:span 6 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "12" {:span 6 :borders {}})
+(draw-box "10" {:span 6 :borders {}})
+(draw-box "12" {:span 8 :borders {}})
+(draw-box nil {:span 6 :borders {}})
+----
diff --git a/src/images/bytefield/sv39pa.edn b/src/images/bytefield/sv39pa.edn
new file mode 100644
index 0000000..0c3e734
--- /dev/null
+++ b/src/images/bytefield/sv39pa.edn
@@ -0,0 +1,28 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "55" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "30" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "29" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "21" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "20" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 4 :text-anchor "end" :borders {}})
+
+(draw-box "PPN[2]" {:span 8})
+(draw-box "PPN[1]" {:span 8})
+(draw-box "PPN[0]" {:span 8})
+(draw-box "page offset" {:span 8})
+
+(draw-box "26" {:span 8 :borders {}})
+(draw-box "9" {:span 8 :borders {}})
+(draw-box "9" {:span 8 :borders {}})
+(draw-box "12" {:span 8 :borders {}})
+----
diff --git a/src/images/bytefield/sv39pte.edn b/src/images/bytefield/sv39pte.edn
new file mode 100644
index 0000000..1aeb5a3
--- /dev/null
+++ b/src/images/bytefield/sv39pte.edn
@@ -0,0 +1,64 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "63" {:borders {}})
+(draw-box "62" {:borders {}})
+(draw-box "61" {:borders {}})
+(draw-box "60" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "54" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "53" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "28" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "27" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "19" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "18" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "10" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "9" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "8" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "7" {:borders {}})
+(draw-box "6" {:borders {}})
+(draw-box "5" {:borders {}})
+(draw-box "4" {:borders {}})
+(draw-box "3" {:borders {}})
+(draw-box "2" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "N")
+(draw-box "PBMT" {:span 2})
+(draw-box "Reserved" {:span 5})
+(draw-box "PPN[2]" {:span 4})
+(draw-box "PPN[1]" {:span 4})
+(draw-box "PPN[0]" {:span 4})
+(draw-box "RSW" {:span 4})
+(draw-box "D")
+(draw-box "A")
+(draw-box "G")
+(draw-box "U")
+(draw-box "X")
+(draw-box "W")
+(draw-box "R")
+(draw-box "V")
+
+(draw-box "1" {:borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "7" {:span 5 :borders {}})
+(draw-box "26" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "2" {:span 4 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+
+----
diff --git a/src/images/bytefield/sv39va.edn b/src/images/bytefield/sv39va.edn
new file mode 100644
index 0000000..285565d
--- /dev/null
+++ b/src/images/bytefield/sv39va.edn
@@ -0,0 +1,28 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "38" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "30" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "29" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "21" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "20" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 7 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 7 :text-anchor "end" :borders {}})
+
+(draw-box "VPN[2]" {:span 6})
+(draw-box "VPN[1]" {:span 6})
+(draw-box "VPN[0]" {:span 6})
+(draw-box "page offset" {:span 14})
+
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "12" {:span 14 :borders {}})
+----
diff --git a/src/images/bytefield/sv39x4va.edn b/src/images/bytefield/sv39x4va.edn
new file mode 100644
index 0000000..fe0bc89
--- /dev/null
+++ b/src/images/bytefield/sv39x4va.edn
@@ -0,0 +1,34 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "40" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "30" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "29" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "21" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "20" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 4 :text-anchor "end" :borders {}})
+(draw-box nil {:span 6 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "VPN[2]" {:span 4})
+(draw-box "VPN[1]" {:span 4})
+(draw-box "VPN[0]" {:span 4})
+(draw-box "page offset" {:span 8})
+(draw-box nil {:span 6 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "11" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "12" {:span 8 :borders {}})
+(draw-box nil {:span 6 :borders {}})
+----
diff --git a/src/images/bytefield/sv48pa.edn b/src/images/bytefield/sv48pa.edn
new file mode 100644
index 0000000..3d4eaa3
--- /dev/null
+++ b/src/images/bytefield/sv48pa.edn
@@ -0,0 +1,32 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "55" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "39" {:span 4 :text-anchor "end" :borders {}})
+(draw-box "38" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "30" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "29" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "21" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "20" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 3 :text-anchor "end" :borders {}})
+
+(draw-box "PPN[3]" {:span 8})
+(draw-box "PPN[2]" {:span 6})
+(draw-box "PPN[1]" {:span 6})
+(draw-box "PPN[0]" {:span 6})
+(draw-box "page offset" {:span 6})
+
+(draw-box "17" {:span 8 :borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "12" {:span 6 :borders {}})
+----
diff --git a/src/images/bytefield/sv48pte.edn b/src/images/bytefield/sv48pte.edn
new file mode 100644
index 0000000..292aeee
--- /dev/null
+++ b/src/images/bytefield/sv48pte.edn
@@ -0,0 +1,68 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "63" {:borders {}})
+(draw-box "62" {:borders {}})
+(draw-box "61" {:borders {}})
+(draw-box "60" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "54" {:span 1 :text-anchor "end" :borders {}})
+(draw-box "53" {:span 1 :text-anchor "start" :borders {}})
+(draw-box "37" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "36" {:span 1 :text-anchor "start" :borders {}})
+(draw-box "28" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "27" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "19" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "18" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "10" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "9" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "8" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "7" {:borders {}})
+(draw-box "6" {:borders {}})
+(draw-box "5" {:borders {}})
+(draw-box "4" {:borders {}})
+(draw-box "3" {:borders {}})
+(draw-box "2" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "N")
+(draw-box "PBMT" {:span 2})
+(draw-box "Reserved" {:span 3})
+(draw-box "PPN[3]" {:span 3})
+(draw-box "PPN[2]" {:span 3})
+(draw-box "PPN[1]" {:span 4})
+(draw-box "PPN[0]" {:span 4})
+(draw-box "RSW" {:span 4})
+(draw-box "D")
+(draw-box "A")
+(draw-box "G")
+(draw-box "U")
+(draw-box "X")
+(draw-box "W")
+(draw-box "R")
+(draw-box "V")
+
+(draw-box "1" {:borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "7" {:span 3 :borders {}})
+(draw-box "17" {:span 3 :borders {}})
+(draw-box "9" {:span 3 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "2" {:span 4 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+
+----
diff --git a/src/images/bytefield/sv48va.edn b/src/images/bytefield/sv48va.edn
new file mode 100644
index 0000000..520ed15
--- /dev/null
+++ b/src/images/bytefield/sv48va.edn
@@ -0,0 +1,38 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 1 :borders {}})
+(draw-box "47" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "39" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "38" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "30" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "29" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "21" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "20" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 3 :text-anchor "end" :borders {}})
+(draw-box nil {:span 1 :borders {}})
+
+(draw-box nil {:span 1 :borders {}})
+(draw-box "VPN[3]" {:span 6})
+(draw-box "VPN[2]" {:span 6})
+(draw-box "VPN[1]" {:span 6})
+(draw-box "VPN[0]" {:span 6})
+(draw-box "page offset" {:span 6})
+(draw-box nil {:span 1 :borders {}})
+
+(draw-box nil {:span 1 :borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "12" {:span 6 :borders {}})
+(draw-box nil {:span 1 :borders {}})
+----
diff --git a/src/images/bytefield/sv48x4va.edn b/src/images/bytefield/sv48x4va.edn
new file mode 100644
index 0000000..7be14a3
--- /dev/null
+++ b/src/images/bytefield/sv48x4va.edn
@@ -0,0 +1,38 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "49" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "39" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "38" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "30" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "29" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "21" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "20" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+(draw-box nil {:span 6 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "VPN[3]" {:span 4})
+(draw-box "VPN[2]" {:span 4})
+(draw-box "VPN[1]" {:span 4})
+(draw-box "VPN[0]" {:span 4})
+(draw-box "page offset" {:span 4})
+(draw-box nil {:span 6 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "11" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "12" {:span 4 :borders {}})
+(draw-box nil {:span 6 :borders {}})
+----
diff --git a/src/images/bytefield/sv57pa.edn b/src/images/bytefield/sv57pa.edn
new file mode 100644
index 0000000..39e4b08
--- /dev/null
+++ b/src/images/bytefield/sv57pa.edn
@@ -0,0 +1,36 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "55" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "48" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "47" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "39" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "38" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "30" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "29" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "21" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "20" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 3 :text-anchor "end" :borders {}})
+
+(draw-box "PPN[4]" {:span 5})
+(draw-box "PPN[3]" {:span 5})
+(draw-box "PPN[2]" {:span 5})
+(draw-box "PPN[1]" {:span 5})
+(draw-box "PPN[0]" {:span 6})
+(draw-box "page offset" {:span 6})
+
+(draw-box "8" {:span 5 :borders {}})
+(draw-box "9" {:span 5 :borders {}})
+(draw-box "9" {:span 5 :borders {}})
+(draw-box "9" {:span 5 :borders {}})
+(draw-box "9" {:span 6 :borders {}})
+(draw-box "12" {:span 6 :borders {}})
+----
diff --git a/src/images/bytefield/sv57pte.edn b/src/images/bytefield/sv57pte.edn
new file mode 100644
index 0000000..f3bb80c
--- /dev/null
+++ b/src/images/bytefield/sv57pte.edn
@@ -0,0 +1,87 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "63" {:borders {}})
+(draw-box "62" {:borders {}})
+(draw-box "61" {:borders {}})
+(draw-box "60" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "54" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "53" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "10" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "9" {:span 4 :text-anchor "start" :borders {}})
+(draw-box "8" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "7" {:borders {}})
+(draw-box "6" {:borders {}})
+(draw-box "5" {:borders {}})
+(draw-box "4" {:borders {}})
+(draw-box "3" {:borders {}})
+(draw-box "2" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "0" {:borders {}})
+
+(draw-box "N")
+(draw-box "PBMT" {:span 2})
+(draw-box "Reserved" {:span 7})
+(draw-box "PPN" {:span 7})
+(draw-box "RSW" {:span 7})
+(draw-box "D")
+(draw-box "A")
+(draw-box "G")
+(draw-box "U")
+(draw-box "X")
+(draw-box "W")
+(draw-box "R")
+(draw-box "V")
+
+(draw-box "1" {:borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "7" {:span 7 :borders {}})
+(draw-box "44" {:span 7 :borders {}})
+(draw-box "2" {:span 7 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "1" {:borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "53" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "46" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "45" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "37" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "36" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "28" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "27" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "19" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "18" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "10" {:span 2 :text-anchor "end" :borders {}})
+(draw-box nil {:span 6 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "PPN[4]" {:span 4})
+(draw-box "PPN[3]" {:span 4})
+(draw-box "PPN[2]" {:span 4})
+(draw-box "PPN[1]" {:span 4})
+(draw-box "PPN[0]" {:span 4})
+(draw-box nil {:span 6 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "8" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box nil {:span 6 :borders {}})
+
+----
diff --git a/src/images/bytefield/sv57va.edn b/src/images/bytefield/sv57va.edn
new file mode 100644
index 0000000..2610e3b
--- /dev/null
+++ b/src/images/bytefield/sv57va.edn
@@ -0,0 +1,36 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "56" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "48" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "47" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "39" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "38" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "30" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "29" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "21" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "20" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+
+(draw-box "VPN[4]" {:span 5})
+(draw-box "VPN[3]" {:span 5})
+(draw-box "VPN[2]" {:span 5})
+(draw-box "VPN[1]" {:span 5})
+(draw-box "VPN[0]" {:span 5})
+(draw-box "page offset" {:span 7})
+
+(draw-box "9" {:span 5 :borders {}})
+(draw-box "9" {:span 5 :borders {}})
+(draw-box "9" {:span 5 :borders {}})
+(draw-box "9" {:span 5 :borders {}})
+(draw-box "9" {:span 5 :borders {}})
+(draw-box "12" {:span 7 :borders {}})
+----
diff --git a/src/images/bytefield/sv57x4va.edn b/src/images/bytefield/sv57x4va.edn
new file mode 100644
index 0000000..f0c7369
--- /dev/null
+++ b/src/images/bytefield/sv57x4va.edn
@@ -0,0 +1,42 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 4 :borders {}})
+(draw-box "58" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "48" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "47" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "39" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "38" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "30" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "29" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "21" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "20" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "12" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "11" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 2 :text-anchor "end" :borders {}})
+(draw-box nil {:span 4 :borders {}})
+
+(draw-box nil {:span 4 :borders {}})
+(draw-box "VPN[4]" {:span 4})
+(draw-box "VPN[3]" {:span 4})
+(draw-box "VPN[2]" {:span 4})
+(draw-box "VPN[1]" {:span 4})
+(draw-box "VPN[0]" {:span 4})
+(draw-box "page offset" {:span 4})
+(draw-box nil {:span 4 :borders {}})
+
+(draw-box nil {:span 4 :borders {}})
+(draw-box "11" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "9" {:span 4 :borders {}})
+(draw-box "12" {:span 4 :borders {}})
+(draw-box nil {:span 4 :borders {}})
+----
diff --git a/src/images/bytefield/vscausereg.edn b/src/images/bytefield/vscausereg.edn
new file mode 100644
index 0000000..74599e2
--- /dev/null
+++ b/src/images/bytefield/vscausereg.edn
@@ -0,0 +1,18 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "VSXLEN-1" {:span 4 :borders {}})
+(draw-box "VSXLEN-2" {:span 14 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 14 :text-anchor "end" :borders {}})
+(draw-box "Interrupt" {:span 4})
+(draw-box "Exception Code" {:span 14 :text-anchor "end" :borders {:top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WLRL)" {:font-weight "bold" :font-size 24}) {:span 14 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "1" {:span 4 :borders {}})
+(draw-box "VSXLEN-1" {:span 28 :borders {}})
+----
diff --git a/src/images/bytefield/vsepcreg.edn b/src/images/bytefield/vsepcreg.edn
new file mode 100644
index 0000000..f604f54
--- /dev/null
+++ b/src/images/bytefield/vsepcreg.edn
@@ -0,0 +1,14 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "VSXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+(draw-box "vsepc" {:span 32})
+(draw-box "VSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/vsiereg-standard.edn b/src/images/bytefield/vsiereg-standard.edn
new file mode 100644
index 0000000..c8829cf
--- /dev/null
+++ b/src/images/bytefield/vsiereg-standard.edn
@@ -0,0 +1,51 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "15" {:text-anchor "start" :borders {}})
+(draw-box "14" {:text-anchor "end" :borders {}})
+(draw-box "13" {:span 2 :borders {}})
+(draw-box "12" {:text-anchor "start" :borders {}})
+(draw-box "10" {:text-anchor "end" :borders {}})
+(draw-box "9" {:span 2 :borders {}})
+(draw-box "8" {:borders {}})
+(draw-box nil {:borders {}})
+(draw-box "6" {:borders {}})
+(draw-box "5" {:span 2 :borders {}})
+(draw-box "4" {:borders {}})
+(draw-box nil {:borders {}})
+(draw-box "2" {:borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "0" {:borders {}})
+(draw-box nil {:span 7 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "0" {:span 2})
+(draw-box (text "LCOFIE" {:font-size 20}) {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "SEIE" {:span 2})
+(draw-box "0" {:span 3})
+(draw-box "STIE" {:span 2})
+(draw-box "0" {:span 3})
+(draw-box "SSIE" {:span 2})
+(draw-box "0")
+(draw-box nil {:span 7 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box nil {:span 7 :borders {}})
+----
diff --git a/src/images/bytefield/vsiereg.edn b/src/images/bytefield/vsiereg.edn
new file mode 100644
index 0000000..53577ae
--- /dev/null
+++ b/src/images/bytefield/vsiereg.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "VSXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "Interrupts" {:span 16 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 16 :text-anchor "start" :borders {:right :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+
+(draw-box "VSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/vsipreg-standard.edn b/src/images/bytefield/vsipreg-standard.edn
new file mode 100644
index 0000000..fff25a2
--- /dev/null
+++ b/src/images/bytefield/vsipreg-standard.edn
@@ -0,0 +1,51 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "15" {:text-anchor "start" :borders {}})
+(draw-box "14" {:text-anchor "end" :borders {}})
+(draw-box "13" {:span 2 :borders {}})
+(draw-box "12" {:text-anchor "start" :borders {}})
+(draw-box "10" {:text-anchor "end" :borders {}})
+(draw-box "9" {:span 2 :borders {}})
+(draw-box "8" {:borders {}})
+(draw-box nil {:borders {}})
+(draw-box "6" {:borders {}})
+(draw-box "5" {:span 2 :borders {}})
+(draw-box "4" {:borders {}})
+(draw-box nil {:borders {}})
+(draw-box "2" {:borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "0" {:borders {}})
+(draw-box nil {:span 7 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "0" {:span 2})
+(draw-box (text "LCOFIP" {:font-size 20}) {:span 2})
+(draw-box "0" {:span 2})
+(draw-box "SEIP" {:span 2})
+(draw-box "0" {:span 3})
+(draw-box "STIP" {:span 2})
+(draw-box "0" {:span 3})
+(draw-box "SSIP" {:span 2})
+(draw-box "0")
+(draw-box nil {:span 7 :borders {}})
+
+(draw-box nil {:span 6 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box nil {:span 7 :borders {}})
+----
diff --git a/src/images/bytefield/vsipreg.edn b/src/images/bytefield/vsipreg.edn
new file mode 100644
index 0000000..53577ae
--- /dev/null
+++ b/src/images/bytefield/vsipreg.edn
@@ -0,0 +1,17 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "VSXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+
+(draw-box "Interrupts" {:span 16 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 16 :text-anchor "start" :borders {:right :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+
+(draw-box "VSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/vsscratchreg.edn b/src/images/bytefield/vsscratchreg.edn
new file mode 100644
index 0000000..5464300
--- /dev/null
+++ b/src/images/bytefield/vsscratchreg.edn
@@ -0,0 +1,14 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "VSXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+(draw-box "vsscratch" {:span 32})
+(draw-box "VSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/vsstatusreg-rv32.edn b/src/images/bytefield/vsstatusreg-rv32.edn
new file mode 100644
index 0000000..5b3a2b7
--- /dev/null
+++ b/src/images/bytefield/vsstatusreg-rv32.edn
@@ -0,0 +1,86 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box nil {:span 10 :borders {}})
+(draw-box "31" {:borders {}})
+(draw-box "30" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "20" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "19" {:span 2 :borders {}})
+(draw-box "18" {:span 2 :borders {}})
+(draw-box "17" {:span 3 :borders {}})
+(draw-box nil {:span 10 :borders {}})
+
+(draw-box nil {:span 10 :borders {}})
+(draw-box "SD")
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 4})
+(draw-box "MXR" {:span 2})
+(draw-box "SUM" {:span 2})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 3})
+(draw-box nil {:borders {:top :border-unrelated :bottom :border-unrelated}})
+(draw-box nil {:span 9 :borders {}})
+
+(draw-box nil {:span 10 :borders {}})
+(draw-box "1" {:borders {}})
+(draw-box "11" {:span 4 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 3 :borders {}})
+(draw-box nil {:borders {}})
+(draw-box nil {:span 9 :borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+
+(draw-box nil {:span 5 :borders {}})
+(draw-box "16" {:span 2:borders {} :text-anchor "start"})
+(draw-box "15" {:borders {}})
+(draw-box "14" {:span 2 :borders {} :text-anchor "start"})
+(draw-box "13" {:borders {}})
+(draw-box "12" {:borders {}})
+(draw-box "11" {:borders {}})
+(draw-box "10" {:span 2 :borders {} :text-anchor "start"})
+(draw-box "9" {:borders {}})
+(draw-box "8" {:span 2 :borders {}})
+(draw-box "7" {:span 2 :borders {}})
+(draw-box "6" {:span 2 :borders {}})
+(draw-box "5" {:span 2 :borders {}})
+(draw-box "4" {:borders {} :text-anchor "start"})
+(draw-box "2" {:borders {} :text-anchor "end"})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "0" {:span 2 :borders {}})
+(draw-box nil {:span 2 :borders {}})
+
+(draw-box nil {:span 4 :borders {}})
+(draw-box nil {:borders {:top :border-unrelated :bottom :border-unrelated}})
+(draw-box "XS[1:0]" {:span 3})
+(draw-box "FS[1:0]" {:span 3})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 2})
+(draw-box "VS[1:0]" {:span 3})
+(draw-box "SPP" {:span 2})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 2})
+(draw-box "UBE" {:span 2})
+(draw-box "SPIE" {:span 2})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 2})
+(draw-box "SIE" {:span 2})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 2})
+(draw-box nil {:span 2 :borders {}})
+
+(draw-box nil {:span 5 :borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box nil {:span 2 :borders {}})
+----
diff --git a/src/images/bytefield/vsstatusreg.edn b/src/images/bytefield/vsstatusreg.edn
new file mode 100644
index 0000000..cf8b828
--- /dev/null
+++ b/src/images/bytefield/vsstatusreg.edn
@@ -0,0 +1,90 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "63" {:span 3 :borders {}})
+(draw-box "62" {:span 5 :text-anchor "start" :borders {}})
+(draw-box "34" {:span 5 :text-anchor "end" :borders {}})
+(draw-box "33" {:span 2 :text-anchor "start" :borders {}})
+(draw-box "32" {:span 2 :text-anchor "end" :borders {}})
+(draw-box "31" {:span 3 :text-anchor "start" :borders {}})
+(draw-box "20" {:span 3 :text-anchor "end" :borders {}})
+(draw-box "19" {:span 2 :borders {}})
+(draw-box "18" {:span 2 :borders {}})
+(draw-box "17" {:span 2 :borders {}})
+(draw-box nil {:span 3 :borders {}})
+
+(draw-box "SD" {:span 3})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 10})
+(draw-box "UXL[1:0]" {:span 4})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 6})
+(draw-box "MXR" {:span 2})
+(draw-box "SUM" {:span 2})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 2})
+(draw-box nil {:borders {:top :border-unrelated :bottom :border-unrelated}})
+(draw-box nil {:span 2 :borders {}})
+
+(draw-box "1" {:span 3 :borders {}})
+(draw-box "29" {:span 10 :borders {}})
+(draw-box "2" {:span 4 :borders {}})
+(draw-box "12" {:span 6 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box nil {:span 3 :borders {}})
+
+(draw-box nil {:span 32 :borders {}})
+
+(draw-box nil {:span 4 :borders {}})
+(draw-box "16" {:span 2 :borders {} :text-anchor "start"})
+(draw-box "15" {:borders {}})
+(draw-box "14" {:span 2 :borders {} :text-anchor "start"})
+(draw-box "13" {:borders {}})
+(draw-box "12" {:borders {}})
+(draw-box "11" {:borders {}})
+(draw-box "10" {:span 2 :borders {} :text-anchor "start"})
+(draw-box "9" {:borders {}})
+(draw-box "8" {:span 2 :borders {}})
+(draw-box "7" {:span 2 :borders {}})
+(draw-box "6" {:span 2 :borders {}})
+(draw-box "5" {:span 2 :borders {}})
+(draw-box "4" {:borders {}})
+(draw-box "2" {:borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "0" {:span 2 :borders {}})
+(draw-box nil {:span 3 :borders {}})
+
+(draw-box nil {:span 3 :borders {}})
+(draw-box nil {:borders {:top :border-unrelated :bottom :border-unrelated}})
+(draw-box "XS[1:0]" {:span 3})
+(draw-box "FS[1:0]" {:span 3})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 2})
+(draw-box "VS[1:0]" {:span 3})
+(draw-box "SPP" {:span 2})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 2})
+(draw-box "UBE" {:span 2})
+(draw-box "SPIE" {:span 2})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 2})
+(draw-box "SIE" {:span 2})
+(draw-box (text "WPRI" {:font-weight "bold" :font-size 24}) {:span 2})
+(draw-box nil {:span 3 :borders {}})
+
+(draw-box nil {:span 4 :borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box "2" {:span 2 :borders {}})
+(draw-box "2" {:span 3 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "3" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box "1" {:span 2 :borders {}})
+(draw-box nil {:span 3 :borders {}})
+----
diff --git a/src/images/bytefield/vstvalreg.edn b/src/images/bytefield/vstvalreg.edn
new file mode 100644
index 0000000..d097b0f
--- /dev/null
+++ b/src/images/bytefield/vstvalreg.edn
@@ -0,0 +1,14 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "VSXLEN-1" {:span 16 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 16 :text-anchor "end" :borders {}})
+(draw-box "vstval" {:span 32})
+(draw-box "VSXLEN" {:span 32 :borders {}})
+----
diff --git a/src/images/bytefield/vstvecreg.edn b/src/images/bytefield/vstvecreg.edn
new file mode 100644
index 0000000..c93d6e0
--- /dev/null
+++ b/src/images/bytefield/vstvecreg.edn
@@ -0,0 +1,22 @@
+[bytefield]
+----
+(defattrs :plain [:plain {:font-family "M+ 1p Fallback" :font-size 24}])
+(def row-height 40 )
+(def row-header-fn nil)
+(def left-margin 30)
+(def right-margin 30)
+(def boxes-per-row 32)
+
+(draw-box "VSXLEN-1" {:span 10 :text-anchor "start" :borders {}})
+(draw-box "2" {:span 10 :text-anchor "end" :borders {}})
+(draw-box "1" {:span 6 :text-anchor "start" :borders {}})
+(draw-box "0" {:span 6 :text-anchor "end" :borders {}})
+
+(draw-box "BASE[VSXLEN-1:2]" {:span 10 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 10 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+(draw-box "MODE" {:span 6 :text-anchor "end" :borders {:left :border-unrelated :top :border-unrelated :bottom :border-unrelated}})
+(draw-box (text "(WARL)" {:font-weight "bold" :font-size 24}) {:span 6 :text-anchor "start" :borders {:top :border-unrelated :bottom :border-unrelated :right :border-unrelated}})
+
+(draw-box "VSXLEN-2" {:span 20 :borders {}})
+(draw-box "2" {:span 12 :borders {}})
+----
diff --git a/src/images/draft.png b/src/images/draft.png
new file mode 100644
index 0000000..2044bc8
--- /dev/null
+++ b/src/images/draft.png
Binary files differ
diff --git a/src/images/es_dataflow.svg b/src/images/es_dataflow.svg
new file mode 100644
index 0000000..c9d3306
--- /dev/null
+++ b/src/images/es_dataflow.svg
@@ -0,0 +1,181 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- This file was generated by dvisvgm 2.11.1 -->
+<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='230.494pt' height='311.191pt' viewBox='0 -311.191 230.494 311.191'>
+<g id='page1'>
+<g transform='matrix(1 0 0 -1 0 0)'>
+<path d='M162.266 298.035146C162.266 305.08202 133.711 310.793 98.4844 310.793C63.2617 310.793 34.707 305.08202 34.707 298.035146C34.707 290.99218 63.2617 285.2812 98.4844 285.2812C133.711 285.2812 162.266 290.99218 162.266 298.035146Z' fill='#ffe6e6'/>
+<path d='M162.266 298.035146C162.266 305.08202 133.711 310.793 98.4844 310.793C63.2617 310.793 34.707 305.08202 34.707 298.035146C34.707 290.99218 63.2617 285.2812 98.4844 285.2812C133.711 285.2812 162.266 290.99218 162.266 298.035146Z' stroke='#000' fill='none' stroke-width='.79701'/>
+<path d='M76.21433 301.52709H75.0337V297.14802C75.0337 297.05334 75.0387 296.94865 75.0437 296.83396C75.04839 296.71959 75.05839 296.6049 75.06839 296.49021L71.29214 301.31302C71.25714 301.35771 71.22214 301.39771 71.19245 301.4274C71.16245 301.4524 71.13245 301.4774 71.10277 301.4874C71.06777 301.5074 71.03308 301.51709 70.99308 301.51709C70.94839 301.52709 70.89839 301.52709 70.8437 301.52709H70.141204V294.323024H71.32183V298.74709C71.32183 298.93146 71.31183 299.13584 71.29214 299.3549L75.05339 294.552087C75.11839 294.467399 75.18808 294.412712 75.25777 294.372712C75.33245 294.343024 75.42214 294.323024 75.52683 294.323024H76.21433V301.52709Z'/>
+<path d='M79.725 299.51427C79.3413 299.51427 78.99753 299.45459 78.68378 299.33021C78.37003 299.20552 78.10597 299.03115 77.88159 298.80709C77.66253 298.58271 77.49316 298.30365 77.37347 297.9799C77.24878 297.65615 77.18909 297.2924 77.18909 296.88896C77.18909 296.48521 77.24878 296.11646 77.37347 295.79271C77.49316 295.46896 77.66253 295.189899 77.88159 294.960837C78.10597 294.731462 78.37003 294.557087 78.68378 294.432712C78.99753 294.308024 79.3413 294.248337 79.725 294.248337C80.1038 294.248337 80.4475 294.308024 80.7613 294.432712C81.0703 294.557087 81.3344 294.731462 81.5585 294.960837C81.7778 295.189899 81.9472 295.46896 82.0666 295.79271C82.1863 296.11646 82.246 296.48521 82.246 296.88896C82.246 297.2924 82.1863 297.65615 82.0666 297.9799C81.9472 298.30365 81.7778 298.58271 81.5585 298.80709C81.3344 299.03115 81.0703 299.20552 80.7613 299.33021C80.4475 299.45459 80.1038 299.51427 79.725 299.51427ZM79.725 295.194899C79.29159 295.194899 78.97285 295.33927 78.76847 295.62834C78.55909 295.9124 78.45472 296.33084 78.45472 296.87896C78.45472 297.42677 78.55909 297.84552 78.76847 298.13927C78.97285 298.42834 79.29159 298.57271 79.725 298.57271C80.1485 298.57271 80.4625 298.42834 80.6716 298.13927C80.871 297.85052 80.9757 297.43177 80.9757 296.87896C80.9757 296.32584 80.871 295.9074 80.6716 295.62334C80.4625 295.33927 80.1485 295.194899 79.725 295.194899ZM84.4619 299.43459H83.2266V294.323024H84.4619V299.43459ZM84.6313 300.92427C84.6313 301.03396 84.6116 301.13865 84.5666 301.23334C84.5219 301.32802 84.4669 301.41271 84.3922 301.4824C84.3225 301.55209 84.2378 301.60677 84.1432 301.64677C84.0485 301.69146 83.9438 301.71146 83.8344 301.71146C83.7297 301.71146 83.625 301.69146 83.5353 301.64677C83.4357 301.60677 83.356 301.55209 83.2863 301.4824S83.1616 301.32802 83.1169 301.23334C83.0769 301.13865 83.0572 301.03396 83.0572 300.92427C83.0572 300.81959 83.0769 300.72021 83.1169 300.62552C83.1616 300.53084 83.2166 300.45115 83.2863 300.38115C83.356 300.31146 83.4357 300.25677 83.5353 300.21177C83.625 300.17209 83.7297 300.15209 83.8344 300.15209C83.9438 300.15209 84.0485 300.17209 84.1432 300.21177C84.2378 300.25677 84.3225 300.31146 84.3922 300.38115C84.4669 300.45115 84.5219 300.53084 84.5666 300.62552C84.6116 300.72021 84.6313 300.81959 84.6313 300.92427ZM88.8358 298.43834L89.1149 298.88177C88.9205 299.07115 88.6814 299.22552 88.3924 299.3399C88.1036 299.45459 87.7846 299.51427 87.4308 299.51427C87.1171 299.51427 86.838 299.47459 86.5939 299.3849C86.3549 299.30521 86.1555 299.19052 85.9961 299.04615C85.8318 298.90646 85.7121 298.74209 85.6274 298.55271C85.5427 298.36365 85.5027 298.16427 85.5027 297.9549C85.5027 297.73084 85.5377 297.53646 85.6074 297.37709C85.6821 297.21771 85.7768 297.08302 85.8964 296.97365C86.0111 296.86396 86.1455 296.77427 86.2949 296.70459C86.4496 296.6299 86.6039 296.5699 86.7633 296.51521C86.9177 296.46021 87.0721 296.41552 87.2218 296.36584C87.3761 296.32584 87.5105 296.27115 87.6302 296.21615C87.7449 296.16146 87.8396 296.09177 87.9093 296.01709C87.9839 295.94209 88.0189 295.84271 88.0189 295.72302C88.0189 295.64334 88.0039 295.56865 87.9689 295.48896C87.9393 295.41896 87.8893 295.34927 87.8196 295.294587C87.7549 295.239587 87.6702 295.189899 87.5605 295.159899C87.4608 295.120212 87.3314 295.105212 87.1868 295.105212C87.0024 295.105212 86.848 295.125212 86.7233 295.169899C86.6039 295.214899 86.4993 295.259587 86.4096 295.309587C86.3199 295.35927 86.2402 295.40427 86.1755 295.44896C86.1058 295.49396 86.0308 295.51365 85.9561 295.51365S85.8168 295.49896 85.7668 295.46896C85.7171 295.43896 85.6724 295.39427 85.6374 295.33927L85.3533 294.871149C85.453 294.781462 85.5677 294.696774 85.6971 294.622087C85.8318 294.547087 85.9761 294.477399 86.1255 294.422712C86.2852 294.367712 86.4446 294.323024 86.6139 294.293024C86.7783 294.258337 86.9527 294.243337 87.1271 294.243337C87.4608 294.243337 87.7499 294.283024 88.0089 294.372712C88.258 294.452712 88.4721 294.572087 88.6464 294.721462C88.8208 294.876149 88.9505 295.055524 89.0352 295.259587C89.1249 295.46896 89.1696 295.69802 89.1696 295.94209C89.1696 296.14646 89.1349 296.32584 89.0652 296.47021C88.9902 296.6149 88.8958 296.74427 88.7761 296.84396C88.6614 296.95365 88.5271 297.03834 88.3777 297.10302C88.228 297.17271 88.0786 297.23271 87.9193 297.2874C87.7696 297.34209 87.6152 297.39209 87.4658 297.43177C87.3164 297.48177 87.1818 297.53146 87.0624 297.58646C86.9477 297.64115 86.853 297.71084 86.7833 297.78052C86.7086 297.86021 86.6736 297.9499 86.6736 298.05959C86.6736 298.22396 86.7433 298.35865 86.883 298.46334C87.0174 298.56771 87.2068 298.61771 87.4508 298.61771C87.6052 298.61771 87.7399 298.60271 87.8593 298.56771C87.9689 298.53302 88.0736 298.49802 88.1633 298.45834C88.253 298.41334 88.3327 298.37834 88.3974 298.34365C88.4671 298.30865 88.5321 298.29365 88.5918 298.29365C88.6464 298.29365 88.6964 298.30365 88.7311 298.32865C88.7661 298.34865 88.8011 298.38334 88.8358 298.43834ZM93.3887 297.46677H91.0671C91.1218 297.84052 91.2515 298.12427 91.4606 298.32865C91.66 298.53302 91.944 298.63271 92.2978 298.63271C92.4821 298.63271 92.6415 298.60271 92.7759 298.53802C92.9156 298.47802 93.03 298.39334 93.1196 298.28896C93.2093 298.18427 93.2743 298.05959 93.324 297.92021C93.364 297.77552 93.3887 297.62615 93.3887 297.46677ZM91.0421 296.72427H94.2059C94.3206 296.72427 94.3953 296.75427 94.435 296.82396C94.475 296.88396 94.495 297.01334 94.495 297.19771C94.495 297.56646 94.44 297.89521 94.3303 298.17927C94.2159 298.46802 94.0615 298.7124 93.8671 298.90646C93.6728 299.10584 93.4387 299.25521 93.1646 299.3599C92.8906 299.46459 92.5965 299.51427 92.2728 299.51427C91.889 299.51427 91.5503 299.44959 91.2415 299.31521C90.9425 299.18052 90.6834 299.00115 90.4743 298.77709C90.26 298.54802 90.1006 298.27896 89.9859 297.9699C89.8715 297.66615 89.8165 297.33709 89.8165 296.98834C89.8165 296.54021 89.8812 296.14646 90.0109 295.80771C90.1406 295.46396 90.3196 295.179899 90.544 294.950837C90.7681 294.716462 91.0371 294.542087 91.3412 294.422712C91.645 294.308024 91.9787 294.248337 92.3325 294.248337C92.5118 294.248337 92.6962 294.263337 92.8856 294.288024C93.08 294.313024 93.2643 294.363024 93.4537 294.422712C93.6328 294.492399 93.8121 294.577087 93.9815 294.681774C94.1509 294.791462 94.3056 294.925837 94.44 295.085212L94.0862 295.53365C94.0365 295.60834 93.9618 295.64834 93.8571 295.64834C93.7825 295.64834 93.7028 295.62334 93.6231 295.57865C93.5384 295.53365 93.4437 295.47896 93.334 295.42396C93.2293 295.36927 93.105 295.314587 92.9553 295.269587C92.8159 295.224899 92.6415 295.199899 92.4421 295.199899C92.2428 295.199899 92.0587 295.229899 91.899 295.289587C91.7296 295.35427 91.5903 295.44896 91.4706 295.56865C91.3512 295.69802 91.2565 295.8524 91.1818 296.04677C91.1068 296.23615 91.0621 296.46021 91.0421 296.72427Z'/>
+<path d='M101.8561 300.21677L102.1899 300.84959C101.9358 301.08865 101.6318 301.27302 101.273 301.40771C100.9146 301.54209 100.5208 301.60677 100.0974 301.60677C99.7186 301.60677 99.3849 301.54709 99.0911 301.4324C98.7971 301.31802 98.553 301.16365 98.3536 300.96927C98.1543 300.7749 98.0049 300.55552 97.8952 300.30646C97.7955 300.0574 97.7408 299.80334 97.7408 299.53927C97.7408 299.21052 97.7855 298.93646 97.8852 298.7074C97.9749 298.48802 98.1046 298.29865 98.2589 298.14927C98.4133 297.9999 98.5927 297.88021 98.7921 297.78552C98.9914 297.69084 99.1955 297.61115 99.3999 297.54646S99.8083 297.41709 100.0077 297.36209C100.2071 297.3074 100.3864 297.23771 100.5408 297.15302C100.6952 297.07302 100.8249 296.97365 100.9146 296.85396C101.0139 296.73427 101.0589 296.5799 101.0589 296.39052C101.0589 296.05177 100.9543 295.79271 100.7452 295.60834C100.5358 295.42896 100.2418 295.33927 99.8583 295.33927C99.6093 295.33927 99.3949 295.37427 99.2205 295.43896C99.0411 295.50865 98.8868 295.58365 98.7521 295.66834C98.6177 295.75302 98.503 295.82771 98.4083 295.8974C98.3136 295.96209 98.2239 295.99709 98.1393 295.99709C98.0796 295.99709 98.0249 295.98209 97.9699 295.94709C97.9152 295.9174 97.8752 295.8774 97.8405 295.83271L97.4468 295.189899C97.5864 295.045524 97.7458 294.915837 97.9252 294.801462C98.1046 294.686774 98.2939 294.587087 98.503 294.502399C98.7024 294.417712 98.9168 294.353024 99.1408 294.313024C99.3649 294.263337 99.5893 294.243337 99.8183 294.243337C100.2171 294.243337 100.5708 294.303024 100.8796 294.422712C101.1883 294.547087 101.4524 294.711774 101.6618 294.920837C101.8808 295.135212 102.0405 295.37927 102.1499 295.66834C102.2646 295.94709 102.3193 296.25615 102.3193 296.5799C102.3193 296.87896 102.2696 297.13302 102.1799 297.34209C102.0802 297.55146 101.9558 297.73084 101.8011 297.87021C101.6468 298.0199 101.4674 298.13927 101.2683 298.22896C101.0689 298.32865 100.8646 298.40834 100.6555 298.47802C100.4461 298.55271 100.2418 298.61771 100.0427 298.6824C99.8433 298.74709 99.6639 298.81677 99.5096 298.89677C99.3549 298.97646 99.2305 299.07115 99.1308 299.18552C99.0411 299.30021 98.9914 299.43959 98.9914 299.60896C98.9914 299.74365 99.0161 299.86302 99.0611 299.97271C99.1058 300.0874 99.1805 300.18209 99.2702 300.26177C99.3699 300.34146 99.4846 300.40115 99.6239 300.45115C99.7636 300.49084 99.928 300.51584 100.1124 300.51584C100.3164 300.51584 100.4958 300.49084 100.6455 300.44115C100.7999 300.38615 100.9293 300.33146 101.0439 300.26677C101.1586 300.20209 101.2533 300.14709 101.333 300.0924C101.4177 300.0424 101.4924 300.01771 101.5621 300.01771C101.6268 300.01771 101.6818 300.0324 101.7314 300.0624C101.7714 300.0974 101.8161 300.14709 101.8561 300.21677Z'/>
+<path d='M105.5384 299.51427C105.1546 299.51427 104.8109 299.45459 104.4971 299.33021C104.1834 299.20552 103.9193 299.03115 103.695 298.80709C103.4759 298.58271 103.3065 298.30365 103.1868 297.9799C103.0621 297.65615 103.0025 297.2924 103.0025 296.88896C103.0025 296.48521 103.0621 296.11646 103.1868 295.79271C103.3065 295.46896 103.4759 295.189899 103.695 294.960837C103.9193 294.731462 104.1834 294.557087 104.4971 294.432712C104.8109 294.308024 105.1546 294.248337 105.5384 294.248337C105.9171 294.248337 106.2609 294.308024 106.5746 294.432712C106.8837 294.557087 107.1478 294.731462 107.3718 294.960837C107.5912 295.189899 107.7606 295.46896 107.88 295.79271C107.9996 296.11646 108.0593 296.48521 108.0593 296.88896C108.0593 297.2924 107.9996 297.65615 107.88 297.9799C107.7606 298.30365 107.5912 298.58271 107.3718 298.80709C107.1478 299.03115 106.8837 299.20552 106.5746 299.33021C106.2609 299.45459 105.9171 299.51427 105.5384 299.51427ZM105.5384 295.194899C105.105 295.194899 104.7862 295.33927 104.5818 295.62834C104.3725 295.9124 104.2681 296.33084 104.2681 296.87896C104.2681 297.42677 104.3725 297.84552 104.5818 298.13927C104.7862 298.42834 105.105 298.57271 105.5384 298.57271C105.9618 298.57271 106.2759 298.42834 106.485 298.13927C106.6843 297.85052 106.789 297.43177 106.789 296.87896C106.789 296.32584 106.6843 295.9074 106.485 295.62334C106.2759 295.33927 105.9618 295.194899 105.5384 295.194899ZM113.404 299.43459H112.1737V295.73802C112.0093 295.57365 111.83 295.43896 111.6456 295.34927C111.4612 295.249587 111.2618 295.204899 111.0478 295.204899C110.7587 295.204899 110.5443 295.289587 110.395 295.45896C110.2556 295.63334 110.1806 295.8724 110.1806 296.18646V299.43459H108.9503V296.18646C108.9503 295.9024 108.99 295.63834 109.0596 295.39927C109.1393 295.164899 109.249 294.960837 109.3937 294.786462C109.5381 294.612087 109.7175 294.482399 109.9365 294.382712C110.1459 294.293024 110.395 294.243337 110.674 294.243337C111.0178 294.243337 111.3118 294.308024 111.5659 294.442712C111.82 294.572087 112.049 294.741462 112.2584 294.955837L112.3431 294.547087C112.3878 294.397712 112.4875 294.323024 112.6518 294.323024H113.404V299.43459ZM115.7798 298.54802L115.7051 299.12584C115.6901 299.24052 115.6551 299.32521 115.6054 299.3649C115.5554 299.4149 115.4657 299.43459 115.3414 299.43459H114.6189V294.323024H115.8495V297.47177C115.9042 297.60615 115.9642 297.73084 116.0339 297.83552C116.0935 297.94021 116.1732 298.02959 116.2529 298.10959C116.3426 298.17927 116.4373 298.23896 116.542 298.27896C116.6467 298.31865 116.771 298.33865 116.9057 298.33865C117.0004 298.33865 117.0951 298.32865 117.1898 298.31365C117.2892 298.29865 117.3642 298.28896 117.4139 298.28896C117.4685 298.28896 117.5085 298.29865 117.5385 298.32865C117.5732 298.34865 117.5982 298.39334 117.6132 298.45334L117.6929 299.3749C117.5482 299.47959 117.3592 299.52927 117.1248 299.52927C116.826 299.52927 116.567 299.44459 116.3476 299.26521C116.1285 299.09584 115.9392 298.85177 115.7798 298.54802Z'/>
+<path d='M121.8436 298.35365L122.1674 298.80209C121.9383 299.03115 121.6793 299.20552 121.3902 299.33021C121.1061 299.45459 120.7724 299.51427 120.3889 299.51427C119.9852 299.51427 119.6314 299.44959 119.3227 299.31521C119.0136 299.18052 118.7546 298.99615 118.5455 298.76709C118.3361 298.52802 118.1767 298.25396 118.0721 297.93021C117.9627 297.61115 117.9077 297.2624 117.9077 296.88896C117.9077 296.47021 117.9674 296.09677 118.0921 295.76771C118.2117 295.44396 118.3761 295.164899 118.5852 294.940837C118.7946 294.716462 119.0386 294.542087 119.3177 294.422712C119.5968 294.308024 119.8955 294.248337 120.2096 294.248337C120.3889 294.248337 120.5683 294.263337 120.7527 294.288024C120.9318 294.313024 121.1061 294.363024 121.2805 294.422712C121.4502 294.492399 121.6146 294.577087 121.7739 294.681774C121.9333 294.791462 122.0827 294.925837 122.2174 295.085212L121.8636 295.53365C121.8136 295.60834 121.7389 295.64834 121.6393 295.64834C121.5646 295.64834 121.4949 295.62334 121.4302 295.57865C121.3702 295.52865 121.3005 295.47396 121.2158 295.41896C121.1311 295.35927 121.0314 295.304587 120.9121 295.259587C120.7874 295.209899 120.628 295.184899 120.4336 295.184899S120.0599 295.219899 119.9055 295.299587C119.7511 295.36927 119.6168 295.47896 119.5071 295.62834C119.3974 295.76771 119.3127 295.94709 119.258 296.16146C119.198 296.37552 119.1683 296.6149 119.1683 296.88896C119.1683 297.15302 119.193 297.38709 119.248 297.59146C119.3027 297.80052 119.3824 297.9799 119.4871 298.12427C119.5968 298.26896 119.7311 298.38334 119.8955 298.45834C120.0599 298.53802 120.2493 298.57771 120.4636 298.57771C120.633 298.57771 120.7724 298.55771 120.8921 298.51802C121.0018 298.48302 121.1014 298.43834 121.1861 298.38834C121.2708 298.34365 121.3405 298.29865 121.4002 298.25896C121.4599 298.22396 121.5199 298.20396 121.5846 298.20396C121.6492 298.20396 121.6993 298.21896 121.7389 298.24396C121.7689 298.26896 121.8086 298.30865 121.8436 298.35365Z'/>
+<path d='M126.186 297.46677H123.8644C123.9191 297.84052 124.0488 298.12427 124.2578 298.32865C124.4572 298.53302 124.7413 298.63271 125.095 298.63271C125.2794 298.63271 125.4388 298.60271 125.5732 298.53802C125.7128 298.47802 125.8272 298.39334 125.9169 298.28896C126.0066 298.18427 126.0716 298.05959 126.1213 297.92021C126.1613 297.77552 126.186 297.62615 126.186 297.46677ZM123.8394 296.72427H127.0032C127.1178 296.72427 127.1925 296.75427 127.2322 296.82396C127.2722 296.88396 127.2922 297.01334 127.2922 297.19771C127.2922 297.56646 127.2372 297.89521 127.1275 298.17927C127.0132 298.46802 126.8588 298.7124 126.6644 298.90646C126.47 299.10584 126.236 299.25521 125.9619 299.3599S125.3938 299.51427 125.07 299.51427C124.6863 299.51427 124.3475 299.44959 124.0388 299.31521C123.7397 299.18052 123.4807 299.00115 123.2716 298.77709C123.0572 298.54802 122.8978 298.27896 122.7832 297.9699C122.6688 297.66615 122.6138 297.33709 122.6138 296.98834C122.6138 296.54021 122.6785 296.14646 122.8082 295.80771C122.9378 295.46396 123.1169 295.179899 123.3413 294.950837C123.5653 294.716462 123.8344 294.542087 124.1385 294.422712C124.4422 294.308024 124.776 294.248337 125.1297 294.248337C125.3091 294.248337 125.4935 294.263337 125.6828 294.288024C125.8772 294.313024 126.0616 294.363024 126.251 294.422712C126.43 294.492399 126.6094 294.577087 126.7788 294.681774C126.9482 294.791462 127.1028 294.925837 127.2372 295.085212L126.8835 295.53365C126.8338 295.60834 126.7591 295.64834 126.6544 295.64834C126.5797 295.64834 126.5 295.62334 126.4203 295.57865C126.3357 295.53365 126.241 295.47896 126.1313 295.42396C126.0266 295.36927 125.9022 295.314587 125.7525 295.269587C125.6132 295.224899 125.4388 295.199899 125.2394 295.199899S124.856 295.229899 124.6963 295.289587C124.5269 295.35427 124.3875 295.44896 124.2678 295.56865C124.1485 295.69802 124.0538 295.8524 123.9791 296.04677C123.9041 296.23615 123.8594 296.46021 123.8394 296.72427Z'/>
+<path d='M98.4844 285.2812V262.832' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M98.484355 260.33635L99.83201 263.906659L98.484355 262.73088L97.1406 263.906659Z'/>
+<path d='M98.484355 260.33635L99.83201 263.906659L98.484355 262.73088L97.1406 263.906659Z' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M65.290282 274.48366L65.78341 274.6721C65.84184 274.6946 65.88653 274.72585 65.90466 274.77053C65.93153 274.80647 65.93153 274.85147 65.90903 274.90085C65.84184 275.05303 65.80591 275.20116 65.80591 275.3446C65.80153 275.49272 65.81935 275.6271 65.85966 275.7571C65.89997 275.88272 65.94935 275.99928 66.02122 276.10678C66.08403 276.20991 66.15122 276.30428 66.21841 276.38053C66.24997 276.41616 66.27216 276.44303 66.2856 276.46553C66.29903 276.48803 66.30372 276.51053 66.30372 276.53272C66.30372 276.57335 66.2856 276.60897 66.25435 276.63147L66.04372 276.77053C65.85091 276.61366 65.68934 276.44772 65.55497 276.26835C65.41591 276.0846 65.312783 275.89616 65.240907 275.70335C65.17372 275.50616 65.14247 275.30428 65.14247 275.10241C65.15122 274.89616 65.19622 274.68991 65.290282 274.48366ZM66.54122 274.48366L67.03466 274.6721C67.09278 274.6946 67.1331 274.72585 67.15997 274.77053C67.17809 274.80647 67.18247 274.85147 67.15997 274.90085C67.09278 275.05303 67.05685 275.20116 67.05247 275.3446C67.05247 275.49272 67.07028 275.6271 67.11091 275.7571C67.15122 275.88272 67.20497 275.99928 67.26778 276.10678C67.33935 276.20991 67.40216 276.30428 67.46934 276.38053C67.50091 276.41616 67.52341 276.44303 67.53685 276.46553C67.55028 276.48803 67.55466 276.51053 67.55466 276.53272C67.55466 276.57335 67.53685 276.60897 67.50528 276.63147L67.29466 276.77053C67.10185 276.61366 66.94028 276.44772 66.80153 276.26835C66.66684 276.0846 66.56372 275.89616 66.49653 275.70335C66.42466 275.50616 66.38872 275.30428 66.39778 275.10241C66.39778 274.89616 66.44716 274.68991 66.54122 274.48366Z'/>
+<path d='M70.39895 273.91428L70.20614 272.35835C70.12114 272.09366 70.02708 271.8471 69.91927 271.62303C69.81177 271.40335 69.6952 271.21053 69.56958 271.04897C69.43958 270.883034 69.30489 270.757409 69.16614 270.663346C69.02708 270.573659 68.88364 270.528971 68.73552 270.528971C68.27364 270.528971 68.04489 270.887721 68.04489 271.6096C68.04489 271.81585 68.06739 272.01741 68.11677 272.21491C68.16614 272.40772 68.23333 272.59147 68.31395 272.76647C68.40364 272.94116 68.50239 273.09803 68.62333 273.24616C68.74458 273.3896 68.87458 273.51522 69.02239 273.61835C69.17052 273.72147 69.32739 273.8021 69.49333 273.86491C69.65927 273.91866 69.83427 273.95022 70.01333 273.95022C70.07614 273.95022 70.13895 273.94553 70.20614 273.94553C70.26895 273.93678 70.33177 273.92772 70.39895 273.91428ZM70.09427 271.12522L70.00895 270.206159C70.00895 270.129909 70.02708 270.062409 70.0627 270.008659C70.10302 269.954909 70.17489 269.928034 70.27802 269.928034H70.69052L71.23302 274.32241C71.05364 274.39866 70.86989 274.45678 70.69052 274.48366C70.50208 274.5196 70.31395 274.53303 70.12114 274.53303C69.85208 274.53303 69.59645 274.49272 69.34989 274.42085C69.10333 274.34022 68.87458 274.23272 68.66395 274.09803C68.44864 273.9546 68.25583 273.79303 68.08083 273.60491C67.90614 273.4121 67.75802 273.20585 67.63239 272.9771C67.51145 272.74835 67.41739 272.51085 67.34552 272.25085C67.2827 271.9996 67.24677 271.73491 67.24677 271.46616C67.24677 271.21053 67.27395 270.98178 67.33208 270.779909C67.39052 270.582721 67.47114 270.416784 67.56989 270.277721C67.67739 270.143346 67.79833 270.040221 67.94645 269.972721C68.09427 269.901159 68.25583 269.865221 68.4352 269.865221C68.60114 269.865221 68.75802 269.896784 68.91489 269.954909C69.06739 270.013346 69.21083 270.098346 69.35427 270.206159C69.48895 270.318034 69.62333 270.448034 69.74895 270.605221C69.86989 270.762096 69.98645 270.93241 70.09427 271.12522ZM73.01231 273.32241L73.07981 274.20585C73.07981 274.38491 72.99013 274.4746 72.81075 274.4746H72.41606L71.86919 269.928034H72.66731L72.92731 272.23272C73.01231 272.47928 73.11106 272.70803 73.22763 272.90522C73.34888 273.11147 73.47419 273.2821 73.61325 273.42553C73.75231 273.56897 73.89138 273.68116 74.04388 273.75741C74.18731 273.83366 74.33513 273.87397 74.4786 273.87397C74.712 273.87397 74.8733 273.78866 74.9586 273.61397C75.0436 273.44335 75.0661 273.17897 75.0258 272.82022L74.6848 269.928034H75.4786L75.8195 272.82022C75.8508 273.09366 75.8508 273.33585 75.8195 273.55116C75.7879 273.76178 75.7251 273.94116 75.6311 274.08897C75.5414 274.2371 75.4248 274.34928 75.2814 274.42085C75.1333 274.50178 74.9673 274.53741 74.7745 274.53741C74.4517 274.53741 74.13794 274.43428 73.83294 274.23272C73.52825 274.02647 73.2545 273.72147 73.01231 273.32241ZM79.7329 273.91428L79.5401 272.35835C79.4551 272.09366 79.3611 271.8471 79.2533 271.62303C79.1458 271.40335 79.0292 271.21053 78.9036 271.04897C78.7736 270.883034 78.6389 270.757409 78.5001 270.663346C78.3611 270.573659 78.2176 270.528971 78.0695 270.528971C77.6076 270.528971 77.3789 270.887721 77.3789 271.6096C77.3789 271.81585 77.4014 272.01741 77.4508 272.21491C77.5001 272.40772 77.5673 272.59147 77.6479 272.76647C77.7376 272.94116 77.8364 273.09803 77.9573 273.24616C78.0786 273.3896 78.2086 273.51522 78.3564 273.61835C78.5045 273.72147 78.6614 273.8021 78.8273 273.86491C78.9933 273.91866 79.1683 273.95022 79.3473 273.95022C79.4101 273.95022 79.4729 273.94553 79.5401 273.94553C79.6029 273.93678 79.6658 273.92772 79.7329 273.91428ZM79.4283 271.12522L79.3429 270.206159C79.3429 270.129909 79.3611 270.062409 79.3967 270.008659C79.437 269.954909 79.5089 269.928034 79.612 269.928034H80.0245L80.567 274.32241C80.3876 274.39866 80.2039 274.45678 80.0245 274.48366C79.8361 274.5196 79.6479 274.53303 79.4551 274.53303C79.1861 274.53303 78.9304 274.49272 78.6839 274.42085C78.4373 274.34022 78.2086 274.23272 77.9979 274.09803C77.7826 273.9546 77.5898 273.79303 77.4148 273.60491C77.2401 273.4121 77.092 273.20585 76.9664 272.9771C76.8454 272.74835 76.7514 272.51085 76.6795 272.25085C76.6167 271.9996 76.5808 271.73491 76.5808 271.46616C76.5808 271.21053 76.6079 270.98178 76.6661 270.779909C76.7245 270.582721 76.8051 270.416784 76.9039 270.277721C77.0114 270.143346 77.1323 270.040221 77.2804 269.972721C77.4283 269.901159 77.5898 269.865221 77.7692 269.865221C77.9351 269.865221 78.092 269.896784 78.2489 269.954909C78.4014 270.013346 78.5448 270.098346 78.6883 270.206159C78.8229 270.318034 78.9573 270.448034 79.0829 270.605221C79.2039 270.762096 79.3204 270.93241 79.4283 271.12522ZM81.2254 269.928034H82.01L82.8129 276.53272H82.0282L81.2254 269.928034ZM84.9872 270.488659C84.6731 270.488659 84.4356 270.596159 84.2697 270.806784C84.1037 271.0221 84.0231 271.34053 84.0231 271.75741C84.0231 272.03991 84.059 272.31335 84.1262 272.57366C84.1934 272.83366 84.2922 273.06241 84.4178 273.2596C84.5431 273.45678 84.6956 273.61397 84.875 273.73053C85.05 273.85147 85.2515 273.90991 85.4715 273.90991C85.7809 273.90991 86.0228 273.8021 86.1843 273.59585C86.3547 273.38053 86.4353 273.06678 86.4353 272.64991C86.4353 272.36741 86.3997 272.09366 86.3322 271.83366C86.265 271.57366 86.1665 271.34491 86.0409 271.14772C85.9109 270.94585 85.7584 270.788971 85.5834 270.668034C85.404 270.546784 85.2068 270.488659 84.9872 270.488659ZM84.9109 269.865221C85.2381 269.865221 85.5431 269.937096 85.8256 270.089596C86.1081 270.233034 86.3547 270.434596 86.5609 270.690221C86.7718 270.94585 86.9331 271.24178 87.0543 271.57803C87.1753 271.91428 87.2337 272.27303 87.2337 272.65428C87.2337 272.95022 87.1931 273.2146 87.1081 273.44803C87.0228 273.68116 86.9062 273.87835 86.7584 274.03991C86.6103 274.20116 86.4309 274.32241 86.2247 274.4121C86.0184 274.49272 85.7897 274.53741 85.5431 274.53741C85.2159 274.53741 84.9109 274.46585 84.6328 274.31772C84.3459 274.16991 84.1037 273.97241 83.8931 273.72147C83.6822 273.46585 83.5209 273.16991 83.4 272.83366C83.2787 272.49741 83.2206 272.13397 83.2206 271.75303C83.2206 271.45272 83.2609 271.18803 83.3459 270.95491C83.4312 270.721784 83.5478 270.524284 83.6959 270.363034C83.8437 270.201471 84.0231 270.080534 84.2293 269.990846C84.4356 269.910221 84.6643 269.865221 84.9109 269.865221Z'/>
+<path d='M89.5385 271.9771C89.3054 271.9771 89.1216 272.04897 88.996 272.18803C88.8613 272.32678 88.7988 272.53335 88.7988 272.8021C88.7988 272.9546 88.821 273.10272 88.8613 273.24178C88.9063 273.38053 88.9691 273.50616 89.0588 273.61835C89.1394 273.73053 89.2469 273.81553 89.3682 273.88272C89.4891 273.95022 89.6325 273.98147 89.7941 273.98147C90.0272 273.98147 90.211 273.91428 90.341 273.7796C90.4757 273.64522 90.5429 273.44803 90.5429 273.18335C90.5429 273.03553 90.5204 272.89178 90.4757 272.74835C90.4307 272.60491 90.3679 272.47491 90.2785 272.35835C90.1975 272.24616 90.09 272.1521 89.9644 272.08022C89.8435 272.01303 89.7 271.9771 89.5385 271.9771ZM90.4397 269.815846C90.4397 269.685846 90.4085 269.564909 90.341 269.448346C90.2785 269.331784 90.1888 269.228659 90.0719 269.143346C89.96 269.058034 89.821 268.986471 89.6594 268.932721C89.4938 268.88335 89.3144 268.85647 89.1169 268.85647C88.785 268.85647 88.5297 268.9146 88.3504 269.026784C88.1663 269.138971 88.0766 269.304909 88.0766 269.519909C88.0766 269.649909 88.1216 269.775534 88.2113 269.887721C88.301 269.999909 88.44 270.093971 88.6282 270.165534C88.8122 270.237409 89.0497 270.282409 89.3366 270.295846C89.6238 270.313659 89.9644 270.291159 90.3591 270.228346C90.3816 270.170221 90.4038 270.107409 90.4172 270.035534C90.4307 269.972721 90.4397 269.896784 90.4397 269.815846ZM91.9644 274.30428H90.7357C90.6191 274.38053 90.4891 274.43897 90.341 274.47928C90.1932 274.5196 90.0407 274.53741 89.8794 274.53741C89.5879 274.53741 89.3279 274.48803 89.1035 274.3896C88.8794 274.29085 88.691 274.16085 88.5385 273.99928C88.386 273.83366 88.2694 273.6496 88.1888 273.44335C88.1125 273.23272 88.0722 273.0221 88.0722 272.80678C88.0722 272.5871 88.1035 272.39428 88.171 272.22366C88.2382 272.06241 88.3279 271.92335 88.44 271.81116C88.5519 271.69928 88.6866 271.61835 88.8344 271.56022C88.9869 271.50178 89.1485 271.47491 89.3232 271.47491C89.5025 271.47491 89.6641 271.49741 89.8032 271.5421C89.9419 271.58272 90.0719 271.64522 90.1841 271.72147C90.1169 271.59616 90.0719 271.48397 90.045 271.38522C90.0138 271.28678 90.0004 271.19241 90.0004 271.09835C90.0004 271.02647 90.0094 270.95928 90.0272 270.896471C90.0407 270.838346 90.0632 270.779909 90.09 270.721784C89.8838 270.753034 89.6729 270.766471 89.4579 270.771159C89.2425 270.771159 89.0319 270.753034 88.8257 270.721784C88.6238 270.690221 88.431 270.636471 88.2472 270.569284C88.0632 270.502096 87.9063 270.412409 87.7672 270.304596C87.6285 270.201471 87.5207 270.076159 87.44 269.928034C87.3594 269.779909 87.3188 269.614284 87.3188 269.421471C87.3188 269.255534 87.3594 269.103034 87.4444 268.959596C87.5254 268.82491 87.6419 268.70397 87.7941 268.60522C87.9422 268.50678 88.126 268.43053 88.3413 268.37647C88.5519 268.32272 88.7897 268.29585 89.0497 268.29585C89.3769 268.29585 89.6685 268.34085 89.9285 268.42147C90.1888 268.51116 90.4085 268.62335 90.5922 268.77116C90.776 268.91928 90.915 269.084909 91.0138 269.273346C91.1122 269.466159 91.1616 269.668034 91.1663 269.878659C91.1663 269.990846 91.1525 270.098346 91.1213 270.188034C91.0944 270.286784 91.0585 270.372096 91.0138 270.452721C90.9735 270.533346 90.9241 270.609596 90.8704 270.681471C90.821 270.753034 90.7716 270.824909 90.7266 270.896471C90.6863 270.96397 90.6504 271.03553 90.6191 271.11178C90.5922 271.18366 90.5788 271.25991 90.5788 271.34053C90.5788 271.45272 90.5966 271.55116 90.6282 271.64991C90.6641 271.7396 90.7088 271.83366 90.7582 271.91897C90.8075 272.00866 90.8657 272.09835 90.9241 272.18803C90.9822 272.27772 91.0407 272.37178 91.09 272.47491C91.1391 272.57803 91.1841 272.68553 91.22 272.80678C91.2513 272.92772 91.2694 273.06241 91.2694 273.21022C91.2694 273.39866 91.2422 273.56897 91.1841 273.72585L91.7535 273.8246C91.8566 273.86053 91.9194 273.9321 91.9329 274.03991L91.9644 274.30428Z'/>
+<path d='M93.5381 276.66741L93.045 276.47897C92.9865 276.45647 92.9462 276.42085 92.9193 276.38491C92.9015 276.33991 92.8968 276.2996 92.9193 276.25022C92.9865 276.09803 93.0225 275.94991 93.0268 275.8021C93.0268 275.65835 93.009 275.52397 92.9687 275.39397S92.8743 275.14741 92.8118 275.0396C92.74 274.93647 92.6772 274.84678 92.61 274.77053C92.5784 274.73491 92.5562 274.70803 92.5428 274.68553C92.5293 274.66303 92.5247 274.64053 92.5247 274.61835C92.5247 274.57772 92.5428 274.5421 92.574 274.5196L92.7847 274.38053C92.9775 274.53741 93.139 274.70335 93.2781 274.88741C93.4125 275.06647 93.5156 275.25491 93.5831 275.4521C93.6547 275.64491 93.6906 275.84678 93.6815 276.05303C93.6815 276.25491 93.6322 276.46116 93.5381 276.66741ZM94.789 276.66741L94.2959 276.47897C94.2375 276.45647 94.1928 276.42085 94.175 276.38491C94.1478 276.33991 94.1478 276.2996 94.1703 276.25022C94.2375 276.09803 94.2734 275.94991 94.2734 275.8021C94.2781 275.65835 94.26 275.52397 94.2197 275.39397C94.1793 275.26397 94.13 275.14741 94.0581 275.0396C93.9956 274.93647 93.9281 274.84678 93.8609 274.77053C93.8297 274.73491 93.8072 274.70803 93.7937 274.68553C93.7803 274.66303 93.7759 274.64053 93.7759 274.61835C93.7759 274.57772 93.7937 274.5421 93.825 274.5196L94.0359 274.38053C94.2287 274.53741 94.39 274.70335 94.5247 274.88741C94.6637 275.06647 94.7668 275.25491 94.8384 275.4521C94.9056 275.64491 94.9372 275.84678 94.9372 276.05303C94.9281 276.25491 94.8834 276.46116 94.789 276.66741Z'/>
+<path d='M105.1965 273.87493L105.39837 274.1618C105.25025 274.31868 105.07087 274.43993 104.86462 274.53399C104.654 274.62368 104.4165 274.66837 104.14275 274.66837C103.88712 274.66837 103.654 274.62805 103.44775 274.54305C103.24619 274.46212 103.07119 274.35462 102.927748 274.21555C102.784311 274.07649 102.676498 273.91962 102.595873 273.74493C102.523998 273.56555 102.483686 273.38149 102.483686 273.18868C102.483686 272.96899 102.528686 272.7943 102.622748 272.6643C102.716811 272.53399 102.833373 272.42649 102.972436 272.34587C103.1115 272.26055 103.264 272.19337 103.42525 272.13962C103.58681 272.09024 103.73931 272.0318 103.87837 271.97368C104.01744 271.91524 104.134 271.83899 104.22806 271.7493C104.32212 271.65962 104.36712 271.53868 104.36712 271.38618C104.36712 271.27399 104.34462 271.16649 104.29962 271.06337C104.25931 270.964616 104.1965 270.879616 104.1115 270.803366C104.03087 270.727116 103.93212 270.668679 103.81556 270.623991C103.69431 270.578991 103.56431 270.556804 103.4165 270.556804C103.25056 270.556804 103.1115 270.578991 102.999311 270.619616C102.891811 270.659929 102.802123 270.709304 102.730248 270.758366C102.658686 270.812429 102.600248 270.861491 102.551186 270.902116C102.501811 270.942429 102.456811 270.964616 102.407436 270.964616C102.358373 270.964616 102.317748 270.955866 102.282123 270.933366C102.255248 270.910866 102.223686 270.883991 102.196811 270.843679L101.999623 270.538679C102.138373 270.377429 102.322436 270.247429 102.542123 270.139617C102.766186 270.041179 103.02181 269.987117 103.31337 269.987117C103.58244 269.987117 103.82462 270.032117 104.03962 270.117429C104.25931 270.202429 104.44337 270.318991 104.59556 270.462429C104.75275 270.610554 104.86931 270.776491 104.95431 270.969304C105.03525 271.16212 105.07556 271.3593 105.07556 271.56993C105.07556 271.78524 105.03056 271.96024 104.9365 272.09462C104.84244 272.2293 104.72587 272.34118 104.58681 272.42649S104.29525 272.58337 104.134 272.6418C103.97244 272.69993 103.81994 272.75837 103.68087 272.82118C103.54212 272.8793 103.42525 272.95118 103.33119 273.03618C103.23712 273.12149 103.19212 273.23368 103.19212 273.37274C103.19212 273.47118 103.21462 273.56555 103.25962 273.65524C103.29994 273.74024 103.36275 273.81649 103.439 273.88368C103.51962 273.95118 103.61369 274.00024 103.72587 274.04087C103.83806 274.07649 103.959 274.09462 104.09337 274.09462C104.23712 274.09462 104.35806 274.07649 104.46119 274.04087C104.56431 274.0093 104.64962 273.96899 104.72119 273.93305C104.78837 273.88837 104.84681 273.85243 104.90056 273.82087C104.94556 273.78962 104.99462 273.7718 105.03525 273.7718C105.07087 273.7718 105.10244 273.78055 105.12494 273.79868C105.14712 273.81212 105.174 273.83899 105.1965 273.87493ZM107.07923 273.5968L107.45142 276.66368H106.65329L105.85517 270.058991H106.64861L106.94017 272.45774C107.02548 272.69555 107.12861 272.90618 107.24954 273.09899C107.36611 273.2918 107.49173 273.45337 107.62611 273.58774C107.75611 273.72243 107.89517 273.82555 108.03861 273.89712C108.18205 273.97337 108.32111 274.0093 108.4558 274.0093C108.69329 274.0093 108.85486 273.92399 108.93986 273.7493C109.02517 273.5743 109.04767 273.30993 109.00267 272.95118L108.66204 270.058991H109.46017L109.80079 272.95118C109.83236 273.22462 109.83236 273.4668 109.80079 273.68212C109.76954 273.89274 109.70673 274.07212 109.61705 274.21993C109.52298 274.36805 109.40642 274.48024 109.25829 274.5518C109.11048 274.63274 108.93986 274.66837 108.74704 274.66837C108.44673 274.66837 108.15517 274.57868 107.8683 274.3993C107.57673 274.21555 107.31673 273.95118 107.07923 273.5968ZM112.3694 270.619616C112.0553 270.619616 111.81783 270.727116 111.65189 270.937741C111.48595 271.15305 111.40533 271.47149 111.40533 271.88837C111.40533 272.17087 111.44126 272.4443 111.50845 272.70462C111.57564 272.96462 111.67439 273.19337 111.80001 273.39055C111.92533 273.58774 112.0778 273.74493 112.2572 273.86149C112.4322 273.98243 112.6338 274.04087 112.8538 274.04087C113.1631 274.04087 113.405 273.93305 113.5666 273.7268C113.7369 273.51149 113.8175 273.19774 113.8175 272.78087C113.8175 272.49837 113.7819 272.22462 113.7144 271.96462C113.6472 271.70462 113.5488 271.47587 113.4231 271.27868C113.2931 271.0768 113.1406 270.919929 112.9656 270.798991C112.7863 270.677741 112.5891 270.619616 112.3694 270.619616ZM112.2931 269.996179C112.6203 269.996179 112.9253 270.068054 113.2078 270.220554C113.4903 270.363991 113.7369 270.565554 113.9431 270.821179C114.1541 271.0768 114.3153 271.37274 114.4366 271.70899C114.5575 272.04524 114.616 272.40399 114.616 272.78524C114.616 273.08118 114.5753 273.34555 114.4903 273.57899C114.405 273.81212 114.2885 274.0093 114.1406 274.17087C113.9925 274.33212 113.8131 274.45337 113.6069 274.54305C113.4006 274.62368 113.1719 274.66837 112.9253 274.66837C112.5981 274.66837 112.2931 274.5968 112.015 274.44868C111.72814 274.30087 111.48595 274.10337 111.27533 273.85243C111.06439 273.5968 110.90314 273.30087 110.7822 272.96462C110.66095 272.62837 110.60283 272.26493 110.60283 271.88399C110.60283 271.58368 110.64314 271.31899 110.72814 271.08587C110.81345 270.852741 110.93001 270.655241 111.07814 270.493991C111.22595 270.332429 111.40533 270.211491 111.61158 270.121804C111.81783 270.041179 112.0466 269.996179 112.2931 269.996179Z'/>
+<path d='M115.5308 270.915554C115.5355 270.614929 115.6252 270.381804 115.7864 270.224929C115.957 270.068054 116.1811 269.987117 116.4727 269.987117C116.6608 269.987117 116.8492 270.023054 117.033 270.094929C117.2214 270.171179 117.3874 270.269616 117.5352 270.399616L117.3649 270.780866C117.3514 270.807741 117.338 270.825866 117.3289 270.839304C117.3111 270.852741 117.293 270.857116 117.2661 270.857116C117.2439 270.857116 117.2214 270.848054 117.1899 270.821179C117.1586 270.803366 117.1227 270.776491 117.078 270.749616C117.033 270.722741 116.9792 270.695554 116.9255 270.677741C116.8627 270.650866 116.7955 270.641804 116.7145 270.641804C116.5936 270.641804 116.4995 270.677741 116.4277 270.749616C116.3561 270.825866 116.3202 270.937741 116.3202 271.09024C116.3202 271.0993 116.3202 271.11274 116.3245 271.13055C116.3245 271.14868 116.3245 271.17993 116.3336 271.22493C116.3336 271.26962 116.3427 271.32805 116.3514 271.4043C116.3605 271.48024 116.3739 271.57899 116.3874 271.70024L116.6608 273.93305H117.858L117.9255 274.51149H116.7327L116.9255 276.07649H116.5083C116.4592 276.07649 116.4233 276.06305 116.3874 276.03149C116.3605 276.00462 116.3336 275.96868 116.3202 275.92399L115.9792 274.52055L115.2799 274.42618L115.2439 274.10805C115.2395 274.04962 115.2483 274.00493 115.2755 273.97805C115.2977 273.94649 115.3336 273.93305 115.3739 273.93305H115.8808L115.6027 271.65962C115.5849 271.52087 115.5714 271.4043 115.5624 271.31899C115.5489 271.23368 115.5442 271.16212 115.5355 271.10837C115.5355 271.054304 115.5308 271.013991 115.5308 270.982741V270.915554ZM118.3777 268.97399L118.5165 268.84399C118.6512 268.95587 118.7721 269.081491 118.8752 269.215866C118.9784 269.350554 119.0681 269.489616 119.1443 269.628679C119.2162 269.772116 119.2699 269.915554 119.3059 270.058991C119.3462 270.207116 119.364 270.345866 119.364 270.480554C119.364 270.570241 119.3506 270.650866 119.3284 270.731491C119.3059 270.803366 119.2699 270.874929 119.2252 270.928991C119.1759 270.991491 119.1174 271.036491 119.0502 271.06774C118.9831 271.0993 118.9021 271.11712 118.8124 271.11712C118.6512 271.11712 118.5212 271.06774 118.4268 270.969304C118.3284 270.870554 118.279 270.749616 118.279 270.610554C118.279 270.448991 118.3284 270.318991 118.4268 270.211491C118.5212 270.112742 118.6468 270.058991 118.8037 270.058991C118.8306 270.058991 118.8484 270.058991 118.8618 270.063366C118.8396 269.933366 118.799 269.816804 118.7409 269.718366C118.6824 269.610554 118.6196 269.520866 118.5571 269.440241C118.4943 269.363991 118.4406 269.296804 118.3912 269.238366C118.3418 269.180241 118.3193 269.135241 118.3193 269.099304C118.3193 269.05024 118.3374 269.00962 118.3777 268.97399Z'/>
+<path d='M125.5742 274.04524L125.3724 272.45774C125.2874 272.19774 125.193 271.96024 125.0855 271.73587C124.9777 271.52087 124.8611 271.32805 124.7358 271.17087C124.6102 271.009616 124.4755 270.883991 124.3367 270.794304C124.1977 270.704616 124.0542 270.659929 123.9105 270.659929C123.682 270.659929 123.5114 270.749616 123.3949 270.928991C123.2739 271.11274 123.2155 271.3818 123.2155 271.74055C123.2155 271.9468 123.238 272.14837 123.2874 272.34587C123.3367 272.53868 123.4039 272.72243 123.4845 272.89743C123.5742 273.07212 123.673 273.22899 123.7939 273.37712C123.9152 273.52055 124.0452 273.64618 124.193 273.7493C124.3411 273.85243 124.498 273.93305 124.6639 273.99587C124.8299 274.04962 125.0049 274.08118 125.1886 274.08118C125.2514 274.08118 125.3142 274.07649 125.3767 274.07649C125.4442 274.06774 125.507 274.05868 125.5742 274.04524ZM125.2064 271.15305L124.9152 268.8618C124.9105 268.82149 124.9105 268.77649 124.9152 268.73618C124.9195 268.69587 124.933 268.65993 124.9555 268.62399C124.9733 268.59712 125.0002 268.57024 125.0361 268.55243C125.072 268.52993 125.1167 268.52087 125.1705 268.52087H125.6727L126.4036 274.45337C126.2242 274.52962 126.0449 274.58774 125.8611 274.61462C125.6774 274.65055 125.4889 274.66399 125.2961 274.66399C125.027 274.66399 124.7714 274.62368 124.5249 274.5518C124.2783 274.47118 124.0495 274.36368 123.8345 274.22899C123.6236 274.08555 123.4308 273.92399 123.2514 273.73587C123.0811 273.54305 122.9286 273.3368 122.803 273.10805C122.682 272.8793 122.588 272.6418 122.5161 272.3818C122.4533 272.13055 122.4174 271.86587 122.4174 271.59712C122.4174 271.34149 122.4445 271.11274 122.5027 270.910866C122.5611 270.713679 122.6417 270.547741 122.7449 270.408679C122.848 270.274304 122.9736 270.171179 123.1214 270.103679C123.2695 270.032117 123.4308 269.996179 123.6102 269.996179C123.767 269.996179 123.9195 270.023054 124.0677 270.076804C124.2155 270.130867 124.3545 270.207116 124.4889 270.310241C124.6192 270.413366 124.7492 270.534304 124.8658 270.677741C124.9911 270.816804 125.1033 270.978054 125.2064 271.15305ZM131.1514 274.60118H130.3577L130.0752 272.24274C129.9902 272.00493 129.8914 271.78524 129.7749 271.59243C129.6536 271.39524 129.5283 271.2293 129.3936 271.09024C129.2592 270.951179 129.1202 270.848054 128.972 270.771804C128.8242 270.695554 128.6852 270.659929 128.5461 270.659929C128.3086 270.659929 128.1517 270.744929 128.062 270.919929C127.9811 271.09493 127.9589 271.3593 127.9992 271.71368L128.3399 274.60118H127.5464L127.2055 271.71368C127.1695 271.43993 127.1695 271.19337 127.2011 270.982741C127.2324 270.771804 127.2952 270.592429 127.3892 270.444616C127.4789 270.296491 127.5955 270.184616 127.7436 270.112742C127.8914 270.032117 128.0574 269.996179 128.2502 269.996179C128.5686 269.996179 128.878 270.094929 129.1739 270.292116C129.4789 270.493991 129.748 270.785241 129.9855 271.17555L129.9183 270.345866C129.9183 270.153054 130.017 270.058991 130.2099 270.058991H130.6042L131.1514 274.60118ZM134.9035 274.04524L134.7106 272.4893C134.6256 272.22462 134.5316 271.97805 134.4238 271.75399C134.3163 271.5343 134.1997 271.34149 134.0741 271.17993C133.9441 271.013991 133.8094 270.888366 133.6706 270.794304C133.5316 270.704616 133.3881 270.659929 133.24 270.659929C132.7781 270.659929 132.5494 271.018679 132.5494 271.74055C132.5494 271.9468 132.5719 272.14837 132.6213 272.34587C132.6706 272.53868 132.7378 272.72243 132.8185 272.89743C132.9081 273.07212 133.0069 273.22899 133.1278 273.37712C133.2491 273.52055 133.3791 273.64618 133.5269 273.7493C133.675 273.85243 133.8319 273.93305 133.9978 273.99587C134.1638 274.04962 134.3388 274.08118 134.5178 274.08118C134.5806 274.08118 134.6435 274.07649 134.7106 274.07649C134.7735 274.06774 134.8363 274.05868 134.9035 274.04524ZM134.5988 271.25618L134.5135 270.337116C134.5135 270.260866 134.5316 270.193366 134.5672 270.139617C134.6075 270.085867 134.6794 270.058991 134.7825 270.058991H135.195L135.7375 274.45337C135.5581 274.52962 135.3744 274.58774 135.195 274.61462C135.0066 274.65055 134.8185 274.66399 134.6256 274.66399C134.3566 274.66399 134.101 274.62368 133.8544 274.5518C133.6078 274.47118 133.3791 274.36368 133.1685 274.22899C132.9531 274.08555 132.7603 273.92399 132.5853 273.73587C132.4106 273.54305 132.2625 273.3368 132.1369 273.10805C132.016 272.8793 131.9219 272.6418 131.85 272.3818C131.7872 272.13055 131.7513 271.86587 131.7513 271.59712C131.7513 271.34149 131.7785 271.11274 131.8366 270.910866C131.895 270.713679 131.9756 270.547741 132.0744 270.408679C132.1819 270.274304 132.3028 270.171179 132.451 270.103679C132.5988 270.032117 132.7603 269.996179 132.9397 269.996179C133.1056 269.996179 133.2625 270.027742 133.4194 270.085867C133.5719 270.144304 133.7153 270.229304 133.8588 270.337116C133.9935 270.448991 134.1278 270.578991 134.2535 270.736179C134.3744 270.893054 134.4909 271.06337 134.5988 271.25618ZM137.5168 273.45337L137.5843 274.3368C137.5843 274.51587 137.4946 274.60555 137.3152 274.60555H136.9206L136.3737 270.058991H137.1718L137.4318 272.36368C137.5168 272.61024 137.6156 272.83899 137.7321 273.03618C137.8534 273.24243 137.9787 273.41305 138.1177 273.55649C138.2568 273.69993 138.3959 273.81212 138.5484 273.88837C138.6918 273.96462 138.8396 274.00493 138.9831 274.00493C139.2165 274.00493 139.3777 273.91962 139.4631 273.74493C139.5481 273.5743 139.5706 273.30993 139.5302 272.95118L139.1893 270.058991H139.9831L140.324 272.95118C140.3552 273.22462 140.3552 273.4668 140.324 273.68212C140.2924 273.89274 140.2296 274.07212 140.1356 274.21993C140.0459 274.36805 139.9293 274.48024 139.7859 274.5518C139.6377 274.63274 139.4718 274.66837 139.279 274.66837C138.9562 274.66837 138.6424 274.56524 138.3374 274.36368C138.0327 274.15743 137.759 273.85243 137.5168 273.45337Z'/>
+<path d='M141.4228 270.915554C141.4275 270.614929 141.5172 270.381804 141.6784 270.224929C141.8491 270.068054 142.0731 269.987117 142.3647 269.987117C142.5528 269.987117 142.7413 270.023054 142.925 270.094929C143.1135 270.171179 143.2794 270.269616 143.4272 270.399616L143.2569 270.780866C143.2435 270.807741 143.23 270.825866 143.2209 270.839304C143.2031 270.852741 143.185 270.857116 143.1581 270.857116C143.136 270.857116 143.1135 270.848054 143.0819 270.821179C143.0506 270.803366 143.0147 270.776491 142.97 270.749616C142.925 270.722741 142.8713 270.695554 142.8175 270.677741C142.7547 270.650866 142.6875 270.641804 142.6066 270.641804C142.4856 270.641804 142.3916 270.677741 142.3197 270.749616C142.2481 270.825866 142.2122 270.937741 142.2122 271.09024C142.2122 271.0993 142.2122 271.11274 142.2166 271.13055C142.2166 271.14868 142.2166 271.17993 142.2256 271.22493C142.2256 271.26962 142.2347 271.32805 142.2435 271.4043C142.2525 271.48024 142.266 271.57899 142.2794 271.70024L142.5528 273.93305H143.75L143.8175 274.51149H142.6247L142.8175 276.07649H142.4003C142.3513 276.07649 142.3153 276.06305 142.2794 276.03149C142.2525 276.00462 142.2256 275.96868 142.2122 275.92399L141.8713 274.52055L141.1719 274.42618L141.136 274.10805C141.1316 274.04962 141.1403 274.00493 141.1675 273.97805C141.1897 273.94649 141.2256 273.93305 141.266 273.93305H141.7728L141.4947 271.65962C141.4769 271.52087 141.4634 271.4043 141.4544 271.31899C141.441 271.23368 141.4363 271.16212 141.4275 271.10837C141.4275 271.054304 141.4228 271.013991 141.4228 270.982741V270.915554ZM148.3501 274.60118H147.5563L147.2738 272.24274C147.1888 272.00493 147.0901 271.78524 146.9735 271.59243C146.8523 271.39524 146.727 271.2293 146.5923 271.09024C146.4579 270.951179 146.3188 270.848054 146.1707 270.771804C146.0229 270.695554 145.8838 270.659929 145.7448 270.659929C145.5073 270.659929 145.3504 270.744929 145.2607 270.919929C145.1798 271.09493 145.1576 271.3593 145.1979 271.71368L145.5385 274.60118H144.7451L144.4042 271.71368C144.3682 271.43993 144.3682 271.19337 144.3998 270.982741C144.431 270.771804 144.4938 270.592429 144.5879 270.444616C144.6776 270.296491 144.7942 270.184616 144.9423 270.112742C145.0901 270.032117 145.256 269.996179 145.4488 269.996179C145.7673 269.996179 146.0767 270.094929 146.3726 270.292116C146.6776 270.493991 146.9467 270.785241 147.1842 271.17555L147.117 270.345866C147.117 270.153054 147.2157 270.058991 147.4085 270.058991H147.8029L148.3501 274.60118ZM148.9906 270.058991H149.7706L150.0531 272.42649C150.1384 272.67305 150.2281 272.89274 150.3312 273.09024C150.4343 273.28305 150.5418 273.44899 150.6631 273.58337C150.7796 273.72243 150.9049 273.82555 151.0396 273.89712C151.1696 273.96899 151.3087 274.00493 151.4521 274.00493C151.6762 274.00493 151.8152 273.91962 151.8737 273.74493C151.9318 273.56993 151.9365 273.30524 151.8915 272.95118L151.5509 270.058991H152.3399L152.6315 272.52524V272.52962C152.7121 272.76743 152.8062 272.98243 152.9049 273.1618C153.0124 273.35024 153.1202 273.50274 153.2412 273.62805C153.3621 273.7493 153.4834 273.84337 153.6134 273.90618C153.739 273.97337 153.8643 274.00493 153.9946 274.00493C154.2187 274.00493 154.3621 273.91962 154.4293 273.74493C154.4921 273.56993 154.5012 273.30524 154.4609 272.95118L154.1156 270.058991H154.9046L155.2456 272.95118C155.3127 273.49805 155.2634 273.91962 155.1021 274.21993C154.9406 274.52055 154.6671 274.66837 154.2771 274.66837C153.9631 274.66837 153.6671 274.56993 153.3802 274.37243C153.1021 274.17087 152.8465 273.86587 152.6224 273.44899C152.6224 273.83899 152.5506 274.1393 152.4027 274.35462C152.2546 274.56087 152.0306 274.66837 151.7212 274.66837C151.4296 274.66837 151.1471 274.56993 150.8781 274.38149C150.6137 274.1843 150.3671 273.9018 150.1427 273.52962L150.2056 274.3368C150.2056 274.51587 150.1159 274.60555 149.9321 274.60555H149.5374L148.9906 270.058991ZM156.0739 268.97399L156.2127 268.84399C156.3474 268.95587 156.4683 269.081491 156.5714 269.215866C156.6745 269.350554 156.7642 269.489616 156.8405 269.628679C156.9124 269.772116 156.9661 269.915554 157.002 270.058991C157.0424 270.207116 157.0602 270.345866 157.0602 270.480554C157.0602 270.570241 157.0467 270.650866 157.0245 270.731491C157.002 270.803366 156.9661 270.874929 156.9214 270.928991C156.872 270.991491 156.8136 271.036491 156.7464 271.06774C156.6792 271.0993 156.5983 271.11712 156.5086 271.11712C156.3474 271.11712 156.2174 271.06774 156.123 270.969304C156.0245 270.870554 155.9752 270.749616 155.9752 270.610554C155.9752 270.448991 156.0245 270.318991 156.123 270.211491C156.2174 270.112742 156.343 270.058991 156.4999 270.058991C156.5267 270.058991 156.5445 270.058991 156.558 270.063366C156.5358 269.933366 156.4952 269.816804 156.437 269.718366C156.3786 269.610554 156.3158 269.520866 156.2533 269.440241C156.1905 269.363991 156.1367 269.296804 156.0874 269.238366C156.038 269.180241 156.0155 269.135241 156.0155 269.099304C156.0155 269.05024 156.0336 269.00962 156.0739 268.97399Z'/>
+<path d='M160.1192 270.552116C160.1192 270.471491 160.1327 270.399616 160.1642 270.328054C160.1911 270.265241 160.2267 270.202429 160.2808 270.153054C160.3255 270.103679 160.3883 270.063366 160.4555 270.032117C160.5227 270.005242 160.5989 269.991804 160.6752 269.991804C160.7514 269.991804 160.8277 270.005242 160.8949 270.032117C160.9624 270.063366 161.0252 270.103679 161.0742 270.153054C161.1236 270.202429 161.1639 270.265241 161.1955 270.328054C161.2267 270.399616 161.2402 270.471491 161.2402 270.552116C161.2402 270.628366 161.2267 270.704616 161.1955 270.771804C161.1639 270.839304 161.1236 270.902116 161.0742 270.951179C161.0252 271.000554 160.9624 271.040866 160.8949 271.07243C160.8277 271.10368 160.7514 271.11712 160.6752 271.11712C160.5989 271.11712 160.5227 271.10368 160.4555 271.07243C160.3883 271.040866 160.3255 271.000554 160.2808 270.951179C160.2267 270.902116 160.1911 270.839304 160.1642 270.771804C160.1327 270.704616 160.1192 270.628366 160.1192 270.552116ZM162.2174 270.552116C162.2174 270.471491 162.2308 270.399616 162.2624 270.328054C162.2892 270.265241 162.3249 270.202429 162.3789 270.153054C162.4236 270.103679 162.4864 270.063366 162.5536 270.032117C162.6208 270.005242 162.697 269.991804 162.7733 269.991804C162.8495 269.991804 162.9258 270.005242 162.993 270.032117C163.0605 270.063366 163.1233 270.103679 163.1724 270.153054C163.2217 270.202429 163.262 270.265241 163.2936 270.328054C163.3249 270.399616 163.3383 270.471491 163.3383 270.552116C163.3383 270.628366 163.3249 270.704616 163.2936 270.771804C163.262 270.839304 163.2217 270.902116 163.1724 270.951179C163.1233 271.000554 163.0605 271.040866 162.993 271.07243C162.9258 271.10368 162.8495 271.11712 162.7733 271.11712C162.697 271.11712 162.6208 271.10368 162.5536 271.07243C162.4864 271.040866 162.4236 271.000554 162.3789 270.951179C162.3249 270.902116 162.2892 270.839304 162.2624 270.771804C162.2308 270.704616 162.2174 270.628366 162.2174 270.552116Z'/>
+<path d='M149.508 255.7812V242.4922C149.508 240.293 147.727 238.5078 145.523 238.5078H51.4453C49.2461 238.5078 47.4609 240.293 47.4609 242.4922V255.7812C47.4609 257.9844 49.2461 259.7695 51.4453 259.7695H145.523C147.727 259.7695 149.508 257.9844 149.508 255.7812Z' fill='#e6ffff'/>
+<path d='M149.508 255.7812V242.4922C149.508 240.293 147.727 238.5078 145.523 238.5078H51.4453C49.2461 238.5078 47.4609 240.293 47.4609 242.4922V255.7812C47.4609 257.9844 49.2461 259.7695 51.4453 259.7695H145.523C147.727 259.7695 149.508 257.9844 149.508 255.7812Z' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M83.27475 252.47342L83.50881 252.93186C83.25975 253.17092 82.97069 253.3553 82.64694 253.47967C82.31819 253.60436 81.95444 253.66905 81.55569 253.66905C81.20194 253.66905 80.88319 253.61436 80.61412 253.50467C80.33506 253.39498 80.106 253.25061 79.91662 253.06623C79.73225 252.88186 79.587874 252.6728 79.488186 252.43842C79.393499 252.20436 79.343811 251.9603 79.343811 251.70623C79.343811 251.39217 79.393499 251.12311 79.488186 250.91405C79.587874 250.69467 79.71725 250.5203 79.87694 250.37592C80.03631 250.23155 80.22069 250.11686 80.42475 250.02717C80.62912 249.93748 80.8385 249.8578 81.05256 249.78811C81.26694 249.72311 81.476 249.65842 81.68037 249.58873C81.88475 249.52905 82.06881 249.44936 82.2285 249.35467C82.38787 249.25998 82.51725 249.1453 82.61694 249.01092C82.71162 248.87123 82.76162 248.69186 82.76162 248.4778C82.76162 248.28342 82.72662 248.10405 82.66194 247.94467C82.59694 247.7853 82.49756 247.64561 82.37787 247.53623C82.24819 247.416547 82.09881 247.331859 81.91944 247.267172C81.74006 247.202172 81.536 247.172484 81.30662 247.172484C81.12225 247.172484 80.95787 247.187484 80.8135 247.227172C80.66912 247.257172 80.53444 247.301859 80.42475 247.356859C80.30537 247.411547 80.20569 247.46623 80.116 247.53123C80.02631 247.59592 79.94662 247.65061 79.87694 247.70561C79.80694 247.7603 79.74725 247.80498 79.687561 247.83498C79.637561 247.87498 79.587874 247.88967 79.542874 247.88967C79.498186 247.88967 79.453186 247.87498 79.418499 247.85498C79.378499 247.82498 79.343811 247.7953 79.318811 247.7603L79.039749 247.301859C79.308811 247.017797 79.632561 246.788734 80.01131 246.619359C80.39006 246.454984 80.8135 246.370297 81.27694 246.370297C81.65537 246.370297 81.99412 246.429984 82.28819 246.544672C82.58725 246.659359 82.83631 246.818734 83.04537 247.022797C83.24475 247.227172 83.40412 247.46623 83.50881 247.7353C83.6135 248.01436 83.66819 248.30342 83.66819 248.61717C83.66819 248.91123 83.6185 249.1603 83.52381 249.36467C83.42412 249.56873 83.29444 249.73811 83.13506 249.8778C82.97069 250.01717 82.78631 250.13186 82.58725 250.22655C82.37787 250.31623 82.1685 250.39592 81.95944 250.47061C81.74006 250.5453 81.531 250.61498 81.33162 250.68467C81.12225 250.74967 80.94287 250.82936 80.7835 250.92405C80.61912 251.01873 80.48975 251.12811 80.39506 251.2628C80.29537 251.39217 80.24537 251.55655 80.24537 251.75592C80.24537 251.9103 80.27537 252.05998 80.33006 252.18936C80.38506 252.32905 80.46975 252.44342 80.58444 252.54311C80.69381 252.6428 80.8335 252.72248 80.99287 252.77717C81.16225 252.83717 81.35162 252.86686 81.56569 252.86686C81.79506 252.86686 81.98912 252.83717 82.14881 252.78217C82.31319 252.72748 82.44756 252.6628 82.56725 252.5978C82.67694 252.52811 82.77631 252.46342 82.85131 252.40873C82.926 252.35373 82.99569 252.32405 83.05037 252.32405C83.10037 252.32405 83.14506 252.33873 83.17506 252.35873C83.21475 252.38873 83.24475 252.42342 83.27475 252.47342Z'/>
+<path d='M87.48139 248.72186V247.67561C87.3817 247.57092 87.28201 247.47623 87.17233 247.391547C87.07264 247.306859 86.96326 247.237172 86.84358 247.177484C86.73389 247.117484 86.60951 247.072797 86.47983 247.037797C86.35045 247.008109 86.20576 246.993109 86.05139 246.993109C85.9367 246.993109 85.82733 247.008109 85.72764 247.037797C85.62295 247.062797 85.53826 247.107484 85.45858 247.167484C85.38889 247.232172 85.32889 247.311859 85.2842 247.406547C85.2392 247.50123 85.21951 247.61592 85.21951 247.7503C85.21951 247.88967 85.2592 248.01436 85.33889 248.12905C85.42358 248.24342 85.55326 248.33811 85.73764 248.4228C85.91701 248.50748 86.15108 248.57248 86.43514 248.62217C86.72389 248.67686 87.07264 248.70686 87.48139 248.72186ZM84.61639 250.78436L84.77608 250.50061C84.80576 250.45561 84.84076 250.41592 84.88545 250.38592C84.93045 250.35092 84.98014 250.33592 85.04014 250.33592C85.11483 250.33592 85.19451 250.36592 85.2692 250.41592C85.34889 250.47561 85.44358 250.5353 85.54826 250.60498C85.65764 250.66998 85.78733 250.73467 85.9367 250.78436C86.08139 250.84436 86.26576 250.86905 86.48483 250.86905C86.80858 250.86905 87.05764 250.76936 87.22701 250.5653C87.3967 250.36592 87.48139 250.07186 87.48139 249.67842V249.28467C86.90826 249.26998 86.42014 249.21998 86.02639 249.1303C85.63295 249.03561 85.30889 248.92123 85.06483 248.77655C84.82076 248.63217 84.64139 248.4728 84.5317 248.28342C84.42233 248.10405 84.36733 247.90967 84.36733 247.71061C84.36733 247.48123 84.40233 247.281859 84.48201 247.117484C84.5517 246.948109 84.65639 246.808734 84.78108 246.699047C84.91045 246.589359 85.05983 246.509672 85.2342 246.449984C85.40858 246.400297 85.59295 246.370297 85.78733 246.370297C85.9817 246.370297 86.15608 246.390297 86.31545 246.419984C86.46983 246.459984 86.6192 246.509672 86.75889 246.569672C86.89826 246.639359 87.03295 246.719047 87.15733 246.808734C87.28201 246.908422 87.41139 247.013109 87.54608 247.137484L87.64576 246.659359C87.67045 246.574672 87.71045 246.519672 87.75514 246.489984C87.80014 246.464984 87.86983 246.449984 87.95451 246.449984H88.34826V249.67842C88.34826 249.96248 88.30826 250.22155 88.23358 250.45561C88.15889 250.68967 88.0442 250.89405 87.89483 251.05842C87.74545 251.2228 87.56108 251.35248 87.3417 251.44717C87.12264 251.54186 86.87358 251.58655 86.58951 251.58655C86.19576 251.58655 85.84201 251.52186 85.51826 251.38717C85.19451 251.2528 84.89545 251.05342 84.61639 250.78436ZM89.6975 246.449984H90.5894V250.21155C90.7437 250.41592 90.9181 250.5753 91.1025 250.69467C91.2869 250.80936 91.4909 250.86905 91.7103 250.86905C92.024 250.86905 92.2584 250.76936 92.4228 250.5703C92.5872 250.37092 92.6669 250.06717 92.6669 249.66342V246.449984H93.5587V249.66342C93.5587 249.8628 93.5884 250.03717 93.6484 250.18655C93.7031 250.34092 93.7828 250.46561 93.8825 250.5653C93.9822 250.66498 94.0965 250.73967 94.2262 250.79436C94.3606 250.84436 94.5003 250.86905 94.6447 250.86905C94.9684 250.86905 95.2178 250.76436 95.3922 250.5653C95.5665 250.35592 95.6512 250.05717 95.6512 249.66342V246.449984H96.5428V249.66342C96.5428 249.96748 96.5031 250.24155 96.4284 250.47561C96.3537 250.71467 96.239 250.91405 96.0994 251.07842C95.95 251.2428 95.7756 251.36248 95.5715 251.45217C95.3622 251.53186 95.1231 251.57655 94.859 251.57655C94.6947 251.57655 94.53 251.55655 94.3656 251.51686C94.2062 251.47686 94.0569 251.41217 93.9125 251.32748C93.7678 251.2428 93.6384 251.13311 93.5287 250.99873C93.409 250.86405 93.3194 250.70967 93.2447 250.5253C93.15 250.84936 93.0006 251.10342 92.7912 251.29248C92.5772 251.48186 92.3031 251.57655 91.9644 251.57655C91.6603 251.57655 91.3915 251.50186 91.1572 251.35748C90.9231 251.2128 90.7137 251.02373 90.5294 250.79436L90.4647 251.31248C90.4347 251.43717 90.355 251.49686 90.2306 251.49686H89.6975V246.449984ZM98.7836 247.66561V250.10686C98.968 250.35092 99.167 250.5353 99.3814 250.66998C99.6005 250.80436 99.8545 250.86905 100.1436 250.86905C100.348 250.86905 100.5273 250.83436 100.6867 250.76436C100.8461 250.69467 100.9808 250.5853 101.0901 250.43561C101.1998 250.28123 101.2845 250.08686 101.3442 249.8528C101.3992 249.61873 101.4289 249.33467 101.4289 249.00592C101.4289 248.38311 101.3045 247.90467 101.0505 247.57092C100.7964 247.237172 100.4376 247.067797 99.9642 247.067797C99.7251 247.067797 99.5108 247.112484 99.3167 247.202172C99.1223 247.291859 98.948 247.446547 98.7836 247.66561ZM98.7386 250.71467L98.6589 251.31248C98.6289 251.43717 98.5492 251.49686 98.4248 251.49686H97.8917V244.74123H98.7836V246.973109C98.953 246.788734 99.1473 246.639359 99.3714 246.539672C99.5905 246.429984 99.8545 246.380297 100.1636 246.380297C100.5023 246.380297 100.8064 246.449984 101.0751 246.579672C101.3492 246.719047 101.5786 246.898422 101.763 247.137484C101.952 247.366547 102.0967 247.64561 102.1964 247.96467C102.2958 248.28842 102.3458 248.63217 102.3458 249.00592C102.3458 249.42436 102.3008 249.79311 102.2111 250.11686S101.992 250.70967 101.8276 250.92405C101.6633 251.14311 101.4589 251.30748 101.2248 251.42217C100.9905 251.53186 100.7264 251.58655 100.4326 251.58655C100.0739 251.58655 99.7551 251.50686 99.4761 251.34748C99.197 251.18811 98.953 250.97873 98.7386 250.71467ZM104.3922 253.78873H103.5057V246.449984H104.3922V253.78873ZM106.7634 251.49686H105.8765V246.449984H106.7634V251.49686ZM106.9528 253.08123C106.9528 253.16592 106.9378 253.25061 106.8981 253.3253C106.8681 253.40498 106.8184 253.47467 106.7584 253.53467C106.7037 253.58936 106.634 253.63436 106.5594 253.66905C106.4794 253.70405 106.3947 253.71905 106.31 253.71905S106.1406 253.70405 106.0709 253.66905C105.9912 253.63436 105.9265 253.58936 105.8715 253.53467C105.8169 253.47467 105.7722 253.40498 105.7372 253.3253C105.7022 253.25061 105.6875 253.16592 105.6875 253.08123C105.6875 252.99655 105.7022 252.91686 105.7372 252.83717C105.7722 252.76748 105.8169 252.69748 105.8715 252.6378C105.9265 252.58311 105.9912 252.53811 106.0709 252.50342C106.1406 252.46842 106.2253 252.45342 106.31 252.45342S106.4794 252.46842 106.5594 252.50342C106.634 252.53811 106.7037 252.58311 106.7584 252.6378C106.8184 252.69748 106.8681 252.76748 106.8981 252.83717C106.9378 252.91686 106.9528 252.99655 106.9528 253.08123ZM109.0547 250.76436L108.9851 251.31248C108.9551 251.43717 108.8754 251.49686 108.751 251.49686H108.2179V246.449984H109.1097V250.16655C109.3038 250.38092 109.5132 250.5553 109.7376 250.67967C109.9666 250.80436 110.2107 250.86905 110.4747 250.86905C110.8285 250.86905 111.0926 250.76436 111.2719 250.5553C111.4413 250.34092 111.531 250.04717 111.531 249.66342V246.449984H112.4229V249.66342C112.4229 249.94748 112.3879 250.21155 112.3132 250.44561S112.1338 250.88405 111.9894 251.05342C111.8497 251.2178 111.6754 251.34748 111.4613 251.44217C111.2519 251.53186 111.0079 251.57655 110.7338 251.57655C110.5544 251.57655 110.3851 251.55655 110.2357 251.52186C110.0763 251.48186 109.9316 251.42717 109.7972 251.35248C109.6576 251.2828 109.5282 251.19811 109.4035 251.09842C109.2791 250.99873 109.1644 250.88905 109.0547 250.76436ZM115.5357 248.91623C115.3563 248.91623 115.1969 248.94092 115.0622 248.99092C114.9279 249.04061 114.8132 249.1103 114.7185 249.19998C114.6238 249.28967 114.5541 249.39936 114.5094 249.51905C114.4594 249.64842 114.4344 249.78311 114.4344 249.93248C114.4344 250.24155 114.5291 250.48561 114.7185 250.66998C114.9029 250.85405 115.1769 250.94373 115.5357 250.94373C115.8894 250.94373 116.1635 250.85405 116.3526 250.66998C116.5369 250.48561 116.6316 250.24155 116.6316 249.93248C116.6316 249.78311 116.6066 249.64842 116.5619 249.51905C116.5172 249.39936 116.4472 249.28967 116.3526 249.19998C116.2579 249.1103 116.1435 249.04061 116.0088 248.99092C115.8744 248.94092 115.7151 248.91623 115.5357 248.91623ZM117.1347 246.175922C117.1347 246.041547 117.1001 245.921859 117.0304 245.812172C116.9604 245.702797 116.861 245.608109 116.7313 245.528422C116.5969 245.44842 116.4372 245.38873 116.2482 245.34405C116.0588 245.29905 115.8444 245.27905 115.6054 245.27905C115.3613 245.27905 115.1469 245.29905 114.9676 245.34405C114.7832 245.38373 114.6338 245.43873 114.5141 245.513422C114.3948 245.583109 114.3051 245.667797 114.2504 245.762484C114.1904 245.862172 114.1607 245.966859 114.1607 246.081234C114.1607 246.255609 114.2204 246.409984 114.3397 246.539672C114.4544 246.674047 114.6088 246.783734 114.7932 246.868422C114.9576 246.843422 115.1319 246.828734 115.3113 246.818734S115.6651 246.798734 115.8444 246.788734C116.0138 246.778734 116.1832 246.763734 116.3379 246.749047C116.4923 246.729047 116.6316 246.699047 116.7513 246.654359C116.866 246.609359 116.9604 246.549672 117.0304 246.474984C117.1001 246.400297 117.1347 246.300609 117.1347 246.175922ZM118.0366 251.29748H116.6666C116.5123 251.39217 116.3379 251.46186 116.1485 251.51186C115.9591 251.55655 115.7547 251.58155 115.5357 251.58155C115.2566 251.58155 114.9976 251.54186 114.7685 251.46686C114.5291 251.39217 114.3301 251.2828 114.1607 251.14311C113.991 250.99873 113.8616 250.82936 113.7619 250.62498C113.6723 250.42561 113.6226 250.20155 113.6226 249.95748C113.6226 249.65342 113.6922 249.38436 113.8316 249.1503C113.9713 248.92123 114.1654 248.73686 114.4148 248.59717C114.3101 248.54248 114.2154 248.4828 114.1357 248.4128C114.056 248.34311 113.991 248.26842 113.9313 248.19373C113.8816 248.11405 113.8366 248.03436 113.8119 247.95467C113.7869 247.87998 113.7719 247.80498 113.7719 247.7303C113.7719 247.54092 113.8166 247.391547 113.9016 247.277172C113.991 247.167484 114.1107 247.077797 114.2601 247.013109C113.9863 246.908422 113.7719 246.773734 113.6176 246.599359C113.4632 246.424984 113.3832 246.215922 113.3832 245.966859C113.3832 245.792484 113.4282 245.622797 113.5229 245.463422C113.6126 245.29905 113.7469 245.15967 113.9313 245.03498C114.1157 244.91061 114.3447 244.81592 114.6188 244.74123C114.8929 244.66623 115.2166 244.63155 115.5854 244.63155C115.9541 244.63155 116.2829 244.67623 116.5819 244.77592C116.8707 244.86561 117.1201 244.9953 117.3241 245.15467C117.5285 245.30905 117.6829 245.488422 117.7876 245.692797C117.8972 245.896859 117.9519 246.106234 117.9519 246.320297C117.9519 246.554672 117.9022 246.744047 117.8076 246.888422C117.7079 247.032797 117.5782 247.147484 117.4188 247.232172C117.2594 247.316859 117.0801 247.376547 116.8707 247.411547C116.6716 247.446547 116.4622 247.47623 116.2432 247.48623C116.0338 247.50623 115.8244 247.51623 115.6154 247.52123C115.416 247.52623 115.2316 247.54592 115.0722 247.57092C114.9129 247.59592 114.7832 247.64061 114.6885 247.70561C114.5891 247.7653 114.5391 247.85498 114.5391 247.97467C114.5391 248.04936 114.5691 248.12405 114.6238 248.20373C114.6788 248.27342 114.7635 248.34811 114.8679 248.4128C115.0772 248.35811 115.3013 248.32811 115.5357 248.32811C115.8097 248.32811 116.0588 248.36811 116.2929 248.4428C116.5269 248.51748 116.7263 248.62717 116.8907 248.77155C117.0551 248.91623 117.1897 249.08561 117.2794 249.28967C117.3791 249.48905 117.4238 249.71342 117.4238 249.95748C117.4238 250.22155 117.3691 250.46561 117.2544 250.68467L117.8272 250.75967C117.9669 250.78936 118.0366 250.85905 118.0366 250.96873V251.29748Z'/>
+<path d='M98.4844 238.5078V216.0586' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M98.484355 213.56279L99.83201 217.133103L98.484355 215.96123L97.1406 217.133103Z'/>
+<path d='M98.484355 213.56279L99.83201 217.133103L98.484355 215.96123L97.1406 217.133103Z' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M66.8154 225.83085L66.89165 226.83085C66.89165 227.00991 66.80196 227.0996 66.61821 227.0996H66.223526L65.676651 222.553034H66.45665L66.7079 224.65585C66.89165 225.35991 67.13384 225.84428 67.42978 226.11335C67.73009 226.38241 68.07103 226.44053 68.46103 226.28366L68.60446 227.05053C68.43853 227.1221 68.27259 227.1446 68.11134 227.12678C67.94978 227.0996 67.7929 227.0371 67.6404 226.92928C67.4879 226.82616 67.34009 226.67835 67.2054 226.48991C67.06196 226.30616 66.93665 226.08647 66.8154 225.83085Z'/>
+<path d='M71.61259 226.53928L71.41978 224.98335C71.33478 224.71866 71.24071 224.4721 71.1329 224.24803C71.0254 224.02835 70.90884 223.83553 70.78321 223.67397C70.65321 223.508034 70.51853 223.382409 70.37978 223.288346C70.24071 223.198659 70.09728 223.153971 69.94915 223.153971C69.48728 223.153971 69.25853 223.512721 69.25853 224.2346C69.25853 224.44085 69.28103 224.64241 69.3304 224.83991C69.37978 225.03272 69.44696 225.21647 69.52759 225.39147C69.61728 225.56616 69.71603 225.72303 69.83696 225.87116C69.95821 226.0146 70.08821 226.14022 70.23603 226.24335C70.38415 226.34647 70.54103 226.4271 70.70696 226.48991C70.8729 226.54366 71.0479 226.57522 71.22696 226.57522C71.28978 226.57522 71.35259 226.57053 71.41978 226.57053C71.48259 226.56178 71.5454 226.55272 71.61259 226.53928ZM71.3079 223.75022L71.22259 222.831159C71.22259 222.754909 71.24071 222.687409 71.27634 222.633659C71.31665 222.579909 71.38853 222.553034 71.49165 222.553034H71.90415L72.44665 226.94741C72.26728 227.02366 72.08353 227.08178 71.90415 227.10866C71.71571 227.1446 71.52759 227.15803 71.33478 227.15803C71.06571 227.15803 70.81009 227.11772 70.56353 227.04585C70.31696 226.96522 70.08821 226.85772 69.87759 226.72303C69.66228 226.5796 69.46946 226.41803 69.29446 226.22991C69.11978 226.0371 68.97165 225.83085 68.84603 225.6021C68.72509 225.37335 68.63103 225.13585 68.55915 224.87585C68.49634 224.6246 68.4604 224.35991 68.4604 224.09116C68.4604 223.83553 68.48759 223.60678 68.54571 223.404909C68.60415 223.207721 68.68478 223.041784 68.78353 222.902721C68.89103 222.768346 69.01196 222.665221 69.16009 222.597721C69.3079 222.526159 69.46946 222.490221 69.64884 222.490221C69.81478 222.490221 69.97165 222.521784 70.12853 222.579909C70.28103 222.638346 70.42446 222.723346 70.5679 222.831159C70.70259 222.943034 70.83696 223.073034 70.96259 223.230221C71.08353 223.387096 71.20009 223.55741 71.3079 223.75022ZM79.3781 227.09522H78.7997C78.7503 227.09522 78.7009 227.08178 78.6563 227.04585C78.6159 227.01897 78.5844 226.97866 78.5709 226.92928L77.4188 224.00585C77.3828 223.90272 77.3469 223.7996 77.32 223.70085C77.2841 223.60241 77.2572 223.503659 77.2303 223.409596C77.2213 223.508034 77.2125 223.60678 77.1991 223.70085C77.1853 223.7996 77.1719 223.90272 77.1584 224.00585L76.6475 226.94741C76.6428 226.9921 76.6206 227.02803 76.5891 227.05928C76.5578 227.09085 76.5128 227.10428 76.4547 227.10428H76.1228C76.0734 227.10428 76.0241 227.09085 75.9838 227.05928C75.9434 227.02803 75.9122 226.9921 75.8984 226.94741L74.65657 224.00585C74.61626 223.90272 74.57595 223.7996 74.53532 223.70085C74.49501 223.60241 74.45939 223.503659 74.42782 223.409596C74.42345 223.503659 74.41876 223.60241 74.41439 223.70085C74.41001 223.7996 74.40095 223.90272 74.39657 224.00585L73.97938 226.92928C73.96595 226.97866 73.94345 227.01897 73.90782 227.05053C73.87188 227.08178 73.82251 227.09522 73.76438 227.09522H73.16782L73.96595 222.553034H74.54907C74.6297 222.553034 74.69251 222.602409 74.73282 222.705534L76.0422 225.78147C76.0825 225.88022 76.1184 225.97866 76.1497 226.07741C76.1541 226.02803 76.1631 225.97866 76.1631 225.93397C76.1722 225.8846 76.1766 225.83522 76.1809 225.78585L76.7325 222.705534C76.7506 222.602409 76.7953 222.553034 76.8672 222.553034H77.4725L79.3781 227.09522Z'/>
+<path d='M82.5543 223.548346L82.6977 224.72335C82.7831 224.98335 82.8862 225.22553 83.0071 225.44053C83.124 225.66491 83.2493 225.85335 83.3884 226.0146C83.5274 226.17147 83.6665 226.2971 83.8143 226.38678C83.9624 226.47647 84.1059 226.52116 84.2493 226.52116C84.4824 226.52116 84.6618 226.4271 84.7918 226.24335C84.9174 226.0596 84.9802 225.78585 84.9802 225.43178C84.9802 225.25241 84.9621 225.07303 84.9352 224.8846C84.8996 224.70522 84.8546 224.52585 84.7918 224.35553C84.729 224.18085 84.6527 224.01928 84.5677 223.87116C84.4781 223.71897 84.3749 223.58428 84.2627 223.476784C84.1506 223.360221 84.0252 223.274909 83.8862 223.207721C83.7471 223.140534 83.6037 223.108971 83.4468 223.108971C83.2852 223.108971 83.124 223.144909 82.9624 223.207721C82.8056 223.279284 82.6665 223.391471 82.5543 223.548346ZM82.8459 225.94303L83.2359 229.15772H82.4559L81.6577 222.553034H82.079C82.1734 222.553034 82.2362 222.570846 82.2718 222.611471C82.3077 222.651784 82.3393 222.709909 82.3615 222.786159L82.4243 223.077721C82.5543 222.889284 82.7159 222.745846 82.9087 222.642721S83.3212 222.490221 83.5634 222.490221C83.774 222.490221 83.9712 222.530534 84.164 222.611471C84.3568 222.692096 84.5318 222.804284 84.6934 222.947721C84.859 223.086471 85.0071 223.252409 85.1415 223.449909C85.2718 223.63803 85.3837 223.84897 85.4824 224.06866C85.5721 224.29272 85.6484 224.52585 85.6977 224.77272C85.7468 225.01928 85.774 225.26147 85.774 225.50803C85.774 226.05053 85.6662 226.45866 85.4509 226.74116C85.2359 227.02366 84.9352 227.16241 84.5452 227.16241C84.3837 227.16241 84.2268 227.13553 84.0699 227.07272C83.9131 227.01897 83.7649 226.93397 83.6215 226.83085C83.4781 226.72303 83.339 226.59303 83.2137 226.44522C83.079 226.2971 82.9581 226.12678 82.8459 225.94303ZM87.773 227.09522H86.9883L86.4411 222.553034H87.2258L87.773 227.09522ZM88.0777 228.52116C88.0777 228.59741 88.0599 228.67366 88.033 228.74085C87.997 228.81272 87.9567 228.87522 87.9074 228.92928C87.858 228.97835 87.7999 229.01897 87.728 229.05022C87.6652 229.08147 87.5936 229.09522 87.5217 229.09522C87.4545 229.09522 87.3874 229.08147 87.3199 229.04585C87.2527 229.01897 87.1945 228.97397 87.1452 228.92022C87.0958 228.87085 87.0555 228.80803 87.0239 228.74085C86.9927 228.67366 86.9792 228.59741 86.9792 228.52116S86.9927 228.37303 87.0239 228.30147C87.0555 228.23866 87.0914 228.17585 87.1452 228.1221C87.1899 228.07272 87.2483 228.03241 87.3155 228.00085C87.3827 227.9696 87.4499 227.95616 87.5174 227.95616C87.5889 227.95616 87.6564 227.9696 87.728 228.00085C87.7908 228.03241 87.8536 228.07272 87.9074 228.1221C87.9567 228.17585 87.997 228.23866 88.033 228.30147C88.0599 228.37303 88.0777 228.44491 88.0777 228.52116ZM88.8171 223.409596C88.8218 223.108971 88.9115 222.875846 89.0727 222.718971C89.2434 222.562096 89.4674 222.481159 89.759 222.481159C89.9471 222.481159 90.1356 222.517096 90.3193 222.588971C90.5077 222.665221 90.6737 222.763659 90.8215 222.893659L90.6512 223.274909C90.6377 223.301784 90.6243 223.319909 90.6152 223.333346C90.5974 223.346784 90.5793 223.351159 90.5524 223.351159C90.5302 223.351159 90.5077 223.342096 90.4762 223.315221C90.4449 223.297409 90.409 223.270534 90.3643 223.243659C90.3193 223.216784 90.2656 223.189596 90.2118 223.171784C90.149 223.144909 90.0818 223.135846 90.0009 223.135846C89.8799 223.135846 89.7859 223.171784 89.714 223.243659C89.6424 223.319909 89.6065 223.431784 89.6065 223.58428C89.6065 223.59335 89.6065 223.60678 89.6109 223.6246C89.6109 223.64272 89.6109 223.67397 89.6199 223.71897C89.6199 223.76366 89.629 223.8221 89.6377 223.89835C89.6468 223.97428 89.6602 224.07303 89.6737 224.19428L89.9471 226.4271H91.1443L91.2118 227.00553H90.019L90.2118 228.57053H89.7946C89.7456 228.57053 89.7096 228.5571 89.6737 228.52553C89.6468 228.49866 89.6199 228.46272 89.6065 228.41803L89.2656 227.0146L88.5662 226.92022L88.5302 226.6021C88.5259 226.54366 88.5346 226.49897 88.5618 226.4721C88.584 226.44053 88.6199 226.4271 88.6602 226.4271H89.1671L88.889 224.15366C88.8712 224.01491 88.8577 223.89835 88.8487 223.81303C88.8352 223.72772 88.8306 223.65616 88.8218 223.60241C88.8218 223.548346 88.8171 223.508034 88.8171 223.476784V223.409596ZM94.565 226.36897L94.7669 226.65585C94.6188 226.81272 94.4394 226.93397 94.2331 227.02803C94.0225 227.11772 93.785 227.16241 93.5113 227.16241C93.2556 227.16241 93.0225 227.1221 92.8163 227.0371C92.6147 226.95616 92.4397 226.84866 92.2963 226.7096C92.1528 226.57053 92.045 226.41366 91.9644 226.23897C91.8925 226.0596 91.8522 225.87553 91.8522 225.68272C91.8522 225.46303 91.8972 225.28835 91.9913 225.15835C92.0853 225.02803 92.2019 224.92053 92.3409 224.83991C92.48 224.7546 92.6325 224.68741 92.7938 224.63366C92.9553 224.58428 93.1078 224.52585 93.2469 224.46772C93.3859 224.40928 93.5025 224.33303 93.5966 224.24335C93.6906 224.15366 93.7356 224.03272 93.7356 223.88022C93.7356 223.76803 93.7131 223.66053 93.6681 223.55741C93.6278 223.458659 93.565 223.373659 93.48 223.297409C93.3994 223.221159 93.3006 223.162721 93.1841 223.118034C93.0628 223.073034 92.9328 223.050846 92.785 223.050846C92.6191 223.050846 92.48 223.073034 92.3678 223.113659C92.2603 223.153971 92.1706 223.203346 92.0988 223.252409C92.0272 223.306471 91.9688 223.355534 91.9197 223.396159C91.8703 223.436471 91.8253 223.458659 91.7759 223.458659C91.7269 223.458659 91.6863 223.449909 91.6506 223.427409C91.6238 223.404909 91.5922 223.378034 91.5653 223.337721L91.3681 223.032721C91.5069 222.871471 91.6909 222.741471 91.9106 222.633659C92.1347 222.535221 92.3903 222.481159 92.6819 222.481159C92.9509 222.481159 93.1931 222.526159 93.4081 222.611471C93.6278 222.696471 93.8119 222.813034 93.9641 222.956471C94.1213 223.104596 94.2378 223.270534 94.3228 223.463346C94.4038 223.65616 94.4441 223.85335 94.4441 224.06397C94.4441 224.27928 94.3991 224.45428 94.305 224.58866C94.2109 224.72335 94.0944 224.83522 93.9553 224.92053C93.8163 225.00585 93.6638 225.07741 93.5025 225.13585C93.3409 225.19397 93.1884 225.25241 93.0494 225.31522C92.9106 225.37335 92.7938 225.44522 92.6997 225.53022C92.6056 225.61553 92.5606 225.72772 92.5606 225.86678C92.5606 225.96522 92.5831 226.0596 92.6281 226.14928C92.6684 226.23428 92.7313 226.31053 92.8075 226.37772C92.8881 226.44522 92.9822 226.49428 93.0944 226.53491C93.2066 226.57053 93.3275 226.58866 93.4619 226.58866C93.6056 226.58866 93.7266 226.57053 93.8297 226.53491C93.9328 226.50335 94.0181 226.46303 94.0897 226.4271C94.1569 226.38241 94.2153 226.34647 94.2691 226.31491C94.3141 226.28366 94.3631 226.26585 94.4038 226.26585C94.4394 226.26585 94.4709 226.2746 94.4934 226.29272C94.5156 226.30616 94.5425 226.33303 94.565 226.36897Z'/>
+<path d='M153.762 212.9961H43.2109L51.7148 191.734H145.258Z' fill='#e6ffff'/>
+<path d='M153.762 212.9961H43.2109L51.7148 191.734H145.258Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M76.39079 201.15272C76.3361 201.15272 76.2761 201.12772 76.22141 201.07803C76.09672 200.96335 75.97735 200.86866 75.84766 200.78397C75.72829 200.70428 75.5886 200.639596 75.44922 200.584909C75.29985 200.529909 75.14516 200.495221 74.97079 200.465221C74.80141 200.445221 74.61204 200.430221 74.39797 200.430221C74.04922 200.430221 73.72547 200.495221 73.42641 200.619596C73.12266 200.74428 72.8636 200.92866 72.63922 201.17272C72.42016 201.41178 72.24579 201.70585 72.1211 202.0546C71.99172 202.40335 71.92672 202.80178 71.92672 203.24522C71.92672 203.68366 71.98672 204.07741 72.1111 204.42616C72.23579 204.77491 72.40516 205.06866 72.62922 205.31272C72.8486 205.5571 73.11266 205.74116 73.41641 205.86585C73.72047 205.99553 74.05922 206.06022 74.42797 206.06022C74.73172 206.06022 74.99079 206.02522 75.20016 205.96553C75.40922 205.89585 75.5836 205.82585 75.72329 205.74616C75.86266 205.66647 75.97735 205.59678 76.06204 205.5271C76.14672 205.46741 76.22141 205.43241 76.2811 205.43241C76.3361 205.43241 76.37578 205.44241 76.40579 205.46741C76.44047 205.4871 76.46547 205.5121 76.48547 205.5471L76.80422 205.99053C76.51047 206.26928 76.16672 206.48866 75.77797 206.65303C75.38953 206.81741 74.9411 206.8971 74.43297 206.8971C73.91454 206.8971 73.44141 206.80741 73.01297 206.63303C72.58454 206.45366 72.21579 206.2046 71.91172 205.88085C71.60297 205.5571 71.36391 205.17335 71.194535 204.72491S70.940473 203.78335 70.940473 203.24522C70.940473 202.7071 71.02016 202.21397 71.184535 201.76553C71.34891 201.3171 71.57797 200.93366 71.87204 200.614596C72.1661 200.290846 72.52454 200.041784 72.94328 199.867409C73.36172 199.688034 73.82485 199.598346 74.33829 199.598346C74.9311 199.598346 75.43422 199.693034 75.84766 199.882409C76.2661 200.071471 76.61985 200.335534 76.91391 200.674596L76.53016 201.08803C76.49047 201.13272 76.44547 201.15272 76.39079 201.15272Z'/>
+<path d='M79.84969 204.8046C79.47594 204.8046 79.14219 204.74491 78.84313 204.62022C78.54907 204.49585 78.295 204.32147 78.08594 204.0971C77.87657 203.87303 77.71719 203.59897 77.6075 203.27522C77.49313 202.95616 77.43813 202.59772 77.43813 202.20397C77.43813 201.80553 77.49313 201.44678 77.6075 201.12772C77.71719 200.80897 77.87657 200.534909 78.08594 200.310846C78.295 200.086471 78.54907 199.912096 78.84313 199.787721C79.14219 199.668034 79.47594 199.608346 79.84969 199.608346C80.21813 199.608346 80.5519 199.668034 80.8459 199.787721C81.14 199.912096 81.3941 200.086471 81.6031 200.310846C81.8125 200.534909 81.9719 200.80897 82.0816 201.12772C82.1963 201.44678 82.2509 201.80553 82.2509 202.20397C82.2509 202.59772 82.1963 202.95616 82.0816 203.27522C81.9719 203.59897 81.8125 203.87303 81.6031 204.0971C81.3941 204.32147 81.14 204.49585 80.8459 204.62022C80.5519 204.74491 80.21813 204.8046 79.84969 204.8046ZM79.84969 200.300846C79.34625 200.300846 78.96782 200.465221 78.72344 200.80397C78.47438 201.13272 78.35 201.60116 78.35 202.19897C78.35 202.49803 78.37969 202.7671 78.44469 203.00616C78.50438 203.24022 78.59407 203.4396 78.72344 203.60397C78.84313 203.76835 79.0025 203.89303 79.19188 203.97772C79.37625 204.06241 79.59532 204.1071 79.84969 204.1071C80.34782 204.1071 80.7216 203.93772 80.9656 203.60397C81.2097 203.27022 81.3341 202.80178 81.3341 202.19897C81.3341 201.60116 81.2097 201.13272 80.9656 200.80397C80.7216 200.465221 80.34782 200.300846 79.84969 200.300846ZM84.2078 203.99241L84.1381 204.54053C84.1081 204.66522 84.0284 204.72491 83.9041 204.72491H83.3709V199.678034H84.2628V203.3946C84.4569 203.60897 84.6663 203.78335 84.8906 203.90772C85.1197 204.03241 85.3638 204.0971 85.6278 204.0971C85.9816 204.0971 86.2456 203.99241 86.425 203.78335C86.5944 203.56897 86.6841 203.27522 86.6841 202.89147V199.678034H87.5759V202.89147C87.5759 203.17553 87.5409 203.4396 87.4663 203.67366C87.3916 203.90772 87.2869 204.1121 87.1425 204.28147C87.0028 204.44585 86.8284 204.57553 86.6144 204.67022C86.405 204.75991 86.1609 204.8046 85.8869 204.8046C85.7075 204.8046 85.5381 204.7846 85.3888 204.74991C85.2294 204.70991 85.0847 204.65522 84.9503 204.58053C84.8106 204.51085 84.6813 204.42616 84.5566 204.32647C84.4322 204.22678 84.3175 204.1171 84.2078 203.99241ZM92.2181 203.52428V201.08803C92.0338 200.84397 91.8347 200.659596 91.6153 200.524909C91.4013 200.390534 91.1472 200.325846 90.8531 200.325846C90.6488 200.325846 90.4694 200.360534 90.31 200.430221C90.1506 200.500221 90.0159 200.609596 89.9066 200.76428C89.7969 200.91366 89.7122 201.10303 89.6575 201.3421C89.6025 201.57116 89.5728 201.85522 89.5728 202.18397C89.5728 202.80678 89.6972 203.28522 89.9513 203.61897C90.2053 203.95272 90.5641 204.1221 91.0325 204.1221C91.2716 204.1221 91.4859 204.07741 91.68 203.99241C91.8744 203.90303 92.0538 203.74835 92.2181 203.52428ZM93.105 207.01678H92.2181V204.22178C92.0438 204.40616 91.8494 204.55053 91.6253 204.66022C91.4063 204.75991 91.1422 204.8146 90.8331 204.8146C90.4944 204.8146 90.1903 204.74991 89.9216 204.61022C89.6475 204.48085 89.4181 204.29147 89.2338 204.05741C89.0497 203.82303 88.905 203.54428 88.8053 203.22522C88.7059 202.90147 88.6559 202.55772 88.6559 202.18397C88.6559 201.76553 88.7009 201.39678 88.7906 201.07303S89.0097 200.480221 89.1741 200.265846C89.3384 200.051784 89.5428 199.887409 89.7769 199.777721C90.0113 199.663034 90.2753 199.608346 90.5641 199.608346C90.9278 199.608346 91.2466 199.688034 91.5206 199.847409C91.7947 200.006784 92.0438 200.216159 92.2581 200.475221L92.3378 199.862409C92.3725 199.737721 92.4525 199.678034 92.5769 199.678034H93.105V207.01678ZM95.4455 204.72491H94.5587V199.678034H95.4455V204.72491ZM95.6349 206.30928C95.6349 206.39397 95.6199 206.47866 95.5802 206.55335C95.5502 206.63303 95.5006 206.70272 95.4406 206.76272C95.3859 206.81741 95.3162 206.86241 95.2415 206.8971C95.1615 206.9321 95.0768 206.9471 94.9921 206.9471S94.8227 206.9321 94.7531 206.8971C94.6734 206.86241 94.6087 206.81741 94.5537 206.76272C94.499 206.70272 94.4543 206.63303 94.4193 206.55335C94.3843 206.47866 94.3696 206.39397 94.3696 206.30928C94.3696 206.2246 94.3843 206.14491 94.4193 206.06522C94.4543 205.99553 94.499 205.92553 94.5537 205.86585C94.6087 205.81116 94.6734 205.76616 94.7531 205.73147C94.8227 205.69647 94.9074 205.68147 94.9921 205.68147S95.1615 205.69647 95.2415 205.73147C95.3162 205.76616 95.3859 205.81116 95.4406 205.86585C95.5006 205.92553 95.5502 205.99553 95.5802 206.06522C95.6199 206.14491 95.6349 206.2246 95.6349 206.30928ZM98.4494 199.598346C98.6788 199.598346 98.9028 199.638034 99.1172 199.718034C99.3313 199.802721 99.5156 199.912096 99.67 200.056784L99.4109 200.480221C99.3763 200.534909 99.3313 200.564909 99.2866 200.564909C99.2616 200.564909 99.2266 200.554909 99.1969 200.524909C99.1569 200.505221 99.1172 200.475221 99.0672 200.445221C99.0175 200.415534 98.9575 200.385534 98.8878 200.365534C98.8231 200.335534 98.7434 200.325846 98.6488 200.325846C98.4844 200.325846 98.3547 200.375534 98.25 200.480221C98.1456 200.584909 98.0956 200.73928 98.0956 200.95335V203.98272H99.5553V204.62522H98.0956V206.36397H97.6472C97.5925 206.36397 97.5428 206.34897 97.5128 206.31428C97.4728 206.28428 97.4531 206.2446 97.4431 206.1946L97.2388 204.63522L96.4119 204.53053V204.17678C96.4119 204.1121 96.4316 204.06241 96.4666 204.03241C96.5016 203.99741 96.5463 203.98272 96.6009 203.98272H97.2088V200.89366C97.2088 200.475221 97.3134 200.156471 97.5328 199.932096C97.7419 199.708034 98.0509 199.598346 98.4494 199.598346ZM101.4081 204.72491H100.5213V199.678034H101.4081V204.72491ZM101.5975 206.30928C101.5975 206.39397 101.5825 206.47866 101.5428 206.55335C101.5128 206.63303 101.4631 206.70272 101.4031 206.76272C101.3484 206.81741 101.2788 206.86241 101.2041 206.8971C101.1241 206.9321 101.0394 206.9471 100.9547 206.9471S100.7853 206.9321 100.7156 206.8971C100.6359 206.86241 100.5713 206.81741 100.5163 206.76272C100.4616 206.70272 100.4169 206.63303 100.3819 206.55335C100.3469 206.47866 100.3322 206.39397 100.3322 206.30928C100.3322 206.2246 100.3469 206.14491 100.3819 206.06522C100.4169 205.99553 100.4616 205.92553 100.5163 205.86585C100.5713 205.81116 100.6359 205.76616 100.7156 205.73147C100.7853 205.69647 100.87 205.68147 100.9547 205.68147S101.1241 205.69647 101.2041 205.73147C101.2788 205.76616 101.3484 205.81116 101.4031 205.86585C101.4631 205.92553 101.5128 205.99553 101.5428 206.06522C101.5825 206.14491 101.5975 206.2246 101.5975 206.30928ZM104.9901 204.8046C104.6163 204.8046 104.2826 204.74491 103.9835 204.62022C103.6895 204.49585 103.4354 204.32147 103.2263 204.0971C103.017 203.87303 102.8576 203.59897 102.7479 203.27522C102.6335 202.95616 102.5785 202.59772 102.5785 202.20397C102.5785 201.80553 102.6335 201.44678 102.7479 201.12772C102.8576 200.80897 103.017 200.534909 103.2263 200.310846C103.4354 200.086471 103.6895 199.912096 103.9835 199.787721C104.2826 199.668034 104.6163 199.608346 104.9901 199.608346C105.3585 199.608346 105.6923 199.668034 105.9863 199.787721C106.2804 199.912096 106.5345 200.086471 106.7435 200.310846C106.9529 200.534909 107.1123 200.80897 107.222 201.12772C107.3366 201.44678 107.3913 201.80553 107.3913 202.20397C107.3913 202.59772 107.3366 202.95616 107.222 203.27522C107.1123 203.59897 106.9529 203.87303 106.7435 204.0971C106.5345 204.32147 106.2804 204.49585 105.9863 204.62022C105.6923 204.74491 105.3585 204.8046 104.9901 204.8046ZM104.9901 200.300846C104.4866 200.300846 104.1082 200.465221 103.8638 200.80397C103.6148 201.13272 103.4904 201.60116 103.4904 202.19897C103.4904 202.49803 103.5201 202.7671 103.5851 203.00616C103.6448 203.24022 103.7345 203.4396 103.8638 203.60397C103.9835 203.76835 104.1429 203.89303 104.3323 203.97772C104.5166 204.06241 104.7357 204.1071 104.9901 204.1071C105.4882 204.1071 105.862 203.93772 106.106 203.60397C106.3501 203.27022 106.4745 202.80178 106.4745 202.19897C106.4745 201.60116 106.3501 201.13272 106.106 200.80397C105.862 200.465221 105.4882 200.300846 104.9901 200.300846ZM109.3482 203.99241L109.2785 204.54053C109.2485 204.66522 109.1688 204.72491 109.0445 204.72491H108.5113V199.678034H109.4032V203.3946C109.5973 203.60897 109.8066 203.78335 110.031 203.90772C110.2601 204.03241 110.5041 204.0971 110.7682 204.0971C111.122 204.0971 111.386 203.99241 111.5654 203.78335C111.7348 203.56897 111.8245 203.27522 111.8245 202.89147V199.678034H112.7163V202.89147C112.7163 203.17553 112.6813 203.4396 112.6066 203.67366C112.532 203.90772 112.4273 204.1121 112.2829 204.28147C112.1432 204.44585 111.9688 204.57553 111.7548 204.67022C111.5454 204.75991 111.3013 204.8046 111.0273 204.8046C110.8479 204.8046 110.6785 204.7846 110.5291 204.74991C110.3698 204.70991 110.2251 204.65522 110.0907 204.58053C109.951 204.51085 109.8216 204.42616 109.697 204.32647C109.5726 204.22678 109.4579 204.1171 109.3482 203.99241ZM115.007 204.72491H114.1201V199.678034H115.007V204.72491ZM115.1963 206.30928C115.1963 206.39397 115.1813 206.47866 115.1416 206.55335C115.1116 206.63303 115.062 206.70272 115.002 206.76272C114.9473 206.81741 114.8776 206.86241 114.8029 206.8971C114.7229 206.9321 114.6382 206.9471 114.5535 206.9471S114.3841 206.9321 114.3145 206.8971C114.2348 206.86241 114.1701 206.81741 114.1151 206.76272C114.0604 206.70272 114.0157 206.63303 113.9807 206.55335C113.9457 206.47866 113.931 206.39397 113.931 206.30928C113.931 206.2246 113.9457 206.14491 113.9807 206.06522C114.0157 205.99553 114.0604 205.92553 114.1151 205.86585C114.1701 205.81116 114.2348 205.76616 114.3145 205.73147C114.3841 205.69647 114.4688 205.68147 114.5535 205.68147S114.7229 205.69647 114.8029 205.73147C114.8776 205.76616 114.9473 205.81116 115.002 205.86585C115.062 205.92553 115.1116 205.99553 115.1416 206.06522C115.1813 206.14491 115.1963 206.2246 115.1963 206.30928ZM117.2983 203.99241L117.2286 204.54053C117.1986 204.66522 117.1189 204.72491 116.9945 204.72491H116.4614V199.678034H117.3533V203.3946C117.5473 203.60897 117.7567 203.78335 117.9811 203.90772C118.2102 204.03241 118.4542 204.0971 118.7183 204.0971C119.072 204.0971 119.3361 203.99241 119.5155 203.78335C119.6848 203.56897 119.7745 203.27522 119.7745 202.89147V199.678034H120.6664V202.89147C120.6664 203.17553 120.6314 203.4396 120.5567 203.67366S120.3773 204.1121 120.233 204.28147C120.0933 204.44585 119.9189 204.57553 119.7048 204.67022C119.4955 204.75991 119.2514 204.8046 118.9773 204.8046C118.798 204.8046 118.6286 204.7846 118.4792 204.74991C118.3198 204.70991 118.1752 204.65522 118.0408 204.58053C117.9011 204.51085 117.7717 204.42616 117.647 204.32647C117.5227 204.22678 117.408 204.1171 117.2983 203.99241ZM123.7792 202.14428C123.5998 202.14428 123.4405 202.16897 123.3058 202.21897C123.1714 202.26866 123.0567 202.33835 122.962 202.42803C122.8673 202.51772 122.7977 202.62741 122.753 202.7471C122.703 202.87647 122.678 203.01116 122.678 203.16053C122.678 203.4696 122.7727 203.71366 122.962 203.89803C123.1464 204.0821 123.4205 204.17178 123.7792 204.17178C124.133 204.17178 124.407 204.0821 124.5961 203.89803C124.7805 203.71366 124.8752 203.4696 124.8752 203.16053C124.8752 203.01116 124.8502 202.87647 124.8055 202.7471C124.7608 202.62741 124.6908 202.51772 124.5961 202.42803C124.5014 202.33835 124.387 202.26866 124.2523 202.21897C124.118 202.16897 123.9586 202.14428 123.7792 202.14428ZM125.3783 199.403971C125.3783 199.269596 125.3436 199.149909 125.2739 199.040221C125.2039 198.930846 125.1045 198.836159 124.9748 198.756471C124.8405 198.67647 124.6808 198.61678 124.4917 198.5721C124.3023 198.5271 124.088 198.5071 123.8489 198.5071C123.6048 198.5071 123.3905 198.5271 123.2111 198.5721C123.0267 198.61178 122.8773 198.66678 122.7577 198.741471C122.6383 198.811159 122.5486 198.895846 122.4939 198.990534C122.4339 199.090221 122.4042 199.194909 122.4042 199.309284C122.4042 199.483659 122.4639 199.638034 122.5833 199.767721C122.698 199.902096 122.8523 200.011784 123.0367 200.096471C123.2011 200.071471 123.3755 200.056784 123.5548 200.046784C123.7342 200.036784 123.9086 200.026784 124.088 200.016784C124.2573 200.006784 124.4267 199.991784 124.5814 199.977096C124.7358 199.957096 124.8752 199.927096 124.9948 199.882409C125.1095 199.837409 125.2039 199.777721 125.2739 199.703034C125.3436 199.628346 125.3783 199.528659 125.3783 199.403971ZM126.2802 204.52553H124.9102C124.7558 204.62022 124.5814 204.68991 124.392 204.73991C124.2027 204.7846 123.9983 204.8096 123.7792 204.8096C123.5002 204.8096 123.2411 204.76991 123.012 204.69491C122.7727 204.62022 122.5736 204.51085 122.4042 204.37116C122.2345 204.22678 122.1052 204.05741 122.0055 203.85303C121.9158 203.65366 121.8661 203.4296 121.8661 203.18553C121.8661 202.88147 121.9358 202.61241 122.0752 202.37835C122.2148 202.14928 122.4089 201.96491 122.6583 201.82522C122.5536 201.77053 122.4589 201.71085 122.3792 201.64085C122.2995 201.57116 122.2345 201.49647 122.1748 201.42178C122.1252 201.3421 122.0802 201.26241 122.0555 201.18272C122.0305 201.10803 122.0155 201.03303 122.0155 200.95835C122.0155 200.76897 122.0602 200.619596 122.1452 200.505221C122.2345 200.395534 122.3542 200.305846 122.5036 200.241159C122.2298 200.136471 122.0155 200.001784 121.8611 199.827409C121.7067 199.653034 121.6267 199.443971 121.6267 199.194909C121.6267 199.020534 121.6717 198.850846 121.7664 198.691471C121.8561 198.5271 121.9905 198.38772 122.1748 198.26303C122.3592 198.13866 122.5883 198.04397 122.8623 197.96928C123.1364 197.89428 123.4602 197.8596 123.8289 197.8596C124.1977 197.8596 124.5264 197.90428 124.8255 198.00397C125.1142 198.09366 125.3636 198.22335 125.5677 198.38272C125.772 198.5371 125.9264 198.716471 126.0311 198.920846C126.1408 199.124909 126.1955 199.334284 126.1955 199.548346C126.1955 199.782721 126.1458 199.972096 126.0511 200.116471C125.9514 200.260846 125.8217 200.375534 125.6623 200.460221C125.503 200.544909 125.3236 200.604596 125.1142 200.639596C124.9152 200.674596 124.7058 200.70428 124.4867 200.71428C124.2773 200.73428 124.068 200.74428 123.8589 200.74928C123.6595 200.75428 123.4752 200.77397 123.3158 200.79897S123.0267 200.86866 122.932 200.93366C122.8327 200.99335 122.7827 201.08303 122.7827 201.20272C122.7827 201.27741 122.8127 201.3521 122.8673 201.43178C122.9223 201.50147 123.007 201.57616 123.1114 201.64085C123.3208 201.58616 123.5448 201.55616 123.7792 201.55616C124.0533 201.55616 124.3023 201.59616 124.5364 201.67085C124.7705 201.74553 124.9698 201.85522 125.1342 201.9996C125.2986 202.14428 125.4333 202.31366 125.523 202.51772C125.6227 202.7171 125.6673 202.94147 125.6673 203.18553C125.6673 203.4496 125.6127 203.69366 125.498 203.91272L126.0708 203.98772C126.2105 204.01741 126.2802 204.0871 126.2802 204.19678V204.52553Z'/>
+<path d='M98.4844 225.75H167.707' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M170.20358 225.750199L166.633264 227.09786L167.80514 225.750199L166.633264 224.40645Z'/>
+<path d='M170.20358 225.750199L166.633264 227.09786L167.80514 225.750199L166.633264 224.40645Z' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M98.4844 191.734V169.285' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M98.484355 166.78883L99.83201 170.363047L98.484355 169.18727L97.1406 170.363047Z'/>
+<path d='M98.484355 166.78883L99.83201 170.363047L98.484355 169.18727L97.1406 170.363047Z' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M44.26928 177.511305L44.4174 178.69974C44.5024 178.95974 44.60553 179.19724 44.72209 179.41724C44.84334 179.63693 44.96897 179.82505 45.10771 179.98193C45.2424 180.13912 45.38146 180.26443 45.52928 180.35412C45.6774 180.43943 45.82084 180.48412 45.96428 180.48412C46.1974 180.48412 46.37678 180.39005 46.50678 180.2063S46.69959 179.7488 46.69959 179.39474C46.69959 179.21537 46.68178 179.03599 46.65021 178.84755C46.61896 178.66818 46.56959 178.4888 46.50678 178.31849C46.44865 178.1438 46.3724 177.98224 46.28272 177.83412C46.19303 177.68193 46.0899 177.54724 45.97771 177.439742C45.86553 177.32318 45.74022 177.237867 45.60115 177.17068C45.46209 177.103492 45.31865 177.07193 45.16178 177.07193C44.99584 177.07193 44.83428 177.107867 44.6774 177.17068C44.52053 177.242242 44.38146 177.35443 44.26928 177.511305ZM44.51146 179.82505L44.58771 180.7938C44.58771 180.97287 44.49803 181.06255 44.31865 181.06255H43.923965L43.184278 174.97787H43.959902L44.20209 176.960055C44.33209 176.798492 44.48459 176.672867 44.66834 176.587867C44.8524 176.49818 45.05396 176.45318 45.27834 176.45318C45.48896 176.45318 45.68615 176.493492 45.87896 176.57443C46.07178 176.655055 46.24678 176.767242 46.40834 176.91068C46.57397 177.04943 46.72209 177.215367 46.85647 177.412867C46.98678 177.60099 47.09865 177.81193 47.1974 178.03162C47.28709 178.25568 47.36334 178.4888 47.41272 178.73568C47.46178 178.98224 47.48896 179.22443 47.48896 179.47099C47.48896 180.01349 47.38115 180.42162 47.17053 180.70412C46.95521 180.98662 46.6549 181.12537 46.26459 181.12537C46.09865 181.12537 45.93303 181.09412 45.77147 181.03568C45.61459 180.97287 45.45771 180.88318 45.30959 180.7713C45.16178 180.65912 45.01803 180.52005 44.88365 180.36318C44.74928 180.20193 44.62365 180.02255 44.51146 179.82505ZM49.25014 179.7938L49.32639 180.7938C49.32639 180.97287 49.2367 181.06255 49.05295 181.06255H48.65826L48.11139 176.515992H48.89139L49.14264 178.6188C49.32639 179.32287 49.56857 179.80724 49.86451 180.0763C50.16482 180.34537 50.50576 180.40349 50.89576 180.24662L51.0392 181.01349C50.87326 181.08505 50.70732 181.10755 50.54607 181.08974C50.38451 181.06255 50.22764 181.00005 50.07514 180.89224C49.92264 180.78912 49.77482 180.6413 49.64014 180.45287C49.4967 180.26912 49.37139 180.04943 49.25014 179.7938Z'/>
+<path d='M53.3161 180.54693C53.437 180.54693 53.5358 180.53349 53.6211 180.49787C53.7061 180.47068 53.7736 180.43037 53.8273 180.38099C53.8767 180.33193 53.917 180.28255 53.9395 180.21974C53.9617 180.16599 53.9751 180.10755 53.9751 180.0538C53.9751 179.9463 53.9529 179.84318 53.9036 179.74443C53.8542 179.64568 53.7554 179.55599 53.6076 179.4663C53.4595 179.38568 53.2442 179.30505 52.96639 179.23318C52.68826 179.15693 52.32076 179.09412 51.85889 179.03599C51.90826 179.24662 51.97545 179.44849 52.06045 179.62787C52.14576 179.8163 52.25326 179.97318 52.37451 180.11224C52.49545 180.24662 52.63889 180.35412 52.79607 180.43037C52.95295 180.50662 53.1276 180.54693 53.3161 180.54693ZM54.5804 177.35443L54.3833 177.60099C54.3386 177.65037 54.2892 177.67724 54.2308 177.67724C54.1814 177.67724 54.1367 177.6638 54.0873 177.63255C54.0379 177.60099 53.9886 177.56537 53.9348 177.52037C53.8767 177.480055 53.8183 177.43068 53.7467 177.37693C53.6839 177.327555 53.6029 177.27818 53.5133 177.233492C53.4283 177.19318 53.3251 177.157242 53.2173 177.12568C53.10076 177.09443 52.97545 177.080992 52.8317 177.080992C52.47764 177.080992 52.21295 177.188492 52.04264 177.394742C51.86326 177.61005 51.77826 177.91505 51.77826 178.31412C51.77826 178.34537 51.77826 178.3813 51.78264 178.40818C51.78264 178.44412 51.78264 178.47537 51.78264 178.50693C52.37451 178.56505 52.85889 178.64599 53.2354 178.74443C53.612 178.84318 53.9079 178.95974 54.1233 179.08974C54.3386 179.22443 54.4864 179.37662 54.567 179.53818C54.6479 179.70849 54.6883 179.88787 54.6883 180.08505C54.6883 180.19724 54.6614 180.3138 54.6073 180.43505C54.5583 180.55599 54.4773 180.66818 54.3698 180.7713C54.2623 180.87443 54.1233 180.95505 53.9573 181.02224C53.7914 181.08974 53.5895 181.12099 53.3611 181.12099C53.1189 181.12099 52.89451 181.08505 52.67951 181.0088C52.47326 180.93255 52.27576 180.82943 52.10545 180.70412C51.92607 180.56943 51.77357 180.41693 51.6392 180.23755C51.50014 180.05818 51.38795 179.86537 51.28951 179.65474C51.19982 179.44412 51.12795 179.22443 51.0742 178.99099C51.0292 178.76255 51.00232 178.52943 51.00232 178.29599C51.00232 178.01349 51.04264 177.76255 51.11889 177.5338C51.19514 177.305055 51.30732 177.112242 51.45076 176.955367C51.5942 176.794117 51.7692 176.668492 51.97545 176.58318C52.1817 176.49818 52.41482 176.45318 52.67482 176.45318C52.86764 176.45318 53.04701 176.471305 53.2086 176.50693C53.3789 176.538492 53.5358 176.592242 53.6839 176.668492C53.8364 176.744742 53.9842 176.838805 54.1323 176.946305C54.2801 177.06318 54.4283 177.197555 54.5804 177.35443ZM55.6155 179.52912L55.5349 178.87443H57.584L57.6649 179.52912H55.6155ZM59.3412 177.511305L59.4893 178.69974C59.5743 178.95974 59.6774 179.19724 59.794 179.41724C59.9152 179.63693 60.0408 179.82505 60.1796 179.98193C60.3143 180.13912 60.4533 180.26443 60.6012 180.35412C60.7493 180.43943 60.8927 180.48412 61.0362 180.48412C61.2693 180.48412 61.4487 180.39005 61.5787 180.2063S61.7715 179.7488 61.7715 179.39474C61.7715 179.21537 61.7537 179.03599 61.7221 178.84755C61.6908 178.66818 61.6415 178.4888 61.5787 178.31849C61.5205 178.1438 61.4443 177.98224 61.3546 177.83412C61.2649 177.68193 61.1618 177.54724 61.0496 177.439742C60.9374 177.32318 60.8121 177.237867 60.673 177.17068C60.534 177.103492 60.3905 177.07193 60.2337 177.07193C60.0677 177.07193 59.9062 177.107867 59.7493 177.17068C59.5924 177.242242 59.4533 177.35443 59.3412 177.511305ZM59.5833 179.82505L59.6596 180.7938C59.6596 180.97287 59.5699 181.06255 59.3905 181.06255H58.9958L58.2562 174.97787H59.0318L59.274 176.960055C59.404 176.798492 59.5565 176.672867 59.7402 176.587867C59.9243 176.49818 60.1258 176.45318 60.3502 176.45318C60.5608 176.45318 60.758 176.493492 60.9508 176.57443C61.1437 176.655055 61.3187 176.767242 61.4802 176.91068C61.6458 177.04943 61.794 177.215367 61.9283 177.412867C62.0587 177.60099 62.1705 177.81193 62.2693 178.03162C62.359 178.25568 62.4352 178.4888 62.4846 178.73568C62.5337 178.98224 62.5608 179.22443 62.5608 179.47099C62.5608 180.01349 62.453 180.42162 62.2424 180.70412C62.0271 180.98662 61.7268 181.12537 61.3365 181.12537C61.1705 181.12537 61.0049 181.09412 60.8433 181.03568C60.6865 180.97287 60.5296 180.88318 60.3815 180.7713C60.2337 180.65912 60.0899 180.52005 59.9555 180.36318C59.8212 180.20193 59.6955 180.02255 59.5833 179.82505ZM64.322 179.7938L64.3983 180.7938C64.3983 180.97287 64.3086 181.06255 64.1248 181.06255H63.7301L63.1833 176.515992H63.9633L64.2145 178.6188C64.3983 179.32287 64.6404 179.80724 64.9364 180.0763C65.2367 180.34537 65.5776 180.40349 65.9676 180.24662L66.1111 181.01349C65.9451 181.08505 65.7792 181.10755 65.6179 181.08974C65.4564 181.06255 65.2995 181.00005 65.147 180.89224C64.9945 180.78912 64.8467 180.6413 64.712 180.45287C64.5686 180.26912 64.4433 180.04943 64.322 179.7938Z'/>
+<path d='M67.8504 177.076617C67.5364 177.076617 67.2989 177.184117 67.133 177.394742C66.967 177.61005 66.8864 177.92849 66.8864 178.34537C66.8864 178.62787 66.9223 178.9013 66.9895 179.16162C67.0567 179.42162 67.1554 179.65037 67.2811 179.84755C67.4064 180.04474 67.5589 180.20193 67.7383 180.31849C67.9133 180.43943 68.1148 180.49787 68.3348 180.49787C68.6442 180.49787 68.8861 180.39005 69.0476 180.1838C69.2179 179.96849 69.2986 179.65474 69.2986 179.23787C69.2986 178.95537 69.2629 178.68162 69.1955 178.42162C69.1283 178.16162 69.0298 177.93287 68.9042 177.73568C68.7742 177.5338 68.6217 177.37693 68.4467 177.255992C68.2673 177.134742 68.0701 177.076617 67.8504 177.076617ZM67.7742 176.45318C68.1014 176.45318 68.4064 176.525055 68.6889 176.677555C68.9714 176.820992 69.2179 177.022555 69.4242 177.27818C69.6351 177.5338 69.7964 177.82974 69.9176 178.16599C70.0386 178.50224 70.097 178.86099 70.097 179.24224C70.097 179.53818 70.0564 179.80255 69.9714 180.03599C69.8861 180.26912 69.7695 180.4663 69.6217 180.62787C69.4736 180.78912 69.2942 180.91037 69.0879 181.00005C68.8817 181.08068 68.6529 181.12537 68.4064 181.12537C68.0792 181.12537 67.7742 181.0538 67.4961 180.90568C67.2092 180.75787 66.967 180.56037 66.7564 180.30943C66.5454 180.0538 66.3842 179.75787 66.2633 179.42162C66.142 179.08537 66.0839 178.72193 66.0839 178.34099C66.0839 178.04068 66.1242 177.77599 66.2092 177.54287C66.2945 177.309742 66.4111 177.112242 66.5592 176.950992C66.707 176.78943 66.8864 176.668492 67.0926 176.578805C67.2989 176.49818 67.5276 176.45318 67.7742 176.45318ZM74.1405 177.33193L73.9433 177.57412C73.8983 177.62349 73.849 177.65037 73.7908 177.65037C73.728 177.65037 73.6652 177.61912 73.6024 177.56068C73.5352 177.502555 73.459 177.435055 73.3649 177.367867C73.2705 177.296305 73.1587 177.228805 73.0196 177.17068C72.8852 177.112242 72.7193 177.080992 72.5174 177.080992C72.3558 177.080992 72.2124 177.107867 72.0958 177.17068C71.9702 177.22443 71.8718 177.309742 71.7865 177.412867C71.7015 177.52037 71.6387 177.65037 71.598 177.79849C71.5577 177.95099 71.5355 178.1213 71.5355 178.30505C71.5355 178.61005 71.5758 178.89693 71.6565 179.16162C71.7327 179.42599 71.8402 179.65912 71.9793 179.85193C72.1183 180.04474 72.2752 180.20193 72.459 180.30943C72.643 180.42599 72.8358 180.47974 73.0421 180.47974C73.1946 180.47974 73.3199 180.46193 73.4143 180.42599C73.5127 180.38568 73.5937 180.34537 73.6608 180.30037C73.728 180.25099 73.7818 180.21068 73.8177 180.17474C73.8627 180.13443 73.903 180.11662 73.9433 180.11662C73.9746 180.11662 74.0062 180.12568 74.033 180.13912C74.0552 180.15255 74.0777 180.17474 74.1002 180.19724L74.3515 180.49787C74.199 180.69943 74.0196 180.8563 73.8177 180.96412C73.6158 181.06724 73.3602 181.12099 73.0599 181.12099C72.7237 181.12099 72.4099 181.04474 72.1227 180.88787C71.8402 180.73099 71.5937 180.52474 71.3874 180.26443C71.1812 180.00443 71.0199 179.70412 70.903 179.36787C70.7912 179.03162 70.7327 178.67724 70.7327 178.30943C70.7327 178.03599 70.7687 177.78037 70.8405 177.5563C70.9077 177.32318 71.0108 177.130367 71.1452 176.96443C71.2843 176.802867 71.4502 176.677555 71.6565 176.587867C71.8537 176.49818 72.0868 176.45318 72.3515 176.45318C72.5265 176.45318 72.6877 176.466617 72.8402 176.493492C72.9883 176.520367 73.1362 176.569742 73.2752 176.632555C73.4143 176.70443 73.5577 176.794117 73.6968 176.905992C73.8355 177.01818 73.9837 177.161617 74.1405 177.33193Z'/>
+<path d='M77.0298 180.54693C77.1508 180.54693 77.2495 180.53349 77.3348 180.49787C77.4198 180.47068 77.4873 180.43037 77.5411 180.38099C77.5904 180.33193 77.6308 180.28255 77.6533 180.21974C77.6754 180.16599 77.6889 180.10755 77.6889 180.0538C77.6889 179.9463 77.6667 179.84318 77.6173 179.74443S77.4692 179.55599 77.3214 179.4663C77.1733 179.38568 76.9579 179.30505 76.6801 179.23318C76.402 179.15693 76.0345 179.09412 75.5726 179.03599C75.622 179.24662 75.6892 179.44849 75.7742 179.62787C75.8595 179.8163 75.967 179.97318 76.0883 180.11224C76.2092 180.24662 76.3526 180.35412 76.5098 180.43037C76.6667 180.50662 76.8414 180.54693 77.0298 180.54693ZM78.2942 177.35443L78.097 177.60099C78.0523 177.65037 78.003 177.67724 77.9445 177.67724C77.8951 177.67724 77.8505 177.6638 77.8011 177.63255C77.7517 177.60099 77.7023 177.56537 77.6486 177.52037C77.5904 177.480055 77.532 177.43068 77.4604 177.37693C77.3976 177.327555 77.3167 177.27818 77.227 177.233492C77.142 177.19318 77.0389 177.157242 76.9311 177.12568C76.8145 177.09443 76.6892 177.080992 76.5455 177.080992C76.1914 177.080992 75.9267 177.188492 75.7564 177.394742C75.577 177.61005 75.492 177.91505 75.492 178.31412C75.492 178.34537 75.492 178.3813 75.4964 178.40818C75.4964 178.44412 75.4964 178.47537 75.4964 178.50693C76.0883 178.56505 76.5726 178.64599 76.9492 178.74443C77.3258 178.84318 77.6217 178.95974 77.837 179.08974C78.0523 179.22443 78.2001 179.37662 78.2808 179.53818C78.3617 179.70849 78.402 179.88787 78.402 180.08505C78.402 180.19724 78.3751 180.3138 78.3211 180.43505C78.272 180.55599 78.1911 180.66818 78.0836 180.7713C77.9761 180.87443 77.837 180.95505 77.6711 181.02224C77.5051 181.08974 77.3033 181.12099 77.0748 181.12099C76.8326 181.12099 76.6083 181.08505 76.3933 181.0088C76.187 180.93255 75.9895 180.82943 75.8192 180.70412C75.6398 180.56943 75.4873 180.41693 75.3529 180.23755C75.2139 180.05818 75.1017 179.86537 75.0033 179.65474C74.9136 179.44412 74.8417 179.22443 74.7879 178.99099C74.7429 178.76255 74.7161 178.52943 74.7161 178.29599C74.7161 178.01349 74.7564 177.76255 74.8326 177.5338C74.9089 177.305055 75.0211 177.112242 75.1645 176.955367C75.308 176.794117 75.483 176.668492 75.6892 176.58318C75.8954 176.49818 76.1286 176.45318 76.3886 176.45318C76.5814 176.45318 76.7608 176.471305 76.9223 176.50693C77.0926 176.538492 77.2495 176.592242 77.3976 176.668492C77.5501 176.744742 77.698 176.838805 77.8461 176.946305C77.9939 177.06318 78.142 177.197555 78.2942 177.35443ZM81.939 180.33193L82.1408 180.6188C81.9927 180.77568 81.8133 180.89693 81.6071 180.99099C81.3965 181.08068 81.159 181.12537 80.8852 181.12537C80.6296 181.12537 80.3965 181.08505 80.1902 181.00005C79.9887 180.91912 79.8137 180.81162 79.6702 180.67255C79.5268 180.53349 79.419 180.37662 79.3383 180.20193C79.2665 180.02255 79.2262 179.83849 79.2262 179.64568C79.2262 179.42599 79.2712 179.2513 79.3652 179.1213C79.4593 178.99099 79.5758 178.88349 79.7149 178.80287C79.854 178.71755 80.0065 178.65037 80.1677 178.59662C80.3293 178.54724 80.4818 178.4888 80.6208 178.43068C80.7599 178.37224 80.8765 178.29599 80.9705 178.2063C81.0646 178.11662 81.1096 177.99568 81.1096 177.84318C81.1096 177.73099 81.0871 177.62349 81.0421 177.52037C81.0018 177.421617 80.939 177.336617 80.854 177.260367C80.7733 177.184117 80.6746 177.12568 80.558 177.080992C80.4368 177.035992 80.3068 177.013805 80.159 177.013805C79.993 177.013805 79.854 177.035992 79.7418 177.076617C79.6343 177.11693 79.5446 177.166305 79.4727 177.215367C79.4012 177.26943 79.3427 177.318492 79.2937 177.359117C79.2443 177.39943 79.1993 177.421617 79.1499 177.421617C79.1008 177.421617 79.0602 177.412867 79.0246 177.390367C78.9977 177.367867 78.9662 177.340992 78.9393 177.30068L78.7421 176.99568C78.8808 176.83443 79.0649 176.70443 79.2846 176.596617C79.5087 176.49818 79.7643 176.444117 80.0558 176.444117C80.3249 176.444117 80.5671 176.489117 80.7821 176.57443C81.0018 176.65943 81.1858 176.775992 81.338 176.91943C81.4952 177.067555 81.6118 177.233492 81.6968 177.426305C81.7777 177.61912 81.818 177.8163 81.818 178.02693C81.818 178.24224 81.773 178.41724 81.679 178.55162C81.5849 178.6863 81.4683 178.79818 81.3293 178.88349C81.1902 178.9688 81.0377 179.04037 80.8765 179.0988C80.7149 179.15693 80.5624 179.21537 80.4233 179.27818C80.2846 179.3363 80.1677 179.40818 80.0737 179.49318C79.9796 179.57849 79.9346 179.69068 79.9346 179.82974C79.9346 179.92818 79.9571 180.02255 80.0021 180.11224C80.0424 180.19724 80.1052 180.27349 80.1815 180.34068C80.2621 180.40818 80.3562 180.45724 80.4683 180.49787C80.5805 180.53349 80.7015 180.55162 80.8358 180.55162C80.9796 180.55162 81.1005 180.53349 81.2037 180.49787C81.3068 180.4663 81.3921 180.42599 81.4637 180.39005C81.5308 180.34537 81.5893 180.30943 81.643 180.27787C81.688 180.24662 81.7371 180.2288 81.7777 180.2288C81.8133 180.2288 81.8449 180.23755 81.8674 180.25568C81.8896 180.26912 81.9165 180.29599 81.939 180.33193ZM85.5254 180.33193L85.7273 180.6188C85.5792 180.77568 85.3998 180.89693 85.1936 180.99099C84.983 181.08068 84.7455 181.12537 84.4717 181.12537C84.2161 181.12537 83.983 181.08505 83.7767 181.00005C83.5751 180.91912 83.4001 180.81162 83.2567 180.67255C83.1133 180.53349 83.0054 180.37662 82.9248 180.20193C82.8529 180.02255 82.8126 179.83849 82.8126 179.64568C82.8126 179.42599 82.8576 179.2513 82.9517 179.1213C83.0458 178.99099 83.1623 178.88349 83.3014 178.80287C83.4405 178.71755 83.593 178.65037 83.7542 178.59662C83.9158 178.54724 84.0683 178.4888 84.2073 178.43068C84.3464 178.37224 84.4629 178.29599 84.557 178.2063C84.6511 178.11662 84.6961 177.99568 84.6961 177.84318C84.6961 177.73099 84.6736 177.62349 84.6286 177.52037C84.5883 177.421617 84.5254 177.336617 84.4405 177.260367C84.3598 177.184117 84.2611 177.12568 84.1445 177.080992C84.0233 177.035992 83.8933 177.013805 83.7455 177.013805C83.5795 177.013805 83.4405 177.035992 83.3283 177.076617C83.2208 177.11693 83.1311 177.166305 83.0592 177.215367C82.9876 177.26943 82.9292 177.318492 82.8801 177.359117C82.8308 177.39943 82.7858 177.421617 82.7364 177.421617C82.6873 177.421617 82.6467 177.412867 82.6111 177.390367C82.5842 177.367867 82.5526 177.340992 82.5258 177.30068L82.3286 176.99568C82.4673 176.83443 82.6514 176.70443 82.8711 176.596617C83.0951 176.49818 83.3508 176.444117 83.6423 176.444117C83.9114 176.444117 84.1536 176.489117 84.3686 176.57443C84.5883 176.65943 84.7723 176.775992 84.9245 176.91943C85.0817 177.067555 85.1983 177.233492 85.2833 177.426305C85.3642 177.61912 85.4045 177.8163 85.4045 178.02693C85.4045 178.24224 85.3595 178.41724 85.2654 178.55162C85.1714 178.6863 85.0548 178.79818 84.9158 178.88349C84.7767 178.9688 84.6242 179.04037 84.4629 179.0988C84.3014 179.15693 84.1489 179.21537 84.0098 179.27818C83.8711 179.3363 83.7542 179.40818 83.6601 179.49318C83.5661 179.57849 83.5211 179.69068 83.5211 179.82974C83.5211 179.92818 83.5436 180.02255 83.5886 180.11224C83.6289 180.19724 83.6917 180.27349 83.768 180.34068C83.8486 180.40818 83.9426 180.45724 84.0548 180.49787C84.167 180.53349 84.288 180.55162 84.4223 180.55162C84.5661 180.55162 84.687 180.53349 84.7901 180.49787C84.8933 180.4663 84.9786 180.42599 85.0501 180.39005C85.1173 180.34537 85.1758 180.30943 85.2295 180.27787C85.2745 180.24662 85.3236 180.2288 85.3642 180.2288C85.3998 180.2288 85.4314 180.23755 85.4539 180.25568C85.4761 180.26912 85.503 180.29599 85.5254 180.33193ZM88.4932 180.54693C88.6141 180.54693 88.7129 180.53349 88.7982 180.49787C88.8832 180.47068 88.9507 180.43037 89.0044 180.38099C89.0538 180.33193 89.0941 180.28255 89.1166 180.21974C89.1388 180.16599 89.1522 180.10755 89.1522 180.0538C89.1522 179.9463 89.1301 179.84318 89.0807 179.74443S88.9326 179.55599 88.7847 179.4663C88.6366 179.38568 88.4213 179.30505 88.1435 179.23318C87.8654 179.15693 87.4979 179.09412 87.036 179.03599C87.0854 179.24662 87.1526 179.44849 87.2376 179.62787C87.3229 179.8163 87.4304 179.97318 87.5516 180.11224C87.6726 180.24662 87.816 180.35412 87.9732 180.43037C88.1301 180.50662 88.3047 180.54693 88.4932 180.54693ZM89.7576 177.35443L89.5604 177.60099C89.5157 177.65037 89.4663 177.67724 89.4079 177.67724C89.3585 177.67724 89.3138 177.6638 89.2644 177.63255C89.2151 177.60099 89.1657 177.56537 89.1119 177.52037C89.0538 177.480055 88.9954 177.43068 88.9238 177.37693C88.861 177.327555 88.7801 177.27818 88.6904 177.233492C88.6054 177.19318 88.5022 177.157242 88.3944 177.12568C88.2779 177.09443 88.1526 177.080992 88.0088 177.080992C87.6547 177.080992 87.3901 177.188492 87.2197 177.394742C87.0404 177.61005 86.9554 177.91505 86.9554 178.31412C86.9554 178.34537 86.9554 178.3813 86.9597 178.40818C86.9597 178.44412 86.9597 178.47537 86.9597 178.50693C87.5516 178.56505 88.036 178.64599 88.4126 178.74443C88.7891 178.84318 89.0851 178.95974 89.3004 179.08974C89.5157 179.22443 89.6635 179.37662 89.7441 179.53818C89.8251 179.70849 89.8654 179.88787 89.8654 180.08505C89.8654 180.19724 89.8385 180.3138 89.7844 180.43505C89.7354 180.55599 89.6544 180.66818 89.5469 180.7713C89.4394 180.87443 89.3004 180.95505 89.1344 181.02224C88.9685 181.08974 88.7666 181.12099 88.5382 181.12099C88.296 181.12099 88.0716 181.08505 87.8566 181.0088C87.6504 180.93255 87.4529 180.82943 87.2826 180.70412C87.1032 180.56943 86.9507 180.41693 86.8163 180.23755C86.6772 180.05818 86.5651 179.86537 86.4666 179.65474C86.3769 179.44412 86.3051 179.22443 86.2513 178.99099C86.2063 178.76255 86.1794 178.52943 86.1794 178.29599C86.1794 178.01349 86.2197 177.76255 86.296 177.5338C86.3722 177.305055 86.4844 177.112242 86.6279 176.955367C86.7713 176.794117 86.9463 176.668492 87.1526 176.58318C87.3588 176.49818 87.5919 176.45318 87.8519 176.45318C88.0447 176.45318 88.2241 176.471305 88.3857 176.50693C88.556 176.538492 88.7129 176.592242 88.861 176.668492C89.0135 176.744742 89.1613 176.838805 89.3094 176.946305C89.4572 177.06318 89.6054 177.197555 89.7576 177.35443ZM93.6804 180.06724L93.5323 178.88787C93.4473 178.62787 93.3442 178.39037 93.2229 178.17068C93.1064 177.95099 92.9808 177.76255 92.8464 177.60099C92.7073 177.444117 92.5683 177.318492 92.4205 177.228805C92.2723 177.139117 92.1289 177.09443 91.9854 177.09443C91.7479 177.09443 91.5686 177.188492 91.4386 177.37693C91.3129 177.56068 91.2501 177.83412 91.2501 178.18849C91.2501 178.45318 91.2861 178.72662 91.3576 179.00005C91.4295 179.27349 91.5326 179.52474 91.6626 179.74443C91.797 179.96849 91.9586 180.15255 92.147 180.2913C92.3351 180.43037 92.5461 180.50224 92.7836 180.50224C92.9495 180.50224 93.1111 180.47068 93.268 180.40818C93.4292 180.34068 93.5683 180.2288 93.6804 180.06724ZM94.8373 183.12068H94.057L93.7476 180.6188C93.6176 180.78005 93.4651 180.90568 93.2767 180.99099C93.0973 181.08068 92.8911 181.12537 92.667 181.12537C92.4564 181.12537 92.2589 181.08505 92.0661 181.00443C91.878 180.9238 91.7029 180.81162 91.537 180.67255C91.3711 180.53349 91.2233 180.36318 91.0886 180.17474C90.9586 179.97755 90.8464 179.7713 90.7479 179.54724C90.6583 179.32287 90.582 179.08974 90.5326 178.84318C90.4833 178.59662 90.4564 178.35443 90.4564 178.10787C90.4564 177.56974 90.5642 177.161617 90.7792 176.874742C90.9945 176.596617 91.2948 176.45318 91.6851 176.45318C91.8511 176.45318 92.0123 176.484742 92.1739 176.542867C92.3308 176.60568 92.4876 176.695367 92.6311 176.807555C92.7836 176.91943 92.9226 177.058492 93.057 177.215367C93.1917 177.372555 93.3173 177.55193 93.4292 177.74912L93.3442 176.794117C93.3442 176.717867 93.362 176.650367 93.3979 176.596617C93.4339 176.542867 93.5054 176.515992 93.6086 176.515992H94.0258L94.8373 183.12068Z'/>
+<path d='M106.78837 177.447423H103.69431V179.64024H106.1965V180.32149H103.69431V182.45586H106.784V183.1643H102.824623V176.738985H106.784L106.78837 177.447423Z'/>
+<path d='M108.43986 180.62211L108.37704 181.11524C108.35017 181.22742 108.27829 181.28117 108.16611 181.28117H107.68642V176.738985H108.48923V180.08399C108.66392 180.2768 108.85236 180.43367 109.05392 180.54586C109.26017 180.65805 109.48017 180.71617 109.71767 180.71617C110.03611 180.71617 110.27361 180.62211 110.43517 180.43367C110.58767 180.24086 110.6683 179.97649 110.6683 179.63117V176.738985H111.47079V179.63117C111.47079 179.8868 111.43954 180.1243 111.37236 180.33524C111.30486 180.54586 111.21079 180.72961 111.08079 180.88211C110.95517 181.03024 110.7983 181.1468 110.60548 181.2318C110.41704 181.31274 110.19736 181.35305 109.95079 181.35305C109.78954 181.35305 109.63705 181.33492 109.50236 181.30367C109.35892 181.26774 109.22892 181.21836 109.10798 181.15117C108.98236 181.08836 108.86579 181.01211 108.75361 180.92242C108.64142 180.83274 108.5383 180.7343 108.43986 180.62211Z'/>
+<path d='M114.0184 176.66711C114.2246 176.66711 114.4262 176.703048 114.619 176.774923C114.8118 176.851173 114.9777 176.94961 115.1168 177.07961L114.8837 177.46086C114.8521 177.510235 114.8118 177.53711 114.7715 177.53711C114.749 177.53711 114.7177 177.528048 114.6909 177.501173C114.6549 177.48336 114.619 177.456485 114.5743 177.42961C114.5293 177.402735 114.4756 177.375548 114.4127 177.357735C114.3546 177.33086 114.2827 177.321798 114.1974 177.321798C114.0496 177.321798 113.9331 177.366798 113.839 177.46086C113.7446 177.554923 113.6999 177.693985 113.6999 177.8868V180.61305H115.0137V181.19149H113.6999V182.75649H113.2962C113.2471 182.75649 113.2021 182.74305 113.1752 182.71149C113.1393 182.68461 113.1215 182.64867 113.1124 182.60399L112.9287 181.20055L112.1843 181.10617V180.78805C112.1843 180.72961 112.2021 180.68492 112.2337 180.65805C112.2649 180.62649 112.3052 180.61305 112.3546 180.61305H112.9018V177.83305C112.9018 177.456485 112.9959 177.169298 113.1931 176.967735C113.3815 176.76586 113.6596 176.66711 114.0184 176.66711ZM116.596 180.37086L116.5422 181.06149C116.5288 181.14211 116.5063 181.20055 116.475 181.2318C116.4435 181.26336 116.3806 181.28117 116.2956 181.28117H115.8381V176.738985H116.641V179.60867C116.6991 179.76555 116.7619 179.90461 116.8291 180.02117C116.901 180.1468 116.9816 180.24555 117.0713 180.32617C117.1566 180.41117 117.2597 180.47399 117.3672 180.5143C117.4838 180.55492 117.6094 180.57711 117.7528 180.57711C117.856 180.57711 117.9456 180.56836 118.0263 180.55024C118.1072 180.53242 118.1697 180.52336 118.2103 180.52336C118.2819 180.52336 118.3269 180.5593 118.3447 180.63555L118.4031 181.2318C118.3356 181.2768 118.255 181.30805 118.1653 181.33055C118.08 181.35305 117.986 181.3618 117.8919 181.3618C117.5913 181.3618 117.336 181.2768 117.125 181.09742C116.9144 180.92711 116.7394 180.68024 116.596 180.37086Z'/>
+<path d='M120.8317 181.35305C120.4954 181.35305 120.1948 181.29899 119.926 181.18711C119.6613 181.07492 119.4326 180.91805 119.2445 180.71617C119.056 180.5143 118.9126 180.26774 118.8138 179.97649C118.7107 179.6893 118.6613 179.36649 118.6613 179.01242C118.6613 178.65367 118.7107 178.33086 118.8138 178.04367C118.9126 177.7568 119.056 177.510235 119.2445 177.30836C119.4326 177.106798 119.6613 176.94961 119.926 176.837735C120.1948 176.729923 120.4954 176.676173 120.8317 176.676173C121.1635 176.676173 121.4638 176.729923 121.7285 176.837735C121.9929 176.94961 122.2217 177.106798 122.4101 177.30836C122.5982 177.510235 122.7417 177.7568 122.8404 178.04367C122.9435 178.33086 122.9929 178.65367 122.9929 179.01242C122.9929 179.36649 122.9435 179.6893 122.8404 179.97649C122.7417 180.26774 122.5982 180.5143 122.4101 180.71617C122.2217 180.91805 121.9929 181.07492 121.7285 181.18711C121.4638 181.29899 121.1635 181.35305 120.8317 181.35305ZM120.8317 177.29961C120.3788 177.29961 120.0379 177.447423 119.8182 177.75242C119.5942 178.04836 119.482 178.46992 119.482 179.00774C119.482 179.2768 119.5088 179.51899 119.5673 179.7343C119.621 179.94492 119.7017 180.1243 119.8182 180.27242C119.926 180.42024 120.0695 180.53242 120.2398 180.60867C120.4057 180.68492 120.6029 180.72524 120.8317 180.72524C121.2801 180.72524 121.6163 180.57274 121.836 180.27242C122.0557 179.9718 122.1679 179.55055 122.1679 179.00774C122.1679 178.46992 122.0557 178.04836 121.836 177.75242C121.6163 177.447423 121.2801 177.29961 120.8317 177.29961ZM124.8037 177.83305V180.03024C124.9693 180.24992 125.1487 180.41586 125.3415 180.5368C125.539 180.65805 125.7674 180.71617 126.0277 180.71617C126.2115 180.71617 126.3731 180.68492 126.5165 180.62211S126.7809 180.46055 126.8796 180.32617C126.9784 180.18711 127.0546 180.01211 127.1084 179.80149C127.1577 179.59086 127.1846 179.33524 127.1846 179.0393C127.1846 178.47867 127.0724 178.04836 126.8437 177.74774C126.6149 177.447423 126.2921 177.294923 125.8662 177.294923C125.6509 177.294923 125.4581 177.335235 125.2834 177.416173C125.1084 177.496798 124.9515 177.63586 124.8037 177.83305ZM124.7631 180.57711L124.6915 181.11524C124.6646 181.22742 124.5927 181.28117 124.4806 181.28117H124.0009V175.20086H124.8037V177.209923C124.9559 177.043985 125.1309 176.909298 125.3327 176.81961C125.5299 176.721173 125.7674 176.676173 126.0456 176.676173C126.3506 176.676173 126.624 176.738985 126.8662 176.855548C127.1127 176.981173 127.319 177.142423 127.4849 177.357735C127.6552 177.563985 127.7852 177.81524 127.8749 178.10211C127.9646 178.39367 128.0096 178.70305 128.0096 179.0393C128.0096 179.41586 127.9693 179.74774 127.8884 180.0393C127.8077 180.33055 127.6912 180.57274 127.5434 180.76555C127.3952 180.96274 127.2115 181.11086 127.0006 181.21399C126.7899 181.31274 126.5521 181.3618 126.2877 181.3618C125.9649 181.3618 125.6781 181.29024 125.4268 181.1468C125.1756 181.00305 124.9559 180.81492 124.7631 180.57711Z'/>
+<path d='M132.8249 181.28117H132.1927C132.1387 181.28117 132.0896 181.26774 132.049 181.2318C132.0043 181.20492 131.9731 181.16461 131.9549 181.11524L130.7756 178.25899C130.7265 178.13336 130.6815 177.99899 130.6412 177.85992C130.6099 177.99899 130.5693 178.12899 130.5202 178.25461L129.3049 181.11524C129.2915 181.15555 129.2602 181.19586 129.2243 181.2318C129.1793 181.26336 129.1256 181.28117 129.0584 181.28117H128.3677L130.2421 177.003673L129.4127 175.20086H130.0046C130.0896 175.20086 130.1481 175.21899 130.1927 175.25492C130.2287 175.29055 130.2646 175.33992 130.2915 175.39836L132.8249 181.28117Z'/>
+<path d='M135.96386 174.60524C135.96386 174.65024 135.93698 174.67711 135.88324 174.73992C134.72699 175.797735 134.3773 177.411485 134.3773 178.98024C134.3773 180.36961 134.64605 182.05524 135.91011 183.25649C135.94605 183.29211 135.96386 183.3193 135.96386 183.36399C135.96386 183.4268 135.91917 183.46242 135.85636 183.46242C135.74886 183.46242 134.94199 182.81711 134.45792 181.83992C134.02761 180.9793 133.812298 180.05586 133.812298 178.9893C133.812298 178.34367 133.893235 177.321798 134.38605 176.263985C134.91511 175.16117 135.74886 174.5068 135.85636 174.5068C135.91917 174.5068 135.96386 174.54274 135.96386 174.60524Z'/>
+<path d='M141.04403 180.17242C141.26809 180.38774 141.78809 180.96149 142.0034 181.18555C142.09309 181.27524 142.31715 181.50836 142.40684 181.6068C142.96247 182.1718 143.32122 182.53024 144.07403 182.58399C144.18184 182.59305 144.28028 182.60211 144.28028 182.74555C144.28028 182.78117 144.2534 182.8618 144.15497 182.8618C144.10122 182.8618 143.79622 182.84399 143.74247 182.84399C143.66184 182.83492 143.45559 182.83492 143.31215 182.83492C143.1509 182.83492 142.98059 182.84399 142.81903 182.84399C142.65778 182.84399 142.4784 182.8618 142.3259 182.8618C142.27215 182.8618 142.15559 182.8618 142.15559 182.70055C142.15559 182.59305 142.2634 182.58399 142.28122 182.58399C142.35309 182.57492 142.62184 182.55711 142.62184 182.32399C142.62184 182.1718 142.41559 181.95649 142.40684 181.94742L140.93653 180.41461L140.13872 182.20742C140.09372 182.29711 140.09372 182.31524 140.09372 182.32399C140.09372 182.36899 140.23715 182.55711 140.62278 182.58399C140.66747 182.58399 140.77528 182.59305 140.77528 182.74555C140.77528 182.82617 140.71247 182.8618 140.64059 182.8618C140.46122 182.8618 140.25528 182.84399 140.0759 182.84399C139.89653 182.84399 139.71715 182.83492 139.52903 182.83492C139.23309 182.83492 139.21528 182.83492 138.99997 182.84399L138.50715 182.8618C138.47122 182.8618 138.33684 182.8618 138.33684 182.70055C138.33684 182.58399 138.44434 182.58399 138.55184 182.58399C139.0809 182.58399 139.12559 182.48555 139.20622 182.30617L140.27309 179.91242C140.27309 179.90367 140.32684 179.80492 140.32684 179.79586C140.32684 179.76899 139.17059 178.56774 139.0359 178.43336C138.93747 178.33461 138.70434 178.07461 138.60559 177.97617C138.05872 177.429298 137.70903 177.070548 136.956216 177.016798C136.848403 177.008048 136.749966 176.998985 136.749966 176.855548C136.749966 176.801798 136.785903 176.738985 136.875591 176.738985C136.929341 176.738985 137.234028 176.756798 137.287778 176.756798C137.368403 176.76586 137.57465 176.76586 137.71809 176.76586C137.87965 176.76586 138.04997 176.756798 138.21122 176.756798S138.54278 176.738985 138.69528 176.738985C138.74028 176.738985 138.87465 176.738985 138.87465 176.900235C138.87465 177.008048 138.76715 177.016798 138.74903 177.016798C138.67747 177.02586 138.4084 177.043673 138.4084 177.276798C138.4084 177.420235 138.5159 177.536798 138.79403 177.83274L139.48434 178.54086L139.9684 179.04305C140.12965 179.21336 140.36278 179.45524 140.43434 179.54492L141.40278 177.39336C141.44747 177.303673 141.44747 177.28586 141.44747 177.276798C141.44747 177.23211 141.30403 177.043673 140.91872 177.016798C140.87372 177.016798 140.76622 177.008048 140.76622 176.855548C140.76622 176.774923 140.82903 176.738985 140.90059 176.738985C141.07997 176.738985 141.28622 176.756798 141.46528 176.756798C141.64465 176.756798 141.82403 176.76586 142.01215 176.76586C142.30809 176.76586 142.3259 176.76586 142.54122 176.756798L143.03434 176.738985C143.07028 176.738985 143.20465 176.738985 143.20465 176.900235C143.20465 177.016798 143.09715 177.016798 142.98934 177.016798C142.46059 177.016798 142.41559 177.115548 142.33497 177.294923L141.04403 180.17242Z'/>
+<path d='M147.47558 178.9893C147.47558 179.7243 147.36808 180.71024 146.90183 181.70555C146.37276 182.80805 145.539014 183.46242 145.431514 183.46242C145.341827 183.46242 145.324014 183.39086 145.324014 183.36399C145.324014 183.3193 145.341827 183.29211 145.404639 183.22961C145.92464 182.76336 146.91089 181.54399 146.91089 178.9893C146.91089 177.70711 146.67776 175.923048 145.377764 174.71305C145.359952 174.68617 145.324014 174.65024 145.324014 174.60524C145.324014 174.57836 145.341827 174.5068 145.431514 174.5068C145.539014 174.5068 146.34589 175.15211 146.82995 176.129298C147.26026 176.989923 147.47558 177.91336 147.47558 178.9893Z'/>
+<path d='M157.15177 178.77399C157.25021 178.81867 157.33084 178.86367 157.33084 178.9893C157.33084 179.10555 157.2324 179.15961 157.15177 179.19524L152.09552 181.62492C151.9699 181.68742 151.925212 181.68742 151.9074 181.68742C151.790837 181.68742 151.718962 181.58899 151.718962 181.4993C151.718962 181.3918 151.772712 181.3468 151.898337 181.28399L156.69459 178.9893L151.898337 176.685235C151.772712 176.622423 151.718962 176.577735 151.718962 176.469923C151.718962 176.407423 151.772712 176.281798 151.91615 176.281798C151.925212 176.281798 151.9699 176.281798 152.07771 176.335548L157.15177 178.77399Z'/>
+<path d='M163.40033 182.46742C163.40033 182.69149 163.39127 182.70961 163.1672 182.70961C162.61127 182.13586 161.78658 182.13586 161.508766 182.13586V181.85774C161.67908 181.85774 162.22595 181.85774 162.71002 182.09086V177.456173C162.71002 177.12461 162.68314 177.016798 161.84939 177.016798H161.562516V176.738985C161.88533 176.76586 162.68314 176.76586 163.05064 176.76586S164.22502 176.76586 164.54783 176.738985V177.016798H164.26095C163.4272 177.016798 163.40033 177.12461 163.40033 177.456173V182.46742ZM169.4247 178.32586H169.17345C169.15564 178.2093 169.08377 177.680235 168.9672 177.536798C168.91345 177.456173 168.29502 177.456173 168.11564 177.456173H166.52002L167.40752 178.29899C168.87783 179.5718 169.4247 180.04711 169.4247 180.96149C169.4247 181.99242 168.57283 182.70961 167.47033 182.70961C166.43939 182.70961 165.74002 181.89367 165.74002 181.07805C165.74002 180.62961 166.12564 180.58492 166.20627 180.58492C166.40345 180.58492 166.67252 180.72836 166.67252 181.05117C166.67252 181.31992 166.48408 181.51711 166.20627 181.51711C166.16127 181.51711 166.13439 181.51711 166.09877 181.50836C166.31377 182.14461 166.88752 182.43149 167.37158 182.43149C168.28595 182.43149 168.5997 181.57992 168.5997 180.96149C168.5997 180.04711 167.90939 179.30305 167.47908 178.8368L165.83877 177.061798C165.74002 176.963048 165.74002 176.945235 165.74002 176.738985H169.17345L169.4247 178.32586Z'/>
+<path d='M173.62103 177.83305V180.03024C173.78666 180.24992 173.96166 180.41586 174.15884 180.5368C174.34728 180.65805 174.57603 180.71617 174.83603 180.71617C175.20822 180.71617 175.49509 180.58617 175.70134 180.32617C175.89884 180.06149 176.00197 179.65367 176.00197 179.09742C176.00197 178.50117 175.88978 178.04836 175.66103 177.74774C175.43228 177.447423 175.10509 177.294923 174.67916 177.294923C174.46822 177.294923 174.27541 177.335235 174.10509 177.416173C173.92572 177.496798 173.76884 177.63586 173.62103 177.83305ZM173.62103 180.62649V183.34367H172.818218V176.738985H173.33384C173.44603 176.738985 173.51791 176.797423 173.54009 176.909298L173.58041 177.321798C173.73291 177.115548 173.91228 176.954298 174.11416 176.846485C174.32041 176.729923 174.57134 176.676173 174.87197 176.676173C175.17228 176.676173 175.44572 176.73461 175.68791 176.855548C175.93009 176.97211 176.13634 177.138048 176.30228 177.348673C176.47259 177.563985 176.60259 177.82399 176.69228 178.12461C176.78197 178.42492 176.82697 178.76117 176.82697 179.12899C176.82697 179.4743 176.78666 179.78367 176.70572 180.05711C176.62947 180.33055 176.51291 180.56836 176.36509 180.75649C176.21697 180.95399 176.03322 181.09742 175.81791 181.20055C175.60728 181.30367 175.36509 181.35305 175.10072 181.35305C174.78666 181.35305 174.50884 181.28555 174.26666 181.15555C174.02884 181.02555 173.81384 180.84617 173.62103 180.62649ZM178.68251 181.28117H177.88439V176.738985H178.68251V181.28117ZM178.85283 182.70711C178.85283 182.78336 178.83939 182.85961 178.80345 182.9268C178.77658 182.99867 178.73189 183.06117 178.67783 183.11524C178.62845 183.1643 178.56595 183.20492 178.49845 183.23617C178.42689 183.26742 178.35064 183.28117 178.27439 183.28117S178.12189 183.26742 178.05908 183.23617C177.98751 183.20492 177.92908 183.1643 177.8797 183.11524C177.83033 183.06117 177.79001 182.99867 177.75876 182.9268C177.7272 182.85961 177.71376 182.78336 177.71376 182.70711S177.7272 182.55899 177.75876 182.48742C177.79001 182.42461 177.83033 182.3618 177.8797 182.30805C177.92908 182.25867 177.98751 182.21836 178.05908 182.1868C178.12189 182.15555 178.19814 182.14211 178.27439 182.14211S178.42689 182.15555 178.49845 182.1868C178.56595 182.21836 178.62845 182.25867 178.67783 182.30805C178.73189 182.3618 178.77658 182.42461 178.80345 182.48742C178.83939 182.55899 178.85283 182.63086 178.85283 182.70711ZM181.38595 176.66711C181.5922 176.66711 181.79376 176.703048 181.98658 176.774923C182.17939 176.851173 182.3453 176.94961 182.4844 177.07961L182.2513 177.46086C182.2197 177.510235 182.17939 177.53711 182.13908 177.53711C182.11658 177.53711 182.08533 177.528048 182.05845 177.501173C182.02251 177.48336 181.98658 177.456485 181.94189 177.42961C181.89689 177.402735 181.84314 177.375548 181.78033 177.357735C181.7222 177.33086 181.65033 177.321798 181.56501 177.321798C181.4172 177.321798 181.30064 177.366798 181.20658 177.46086C181.1122 177.554923 181.06751 177.693985 181.06751 177.8868V180.61305H182.3813V181.19149H181.06751V182.75649H180.66376C180.6147 182.75649 180.5697 182.74305 180.54283 182.71149C180.50689 182.68461 180.48908 182.64867 180.48001 182.60399L180.29626 181.20055L179.55189 181.10617V180.78805C179.55189 180.72961 179.5697 180.68492 179.60126 180.65805C179.63251 180.62649 179.67283 180.61305 179.7222 180.61305H180.26939V177.83305C180.26939 177.456485 180.36345 177.169298 180.56064 176.967735C180.74908 176.76586 181.0272 176.66711 181.38595 176.66711ZM185.8513 180.53242L186.0307 180.82399C185.8557 180.98961 185.6495 181.11524 185.4163 181.21399C185.1742 181.30367 184.9098 181.35305 184.6092 181.35305C184.3535 181.35305 184.1251 181.31711 183.9232 181.24524C183.7213 181.17367 183.5554 181.0793 183.4167 180.95399C183.2776 180.83742 183.1745 180.69367 183.1026 180.53242C183.031 180.37555 182.9951 180.20961 182.9951 180.03461C182.9951 179.8418 183.031 179.67586 183.0935 179.5368C183.1654 179.40242 183.2507 179.29024 183.3626 179.19617C183.4748 179.10211 183.6004 179.02586 183.7395 178.96305C183.8829 178.90461 184.0263 178.85086 184.1788 178.80149C184.3223 178.75242 184.4701 178.70742 184.6092 178.66711C184.7526 178.62211 184.8782 178.56836 184.9904 178.51461C185.1026 178.4518 185.1923 178.38461 185.2548 178.2993C185.3267 178.21867 185.3579 178.11555 185.3579 177.98992C185.3579 177.8868 185.3401 177.79274 185.2998 177.703048C185.2638 177.61336 185.2057 177.532735 185.1295 177.465235C185.0532 177.398048 184.9545 177.339923 184.8379 177.303985C184.7213 177.258985 184.587 177.241173 184.4298 177.241173C184.246 177.241173 184.0935 177.263673 183.9726 177.303985C183.8513 177.344298 183.7482 177.393673 183.6585 177.443048C183.5779 177.492423 183.5017 177.541485 183.4435 177.58211C183.3851 177.622423 183.327 177.64461 183.2729 177.64461C183.2238 177.64461 183.1788 177.63586 183.1476 177.61336C183.116 177.59086 183.0848 177.563985 183.0623 177.523673L182.8738 177.218673C183.0532 177.057423 183.2729 176.927423 183.5285 176.81961C183.7842 176.721173 184.071 176.66711 184.3895 176.66711C184.6676 176.66711 184.9142 176.703048 185.1248 176.779298C185.3357 176.855548 185.5151 176.954298 185.6629 177.088673C185.811 177.214298 185.9185 177.371173 185.9948 177.546173C186.071 177.725548 186.107 177.91836 186.107 178.12899C186.107 178.31274 186.071 178.46992 186.0082 178.59524C185.9363 178.72992 185.8513 178.83742 185.7392 178.92711C185.627 179.0168 185.5017 179.09305 185.3626 179.15149C185.2235 179.20961 185.0754 179.26805 184.932 179.31274C184.7795 179.36649 184.636 179.41149 184.4973 179.45617C184.3582 179.49649 184.2326 179.54586 184.1204 179.6043C184.0085 179.66242 183.9188 179.72961 183.856 179.80586C183.7842 179.88211 183.7529 179.98086 183.7529 180.09742C183.7529 180.19149 183.7751 180.2768 183.811 180.35305C183.856 180.43367 183.9098 180.50555 183.9904 180.56367C184.0623 180.62211 184.1563 180.67149 184.2638 180.70274C184.3717 180.73867 184.4926 180.75649 184.6273 180.75649C184.7842 180.75649 184.9185 180.73867 185.0307 180.70274C185.1429 180.67149 185.2413 180.63117 185.3267 180.59524C185.4073 180.55024 185.4748 180.5143 185.5329 180.48305C185.5913 180.4518 185.6404 180.43367 185.6854 180.43367C185.7617 180.43367 185.8154 180.46524 185.8513 180.53242Z'/>
+<path d='M170.77 244.8867V206.6172H230.297V244.8867Z' fill='#e6e6ff'/>
+<path d='M170.77 244.8867V206.6172H230.297V244.8867Z' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M192.65392 235.30941H191.68736V232.12597H187.83611V235.30941H186.869855V228.170037H187.83611V231.41847H191.68736V228.170037H192.65392V235.30941Z'/>
+<path d='M197.4943 231.2441H194.73431C194.794 231.68254 194.94837 232.02629 195.19775 232.27535C195.44181 232.51941 195.78056 232.6441 196.204 232.6441C196.4084 232.6441 196.5877 232.6091 196.7471 232.54441C196.9065 232.47472 197.0409 232.37504 197.1506 232.25535C197.2652 232.12597 197.3499 231.98129 197.4096 231.80691C197.4646 231.63754 197.4943 231.44816 197.4943 231.2441ZM198.2118 228.877537L197.9627 229.20129C197.9227 229.25629 197.8681 229.28597 197.7934 229.28597C197.7384 229.28597 197.6687 229.26097 197.589 229.20629C197.5143 229.1566 197.4146 229.1016 197.2999 229.041912C197.1856 228.982225 197.0459 228.927225 196.8815 228.877537C196.7221 228.82285 196.5327 228.79785 196.3087 228.79785C196.0696 228.79785 195.85525 228.837537 195.66087 228.917225C195.4665 228.992225 195.30212 229.1116 195.16275 229.26597C195.02337 229.42566 194.91368 229.62472 194.839 229.8591C194.75931 230.09316 194.71431 230.37222 194.70431 230.69097H198.0771C198.1621 230.69097 198.2168 230.71597 198.2468 230.76066C198.2765 230.80566 198.2915 230.90035 198.2915 231.03972C198.2915 231.39847 198.2368 231.71722 198.1321 231.99629C198.0274 232.28035 197.8781 232.51441 197.6887 232.70379C197.5043 232.89816 197.2802 233.04254 197.0212 233.14222C196.7671 233.24691 196.4881 233.2966 196.184 233.2966C195.82025 233.2966 195.4915 233.23191 195.19775 233.10222C194.90368 232.97785 194.65962 232.80347 194.45525 232.5741C194.25087 232.35504 194.0965 232.08597 193.99181 231.78222C193.88243 231.47816 193.82743 231.14941 193.82743 230.79566C193.82743 230.36222 193.88743 229.97347 194.00681 229.63972C194.1265 229.30597 194.29087 229.021912 194.50993 228.79785C194.71931 228.568475 194.97837 228.3941 195.26743 228.279725C195.56618 228.160037 195.88525 228.10035 196.234 228.10035C196.4184 228.10035 196.6024 228.11535 196.7868 228.150037C196.9712 228.180037 197.1506 228.224725 197.3299 228.289725C197.4993 228.354412 197.6637 228.4341 197.8181 228.528787C197.9727 228.628475 198.1021 228.74285 198.2118 228.877537ZM202.112 230.44191V229.39566C202.0124 229.29097 201.9127 229.19629 201.803 229.1116C201.7033 229.026912 201.5939 228.957225 201.4742 228.897537C201.3645 228.837537 201.2402 228.79285 201.1105 228.75785C200.9811 228.728162 200.8364 228.713162 200.682 228.713162C200.5674 228.713162 200.458 228.728162 200.3583 228.75785C200.2536 228.78285 200.1689 228.827537 200.0892 228.887537C200.0195 228.952225 199.9595 229.031912 199.9149 229.1266C199.8699 229.22129 199.8502 229.33597 199.8502 229.47035C199.8502 229.60972 199.8899 229.73441 199.9695 229.8491C200.0542 229.96347 200.1839 230.05816 200.3683 230.14285C200.5477 230.22754 200.7817 230.29254 201.0658 230.34222C201.3545 230.39691 201.7033 230.42691 202.112 230.44191ZM199.247 232.50441L199.4067 232.22066C199.4364 232.17566 199.4714 232.13597 199.5161 232.10597C199.5611 232.07097 199.6108 232.05597 199.6708 232.05597C199.7455 232.05597 199.8252 232.08597 199.8999 232.13597C199.9795 232.19566 200.0742 232.25535 200.1789 232.32504C200.2883 232.39004 200.418 232.45472 200.5674 232.50441C200.712 232.56441 200.8964 232.5891 201.1155 232.5891C201.4392 232.5891 201.6883 232.48941 201.8577 232.28535C202.0274 232.08597 202.112 231.79191 202.112 231.39847V231.00472C201.5389 230.99004 201.0508 230.94004 200.657 230.85035C200.2636 230.75566 199.9395 230.64129 199.6955 230.4966C199.4514 230.35222 199.272 230.19285 199.1624 230.00347C199.053 229.8241 198.998 229.62972 198.998 229.43066C198.998 229.20129 199.033 229.001912 199.1127 228.837537C199.1824 228.668162 199.287 228.528787 199.4117 228.4191C199.5411 228.309412 199.6905 228.229725 199.8649 228.170037C200.0392 228.12035 200.2236 228.09035 200.418 228.09035S200.7867 228.11035 200.9461 228.140037C201.1005 228.180037 201.2499 228.229725 201.3895 228.289725C201.5289 228.359412 201.6636 228.4391 201.788 228.528787C201.9127 228.628475 202.042 228.733162 202.1767 228.857537L202.2764 228.379412C202.3011 228.294725 202.3411 228.239725 202.3858 228.210037C202.4308 228.185037 202.5005 228.170037 202.5852 228.170037H202.9789V231.39847C202.9789 231.68254 202.9389 231.9416 202.8642 232.17566S202.6749 232.6141 202.5255 232.77847C202.3761 232.94285 202.1917 233.07254 201.9724 233.16722C201.7533 233.26191 201.5042 233.3066 201.2202 233.3066C200.8264 233.3066 200.4727 233.24191 200.1489 233.10722C199.8252 232.97285 199.5261 232.77347 199.247 232.50441ZM205.2447 235.50879H204.3581V228.170037H205.2447V235.50879ZM208.2287 228.09035C208.4581 228.09035 208.6821 228.130037 208.8965 228.210037C209.1106 228.294725 209.2949 228.4041 209.4493 228.548787L209.1902 228.972225C209.1556 229.026912 209.1106 229.056912 209.0659 229.056912C209.0409 229.056912 209.0059 229.046912 208.9762 229.016912C208.9362 228.997225 208.8965 228.967225 208.8465 228.937225C208.7968 228.907537 208.7368 228.877537 208.6671 228.857537C208.6024 228.827537 208.5227 228.81785 208.4281 228.81785C208.2637 228.81785 208.134 228.867537 208.0293 228.972225C207.9249 229.076912 207.8749 229.23129 207.8749 229.44535V232.47472H209.3346V233.11722H207.8749V234.85597H207.4265C207.3718 234.85597 207.3221 234.84097 207.2921 234.80629C207.2521 234.77629 207.2324 234.7366 207.2224 234.6866L207.0181 233.12722L206.1912 233.02254V232.66879C206.1912 232.6041 206.2109 232.55441 206.2459 232.52441C206.2809 232.48941 206.3256 232.47472 206.3802 232.47472H206.9881V229.38566C206.9881 228.967225 207.0927 228.648475 207.3121 228.4241C207.5212 228.200037 207.8302 228.09035 208.2287 228.09035ZM211.1427 232.54441V235.50879H210.2509V228.170037H211.1427V231.8866C211.3368 232.10097 211.5462 232.27535 211.7706 232.39972C211.9996 232.52441 212.2437 232.5891 212.5077 232.5891C212.8615 232.5891 213.1256 232.48441 213.3049 232.27535C213.4743 232.06097 213.564 231.76722 213.564 231.38347V228.170037H214.4559V231.38347C214.4559 231.66754 214.4209 231.9316 214.3462 232.16566S214.1668 232.6041 214.0224 232.77347C213.8827 232.93785 213.7084 233.06754 213.4943 233.16222C213.2849 233.25191 213.0409 233.2966 212.7668 233.2966C212.4231 233.2966 212.124 233.22691 211.8599 233.09254C211.5962 232.95785 211.3568 232.77347 211.1427 232.54441Z'/>
+<path d='M195.20739 222.54218V223.35437H189.61739V222.54218H191.93426V216.214997H192.89583V222.54218H195.20739Z'/>
+<path d='M198.21567 219.28906H195.45567C195.51536 219.7275 195.66973 220.07125 195.91911 220.32031C196.16317 220.56437 196.50192 220.68906 196.92536 220.68906C197.12973 220.68906 197.30911 220.65406 197.46848 220.58937C197.62786 220.51968 197.76223 220.42 197.87192 220.30031C197.98661 220.17093 198.0713 220.02625 198.13098 219.85187C198.18598 219.6825 198.21567 219.49312 198.21567 219.28906ZM198.93317 216.922497L198.68411 217.24625C198.64411 217.30125 198.58942 217.33093 198.51473 217.33093C198.45973 217.33093 198.39005 217.30593 198.31036 217.25125C198.23567 217.201559 198.13598 217.146559 198.0213 217.086872C197.90692 217.027184 197.76723 216.972184 197.60286 216.922497C197.44348 216.867809 197.25411 216.842809 197.03005 216.842809C196.79098 216.842809 196.57661 216.882497 196.38223 216.962184C196.18786 217.037184 196.02348 217.156559 195.88411 217.31093C195.74473 217.47062 195.63505 217.66968 195.56036 217.90406C195.48067 218.13812 195.43567 218.41718 195.42567 218.73593H198.79848C198.88348 218.73593 198.93817 218.76093 198.96817 218.80562C198.99786 218.85062 199.01286 218.94531 199.01286 219.08468C199.01286 219.44343 198.95817 219.76218 198.85348 220.04125C198.7488 220.32531 198.59942 220.55937 198.41005 220.74875C198.22567 220.94312 198.00161 221.0875 197.74255 221.18718C197.48848 221.29187 197.20942 221.34156 196.90536 221.34156C196.54161 221.34156 196.21286 221.27687 195.91911 221.14718C195.62505 221.02281 195.38098 220.84843 195.17661 220.61906C194.97223 220.4 194.81786 220.13093 194.71317 219.82718C194.6038 219.52312 194.5488 219.19437 194.5488 218.84062C194.5488 218.40718 194.6088 218.01843 194.72817 217.68468C194.84786 217.35093 195.01223 217.066872 195.2313 216.842809C195.44067 216.613434 195.69973 216.439059 195.9888 216.324684C196.28755 216.204997 196.60661 216.145309 196.95536 216.145309C197.13973 216.145309 197.3238 216.160309 197.50817 216.194997C197.69255 216.224997 197.87192 216.269684 198.0513 216.334684C198.22067 216.399372 198.38505 216.479059 198.53942 216.573747C198.69411 216.673434 198.82348 216.787809 198.93317 216.922497ZM203.0375 220.43L203.2368 220.75375C203.0425 220.93812 202.8134 221.0775 202.5543 221.18718C202.2853 221.28687 201.9912 221.34156 201.6575 221.34156C201.3734 221.34156 201.1193 221.30187 200.8953 221.22218C200.6709 221.14218 200.4865 221.03781 200.3322 220.89812C200.1778 220.76875 200.0631 220.60937 199.9834 220.43C199.9037 220.25562 199.864 220.07125 199.864 219.87687C199.864 219.6625 199.9037 219.47843 199.9734 219.32375C200.0531 219.17437 200.1478 219.04968 200.2725 218.94531C200.3972 218.84062 200.5365 218.75593 200.6909 218.68625C200.8503 218.62125 201.0097 218.56156 201.1793 218.50687C201.3387 218.45187 201.5031 218.40218 201.6575 218.35718C201.8168 218.3075 201.9565 218.24781 202.0809 218.18781C202.2056 218.11812 202.3053 218.04343 202.375 217.94875C202.4547 217.85906 202.4897 217.74437 202.4897 217.605C202.4897 217.49031 202.4697 217.38593 202.4247 217.28625C202.385 217.186559 202.32 217.096872 202.2353 217.022184C202.1506 216.947497 202.0412 216.882497 201.9115 216.842809C201.7822 216.792809 201.6325 216.773122 201.4581 216.773122C201.254 216.773122 201.0847 216.797809 200.95 216.842809C200.8156 216.887497 200.7009 216.942497 200.6012 216.997184C200.5115 217.051872 200.4268 217.106872 200.3622 217.151559C200.2975 217.196559 200.2325 217.22125 200.1728 217.22125C200.1181 217.22125 200.0681 217.211559 200.0334 217.186559C199.9984 217.161559 199.9634 217.131559 199.9387 217.086872L199.7293 216.748122C199.9287 216.568747 200.1728 216.424372 200.4568 216.304684C200.7409 216.194997 201.0597 216.135309 201.4134 216.135309C201.7222 216.135309 201.9962 216.174997 202.2303 216.259684C202.4647 216.344684 202.664 216.454059 202.8284 216.603747C202.9928 216.743122 203.1122 216.917497 203.1968 217.111872C203.2815 217.31093 203.3215 217.52531 203.3215 217.75937C203.3215 217.96375 203.2815 218.13812 203.2118 218.2775C203.1322 218.42718 203.0375 218.54656 202.9131 218.64625C202.7884 218.74593 202.649 218.83062 202.4943 218.89531C202.34 218.96031 202.1756 219.025 202.0162 219.07468C201.8468 219.13468 201.6875 219.18437 201.5328 219.23406C201.3784 219.27906 201.239 219.33375 201.1143 219.39843C200.99 219.46343 200.8903 219.53812 200.8206 219.62281C200.7409 219.7075 200.7059 219.81718 200.7059 219.94656C200.7059 220.05125 200.7309 220.14593 200.7706 220.23062C200.8206 220.32031 200.8803 220.4 200.97 220.46468C201.0497 220.52937 201.1543 220.58437 201.2737 220.61906C201.3934 220.65906 201.5281 220.67906 201.6775 220.67906C201.8518 220.67906 202.0012 220.65906 202.1259 220.61906C202.2503 220.58437 202.36 220.53937 202.4547 220.49968C202.5443 220.44968 202.619 220.41 202.6837 220.375C202.7487 220.34031 202.8034 220.32031 202.8531 220.32031C202.9378 220.32031 202.9978 220.35531 203.0375 220.43ZM205.9612 216.135309C206.1906 216.135309 206.4147 216.174997 206.629 216.254997C206.8431 216.339684 207.0275 216.449059 207.1818 216.593747L206.9228 217.017184C206.8881 217.071872 206.8431 217.101872 206.7984 217.101872C206.7734 217.101872 206.7384 217.091872 206.7087 217.061872C206.6687 217.042184 206.629 217.012184 206.579 216.982184C206.5293 216.952497 206.4693 216.922497 206.3997 216.902497C206.335 216.872497 206.2553 216.862809 206.1606 216.862809C205.9962 216.862809 205.8665 216.912497 205.7618 217.017184C205.6575 217.121872 205.6075 217.27625 205.6075 217.49031V220.51968H207.0672V221.16218H205.6075V222.90093H205.159C205.1043 222.90093 205.0547 222.88593 205.0247 222.85125C204.9847 222.82125 204.965 222.78156 204.955 222.73156L204.7506 221.17218L203.9237 221.0675V220.71375C203.9237 220.64906 203.9434 220.59937 203.9784 220.56937C204.0134 220.53437 204.0581 220.51968 204.1128 220.51968H204.7206V217.43062C204.7206 217.012184 204.8253 216.693434 205.0447 216.469059C205.2537 216.244997 205.5628 216.135309 205.9612 216.135309ZM210.9228 220.43L211.1222 220.75375C210.9278 220.93812 210.6987 221.0775 210.4397 221.18718C210.1706 221.28687 209.8765 221.34156 209.5428 221.34156C209.2587 221.34156 209.0047 221.30187 208.7806 221.22218C208.5562 221.14218 208.3718 221.03781 208.2175 220.89812C208.0631 220.76875 207.9484 220.60937 207.8687 220.43C207.789 220.25562 207.7493 220.07125 207.7493 219.87687C207.7493 219.6625 207.789 219.47843 207.8587 219.32375C207.9384 219.17437 208.0331 219.04968 208.1578 218.94531C208.2825 218.84062 208.4218 218.75593 208.5762 218.68625C208.7356 218.62125 208.895 218.56156 209.0647 218.50687C209.224 218.45187 209.3884 218.40218 209.5428 218.35718C209.7022 218.3075 209.8418 218.24781 209.9662 218.18781C210.0909 218.11812 210.1906 218.04343 210.2603 217.94875C210.34 217.85906 210.375 217.74437 210.375 217.605C210.375 217.49031 210.355 217.38593 210.31 217.28625C210.2703 217.186559 210.2053 217.096872 210.1206 217.022184C210.0359 216.947497 209.9265 216.882497 209.7968 216.842809C209.6675 216.792809 209.5178 216.773122 209.3434 216.773122C209.1393 216.773122 208.97 216.797809 208.8353 216.842809C208.7009 216.887497 208.5862 216.942497 208.4865 216.997184C208.3968 217.051872 208.3122 217.106872 208.2475 217.151559C208.1828 217.196559 208.1178 217.22125 208.0581 217.22125C208.0034 217.22125 207.9534 217.211559 207.9187 217.186559C207.8837 217.161559 207.8487 217.131559 207.824 217.086872L207.6147 216.748122C207.814 216.568747 208.0581 216.424372 208.3422 216.304684C208.6262 216.194997 208.945 216.135309 209.2987 216.135309C209.6075 216.135309 209.8815 216.174997 210.1156 216.259684C210.35 216.344684 210.5493 216.454059 210.7137 216.603747C210.8781 216.743122 210.9975 216.917497 211.0822 217.111872C211.1668 217.31093 211.2068 217.52531 211.2068 217.75937C211.2068 217.96375 211.1668 218.13812 211.0972 218.2775C211.0175 218.42718 210.9228 218.54656 210.7984 218.64625C210.6737 218.74593 210.5343 218.83062 210.3797 218.89531C210.2253 218.96031 210.0609 219.025 209.9015 219.07468C209.7322 219.13468 209.5728 219.18437 209.4181 219.23406C209.2637 219.27906 209.1243 219.33375 208.9997 219.39843C208.8753 219.46343 208.7756 219.53812 208.7059 219.62281C208.6262 219.7075 208.5912 219.81718 208.5912 219.94656C208.5912 220.05125 208.6162 220.14593 208.6559 220.23062C208.7059 220.32031 208.7656 220.4 208.8553 220.46468C208.935 220.52937 209.0397 220.58437 209.159 220.61906C209.2787 220.65906 209.4134 220.67906 209.5628 220.67906C209.7372 220.67906 209.8865 220.65906 210.0112 220.61906C210.1356 220.58437 210.2453 220.53937 210.34 220.49968C210.4297 220.44968 210.5043 220.41 210.569 220.375C210.634 220.34031 210.6887 220.32031 210.7384 220.32031C210.8231 220.32031 210.8831 220.35531 210.9228 220.43Z'/>
+<path d='M200.535 206.6172V155.594H165.328' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M162.83221 155.593717L166.406429 154.24606L165.23065 155.593717L166.406429 156.93747Z'/>
+<path d='M162.83221 155.593717L166.406429 154.24606L165.23065 155.593717L166.406429 156.93747Z' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M179.54532 162.4279C179.54532 162.74634 179.50939 163.04665 179.43751 163.33353C179.37032 163.62072 179.2672 163.88509 179.13282 164.13165C178.99814 164.37853 178.83689 164.59822 178.63939 164.79978C178.45126 164.99728 178.23157 165.16759 177.98939 165.30197C177.7472 165.44572 177.48251 165.55322 177.19126 165.62509C176.8997 165.70572 176.59032 165.74166 176.26314 165.74166C175.77439 165.74166 175.32595 165.66072 174.9222 165.4904C174.51876 165.32916 174.17345 165.09572 173.88657 164.79978C173.595012 164.50384 173.37095 164.15415 173.214075 163.75072C173.056887 163.34259 172.976262 162.90322 172.976262 162.4279C172.976262 161.95259 173.056887 161.51322 173.214075 161.10509C173.37095 160.70165 173.595012 160.35197 173.88657 160.05603C174.17345 159.760092 174.51876 159.526655 174.9222 159.365405C175.32595 159.195092 175.77439 159.114155 176.26314 159.114155C176.75626 159.114155 177.2047 159.195092 177.60814 159.365405C178.01189 159.526655 178.35689 159.760092 178.64407 160.05603C178.93095 160.35197 179.15064 160.70165 179.3122 161.10509C179.4647 161.51322 179.54532 161.95259 179.54532 162.4279ZM178.3122 162.4279C178.3122 162.07353 178.26282 161.75072 178.16876 161.4729C178.07439 161.18572 177.93564 160.94822 177.76064 160.7554C177.58564 160.55822 177.37064 160.40572 177.11501 160.30259C176.86376 160.19947 176.58126 160.145717 176.26314 160.145717C175.9447 160.145717 175.6622 160.19947 175.41095 160.30259C175.15564 160.40572 174.94032 160.55822 174.76532 160.7554C174.58595 160.94822 174.44689 161.18572 174.35282 161.4729C174.25876 161.75072 174.20939 162.07353 174.20939 162.4279C174.20939 162.78228 174.25876 163.10509 174.35282 163.38291C174.44689 163.67009 174.58595 163.90759 174.76532 164.10478C174.94032 164.30228 175.15564 164.45478 175.41095 164.5579C175.6622 164.66103 175.9447 164.71478 176.26314 164.71478C176.58126 164.71478 176.86376 164.66103 177.11501 164.5579C177.37064 164.45478 177.58564 164.30228 177.76064 164.10478C177.93564 163.90759 178.07439 163.67009 178.16876 163.38291C178.26282 163.10509 178.3122 162.78228 178.3122 162.4279ZM181.81298 162.95259V165.66978H180.60673V159.18603H181.81298V162.0379H182.19423C182.33298 162.0379 182.44079 162.01978 182.51704 161.98853C182.59329 161.95697 182.6558 161.89884 182.7142 161.81822L184.548 159.42353C184.5974 159.347592 184.6558 159.28478 184.7274 159.248842C184.7949 159.203842 184.9024 159.18603 185.0458 159.18603H186.1086L183.8577 162.22166C183.7858 162.32478 183.7095 162.41009 183.6333 162.47728C183.5527 162.54009 183.463 162.58947 183.3642 162.62509C183.5033 162.69259 183.6333 162.80915 183.7636 162.97509L185.947 165.66978H184.9067C184.7814 165.66978 184.6783 165.65197 184.593 165.61603C184.5124 165.57572 184.4361 165.50822 184.3599 165.41416L182.57079 163.14978C182.51704 163.08259 182.45423 163.03322 182.37798 162.99728C182.30173 162.9704 182.20767 162.95259 182.09548 162.95259H181.81298ZM186.3497 165.08228L186.6409 164.6204C186.6903 164.53072 186.7666 164.48603 186.8744 164.48603C186.9191 164.48603 186.9684 164.50384 187.0266 164.53978C187.085 164.58009 187.1522 164.6204 187.2328 164.6654C187.3181 164.71478 187.4169 164.75509 187.5378 164.79103C187.6544 164.83134 187.7978 164.84916 187.9684 164.84916C188.085 164.84916 188.1925 164.83134 188.2913 164.79978C188.3944 164.76853 188.4794 164.71915 188.5513 164.65634C188.6228 164.59822 188.6769 164.52197 188.7216 164.44134C188.7575 164.35166 188.78 164.25728 188.78 164.14978C188.78 163.98384 188.7441 163.84041 188.6769 163.71478C188.605 163.59822 188.5153 163.48603 188.4122 163.39197C188.3091 163.29322 188.1969 163.20353 188.0759 163.1229C187.955 163.03759 187.8472 162.95259 187.7531 162.8629C187.6544 162.77759 187.5738 162.67916 187.52 162.57603C187.4572 162.46822 187.4391 162.34259 187.4572 162.20384L187.5334 161.4729H188.2913L188.3944 162.12759C188.4078 162.22166 188.4525 162.30697 188.5331 162.38759C188.605 162.45915 188.6991 162.54009 188.8022 162.62072C188.9053 162.69697 189.0175 162.78228 189.1341 162.87197C189.2553 162.96134 189.3628 163.06915 189.4616 163.19009C189.56 163.31134 189.6409 163.45478 189.7081 163.62509C189.7753 163.78666 189.8066 163.98384 189.8066 164.21259C189.8066 164.44572 189.7663 164.65634 189.6813 164.84478C189.5959 165.03322 189.4794 165.19447 189.3269 165.32916C189.1744 165.45915 188.9906 165.56228 188.7753 165.63384C188.5647 165.70572 188.3269 165.74166 188.0669 165.74166C187.8741 165.74166 187.6994 165.72353 187.5334 165.68759C187.3675 165.65634 187.215 165.60697 187.0759 165.54884C186.9369 165.4904 186.8025 165.41853 186.6859 165.33791C186.5603 165.25728 186.4528 165.17197 186.3497 165.08228ZM187.1972 159.795717C187.1972 159.701655 187.215 159.611967 187.2509 159.526655C187.2822 159.44603 187.3316 159.374467 187.39 159.31603C187.4481 159.257905 187.52 159.20853 187.605 159.176967C187.6903 159.141342 187.78 159.123217 187.8741 159.123217C187.9684 159.123217 188.0581 159.141342 188.1388 159.176967C188.2238 159.20853 188.2956 159.257905 188.3541 159.31603C188.4166 159.374467 188.4659 159.44603 188.5019 159.526655C188.5378 159.611967 188.5556 159.701655 188.5556 159.795717C188.5556 159.890092 188.5378 159.975092 188.5019 160.060405C188.4659 160.145717 188.4166 160.21728 188.3541 160.27572C188.2956 160.33384 188.2238 160.38322 188.1388 160.41915C188.0581 160.45509 187.9684 160.4729 187.8741 160.4729C187.78 160.4729 187.6903 160.45509 187.605 160.41915C187.52 160.38322 187.4481 160.33384 187.39 160.27572C187.3316 160.21728 187.2822 160.145717 187.2509 160.060405C187.215 159.975092 187.1972 159.890092 187.1972 159.795717Z'/>
+<path d='M34.707 166.223V144.965H162.266V166.223Z' fill='#e6ffe6'/>
+<path d='M34.707 166.223V144.965H162.266V166.223Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M70.12139 158.08518V158.89737H64.531391V158.08518H66.84827V151.757996H67.80983V158.08518H70.12139Z'/>
+<path d='M71.77952 156.13237V159.09675H70.88764V151.757996H71.77952V155.47456C71.97358 155.68893 72.18295 155.86331 72.40733 155.98768C72.63639 156.11237 72.88045 156.17706 73.14452 156.17706C73.49827 156.17706 73.76233 156.07237 73.9417 155.86331C74.11108 155.64893 74.20077 155.35518 74.20077 154.97143V151.757996H75.0926V154.97143C75.0926 155.2555 75.0576 155.51956 74.983 155.75362C74.9083 155.98768 74.8036 156.19206 74.6592 156.36143C74.5195 156.52581 74.34514 156.6555 74.13108 156.75018C73.9217 156.83987 73.67764 156.88456 73.40358 156.88456C73.05983 156.88456 72.76077 156.81487 72.4967 156.6805C72.23295 156.54581 71.99358 156.36143 71.77952 156.13237ZM79.8245 154.83206H77.0645C77.1242 155.2705 77.2786 155.61425 77.528 155.86331C77.772 156.10737 78.1108 156.23206 78.5342 156.23206C78.7386 156.23206 78.918 156.19706 79.0773 156.13237C79.2367 156.06268 79.3711 155.963 79.4808 155.84331C79.5955 155.71393 79.6801 155.56925 79.7398 155.39487C79.7948 155.2255 79.8245 155.03612 79.8245 154.83206ZM80.542 152.465496L80.293 152.78925C80.253 152.84425 80.1983 152.87393 80.1236 152.87393C80.0686 152.87393 79.9989 152.84893 79.9192 152.79425C79.8445 152.744559 79.7448 152.689559 79.6301 152.629871C79.5158 152.570184 79.3761 152.515184 79.2117 152.465496C79.0523 152.410809 78.863 152.385809 78.6389 152.385809C78.3998 152.385809 78.1855 152.425496 77.9911 152.505184C77.7967 152.580184 77.6323 152.699559 77.493 152.85393C77.3536 153.01362 77.2439 153.21268 77.1692 153.44706C77.0895 153.68112 77.0445 153.96018 77.0345 154.27893H80.4073C80.4923 154.27893 80.547 154.30393 80.577 154.34862C80.6067 154.39362 80.6217 154.48831 80.6217 154.62768C80.6217 154.98643 80.567 155.30518 80.4623 155.58425C80.3576 155.86831 80.2083 156.10237 80.0189 156.29175C79.8345 156.48612 79.6105 156.6305 79.3514 156.73018C79.0973 156.83487 78.8183 156.88456 78.5142 156.88456C78.1505 156.88456 77.8217 156.81987 77.528 156.69018C77.2339 156.56581 76.9898 156.39143 76.7855 156.16206C76.5811 155.943 76.4267 155.67393 76.322 155.37018C76.2126 155.06612 76.1576 154.73737 76.1576 154.38362C76.1576 153.95018 76.2176 153.56143 76.337 153.22768C76.4567 152.89393 76.6211 152.609871 76.8401 152.385809C77.0495 152.156434 77.3086 151.982059 77.5976 151.867684C77.8964 151.747996 78.2155 151.688309 78.5642 151.688309C78.7486 151.688309 78.9326 151.703309 79.117 151.737996C79.3014 151.767996 79.4808 151.812684 79.6601 151.877684C79.8295 151.942371 79.9939 152.022059 80.1483 152.116746C80.303 152.216434 80.4323 152.330809 80.542 152.465496Z'/>
+<path d='M84.337203 156.38643L85.07939 156.6755C85.16408 156.70518 85.21908 156.75518 85.24408 156.82987C85.26877 156.89956 85.25377 156.98425 85.19408 157.07893C85.0747 157.27331 84.9997 157.46268 84.97002 157.65675C84.94002 157.85112 84.93502 158.0305 84.96502 158.19987C84.98502 158.36925 85.0297 158.52362 85.09439 158.65831C85.15939 158.79268 85.22408 158.90237 85.29377 158.98706C85.32877 159.02206 85.35345 159.07175 85.35845 159.13643C85.36345 159.20143 85.33377 159.25112 85.26877 159.29612L84.88533 159.53018C84.63627 159.32581 84.436891 159.10175 84.287516 158.84268C84.142828 158.59362 84.043141 158.32456 83.998453 158.0505C83.953453 157.77643 83.958453 157.49237 84.013453 157.20831C84.068141 156.92456 84.177828 156.6505 84.337203 156.38643ZM85.99127 156.38643L86.73345 156.6755C86.81845 156.70518 86.87314 156.75518 86.89814 156.82987C86.92283 156.89956 86.90783 156.98425 86.84814 157.07893C86.72877 157.27331 86.65377 157.46268 86.62408 157.65675C86.59408 157.85112 86.58908 158.0305 86.61908 158.19987C86.63908 158.36925 86.68377 158.52362 86.74845 158.65831C86.81345 158.79268 86.87814 158.90237 86.94783 158.98706C86.98283 159.02206 87.00752 159.07175 87.01252 159.13643C87.01752 159.20143 86.98783 159.25112 86.92283 159.29612L86.53939 159.53018C86.29033 159.32581 86.09095 159.10175 85.94158 158.84268C85.79689 158.59362 85.6972 158.32456 85.65252 158.0505C85.60752 157.77643 85.61252 157.49237 85.66752 157.20831C85.7222 156.92456 85.83189 156.6505 85.99127 156.38643Z'/>
+<path d='M90.93494 155.87331L91.214 156.31675C91.01962 156.50612 90.78056 156.6605 90.4915 156.77487C90.20275 156.88956 89.88369 156.94925 89.52994 156.94925C89.21619 156.94925 88.93713 156.90956 88.69306 156.81987C88.454 156.74018 88.25463 156.6255 88.09525 156.48112C87.93088 156.34143 87.81119 156.17706 87.7265 155.98768C87.64181 155.79862 87.60181 155.59925 87.60181 155.38987C87.60181 155.16581 87.63681 154.97143 87.7065 154.81206C87.78119 154.65268 87.87587 154.518 87.99556 154.40862C88.11025 154.29893 88.24462 154.20925 88.394 154.13956C88.54869 154.06487 88.70306 154.00487 88.86244 153.95018C89.01681 153.89518 89.17119 153.8505 89.32087 153.80081C89.47525 153.76081 89.60963 153.70612 89.72931 153.65112C89.844 153.59643 89.93869 153.52675 90.00837 153.45206C90.08306 153.37706 90.11806 153.27768 90.11806 153.158C90.11806 153.07831 90.10306 153.00362 90.06806 152.92393C90.03837 152.85393 89.98837 152.78425 89.91869 152.729559C89.854 152.674559 89.76931 152.624871 89.65962 152.594871C89.55994 152.555184 89.43056 152.540184 89.28588 152.540184C89.1015 152.540184 88.94712 152.560184 88.82244 152.604871C88.70306 152.649871 88.59838 152.694559 88.50869 152.744559C88.419 152.79425 88.33931 152.83925 88.27463 152.88393C88.20494 152.92893 88.12994 152.94862 88.05525 152.94862S87.91587 152.93393 87.86588 152.90393C87.81619 152.87393 87.7715 152.82925 87.7365 152.77425L87.45244 152.306121C87.55212 152.216434 87.66681 152.131746 87.79619 152.057059C87.93088 151.982059 88.07525 151.912371 88.22462 151.857684C88.38431 151.802684 88.54369 151.757996 88.71306 151.727996C88.87744 151.693309 89.05181 151.678309 89.22619 151.678309C89.55994 151.678309 89.849 151.717996 90.10806 151.807683C90.35713 151.887684 90.57119 152.007059 90.74556 152.156434C90.91994 152.311121 91.04962 152.490496 91.13431 152.694559C91.224 152.90393 91.26869 153.133 91.26869 153.37706C91.26869 153.58143 91.234 153.76081 91.16431 153.90518C91.08931 154.04987 90.99494 154.17925 90.87525 154.27893C90.76056 154.38862 90.62619 154.47331 90.47681 154.538C90.32712 154.60768 90.17775 154.66768 90.01837 154.72237C89.86869 154.77706 89.71431 154.82706 89.56494 154.86675C89.41556 154.91675 89.28088 154.96643 89.1615 155.02143C89.04681 155.07612 88.95212 155.14581 88.88244 155.2155C88.80775 155.29518 88.77275 155.38487 88.77275 155.49456C88.77275 155.65893 88.84244 155.79362 88.98213 155.89831C89.1165 156.00268 89.30588 156.05268 89.54994 156.05268C89.70431 156.05268 89.839 156.03768 89.95837 156.00268C90.06806 155.968 90.17275 155.933 90.26244 155.89331C90.35212 155.84831 90.43181 155.81331 90.4965 155.77862C90.56619 155.74362 90.63119 155.72862 90.69087 155.72862C90.74556 155.72862 90.79556 155.73862 90.83025 155.76362C90.86525 155.78362 90.90025 155.81831 90.93494 155.87331ZM95.4878 154.90175H93.16627C93.22095 155.2755 93.35064 155.55925 93.5597 155.76362C93.7591 155.968 94.0431 156.06768 94.3969 156.06768C94.5813 156.06768 94.7406 156.03768 94.875 155.973C95.0147 155.913 95.1291 155.82831 95.2188 155.72393C95.3085 155.61925 95.3735 155.49456 95.4231 155.35518C95.4631 155.2105 95.4878 155.06112 95.4878 154.90175ZM93.14127 154.15925H96.305C96.4197 154.15925 96.4944 154.18925 96.5341 154.25893C96.5741 154.31893 96.5941 154.44831 96.5941 154.63268C96.5941 155.00143 96.5391 155.33018 96.4294 155.61425C96.315 155.903 96.1606 156.14737 95.9663 156.34143C95.7719 156.54081 95.5378 156.69018 95.2638 156.79487C94.9897 156.89956 94.6956 156.94925 94.3719 156.94925C93.9881 156.94925 93.6494 156.88456 93.34064 156.75018C93.04158 156.6155 92.78252 156.43612 92.57345 156.21206C92.35908 155.983 92.1997 155.71393 92.08502 155.40487C91.97064 155.10112 91.91564 154.77206 91.91564 154.42331C91.91564 153.97518 91.98033 153.58143 92.11002 153.24268C92.2397 152.89893 92.41877 152.614871 92.64314 152.385809C92.8672 152.151434 93.13627 151.977059 93.44033 151.857684C93.7441 151.742996 94.0778 151.683309 94.4316 151.683309C94.611 151.683309 94.7953 151.698308 94.9847 151.722996C95.1791 151.747996 95.3635 151.797996 95.5528 151.857684C95.7319 151.927371 95.9113 152.012059 96.0806 152.116746C96.25 152.226434 96.4047 152.360809 96.5391 152.520184L96.1853 152.96862C96.1356 153.04331 96.061 153.08331 95.9563 153.08331C95.8816 153.08331 95.8019 153.05831 95.7222 153.01362C95.6375 152.96862 95.5428 152.91393 95.4331 152.85893C95.3285 152.80425 95.2041 152.749559 95.0544 152.704559C94.915 152.659871 94.7406 152.634871 94.5413 152.634871C94.3419 152.634871 94.1578 152.664871 93.9981 152.724559C93.8288 152.78925 93.6894 152.88393 93.5697 153.00362C93.45033 153.133 93.35564 153.28737 93.28095 153.48175C93.20595 153.67112 93.16127 153.89518 93.14127 154.15925ZM100.8078 154.90175H98.4863C98.541 155.2755 98.6706 155.55925 98.8797 155.76362C99.0791 155.968 99.3631 156.06768 99.7169 156.06768C99.9013 156.06768 100.0606 156.03768 100.195 155.973C100.3347 155.913 100.4491 155.82831 100.5388 155.72393C100.6285 155.61925 100.6935 155.49456 100.7431 155.35518C100.7831 155.2105 100.8078 155.06112 100.8078 154.90175ZM98.4613 154.15925H101.625C101.7397 154.15925 101.8144 154.18925 101.8541 154.25893C101.8941 154.31893 101.9141 154.44831 101.9141 154.63268C101.9141 155.00143 101.8591 155.33018 101.7494 155.61425C101.635 155.903 101.4806 156.14737 101.2863 156.34143C101.0919 156.54081 100.8578 156.69018 100.5838 156.79487C100.3097 156.89956 100.0156 156.94925 99.6919 156.94925C99.3081 156.94925 98.9694 156.88456 98.6606 156.75018C98.3616 156.6155 98.1025 156.43612 97.8935 156.21206C97.6791 155.983 97.5197 155.71393 97.405 155.40487C97.2906 155.10112 97.2356 154.77206 97.2356 154.42331C97.2356 153.97518 97.3003 153.58143 97.43 153.24268C97.5597 152.89893 97.7388 152.614871 97.9631 152.385809C98.1872 152.151434 98.4563 151.977059 98.7603 151.857684C99.0641 151.742996 99.3978 151.683309 99.7516 151.683309C99.931 151.683309 100.1153 151.698308 100.3047 151.722996C100.4991 151.747996 100.6835 151.797996 100.8728 151.857684C101.0519 151.927371 101.2313 152.012059 101.4006 152.116746C101.57 152.226434 101.7247 152.360809 101.8591 152.520184L101.5053 152.96862C101.4556 153.04331 101.381 153.08331 101.2763 153.08331C101.2016 153.08331 101.1219 153.05831 101.0422 153.01362C100.9575 152.96862 100.8628 152.91393 100.7531 152.85893C100.6485 152.80425 100.5241 152.749559 100.3744 152.704559C100.235 152.659871 100.0606 152.634871 99.8613 152.634871C99.6619 152.634871 99.4778 152.664871 99.3181 152.724559C99.1488 152.78925 99.0094 152.88393 98.8897 153.00362C98.7703 153.133 98.6756 153.28737 98.601 153.48175C98.526 153.67112 98.4813 153.89518 98.4613 154.15925ZM106.0431 155.56425V153.27268C105.8838 153.07831 105.7144 152.92393 105.535 152.81925C105.3556 152.714559 105.1366 152.659871 104.8825 152.659871C104.7228 152.659871 104.5785 152.689559 104.4491 152.744559C104.3194 152.80425 104.2097 152.89893 104.12 153.03331C104.0303 153.163 103.9606 153.33237 103.911 153.54175C103.866 153.74581 103.841 153.99987 103.841 154.29893C103.841 154.59268 103.871 154.85206 103.926 155.06612C103.9806 155.2855 104.0653 155.46456 104.17 155.60425C104.2747 155.74862 104.4041 155.85331 104.5535 155.923C104.7031 155.99268 104.8725 156.02768 105.0569 156.02768C105.246 156.02768 105.4253 155.99268 105.5847 155.923C105.7544 155.85331 105.9038 155.73362 106.0431 155.56425ZM107.2738 159.16143H106.0431V156.46612C105.8838 156.6205 105.7044 156.74018 105.5 156.82987C105.296 156.91956 105.0519 156.96425 104.7678 156.96425C104.4341 156.96425 104.13 156.89956 103.861 156.76018C103.5919 156.6305 103.3628 156.44112 103.1685 156.20206C102.9741 155.963 102.8297 155.67893 102.725 155.35518C102.6203 155.03112 102.5706 154.67768 102.5706 154.29893C102.5706 153.8805 102.6156 153.50675 102.7053 153.183C102.7997 152.85893 102.9294 152.585184 103.0938 152.365809C103.2631 152.141746 103.4625 151.972371 103.6966 151.857684C103.9306 151.742996 104.185 151.683309 104.4638 151.683309C104.8175 151.683309 105.1316 151.757996 105.3956 151.902371C105.6647 152.047059 105.9038 152.241121 106.1078 152.475496L106.2125 151.982059C106.2575 151.832684 106.3572 151.757996 106.5216 151.757996H107.2738V159.16143ZM109.3253 159.4455L108.5781 159.15643C108.4935 159.12643 108.4388 159.07675 108.4188 159.00206C108.3888 158.93237 108.4088 158.84768 108.4635 158.753C108.5831 158.55862 108.6578 158.36925 108.6878 158.17487C108.7225 157.98081 108.7275 157.80143 108.6978 157.63206C108.6778 157.46268 108.6328 157.308 108.5681 157.17362C108.5035 157.03893 108.4388 156.92956 108.3688 156.84487C108.3491 156.82487 108.3341 156.79987 108.3191 156.77487C108.3091 156.75018 108.3041 156.72018 108.2991 156.69018C108.2991 156.6655 108.3041 156.6355 108.3191 156.6105C108.3341 156.58081 108.3541 156.55581 108.3888 156.53581L108.7775 156.30175C109.0266 156.50612 109.226 156.73018 109.3753 156.98925C109.5197 157.23831 109.6194 157.50737 109.6644 157.78643C109.7091 158.0605 109.7041 158.34425 109.6494 158.62331C109.5944 158.91237 109.485 159.18143 109.3253 159.4455ZM110.9794 159.4455L110.2322 159.15643C110.1475 159.12643 110.0928 159.07675 110.0728 159.00206C110.0428 158.93237 110.0628 158.84768 110.1175 158.753C110.2372 158.55862 110.3119 158.36925 110.3419 158.17487C110.3766 157.98081 110.3816 157.80143 110.3519 157.63206C110.3319 157.46268 110.2869 157.308 110.2222 157.17362C110.1575 157.03893 110.0928 156.92956 110.0228 156.84487C110.0031 156.82487 109.9881 156.79987 109.9731 156.77487C109.9631 156.75018 109.9581 156.72018 109.9531 156.69018C109.9531 156.6655 109.9581 156.6355 109.9731 156.6105C109.9881 156.58081 110.0081 156.55581 110.0428 156.53581L110.4316 156.30175C110.6806 156.50612 110.88 156.73018 111.0294 156.98925C111.1738 157.23831 111.2735 157.50737 111.3185 157.78643C111.3631 158.0605 111.3581 158.34425 111.3035 158.62331C111.2485 158.91237 111.1391 159.18143 110.9794 159.4455Z'/>
+<path d='M120.20875 153.23268C120.15407 153.23268 120.09407 153.20768 120.03938 153.158C119.91469 153.04331 119.79532 152.94862 119.66563 152.86393C119.54625 152.78425 119.40657 152.719559 119.26719 152.664871C119.11782 152.609871 118.96313 152.575184 118.78875 152.545184C118.61938 152.525184 118.43 152.510184 118.21594 152.510184C117.86719 152.510184 117.54344 152.575184 117.24438 152.699559C116.94063 152.82425 116.68157 153.00862 116.45719 153.25268C116.23813 153.49175 116.06375 153.78581 115.93907 154.13456C115.80969 154.48331 115.74469 154.88175 115.74469 155.32518C115.74469 155.76362 115.80469 156.15737 115.92907 156.50612C116.05375 156.85487 116.22313 157.14862 116.44719 157.39268C116.66657 157.63706 116.93063 157.82112 117.23438 157.94581C117.53844 158.0755 117.87719 158.14018 118.24594 158.14018C118.54969 158.14018 118.80875 158.10518 119.01813 158.0455C119.22719 157.97581 119.40157 157.90581 119.54125 157.82612C119.68063 157.74643 119.79532 157.67675 119.88 157.60706C119.96469 157.54737 120.03938 157.51237 120.09907 157.51237C120.15407 157.51237 120.19375 157.52237 120.22375 157.54737C120.25844 157.56706 120.28344 157.59206 120.30344 157.62706L120.62219 158.0705C120.32844 158.34925 119.98469 158.56862 119.59594 158.733C119.2075 158.89737 118.75907 158.97706 118.25094 158.97706C117.7325 158.97706 117.25938 158.88737 116.83094 158.713C116.4025 158.53362 116.03375 158.28456 115.72969 157.96081C115.42094 157.63706 115.181878 157.25331 115.012503 156.80487S114.758441 155.86331 114.758441 155.32518C114.758441 154.78706 114.838128 154.29393 115.002503 153.8455C115.166878 153.39706 115.39594 153.01362 115.69 152.694559C115.98407 152.370809 116.3425 152.121746 116.76125 151.947371C117.17969 151.767996 117.64282 151.678309 118.15625 151.678309C118.74907 151.678309 119.25219 151.772996 119.66563 151.962371C120.08407 152.151434 120.43782 152.415496 120.73188 152.754559L120.34813 153.168C120.30844 153.21268 120.26344 153.23268 120.20875 153.23268ZM125.5038 157.78143L125.7378 158.23987C125.4888 158.47893 125.1997 158.66331 124.8759 158.78768C124.5472 158.91237 124.18344 158.97706 123.78469 158.97706C123.43094 158.97706 123.11219 158.92237 122.84313 158.81268C122.56407 158.703 122.335 158.55862 122.14563 158.37425C121.96125 158.18987 121.81688 157.98081 121.71719 157.74643C121.6225 157.51237 121.57282 157.26831 121.57282 157.01425C121.57282 156.70018 121.6225 156.43112 121.71719 156.22206C121.81688 156.00268 121.94625 155.82831 122.10594 155.68393C122.26532 155.53956 122.44969 155.42487 122.65375 155.33518C122.85813 155.2455 123.0675 155.16581 123.28157 155.09612C123.49594 155.03112 123.705 154.96643 123.90938 154.89675C124.11375 154.83706 124.2978 154.75737 124.4575 154.66268C124.6169 154.568 124.7463 154.45331 124.8459 154.31893C124.9406 154.17925 124.9906 153.99987 124.9906 153.78581C124.9906 153.59143 124.9556 153.41206 124.8909 153.25268C124.8259 153.09331 124.7266 152.95362 124.6069 152.84425C124.4772 152.724559 124.3278 152.639871 124.14844 152.575184C123.96907 152.510184 123.765 152.480496 123.53563 152.480496C123.35125 152.480496 123.18688 152.495496 123.0425 152.535184C122.89813 152.565184 122.76344 152.609871 122.65375 152.664871C122.53438 152.719559 122.43469 152.77425 122.345 152.83925C122.25532 152.90393 122.17563 152.95862 122.10594 153.01362C122.03594 153.06831 121.97625 153.113 121.91657 153.143C121.86657 153.183 121.81688 153.19768 121.77188 153.19768C121.72719 153.19768 121.68219 153.183 121.6475 153.163C121.6075 153.133 121.57282 153.10331 121.54782 153.06831L121.26875 152.609871C121.53782 152.325809 121.86157 152.096746 122.24032 151.927371C122.61907 151.762996 123.0425 151.678309 123.50594 151.678309C123.88438 151.678309 124.22313 151.737996 124.5172 151.852684C124.8163 151.967371 125.0653 152.126746 125.2744 152.330809C125.4738 152.535184 125.6331 152.77425 125.7378 153.04331C125.8425 153.32237 125.8972 153.61143 125.8972 153.92518C125.8972 154.21925 125.8475 154.46831 125.7528 154.67268C125.6531 154.87675 125.5234 155.04612 125.3641 155.18581C125.1997 155.32518 125.0153 155.43987 124.8163 155.53456C124.6069 155.62425 124.3975 155.70393 124.18844 155.77862C123.96907 155.85331 123.76 155.923 123.56063 155.99268C123.35125 156.05768 123.17188 156.13737 123.0125 156.23206C122.84813 156.32675 122.71875 156.43612 122.62407 156.57081C122.52438 156.70018 122.47438 156.86456 122.47438 157.06393C122.47438 157.21831 122.50438 157.368 122.55907 157.49737C122.61407 157.63706 122.69875 157.75143 122.81344 157.85112C122.92282 157.95081 123.0625 158.0305 123.22188 158.08518C123.39125 158.14518 123.58063 158.17487 123.79469 158.17487C124.02407 158.17487 124.21813 158.14518 124.3778 158.09018C124.5422 158.0355 124.6766 157.97081 124.7963 157.90581C124.9059 157.83612 125.0053 157.77143 125.0803 157.71675C125.155 157.66175 125.2247 157.63206 125.2794 157.63206C125.3294 157.63206 125.3741 157.64675 125.4041 157.66675C125.4438 157.69675 125.4738 157.73143 125.5038 157.78143ZM129.2344 155.43987H128.2181V158.13518H129.2741C129.8322 158.13518 130.2506 158.0255 130.5297 157.81143C130.8088 157.59706 130.9481 157.27331 130.9481 156.84987C130.9481 156.6405 130.9134 156.45112 130.8384 156.27675C130.7638 156.10237 130.6591 155.953 130.5097 155.83331C130.3703 155.70393 130.1909 155.60925 129.9716 155.54456C129.7625 155.47456 129.5134 155.43987 129.2344 155.43987ZM132.5325 151.757996L130.45 154.59268C130.3603 154.72737 130.2556 154.82706 130.1313 154.89675C130.405 154.96143 130.6544 155.05112 130.8684 155.17581C131.0878 155.30018 131.2719 155.44487 131.4266 155.62425C131.5759 155.79362 131.6906 155.99268 131.7703 156.21206C131.85 156.43112 131.8897 156.6655 131.8897 156.91956C131.8897 157.22331 131.84 157.49737 131.7353 157.73643C131.6306 157.98581 131.4763 158.18987 131.2572 158.36425C131.0478 158.53862 130.7738 158.66831 130.445 158.763C130.1163 158.85268 129.7275 158.89737 129.2741 158.89737H127.2566V151.757996H128.2181V154.73737H128.9503C129.085 154.73737 129.1844 154.71737 129.2544 154.68737C129.3141 154.64768 129.3788 154.59268 129.4338 154.513L131.2869 151.962371C131.3716 151.827684 131.5013 151.757996 131.6756 151.757996H132.5325Z'/>
+<path d='M7.99616 152.012974V159.21704H6.651161V152.012974H7.99616ZM13.44132 157.90672L13.77507 158.53954C13.521 158.7786 13.21694 158.96297 12.85819 159.09766C12.49975 159.23204 12.106 159.29672 11.68257 159.29672C11.30382 159.29672 10.97007 159.23704 10.67632 159.12235C10.38225 159.00797 10.13819 158.8536 9.93882 158.65922C9.73944 158.46485 9.59007 158.24547 9.48038 157.99641C9.38069 157.74735 9.326 157.49329 9.326 157.22922C9.326 156.90047 9.37069 156.62641 9.47038 156.39735C9.56007 156.17797 9.68975 155.9886 9.84413 155.83922C9.9985 155.68985 10.17788 155.57016 10.37725 155.47547C10.57663 155.38079 10.78069 155.3011 10.98507 155.23641C11.18944 155.17172 11.3935 155.10704 11.59288 155.05204C11.79225 154.99735 11.97163 154.92766 12.126 154.84297C12.28038 154.76297 12.41007 154.6636 12.49975 154.54391C12.59913 154.42422 12.64413 154.26985 12.64413 154.08047C12.64413 153.74172 12.53944 153.48266 12.33038 153.29829C12.121 153.11891 11.82694 153.02922 11.4435 153.02922C11.19444 153.02922 10.98007 153.06422 10.80569 153.12891C10.62632 153.1986 10.47194 153.2736 10.33725 153.35829C10.20288 153.44297 10.08819 153.51766 9.9935 153.58735C9.89882 153.65204 9.80913 153.68704 9.72444 153.68704C9.66475 153.68704 9.61007 153.67204 9.55507 153.63704C9.50038 153.60735 9.46038 153.56735 9.42569 153.52266L9.03194 152.879849C9.17163 152.735474 9.331 152.605787 9.51038 152.491412C9.68975 152.376724 9.87913 152.277037 10.08819 152.192349C10.28757 152.107662 10.50194 152.042974 10.726 152.002974C10.95007 151.953287 11.17444 151.933287 11.4035 151.933287C11.80225 151.933287 12.156 151.992974 12.46475 152.112662C12.7735 152.237037 13.03757 152.401724 13.24694 152.610787C13.466 152.825162 13.62569 153.06922 13.73507 153.35829C13.84975 153.63704 13.90444 153.9461 13.90444 154.26985C13.90444 154.56891 13.85475 154.82297 13.76507 155.03204C13.66538 155.24141 13.541 155.42079 13.38632 155.56016C13.23194 155.70985 13.05257 155.82922 12.8535 155.91891C12.65413 156.0186 12.44975 156.09829 12.24069 156.16797C12.03132 156.24266 11.82694 156.30766 11.62788 156.37235C11.4285 156.43704 11.24913 156.50672 11.09475 156.58672C10.94007 156.66641 10.81569 156.7611 10.716 156.87547C10.62632 156.99016 10.57663 157.12954 10.57663 157.29891C10.57663 157.4336 10.60132 157.55297 10.64632 157.66266C10.691 157.77735 10.76569 157.87204 10.85538 157.95172C10.95507 158.03141 11.06975 158.0911 11.20913 158.1411C11.34882 158.18079 11.51319 158.20579 11.69757 158.20579C11.90163 158.20579 12.081 158.18079 12.23069 158.1311C12.38507 158.0761 12.51444 158.02141 12.62913 157.95672C12.74382 157.89204 12.8385 157.83704 12.91819 157.78235C13.00288 157.73235 13.07757 157.70766 13.14725 157.70766C13.21194 157.70766 13.26694 157.72235 13.31663 157.75235C13.35663 157.78735 13.40132 157.83704 13.44132 157.90672Z'/>
+<path d='M18.7221 154.73329H16.4302L17.3021 157.11954C17.3471 157.22922 17.3918 157.35891 17.4368 157.50329C17.4815 157.65266 17.5265 157.81204 17.5712 157.98172C17.6162 157.81204 17.6658 157.65266 17.7108 157.50829C17.7555 157.36391 17.8005 157.23422 17.8452 157.12954L18.7221 154.73329ZM21.0887 152.012974L18.2587 159.21704H16.8937L14.05897 152.012974H15.10522C15.2196 152.012974 15.31429 152.042974 15.38897 152.107662C15.46397 152.172349 15.51866 152.242037 15.54366 152.317037L16.0815 153.78672H19.0658L19.604 152.317037C19.639 152.232037 19.6937 152.157349 19.7683 152.102662C19.843 152.042974 19.9377 152.012974 20.0524 152.012974H21.0887Z'/>
+<path d='M13.445313 166.223V306.14061' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='.3985,1.99255'/>
+<path d='M11.05469 304.26986C12.488282 304.64877 13.167969 305.49252 13.445313 306.340176C13.722657 305.49252 14.402344 304.64877 15.83594 304.26986' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-linecap='round' stroke-linejoin='round'/>
+<path d='M3.59327 211.11381V209.90318H6.38234V206.8585H3.59327V205.647871H10.077023V206.8585H7.24327V209.90318H10.077023V211.11381H3.59327Z'/>
+<path d='M8.11296 214.69287H8.8889C9.05484 214.536 9.180148 214.37006 9.261085 214.20881C9.346085 214.0385 9.386398 213.84568 9.386398 213.61693C9.386398 213.43287 9.346085 213.28068 9.261085 213.1685C9.175773 213.05193 9.03671 212.9935 8.8439 212.9935C8.74515 212.9935 8.65577 213.02037 8.57046 213.07881C8.48515 213.13693 8.41359 213.23131 8.35077 213.36131C8.28796 213.49131 8.23859 213.66631 8.1939 213.886C8.15796 214.10568 8.1264 214.37475 8.11296 214.69287ZM6.11765 212.15506L6.47202 212.35225C6.52577 212.38381 6.57046 212.4285 6.61546 212.48256C6.6514 212.53631 6.67359 212.6035 6.67359 212.67975C6.67359 212.76943 6.6514 212.85006 6.61109 212.92631C6.57046 212.99818 6.5214 213.07881 6.47202 213.1685C6.41827 213.25818 6.3689 213.36131 6.32859 213.48225C6.28796 213.59881 6.26577 213.74693 6.26577 213.92631C6.26577 214.17287 6.33733 214.36568 6.48984 214.49568C6.63327 214.62568 6.86202 214.69287 7.1714 214.69287H7.44046C7.44952 214.34318 7.4764 214.03381 7.52109 213.76037C7.5614 213.48693 7.61983 213.24912 7.68702 213.04287C7.75421 212.841 7.83515 212.66631 7.92921 212.52725C8.02327 212.38818 8.12202 212.27162 8.22515 212.18193C8.32827 212.09693 8.44046 212.03412 8.55234 211.99381C8.66921 211.95318 8.78577 211.93537 8.90234 211.93537C9.108585 211.93537 9.28796 211.96693 9.444835 212.03412S9.73171 212.191 9.834835 212.31193C9.93796 212.43318 10.018585 212.57225 10.06796 212.73787C10.12171 212.90381 10.148898 213.08318 10.148898 213.276C10.148898 213.44193 10.13546 213.59006 10.103898 213.72443C10.077023 213.8635 10.03671 213.98912 9.98296 214.11006C9.928898 214.23131 9.86171 214.34318 9.781085 214.45537C9.704835 214.56756 9.610773 214.67943 9.507648 214.796L9.839523 214.89475C9.933585 214.9263 9.996398 214.971 10.032335 215.0294C10.05921 215.0876 10.077023 215.1682 10.077023 215.2713V215.7735H7.1714C6.9114 215.7735 6.67359 215.7332 6.4539 215.6616C6.23421 215.5807 6.05046 215.4732 5.8889 215.3254C5.73671 215.1772 5.61109 214.9979 5.5214 214.78725C5.43609 214.57631 5.3914 214.33443 5.3914 214.06537C5.3914 213.321 5.63359 212.68412 6.11765 212.15506ZM6.27452 217.8579L5.75452 217.7908C5.6514 217.777 5.57515 217.7458 5.53921 217.7011C5.49452 217.6561 5.4764 217.5754 5.4764 217.4633V216.8133H10.077023V217.9208H7.24327C7.12202 217.9698 7.01015 218.0239 6.91577 218.0867C6.82171 218.1404 6.74109 218.212 6.66921 218.2839C6.6064 218.3645 6.55265 218.4498 6.51671 218.5439C6.48077 218.6379 6.46296 218.7501 6.46296 218.8714C6.46296 218.9564 6.47202 219.0417 6.48546 219.1267C6.4989 219.2164 6.50796 219.2839 6.50796 219.3286C6.50796 219.3779 6.4989 219.4139 6.47202 219.4408C6.4539 219.472 6.41359 219.4945 6.35984 219.5079L5.53046 219.5798C5.43609 219.4495 5.3914 219.2792 5.3914 219.0686C5.3914 218.7995 5.46765 218.5664 5.6289 218.3689C5.7814 218.1717 6.00109 218.0014 6.27452 217.8579Z'/>
+<path d='M6.6514 222.9154H8.7139C8.8889 222.772 9.02765 222.6195 9.122023 222.4579C9.216085 222.2967 9.26546 222.0995 9.26546 221.8708C9.26546 221.7273 9.238585 221.5973 9.18921 221.4804C9.13546 221.3639 9.05015 221.2654 8.92921 221.1845C8.81265 221.1039 8.66015 221.0411 8.47171 220.9964C8.28796 220.9561 8.05921 220.9336 7.79015 220.9336C7.52577 220.9336 7.29265 220.9604 7.09984 221.0098C6.90234 221.0592 6.74109 221.1354 6.61546 221.2295C6.48546 221.3236 6.39109 221.4401 6.32859 221.5748C6.26577 221.7092 6.23421 221.8617 6.23421 222.0276C6.23421 222.1979 6.26577 222.3595 6.32859 222.5029C6.39109 222.6554 6.4989 222.7898 6.6514 222.9154ZM3.4139 224.0229V222.9154H5.83984C5.70077 222.772 5.59296 222.6104 5.51234 222.4267C5.43171 222.2429 5.3914 222.0233 5.3914 221.7676C5.3914 221.467 5.44952 221.1936 5.57515 220.9514C5.69171 220.7095 5.86202 220.5029 6.07733 220.3283C6.29265 220.1533 6.54827 220.0233 6.83952 219.9292C7.13109 219.8351 7.44952 219.7901 7.79015 219.7901C8.16702 219.7901 8.50327 219.8304 8.79452 219.9111C9.086085 219.9964 9.332648 220.1129 9.529835 220.2611C9.73171 220.4133 9.88421 220.5926 9.987335 220.8036C10.09046 221.0142 10.14421 221.2429 10.14421 221.4942C10.14421 221.8123 10.077023 222.0948 9.947023 222.3326C9.817023 222.5748 9.642023 222.7898 9.431398 222.9739L9.875148 223.0679C10.009835 223.1083 10.077023 223.1979 10.077023 223.3458V224.0229H3.4139ZM5.4764 231.6851V230.8422C5.4764 230.766 5.49452 230.7032 5.53484 230.6494C5.57515 230.5954 5.62452 230.5597 5.68265 230.5372L8.13984 229.8601C8.4089 229.7885 8.66921 229.7347 8.92452 229.6941C8.79452 229.6629 8.66921 229.6269 8.53452 229.591C8.4089 229.5597 8.27452 229.5238 8.13984 229.4835L5.6739 228.7438C5.61546 228.7257 5.56609 228.6897 5.52577 228.6316C5.48546 228.5779 5.46765 228.5104 5.46765 228.4341V227.9454C5.46765 227.8694 5.48546 227.8066 5.52577 227.7526C5.56609 227.7035 5.61546 227.6676 5.6739 227.6494L8.13984 226.8872C8.27452 226.8469 8.40452 226.8066 8.53452 226.7663C8.66452 226.7304 8.79015 226.6944 8.92015 226.6632C8.79015 226.6451 8.66452 226.6229 8.53452 226.596C8.40452 226.5735 8.27452 226.5419 8.13984 226.5107L5.68265 225.8516C5.62452 225.8335 5.57515 225.7979 5.53484 225.7394C5.49452 225.681 5.4764 225.6138 5.4764 225.5332V224.6497L10.077023 226.1072V226.9591C10.077023 227.0801 10.009835 227.1607 9.879835 227.1966L7.22984 228.0351C7.14015 228.0622 7.05046 228.0844 6.95609 228.1113C6.8664 228.1294 6.77671 228.1516 6.68702 228.1697C6.77671 228.1832 6.8664 228.201 6.95609 228.2279C7.0414 228.246 7.13109 228.2729 7.22077 228.2997L9.879835 229.1247C10.009835 229.1651 10.077023 229.2322 10.077023 229.3357V230.2235L5.4764 231.6851Z'/>
+<path d='M8.11296 234.6854H8.8889C9.05484 234.5286 9.180148 234.3626 9.261085 234.2014C9.346085 234.0311 9.386398 233.8383 9.386398 233.6095C9.386398 233.4254 9.346085 233.2733 9.261085 233.1611C9.175773 233.0445 9.03671 232.9861 8.8439 232.9861C8.74515 232.9861 8.65577 233.0129 8.57046 233.0714C8.48515 233.1295 8.41359 233.2239 8.35077 233.3539C8.28796 233.4839 8.23859 233.6589 8.1939 233.8786C8.15796 234.0983 8.1264 234.3673 8.11296 234.6854ZM6.11765 232.1476L6.47202 232.3448C6.52577 232.3764 6.57046 232.4211 6.61546 232.4751C6.6514 232.5289 6.67359 232.5961 6.67359 232.6723C6.67359 232.762 6.6514 232.8426 6.61109 232.9189C6.57046 232.9908 6.5214 233.0714 6.47202 233.1611C6.41827 233.2508 6.3689 233.3539 6.32859 233.4748C6.28796 233.5914 6.26577 233.7395 6.26577 233.9189C6.26577 234.1654 6.33733 234.3583 6.48984 234.4883C6.63327 234.6183 6.86202 234.6854 7.1714 234.6854H7.44046C7.44952 234.3358 7.4764 234.0264 7.52109 233.7529C7.5614 233.4795 7.61983 233.2417 7.68702 233.0354C7.75421 232.8336 7.83515 232.6589 7.92921 232.5198C8.02327 232.3808 8.12202 232.2642 8.22515 232.1745C8.32827 232.0895 8.44046 232.0267 8.55234 231.9864C8.66921 231.9458 8.78577 231.9279 8.90234 231.9279C9.108585 231.9279 9.28796 231.9595 9.444835 232.0267S9.73171 232.1836 9.834835 232.3045C9.93796 232.4258 10.018585 232.5648 10.06796 232.7304C10.12171 232.8964 10.148898 233.0758 10.148898 233.2686C10.148898 233.4345 10.13546 233.5826 10.103898 233.717C10.077023 233.8561 10.03671 233.9817 9.98296 234.1026C9.928898 234.2239 9.86171 234.3358 9.781085 234.4479C9.704835 234.5601 9.610773 234.672 9.507648 234.7886L9.839523 234.8873C9.933585 234.9189 9.996398 234.9636 10.032335 235.022C10.05921 235.0801 10.077023 235.1608 10.077023 235.2639V235.7661H7.1714C6.9114 235.7661 6.67359 235.7258 6.4539 235.6542C6.23421 235.5733 6.05046 235.4658 5.8889 235.3179C5.73671 235.1698 5.61109 234.9904 5.5214 234.7798C5.43609 234.5689 5.3914 234.327 5.3914 234.0579C5.3914 233.3136 5.63359 232.6767 6.11765 232.1476ZM6.27452 237.8505L5.75452 237.7833C5.6514 237.7696 5.57515 237.7383 5.53921 237.6937C5.49452 237.6487 5.4764 237.568 5.4764 237.4558V236.8058H10.077023V237.9133H7.24327C7.12202 237.9624 7.01015 238.0165 6.91577 238.0793C6.82171 238.133 6.74109 238.2046 6.66921 238.2765C6.6064 238.3571 6.55265 238.4424 6.51671 238.5365C6.48077 238.6305 6.46296 238.7427 6.46296 238.864C6.46296 238.949 6.47202 239.0343 6.48546 239.1193C6.4989 239.209 6.50796 239.2765 6.50796 239.3212C6.50796 239.3705 6.4989 239.4065 6.47202 239.4333C6.4539 239.4646 6.41359 239.4871 6.35984 239.5005L5.53046 239.5724C5.43609 239.4421 5.3914 239.2718 5.3914 239.0612C5.3914 238.7921 5.46765 238.559 5.6289 238.3615C5.7814 238.1643 6.00109 237.994 6.27452 237.8505Z'/>
+<path d='M7.24765 242.9753V240.8856C6.9114 240.935 6.65577 241.0515 6.47202 241.24C6.28796 241.4194 6.19827 241.675 6.19827 241.9934C6.19827 242.159 6.22546 242.3028 6.28359 242.4237C6.33733 242.5494 6.41359 242.6525 6.50796 242.7331C6.60202 242.8137 6.71421 242.8722 6.83952 242.9169C6.96952 242.9528 7.10421 242.9753 7.24765 242.9753ZM7.91577 240.8634V243.7106C7.91577 243.8137 7.8889 243.8809 7.82609 243.9169C7.77234 243.9528 7.65577 243.9706 7.48984 243.9706C7.15796 243.9706 6.86202 243.9212 6.6064 243.8228C6.3464 243.7197 6.12671 243.5806 5.95171 243.4056C5.77233 243.2309 5.63796 243.02 5.5439 242.7734C5.44952 242.5269 5.40484 242.2622 5.40484 241.9709C5.40484 241.6256 5.46296 241.3206 5.58421 241.0428C5.70515 240.7737 5.86671 240.5406 6.06827 240.3522C6.27452 240.1594 6.51671 240.0159 6.79484 239.9128C7.06827 239.8097 7.36421 239.7603 7.67827 239.7603C8.08171 239.7603 8.43577 239.8187 8.74077 239.9353C9.05015 240.0519 9.305773 240.2131 9.512023 240.415C9.722648 240.6169 9.879835 240.8587 9.987335 241.1325C10.09046 241.4059 10.14421 241.7062 10.14421 242.0247C10.14421 242.1862 10.130773 242.3519 10.108273 242.5225C10.086085 242.6972 10.041085 242.8631 9.987335 243.0334C9.924523 243.195 9.848273 243.3565 9.75421 243.5087C9.65546 243.6612 9.534523 243.8003 9.391085 243.9212L8.98734 243.6031C8.92015 243.5581 8.88421 243.4909 8.88421 243.3969C8.88421 243.3294 8.90671 243.2578 8.94702 243.1859C8.98734 243.1097 9.03671 243.0247 9.086085 242.9259C9.13546 242.8319 9.184835 242.7197 9.225148 242.5853C9.26546 242.4597 9.28796 242.3028 9.28796 242.1234S9.261085 241.7781 9.207023 241.6347C9.148898 241.4822 9.06359 241.3565 8.95609 241.249C8.83952 241.1412 8.70046 241.0562 8.52546 240.989C8.35515 240.9215 8.15327 240.8812 7.91577 240.8634ZM9.467335 244.7277C9.561398 244.7277 9.651085 244.7455 9.736398 244.7815C9.817023 244.813 9.888585 244.8621 9.947023 244.9205C10.005148 244.9787 10.054523 245.0505 10.086085 245.1358C10.12171 245.2208 10.139835 245.3105 10.139835 245.4049C10.139835 245.499 10.12171 245.5887 10.086085 245.6693C10.054523 245.7546 10.005148 245.8262 9.947023 245.8846C9.888585 245.9474 9.817023 245.9968 9.736398 246.0324C9.651085 246.0683 9.561398 246.0865 9.467335 246.0865C9.37296 246.0865 9.28796 246.0683 9.202648 246.0324C9.117335 245.9968 9.04577 245.9474 8.98734 245.8846C8.92921 245.8262 8.87984 245.7546 8.8439 245.6693C8.80796 245.5887 8.79015 245.499 8.79015 245.4049C8.79015 245.3105 8.80796 245.2208 8.8439 245.1358C8.87984 245.0505 8.92921 244.9787 8.98734 244.9205C9.04577 244.8621 9.117335 244.813 9.202648 244.7815C9.28796 244.7455 9.37296 244.7277 9.467335 244.7277ZM6.27015 244.7277C6.36421 244.7277 6.4539 244.7455 6.53484 244.7815C6.61983 244.813 6.69171 244.8621 6.74984 244.9205C6.80827 244.9787 6.85765 245.0505 6.89359 245.1358C6.92484 245.2208 6.94265 245.3105 6.94265 245.4049C6.94265 245.499 6.92484 245.5887 6.89359 245.6693C6.85765 245.7546 6.80827 245.8262 6.74984 245.8846C6.69171 245.9474 6.61983 245.9968 6.53484 246.0324C6.4539 246.0683 6.36421 246.0865 6.27015 246.0865S6.09077 246.0683 6.00577 246.0324C5.92046 245.9968 5.84858 245.9474 5.79046 245.8846C5.73202 245.8262 5.68265 245.7546 5.64702 245.6693C5.61109 245.5887 5.59296 245.499 5.59296 245.4049C5.59296 245.3105 5.61109 245.2208 5.64702 245.1358C5.68265 245.0505 5.73202 244.9787 5.79046 244.9205C5.84858 244.8621 5.92046 244.813 6.00577 244.7815C6.09077 244.7455 6.17609 244.7277 6.27015 244.7277Z'/>
+<path d='M16.29261 191.55528V194.37121L15.60667 194.45653V190.79778L22.031985 190.008401V193.67184L21.350423 193.75715V190.93653L19.1173 191.21028V193.47903L18.45823 193.56434V191.2909L16.29261 191.55528Z'/>
+<path d='M18.63761 195.66262L17.75417 195.73012C17.57511 195.73012 17.48542 195.64043 17.48542 195.46106V195.06637L22.031985 194.51949V195.31762L19.7273 195.57762C19.48073 195.66262 19.25199 195.76137 19.0548 195.87793C18.84855 195.99918 18.67792 196.12449 18.53449 196.26356C18.39105 196.40262 18.27886 196.54168 18.20261 196.69418C18.12636 196.83762 18.08605 196.98543 18.08605 197.12887C18.08605 197.36231 18.17136 197.52356 18.34605 197.60887C18.51667 197.69387 18.78105 197.71637 19.1398 197.67606L22.031985 197.33512V198.12887L19.1398 198.46981C18.86636 198.50106 18.62417 198.50106 18.40886 198.46981C18.19823 198.43824 18.01886 198.37543 17.87105 198.28137C17.72292 198.19168 17.61073 198.07512 17.53917 197.93168C17.45824 197.78356 17.42261 197.61762 17.42261 197.42481C17.42261 197.102 17.52573 196.78824 17.7273 196.48325C17.93355 196.17856 18.23855 195.90481 18.63761 195.66262Z'/>
+<path d='M21.175423 199.5741C21.476048 199.5788 21.709173 199.6685 21.866048 199.8297C22.022923 200.0004 22.10386 200.2244 22.10386 200.516C22.10386 200.7041 22.067923 200.8925 21.996047 201.0763C21.919798 201.2647 21.82136 201.4307 21.69136 201.5785L21.31011 201.4082C21.283235 201.3947 21.26511 201.3813 21.251673 201.3722C21.238235 201.3544 21.23386 201.3363 21.23386 201.3094C21.23386 201.2872 21.242923 201.2647 21.269798 201.2332C21.28761 201.2019 21.314485 201.166 21.34136 201.1213C21.368235 201.0763 21.395423 201.0225 21.413235 200.9688C21.44011 200.906 21.449173 200.8388 21.449173 200.7579C21.449173 200.6369 21.413235 200.5429 21.34136 200.471C21.26511 200.3994 21.153235 200.3635 21.00074 200.3635C20.99167 200.3635 20.97824 200.3635 20.96042 200.3679C20.9423 200.3679 20.91105 200.3679 20.86605 200.3769C20.82136 200.3769 20.76292 200.386 20.68667 200.3947C20.61073 200.4038 20.51198 200.4172 20.39074 200.4307L18.15792 200.7041V201.9013L17.57948 201.9688V200.776L16.01448 200.9688V200.5516C16.01448 200.5025 16.02792 200.4666 16.05948 200.4307C16.08636 200.4038 16.1223 200.3769 16.16698 200.3635L17.57042 200.0225L17.6648 199.32317L17.98292 199.28723C18.04136 199.28285 18.08605 199.2916 18.11292 199.31879C18.14448 199.34098 18.15792 199.37692 18.15792 199.41723V199.9241L20.43136 199.646C20.57011 199.6282 20.68667 199.6147 20.77198 199.6057C20.8573 199.5922 20.92886 199.5875 20.98261 199.5788C21.036673 199.5788 21.076985 199.5741 21.108235 199.5741H21.175423ZM18.75417 203.5329L17.75417 203.6092C17.57511 203.6092 17.48542 203.5195 17.48542 203.3357V202.9411L22.031985 202.3942V203.1742L19.92917 203.4254C19.22511 203.6092 18.74073 203.8514 18.47167 204.1473C18.20261 204.4476 18.14448 204.7886 18.30136 205.1786L17.53449 205.322C17.46292 205.1561 17.44042 204.9901 17.45824 204.8289C17.48542 204.6673 17.54792 204.5104 17.65573 204.3579C17.75886 204.2054 17.90667 204.0576 18.09511 203.9229C18.27886 203.7795 18.49855 203.6542 18.75417 203.5329Z'/>
+<path d='M21.47136 207.0541C21.47136 206.74 21.36386 206.5025 21.153235 206.3366C20.93792 206.1707 20.61949 206.09 20.20261 206.09C19.92011 206.09 19.64667 206.126 19.38636 206.1932C19.12636 206.2604 18.89761 206.3591 18.70042 206.4847C18.50324 206.61 18.34605 206.7625 18.22948 206.9419C18.10855 207.1169 18.05011 207.3185 18.05011 207.5385C18.05011 207.8479 18.15792 208.0897 18.36417 208.2513C18.57949 208.4216 18.89324 208.5022 19.31011 208.5022C19.59261 208.5022 19.86636 208.4666 20.12636 208.3991C20.38636 208.3319 20.61511 208.2335 20.8123 208.1079C21.01417 207.9779 21.171048 207.8254 21.291985 207.6504C21.413235 207.471 21.47136 207.2738 21.47136 207.0541ZM22.094797 206.9779C22.094797 207.305 22.022923 207.61 21.870423 207.8925C21.726985 208.175 21.525423 208.4216 21.269798 208.6279C21.01417 208.8388 20.71824 209 20.38199 209.1213C20.04574 209.2422 19.68698 209.3007 19.30574 209.3007C19.0098 209.3007 18.74542 209.26 18.51198 209.175C18.27886 209.0897 18.08167 208.9732 17.92011 208.8254C17.75886 208.6772 17.63761 208.4979 17.54792 208.2916C17.4673 208.0854 17.42261 207.8566 17.42261 207.61C17.42261 207.2829 17.49417 206.9779 17.6423 206.6997C17.79011 206.4129 17.98761 206.1707 18.23855 205.96C18.49417 205.7491 18.79011 205.5879 19.12636 205.4669C19.46261 205.3457 19.82605 205.2875 20.20699 205.2875C20.5073 205.2875 20.77198 205.3279 21.00511 205.4129C21.238235 205.4982 21.435735 205.6147 21.596985 205.7629C21.758548 205.9107 21.879485 206.09 21.969172 206.2963C22.049798 206.5025 22.094797 206.7313 22.094797 206.9779ZM21.036673 210.8376L19.84824 210.9857C19.58824 211.0707 19.35074 211.1739 19.13074 211.2904C18.91105 211.4117 18.72292 211.5373 18.56605 211.6761C18.40886 211.8107 18.28355 211.9498 18.19386 212.0976C18.10855 212.2457 18.06386 212.3892 18.06386 212.5326C18.06386 212.7657 18.15792 212.9451 18.34167 213.0751S18.79917 213.2679 19.15324 213.2679C19.33261 213.2679 19.51198 213.2501 19.70042 213.2186C19.8798 213.1873 20.05917 213.1379 20.22949 213.0751C20.40417 213.017 20.56574 212.9407 20.71386 212.8511C20.86605 212.7614 21.00074 212.6582 21.108235 212.5461C21.224798 212.4339 21.31011 212.3086 21.377298 212.1695C21.444485 212.0304 21.476048 211.887 21.476048 211.7301C21.476048 211.5642 21.44011 211.4026 21.377298 211.2457C21.305735 211.0889 21.193548 210.9498 21.036673 210.8376ZM18.72292 211.0798L17.75417 211.1561C17.57511 211.1561 17.48542 211.0664 17.48542 210.887V210.4923L23.57011 209.7526V210.5282L21.587923 210.7704C21.749485 210.9004 21.87511 211.0529 21.96011 211.2367C22.049798 211.4207 22.094797 211.6223 22.094797 211.8467C22.094797 212.0573 22.054485 212.2545 21.973547 212.4473C21.892923 212.6401 21.780735 212.8151 21.637298 212.9767C21.498548 213.1423 21.33261 213.2904 21.13511 213.4248C20.94699 213.5551 20.73605 213.667 20.51636 213.7657C20.2923 213.8554 20.05917 213.9317 19.8123 213.9811C19.56574 214.0301 19.32355 214.0573 19.07699 214.0573C18.53449 214.0573 18.12636 213.9495 17.84386 213.7389C17.56136 213.5236 17.42261 213.2232 17.42261 212.8329C17.42261 212.667 17.45386 212.5014 17.5123 212.3398C17.57511 212.1829 17.6648 212.0261 17.77667 211.8779C17.88886 211.7301 18.02792 211.5864 18.1848 211.452C18.34605 211.3176 18.52542 211.192 18.72292 211.0798Z'/>
+<path d='M17.4898 218.754V218.1218C17.4898 218.0768 17.50324 218.0322 17.53011 217.9918C17.56136 217.9468 17.5973 217.9109 17.64667 217.8884L20.51198 216.4537C20.5748 216.4225 20.63761 216.3953 20.7048 216.3684C20.76761 216.3415 20.83042 216.3147 20.89292 216.2878C20.83042 216.2834 20.76761 216.2743 20.7048 216.2653C20.64198 216.2565 20.57917 216.2431 20.51636 216.2297L17.65573 215.4987C17.60636 215.4853 17.56605 215.4628 17.53917 215.4312C17.50324 215.4 17.4898 215.3553 17.4898 215.2878V214.6287L21.762923 215.8081L23.57011 214.8215V215.409C23.57011 215.4762 23.55667 215.53 23.52511 215.5703C23.49386 215.6153 23.44886 215.6556 23.38605 215.6868L17.4898 218.754Z'/>
+<path d='M16.60198 224.8575L16.24761 225.104C16.02792 224.9337 15.85761 224.7184 15.73199 224.454C15.60667 224.1893 15.54386 223.8934 15.54386 223.5662C15.54386 223.2434 15.59761 222.9518 15.7098 222.6918C15.82167 222.4362 15.9698 222.2165 16.15355 222.0372C16.3373 221.8578 16.55261 221.7187 16.7948 221.6247C17.03698 221.5303 17.28792 221.4812 17.55261 221.4812C17.79011 221.4812 17.98761 221.5168 18.14886 221.5887C18.31042 221.6606 18.4448 221.7546 18.55699 221.8712C18.66917 221.9878 18.75886 222.1222 18.83042 222.2703C18.9023 222.4181 18.96511 222.5706 19.02324 222.7278C19.08167 222.8847 19.13542 223.0372 19.18917 223.185C19.24761 223.3331 19.31011 223.4675 19.38636 223.584C19.46261 223.7006 19.5523 223.795 19.66449 223.8665C19.77198 223.9384 19.90667 223.974 20.07261 223.974C20.2698 223.974 20.44917 223.9428 20.61511 223.88C20.77636 223.8171 20.91542 223.7275 21.03199 223.6156C21.148548 223.4987 21.238235 223.3553 21.305735 223.194C21.372923 223.0237 21.404173 222.8397 21.404173 222.6334C21.404173 222.4093 21.368235 222.2209 21.305735 222.0731C21.23386 221.925 21.161985 221.7993 21.08136 221.6962C20.99605 221.5931 20.92011 221.5125 20.8573 221.4453C20.78542 221.3781 20.75417 221.3197 20.75417 221.2615C20.75417 221.2209 20.76292 221.1806 20.78542 221.145C20.80792 221.109 20.8348 221.0775 20.86605 221.0553L21.26511 220.7593C21.520735 220.9522 21.726985 221.2031 21.879485 221.499C22.02761 221.804 22.10386 222.1447 22.10386 222.5259C22.10386 222.8712 22.045423 223.185 21.924485 223.4631C21.803235 223.7409 21.641985 223.9787 21.44011 224.1715C21.238235 224.3687 21.00074 224.5212 20.73167 224.6243C20.45824 224.7275 20.17105 224.7812 19.86636 224.7812C19.64667 224.7812 19.45823 224.7453 19.30136 224.6737C19.14448 224.6018 19.01417 224.5078 18.9023 224.3912C18.79011 224.2747 18.70042 224.14 18.62417 223.9922C18.54792 223.8397 18.48073 223.6872 18.41792 223.5303C18.3598 223.3734 18.30136 223.2209 18.23855 223.0684C18.1848 222.9206 18.11292 222.7859 18.04136 222.6693C17.96074 222.5528 17.87105 222.4587 17.76324 222.3868C17.66011 222.315 17.53011 222.2793 17.37324 222.2793C17.21636 222.2793 17.06823 222.3062 16.92917 222.36C16.79042 222.4137 16.66917 222.4943 16.57042 222.5931C16.46292 222.7006 16.3823 222.8262 16.32386 222.9743C16.26574 223.1222 16.23417 223.2925 16.23417 223.4853C16.23417 223.6737 16.26105 223.8306 16.31042 223.9562C16.36417 224.0818 16.42261 224.1893 16.48074 224.279C16.54355 224.3643 16.60198 224.4359 16.65136 224.4943C16.70511 224.5525 16.73199 224.6065 16.73199 224.6556C16.73199 224.6962 16.72292 224.7318 16.69605 224.7634C16.67823 224.7947 16.6423 224.8262 16.60198 224.8575Z'/>
+<path d='M21.47136 227.2599C21.47136 226.9458 21.36386 226.7083 21.153235 226.5424C20.93792 226.3764 20.61949 226.2958 20.20261 226.2958C19.92011 226.2958 19.64667 226.3318 19.38636 226.3989C19.12636 226.4661 18.89761 226.5649 18.70042 226.6905C18.50324 226.8158 18.34605 226.9683 18.22948 227.1477C18.10855 227.3227 18.05011 227.5243 18.05011 227.7443C18.05011 228.0536 18.15792 228.2955 18.36417 228.4571C18.57949 228.6274 18.89324 228.708 19.31011 228.708C19.59261 228.708 19.86636 228.6724 20.12636 228.6049C20.38636 228.5377 20.61511 228.4393 20.8123 228.3136C21.01417 228.1836 21.171048 228.0311 21.291985 227.8561C21.413235 227.6768 21.47136 227.4796 21.47136 227.2599ZM22.094797 227.1836C22.094797 227.5108 22.022923 227.8158 21.870423 228.0983C21.726985 228.3808 21.525423 228.6274 21.269798 228.8336C21.01417 229.0446 20.71824 229.2058 20.38199 229.3271C20.04574 229.448 19.68698 229.5064 19.30574 229.5064C19.0098 229.5064 18.74542 229.4658 18.51198 229.3808C18.27886 229.2955 18.08167 229.1789 17.92011 229.0311C17.75886 228.883 17.63761 228.7036 17.54792 228.4974C17.4673 228.2911 17.42261 228.0624 17.42261 227.8158C17.42261 227.4886 17.49417 227.1836 17.6423 226.9055C17.79011 226.6186 17.98761 226.3764 18.23855 226.1658C18.49417 225.9549 18.79011 225.7936 19.12636 225.6727C19.46261 225.5514 19.82605 225.4933 20.20699 225.4933C20.5073 225.4933 20.77198 225.5336 21.00511 225.6186C21.238235 225.7039 21.435735 225.8205 21.596985 225.9686C21.758548 226.1164 21.879485 226.2958 21.969172 226.5021C22.049798 226.7083 22.094797 226.9371 22.094797 227.1836ZM17.4898 234.254V233.4603L19.84824 233.1778C20.08605 233.0928 20.30574 232.994 20.49855 232.8775C20.69574 232.7562 20.86167 232.6309 21.00074 232.4962C21.139798 232.3618 21.242923 232.2228 21.319173 232.0746C21.395423 231.9268 21.431048 231.7878 21.431048 231.6487C21.431048 231.4112 21.346048 231.2543 21.171048 231.1646C20.99605 231.0837 20.73167 231.0615 20.3773 231.1018L17.4898 231.4425V230.649L20.3773 230.3081C20.65105 230.2722 20.89761 230.2722 21.108235 230.3037C21.319173 230.335 21.498548 230.3978 21.64636 230.4918C21.794485 230.5815 21.90636 230.6981 21.978235 230.8462C22.05886 230.994 22.094797 231.16 22.094797 231.3528C22.094797 231.6712 21.996047 231.9806 21.79886 232.2765C21.596985 232.5815 21.305735 232.8506 20.91542 233.0881L21.74511 233.0209C21.937922 233.0209 22.031985 233.1197 22.031985 233.3125V233.7068L17.4898 234.254ZM18.75417 236.0332L17.75417 236.1095C17.57511 236.1095 17.48542 236.0198 17.48542 235.8361V235.4414L22.031985 234.8945V235.6745L19.92917 235.9257C19.22511 236.1095 18.74073 236.3517 18.47167 236.6476C18.20261 236.9479 18.14448 237.2889 18.30136 237.6789L17.53449 237.8223C17.46292 237.6564 17.44042 237.4904 17.45824 237.3292C17.48542 237.1676 17.54792 237.0107 17.65573 236.8582C17.75886 236.7057 17.90667 236.5579 18.09511 236.4232C18.27886 236.2798 18.49855 236.1545 18.75417 236.0332Z'/>
+<path d='M21.216048 241.2L20.97386 241.0028C20.92449 240.9578 20.89761 240.9084 20.89761 240.8503C20.89761 240.7875 20.92886 240.7247 20.9873 240.6618C21.045423 240.5947 21.112923 240.5184 21.18011 240.4243C21.251673 240.33 21.319173 240.2181 21.377298 240.079C21.435735 239.9447 21.466985 239.7787 21.466985 239.5768C21.466985 239.4153 21.44011 239.2718 21.377298 239.1553C21.323548 239.0297 21.238235 238.9312 21.13511 238.8459C21.02761 238.7609 20.89761 238.6981 20.74949 238.6575C20.59699 238.6172 20.42667 238.595 20.24292 238.595C19.93792 238.595 19.65105 238.6353 19.38636 238.7159C19.12199 238.7922 18.88886 238.8997 18.69605 239.0387C18.50324 239.1778 18.34605 239.3347 18.23855 239.5184C18.12199 239.7025 18.06824 239.8953 18.06824 240.1015C18.06824 240.254 18.08605 240.3793 18.12199 240.4737C18.1623 240.5722 18.20261 240.6531 18.24761 240.7203C18.29699 240.7875 18.3373 240.8412 18.37324 240.8772C18.41355 240.9221 18.43136 240.9625 18.43136 241.0028C18.43136 241.034 18.4223 241.0656 18.40886 241.0925C18.39542 241.1147 18.37324 241.1371 18.35074 241.1597L18.05011 241.4109C17.84855 241.2584 17.69167 241.079 17.58386 240.8772C17.48074 240.6753 17.42699 240.4197 17.42699 240.1193C17.42699 239.7831 17.50324 239.4693 17.66011 239.1822C17.81699 238.8997 18.02324 238.6531 18.28355 238.4468C18.54355 238.2406 18.84386 238.0793 19.18011 237.9625C19.51636 237.8506 19.87074 237.7922 20.23855 237.7922C20.51198 237.7922 20.76761 237.8281 20.99167 237.9C21.224798 237.9672 21.41761 238.0703 21.583548 238.2047C21.74511 238.3437 21.870423 238.5097 21.96011 238.7159C22.049798 238.9131 22.094797 239.1462 22.094797 239.4109C22.094797 239.5859 22.08136 239.7472 22.054485 239.8997C22.02761 240.0478 21.978235 240.1956 21.915423 240.3347C21.843548 240.4737 21.75386 240.6172 21.641985 240.7562C21.529798 240.895 21.38636 241.0431 21.216048 241.2Z'/>
+<path d='M18.00105 244.0904C18.00105 244.2114 18.01448 244.3101 18.05011 244.3954C18.0773 244.4804 18.11761 244.5479 18.16698 244.6017C18.21605 244.6511 18.26542 244.6914 18.32824 244.7139C18.38199 244.7361 18.44042 244.7495 18.49417 244.7495C18.60167 244.7495 18.7048 244.7273 18.80355 244.6779C18.9023 244.6286 18.99199 244.5298 19.08167 244.382C19.1623 244.2339 19.24292 244.0186 19.3148 243.7407C19.39105 243.4626 19.45386 243.0951 19.51198 242.6332C19.30136 242.6826 19.09949 242.7498 18.92011 242.8348C18.73167 242.9201 18.5748 243.0276 18.43574 243.1489C18.30136 243.2698 18.19386 243.4132 18.11761 243.5704C18.04136 243.7273 18.00105 243.902 18.00105 244.0904ZM21.193548 245.3548L20.94699 245.1576C20.89761 245.1129 20.87074 245.0636 20.87074 245.0051C20.87074 244.9557 20.88417 244.9111 20.91542 244.8617C20.94699 244.8123 20.98261 244.7629 21.02761 244.7092C21.067923 244.6511 21.117298 244.5926 21.171048 244.5211C21.220423 244.4582 21.269798 244.3773 21.314485 244.2876C21.354798 244.2026 21.390735 244.0995 21.422298 243.9917C21.453548 243.8751 21.466985 243.7498 21.466985 243.6061C21.466985 243.252 21.359485 242.9873 21.153235 242.817C20.93792 242.6376 20.63292 242.5526 20.23386 242.5526C20.20261 242.5526 20.16667 242.5526 20.1398 242.557C20.10386 242.557 20.07261 242.557 20.04105 242.557C19.98292 243.1489 19.90199 243.6332 19.80355 244.0098C19.7048 244.3864 19.58824 244.6823 19.45823 244.8976C19.32355 245.1129 19.17136 245.2607 19.0098 245.3414C18.83949 245.4223 18.66011 245.4626 18.46292 245.4626C18.35074 245.4626 18.23417 245.4357 18.11292 245.3817C17.99199 245.3326 17.8798 245.2517 17.77667 245.1442C17.67355 245.0367 17.59292 244.8976 17.52573 244.7317C17.45824 244.5657 17.42699 244.3639 17.42699 244.1354C17.42699 243.8932 17.46292 243.6689 17.53917 243.4539C17.61542 243.2476 17.71855 243.0501 17.84386 242.8798C17.97855 242.7004 18.13105 242.5479 18.31042 242.4136C18.4898 242.2745 18.68261 242.1623 18.89324 242.0639C19.10386 241.9742 19.32355 241.9023 19.55699 241.8486C19.78542 241.8036 20.01855 241.7767 20.25199 241.7767C20.53449 241.7767 20.78542 241.817 21.01417 241.8932C21.242923 241.9695 21.435735 242.0817 21.59261 242.2251C21.75386 242.3686 21.879485 242.5436 21.964797 242.7498C22.049798 242.9561 22.094797 243.1892 22.094797 243.4492C22.094797 243.642 22.076673 243.8214 22.041048 243.9829C22.009485 244.1532 21.955735 244.3101 21.879485 244.4582C21.803235 244.6107 21.709173 244.7586 21.601673 244.9067C21.484798 245.0545 21.350423 245.2026 21.193548 245.3548Z'/>
+<path d='M20.05449 248.9667C19.61074 248.9667 19.19823 248.9979 18.80355 249.0607C18.41792 249.1189 18.04136 249.2086 17.68261 249.3251C17.32386 249.442 16.97417 249.5854 16.63323 249.7557C16.29699 249.9261 15.95636 250.1236 15.61542 250.3432C15.53042 250.4014 15.46292 250.4195 15.41386 250.4014C15.36449 250.3836 15.32855 250.3567 15.29699 250.3164L15.08636 249.9979C15.57073 249.6482 16.02792 249.3611 16.45386 249.1414C16.88449 248.9217 17.30136 248.747 17.70511 248.6214C18.10855 248.4914 18.50761 248.4061 18.9023 248.3567C19.30136 248.3073 19.70917 248.2851 20.12636 248.2851C20.37292 248.2851 20.63292 248.2986 20.90199 248.3254C21.171048 248.3523 21.444485 248.3926 21.718235 248.4511C21.991672 248.5092 22.26511 248.5811 22.543235 248.6661C22.812298 248.7557 23.08136 248.8636 23.33667 248.9889L23.13042 249.3523C23.09917 249.4014 23.06324 249.4373 23.01386 249.4642C22.964485 249.4957 22.897298 249.4911 22.80761 249.4598C22.606048 249.3792 22.390735 249.3073 22.161985 249.2445S21.695735 249.1326 21.457923 249.0876C21.220423 249.0517 20.98261 249.0204 20.74073 248.9979C20.5073 248.9754 20.27417 248.9667 20.05449 248.9667ZM16.29261 252.2079V255.0239L15.60667 255.1092V251.4504L22.031985 250.6611V254.3245L21.350423 254.4098V251.5892L19.1173 251.8629V254.1317L18.45823 254.217V251.9436L16.29261 252.2079ZM16.60198 259.2021L16.24761 259.4487C16.02792 259.2784 15.85761 259.0631 15.73199 258.7987C15.60667 258.534 15.54386 258.2381 15.54386 257.9109C15.54386 257.5881 15.59761 257.2965 15.7098 257.0365C15.82167 256.7809 15.9698 256.5612 16.15355 256.3818C16.3373 256.2025 16.55261 256.0634 16.7948 255.9693C17.03698 255.875 17.28792 255.8259 17.55261 255.8259C17.79011 255.8259 17.98761 255.8615 18.14886 255.9334C18.31042 256.0053 18.4448 256.0993 18.55699 256.2159C18.66917 256.3325 18.75886 256.4668 18.83042 256.615C18.9023 256.7628 18.96511 256.9153 19.02324 257.0725C19.08167 257.2293 19.13542 257.3818 19.18917 257.5296C19.24761 257.6778 19.31011 257.8121 19.38636 257.9287S19.5523 258.1396 19.66449 258.2112C19.77198 258.2831 19.90667 258.3187 20.07261 258.3187C20.2698 258.3187 20.44917 258.2875 20.61511 258.2247C20.77636 258.1618 20.91542 258.0722 21.03199 257.9603C21.148548 257.8434 21.238235 257.7 21.305735 257.5387C21.372923 257.3684 21.404173 257.1843 21.404173 256.9781C21.404173 256.754 21.368235 256.5656 21.305735 256.4178C21.23386 256.2697 21.161985 256.144 21.08136 256.0409C20.99605 255.9378 20.92011 255.8572 20.8573 255.79C20.78542 255.7228 20.75417 255.6643 20.75417 255.6062C20.75417 255.5656 20.76292 255.5253 20.78542 255.4897C20.80792 255.4537 20.8348 255.4221 20.86605 255.4L21.26511 255.104C21.520735 255.2968 21.726985 255.5478 21.879485 255.8437C22.02761 256.1487 22.10386 256.4893 22.10386 256.8706C22.10386 257.2159 22.045423 257.5296 21.924485 257.8078C21.803235 258.0856 21.641985 258.3234 21.44011 258.5162C21.238235 258.7134 21.00074 258.8659 20.73167 258.969C20.45824 259.0722 20.17105 259.1259 19.86636 259.1259C19.64667 259.1259 19.45823 259.09 19.30136 259.0184C19.14448 258.9465 19.01417 258.8525 18.9023 258.7359C18.79011 258.6193 18.70042 258.4846 18.62417 258.3368C18.54792 258.1843 18.48073 258.0318 18.41792 257.875C18.3598 257.7181 18.30136 257.5656 18.23855 257.4131C18.1848 257.2653 18.11292 257.1306 18.04136 257.014C17.96074 256.8975 17.87105 256.8034 17.76324 256.7315C17.66011 256.6597 17.53011 256.624 17.37324 256.624C17.21636 256.624 17.06823 256.6509 16.92917 256.7047C16.79042 256.7584 16.66917 256.839 16.57042 256.9378C16.46292 257.0453 16.3823 257.1709 16.32386 257.319C16.26574 257.4668 16.23417 257.6372 16.23417 257.83C16.23417 258.0184 16.26105 258.1753 16.31042 258.3009C16.36417 258.4265 16.42261 258.534 16.48074 258.6237C16.54355 258.709 16.60198 258.7806 16.65136 258.839C16.70511 258.8971 16.73199 258.9512 16.73199 259.0003C16.73199 259.0409 16.72292 259.0765 16.69605 259.1081C16.67823 259.1393 16.6423 259.1709 16.60198 259.2021ZM18.36855 260.883C18.78574 260.883 19.18917 260.8514 19.5748 260.7933C19.9648 260.7305 20.34167 260.6408 20.7048 260.5243C21.072298 260.403 21.431048 260.2596 21.77636 260.0893C22.121672 259.9189 22.466985 259.7261 22.80761 259.5064C22.85261 259.4749 22.892923 259.4571 22.92886 259.448C22.96011 259.4389 22.991673 259.4389 23.018548 259.4436C23.04074 259.448 23.06324 259.4614 23.08136 259.4749C23.09917 259.4883 23.11699 259.5064 23.13042 259.5286L23.33667 259.8471C22.85261 260.1968 22.39511 260.4839 21.969172 260.7036S21.12636 261.098 20.72261 261.2236C20.31917 261.3493 19.92011 261.4346 19.52105 261.4836C19.12636 261.533 18.71823 261.5555 18.30136 261.5555C18.05011 261.5555 17.79011 261.5421 17.52105 261.5152S16.97855 261.448 16.70511 261.394C16.43167 261.3358 16.15792 261.2639 15.88449 261.1789C15.61105 261.0893 15.34636 260.9814 15.08636 260.8605L15.29699 260.4883C15.32855 260.4389 15.36449 260.403 15.41386 260.3761C15.46292 260.3493 15.53042 260.354 15.61542 260.3852C15.8173 260.4658 16.03261 260.5377 16.26105 260.5958C16.4898 260.6586 16.72761 260.7124 16.96511 260.7574C17.20292 260.7977 17.4448 260.8293 17.68261 260.8514C17.92011 260.8739 18.14886 260.883 18.36855 260.883Z'/>
+<path d='M13.445313 144.965V5.043' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='.3985,1.99255'/>
+<path d='M15.83594 6.91797C14.402344 6.53906 13.722657 5.695314 13.445313 4.843752C13.167969 5.695314 12.488282 6.53906 11.05469 6.91797' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-linecap='round' stroke-linejoin='round'/>
+<path d='M4.77061 70.3657L4.20092 70.66601C3.98592 70.43726 3.81998 70.16382 3.69873 69.84101C3.5778 69.5182 3.51936 69.16382 3.51936 68.78257C3.51936 68.44195 3.57342 68.14163 3.67655 67.87695C3.77967 67.61226 3.91842 67.39257 4.09342 67.2132C4.26842 67.034133 4.46561 66.899445 4.68967 66.800695C4.91405 66.711008 5.1428 66.661945 5.3803 66.661945C5.67623 66.661945 5.9228 66.702258 6.12905 66.791945C6.32655 66.87257 6.49686 66.989133 6.63123 67.128195C6.76592 67.26726 6.87342 67.42851 6.95873 67.60788C7.04373 67.78726 7.11561 67.97101 7.17373 68.15507C7.23217 68.33882 7.29061 68.52257 7.33967 68.70195C7.38905 68.88132 7.45186 69.04288 7.52811 69.18163C7.59998 69.3207 7.68967 69.43726 7.79717 69.5182C7.90467 69.60788 8.04373 69.6482 8.21405 69.6482C8.51905 69.6482 8.75217 69.55382 8.91811 69.3657C9.079672 69.17726 9.160297 68.91288 9.160297 68.56757C9.160297 68.3432 9.128734 68.15038 9.07061 67.99351C9.0078 67.83226 8.94061 67.6932 8.86436 67.57195C8.78811 67.45101 8.72092 67.34788 8.65811 67.26257C8.59967 67.17757 8.56842 67.096633 8.56842 67.020383C8.56842 66.966633 8.58186 66.917258 8.61311 66.868195C8.63998 66.81882 8.67592 66.782883 8.71623 66.751633L9.294672 66.397258C9.424672 66.522883 9.541547 66.66632 9.644672 66.82757C9.747797 66.989133 9.837484 67.159445 9.913422 67.34788C9.989672 67.52726 10.048109 67.72007 10.084047 67.92195C10.128734 68.12351 10.146859 68.32538 10.146859 68.53163C10.146859 68.89038 10.092797 69.20882 9.985297 69.48663C9.873109 69.76476 9.725297 70.00226 9.536859 70.1907C9.344047 70.38788 9.124359 70.53132 8.86436 70.63007C8.61311 70.7332 8.3353 70.78257 8.04373 70.78257C7.77467 70.78257 7.54592 70.73757 7.3578 70.65695C7.16936 70.56726 7.00811 70.45507 6.88248 70.31632C6.7478 70.17726 6.6403 70.0157 6.55967 69.83632C6.46998 69.65695 6.39811 69.4732 6.3353 69.28507C6.26811 69.09663 6.20998 68.91288 6.15155 68.73351C6.09311 68.55413 6.03061 68.39257 5.95873 68.25351C5.88686 68.11476 5.80186 68.00257 5.69873 67.91288C5.59561 67.83226 5.46998 67.78726 5.31748 67.78726C5.19655 67.78726 5.08873 67.80976 4.9903 67.85007C4.88717 67.89038 4.80186 67.95757 4.7303 68.03851C4.65842 68.1282 4.60467 68.23132 4.55967 68.35663C4.52373 68.48226 4.50155 68.63038 4.50155 68.79632C4.50155 68.98007 4.52373 69.14132 4.56873 69.27601C4.61811 69.41507 4.66748 69.53163 4.72561 69.63476C4.78405 69.73788 4.83342 69.82288 4.88248 69.89476C4.92748 69.97101 4.94998 70.0382 4.94998 70.10101C4.94998 70.15913 4.93655 70.20851 4.90936 70.25351C4.87811 70.28945 4.83342 70.32976 4.77061 70.3657Z'/>
+<path d='M5.4028 73.67382C5.4028 73.32851 5.45655 73.01913 5.56873 72.73663C5.68061 72.45413 5.8378 72.21632 6.03936 72.01476C6.24123 71.81726 6.49248 71.66507 6.78373 71.55726C7.0753 71.44538 7.40248 71.39132 7.76561 71.39132C8.12905 71.39132 8.46092 71.44538 8.75217 71.55726C9.04373 71.66507 9.294672 71.81726 9.500922 72.01476C9.707172 72.21632 9.864359 72.45413 9.976234 72.73663C10.088422 73.01913 10.142172 73.32851 10.142172 73.67382C10.142172 74.01445 10.088422 74.32382 9.976234 74.60632C9.864359 74.88445 9.707172 75.12195 9.500922 75.32382C9.294672 75.52101 9.04373 75.67351 8.75217 75.78132C8.46092 75.88882 8.12905 75.94257 7.76561 75.94257C7.40248 75.94257 7.0753 75.88882 6.78373 75.78132C6.49248 75.67351 6.24123 75.52101 6.03936 75.32382C5.8378 75.12195 5.68061 74.88445 5.56873 74.60632C5.45655 74.32382 5.4028 74.01445 5.4028 73.67382ZM9.290297 73.67382C9.290297 73.28351 9.160297 72.99663 8.9003 72.81288C8.64467 72.62445 8.26811 72.53038 7.77467 72.53038C7.28155 72.53038 6.90498 72.62445 6.6403 72.81288C6.3803 72.99663 6.2503 73.28351 6.2503 73.67382C6.2503 74.05476 6.3803 74.33726 6.6403 74.52569C6.9003 74.70507 7.27717 74.79913 7.77467 74.79913C8.27248 74.79913 8.64905 74.70507 8.90467 74.52569C9.160297 74.33726 9.290297 74.05476 9.290297 73.67382Z'/>
+<path d='M10.074984 77.0019V78.1094H6.30405V79.2706H5.51498V78.0734H5.20998C5.03967 78.0734 4.89592 78.0912 4.78405 78.1316C4.66748 78.1675 4.57311 78.2212 4.50592 78.2931C4.43436 78.365 4.38498 78.4547 4.35342 78.5531C4.32655 78.6609 4.31311 78.7775 4.31311 78.9075C4.31311 78.9569 4.30873 79.0059 4.30873 79.0509C4.29967 79.0956 4.29061 79.1362 4.28186 79.1719C4.26373 79.2034 4.24592 79.2303 4.21905 79.2528C4.19655 79.275 4.16061 79.2841 4.1203 79.2884L3.56436 79.3109C3.50592 79.1272 3.47905 78.9297 3.47905 78.7191C3.47905 78.4547 3.51936 78.2125 3.59561 78.0016C3.67186 77.7909 3.78405 77.6116 3.93186 77.4591C4.07998 77.3156 4.25498 77.1991 4.46561 77.1184C4.67623 77.0422 4.90936 77.0019 5.17405 77.0019H5.51498V76.3156H5.9678C6.04842 76.3156 6.11123 76.3425 6.15592 76.3919C6.19623 76.4456 6.2278 76.5175 6.24561 76.6028L6.30842 77.0019H10.074984ZM10.146859 81.4269C10.146859 81.651 10.110922 81.8663 10.043734 82.0769C9.976234 82.2879 9.873109 82.4716 9.738734 82.6329L9.200609 82.3013C9.169359 82.2788 9.142484 82.2563 9.124359 82.2338C9.110922 82.2116 9.101859 82.1848 9.101859 82.1532C9.101859 82.1263 9.110922 82.0994 9.124359 82.0726C9.142484 82.0457 9.160297 82.0141 9.178109 81.9829C9.196234 81.9469 9.214047 81.9066 9.231859 81.8573C9.245609 81.8126 9.254359 81.7541 9.254359 81.6869C9.254359 81.566 9.214047 81.4673 9.133422 81.4001C9.0528 81.3282 8.94061 81.2923 8.79717 81.2923H6.30405V82.521H5.51498V81.2923H4.06655V80.7185C4.06655 80.651 4.08436 80.5973 4.11592 80.5569C4.14717 80.5166 4.19655 80.4854 4.25498 80.4716L5.5103 80.2385L5.63155 79.4988H6.07092C6.14717 79.4988 6.2053 79.5213 6.24561 79.5616S6.30405 79.6557 6.30405 79.7141V80.1848H8.87342C9.272484 80.1848 9.581859 80.2926 9.805922 80.5032C10.034672 80.7185 10.146859 81.0279 10.146859 81.4269ZM5.47436 89.7977V88.9549C5.47436 88.8787 5.49248 88.8159 5.5328 88.7621C5.57311 88.708 5.62248 88.6724 5.68061 88.6499L8.1378 87.9727C8.40686 87.9012 8.66717 87.8474 8.92248 87.8068C8.79248 87.7755 8.66717 87.7396 8.53248 87.7037C8.40686 87.6724 8.27248 87.6365 8.1378 87.5962L5.67186 86.8565C5.61342 86.8384 5.56405 86.8024 5.52373 86.7443C5.48342 86.6905 5.46561 86.623 5.46561 86.5468V86.058C5.46561 85.9821 5.48342 85.9193 5.52373 85.8652C5.56405 85.8162 5.61342 85.7802 5.67186 85.7621L8.1378 84.9999C8.27248 84.9596 8.40248 84.9193 8.53248 84.879C8.66248 84.843 8.78811 84.8071 8.91811 84.7759C8.78811 84.7577 8.66248 84.7355 8.53248 84.7087C8.40248 84.6862 8.27248 84.6546 8.1378 84.6234L5.68061 83.9643C5.62248 83.9462 5.57311 83.9105 5.5328 83.8521C5.49248 83.7937 5.47436 83.7265 5.47436 83.6459V82.7624L10.074984 84.2199V85.0718C10.074984 85.1927 10.007797 85.2734 9.877797 85.3093L7.2278 86.1477C7.13811 86.1749 7.04842 86.1971 6.95405 86.224C6.86436 86.2421 6.77467 86.2643 6.68498 86.2824C6.77467 86.2959 6.86436 86.3137 6.95405 86.3405C7.03936 86.3587 7.12905 86.3855 7.21873 86.4124L9.877797 87.2374C10.007797 87.2777 10.074984 87.3449 10.074984 87.4484V88.3362L5.47436 89.7977Z'/>
+<path d='M8.11092 92.7846H8.88686C9.0528 92.6277 9.178109 92.4618 9.259047 92.3005C9.344047 92.1302 9.384359 91.9374 9.384359 91.7087C9.384359 91.5246 9.344047 91.3724 9.259047 91.2602C9.173734 91.1437 9.03467 91.0852 8.84186 91.0852C8.74311 91.0852 8.65373 91.1121 8.56842 91.1705C8.48311 91.2287 8.41155 91.323 8.34873 91.453C8.28592 91.583 8.23655 91.758 8.19186 91.9777C8.15592 92.1974 8.12436 92.4665 8.11092 92.7846ZM6.11561 90.2468L6.46998 90.444C6.52373 90.4755 6.56842 90.5202 6.61342 90.5743C6.64936 90.628 6.67155 90.6952 6.67155 90.7715C6.67155 90.8612 6.64936 90.9418 6.60905 91.018C6.56842 91.0899 6.51936 91.1705 6.46998 91.2602C6.41623 91.3499 6.36686 91.453 6.32655 91.574C6.28592 91.6905 6.26373 91.8387 6.26373 92.018C6.26373 92.2646 6.3353 92.4574 6.4878 92.5874C6.63123 92.7174 6.85998 92.7846 7.16936 92.7846H7.43842C7.44748 92.4349 7.47436 92.1255 7.51905 91.8521C7.55936 91.5787 7.6178 91.3409 7.68498 91.1346C7.75217 90.9327 7.83311 90.758 7.92717 90.619C8.02123 90.4799 8.11998 90.3634 8.22311 90.2737C8.32623 90.1887 8.43842 90.1259 8.5503 90.0855C8.66717 90.0449 8.78373 90.0271 8.9003 90.0271C9.106547 90.0271 9.285922 90.0587 9.442797 90.1259C9.599672 90.193 9.729672 90.2827 9.832797 90.4037C9.935922 90.5249 10.016547 90.664 10.065922 90.8296C10.119672 90.9955 10.146859 91.1749 10.146859 91.3677C10.146859 91.5337 10.133422 91.6818 10.101859 91.8162C10.074984 91.9552 10.034672 92.0809 9.980922 92.2018C9.926859 92.323 9.859672 92.4349 9.779047 92.5471C9.702797 92.6593 9.608734 92.7712 9.505609 92.8877L9.837484 92.9865C9.931547 93.018 9.994359 93.0627 10.030297 93.1212C10.057172 93.1793 10.074984 93.2599 10.074984 93.363V93.8652H7.16936C6.90936 93.8652 6.67155 93.8249 6.45186 93.7534C6.23217 93.6724 6.04842 93.5649 5.88686 93.4171C5.73467 93.269 5.60905 93.0896 5.51936 92.879C5.43405 92.668 5.38936 92.4262 5.38936 92.1571C5.38936 91.4127 5.63155 90.7759 6.11561 90.2468ZM6.27248 95.9497L5.75248 95.8825C5.64936 95.8687 5.57311 95.8375 5.53717 95.7928C5.49248 95.7478 5.47436 95.6672 5.47436 95.555V94.905H10.074984V96.0125H7.24123C7.11998 96.0616 7.00811 96.1156 6.91373 96.1784C6.81967 96.2322 6.73905 96.3037 6.66717 96.3756C6.60436 96.4562 6.55061 96.5416 6.51467 96.6356C6.47873 96.7297 6.46092 96.8419 6.46092 96.9631C6.46092 97.0481 6.46998 97.1334 6.48342 97.2184C6.49686 97.3081 6.50592 97.3756 6.50592 97.4203C6.50592 97.4697 6.49686 97.5056 6.46998 97.5325C6.45186 97.5637 6.41155 97.5862 6.3578 97.5997L5.52842 97.6716C5.43405 97.5412 5.38936 97.3709 5.38936 97.1603C5.38936 96.8912 5.46561 96.6581 5.62686 96.4606C5.77936 96.2634 5.99905 96.0931 6.27248 95.9497Z'/>
+<path d='M7.24561 101.0834V98.9937C6.90936 99.0431 6.65373 99.1597 6.46998 99.3481C6.28592 99.5275 6.19623 99.7831 6.19623 100.1016C6.19623 100.2672 6.22342 100.4109 6.28155 100.5319C6.3353 100.6575 6.41155 100.7606 6.50592 100.8412C6.59998 100.9219 6.71217 100.9803 6.83748 101.025C6.96748 101.0609 7.10217 101.0834 7.24561 101.0834ZM7.91373 98.9716V101.8187C7.91373 101.9219 7.88686 101.9891 7.82405 102.025C7.7703 102.0609 7.65373 102.0787 7.4878 102.0787C7.15592 102.0787 6.85998 102.0294 6.60436 101.9309C6.34436 101.8278 6.12467 101.6887 5.94967 101.5137C5.7703 101.3391 5.63592 101.1281 5.54186 100.8816C5.44748 100.635 5.4028 100.3703 5.4028 100.0791C5.4028 99.7337 5.46092 99.4287 5.58217 99.1509C5.70311 98.8819 5.86467 98.6487 6.06623 98.4603C6.27248 98.2675 6.51467 98.1241 6.7928 98.0209C7.06623 97.9178 7.36217 97.8684 7.67623 97.8684C8.07967 97.8684 8.43373 97.9269 8.73873 98.0434C9.04811 98.16 9.303734 98.3212 9.509984 98.5231C9.720609 98.725 9.877797 98.9669 9.985297 99.2406C10.088422 99.5141 10.142172 99.8144 10.142172 100.1328C10.142172 100.2944 10.128734 100.46 10.106234 100.6306C10.084047 100.8053 10.039047 100.9712 9.985297 101.1416C9.922484 101.3031 9.846234 101.4647 9.752172 101.6169C9.653422 101.7694 9.532484 101.9084 9.389047 102.0294L8.9853 101.7112C8.91811 101.6662 8.88217 101.5991 8.88217 101.505C8.88217 101.4375 8.90467 101.3659 8.94498 101.2941C8.9853 101.2178 9.03467 101.1328 9.084047 101.0341C9.133422 100.94 9.182797 100.8278 9.223109 100.6934C9.263422 100.5678 9.285922 100.4109 9.285922 100.2316C9.285922 100.0522 9.259047 99.8862 9.204984 99.7428C9.146859 99.5903 9.06155 99.4647 8.95405 99.3572C8.83748 99.2494 8.69842 99.1644 8.52342 99.0972C8.35311 99.0297 8.15123 98.9894 7.91373 98.9716ZM9.465297 102.8359C9.559359 102.8359 9.649047 102.8537 9.734359 102.8896C9.814984 102.9212 9.886547 102.9702 9.944984 103.0287C10.003109 103.0868 10.052484 103.1587 10.084047 103.244C10.119672 103.329 10.137797 103.4187 10.137797 103.513C10.137797 103.6071 10.119672 103.6968 10.084047 103.7774C10.052484 103.8627 10.003109 103.9343 9.944984 103.9927C9.886547 104.0555 9.814984 104.1049 9.734359 104.1405C9.649047 104.1765 9.559359 104.1946 9.465297 104.1946C9.370922 104.1946 9.285922 104.1765 9.200609 104.1405C9.115297 104.1049 9.04373 104.0555 8.9853 103.9927C8.92717 103.9343 8.8778 103.8627 8.84186 103.7774C8.80592 103.6968 8.78811 103.6071 8.78811 103.513C8.78811 103.4187 8.80592 103.329 8.84186 103.244C8.8778 103.1587 8.92717 103.0868 8.9853 103.0287C9.04373 102.9702 9.115297 102.9212 9.200609 102.8896C9.285922 102.8537 9.370922 102.8359 9.465297 102.8359ZM6.26811 102.8359C6.36217 102.8359 6.45186 102.8537 6.5328 102.8896C6.6178 102.9212 6.68967 102.9702 6.7478 103.0287C6.80623 103.0868 6.85561 103.1587 6.89155 103.244C6.9228 103.329 6.94061 103.4187 6.94061 103.513C6.94061 103.6071 6.9228 103.6968 6.89155 103.7774C6.85561 103.8627 6.80623 103.9343 6.7478 103.9927C6.68967 104.0555 6.6178 104.1049 6.5328 104.1405C6.45186 104.1765 6.36217 104.1946 6.26811 104.1946S6.08873 104.1765 6.00373 104.1405C5.91842 104.1049 5.84655 104.0555 5.78842 103.9927C5.72998 103.9343 5.68061 103.8627 5.64498 103.7774C5.60905 103.6968 5.59092 103.6071 5.59092 103.513C5.59092 103.4187 5.60905 103.329 5.64498 103.244C5.68061 103.1587 5.72998 103.0868 5.78842 103.0287C5.84655 102.9702 5.91842 102.9212 6.00373 102.8896C6.08873 102.8537 6.17405 102.8359 6.26811 102.8359Z'/>
+<path d='M18.36659 59.75453C17.95877 59.75453 17.58659 59.69609 17.25003 59.57515C16.9094 59.4539 16.61784 59.28359 16.37128 59.0639C16.12909 58.83984 15.94096 58.57078 15.80628 58.25234C15.6719 57.9339 15.60471 57.57984 15.60471 57.18515V54.96578L22.030025 54.1764V56.3914C22.030025 56.87578 21.940338 57.32421 21.765338 57.73671C21.59065 58.14484 21.3394 58.4989 21.01659 58.79953C20.69815 59.09984 20.31284 59.33296 19.85971 59.50328C19.41127 59.66921 18.91377 59.75453 18.36659 59.75453ZM18.38471 58.8889C18.84659 58.8889 19.26346 58.83078 19.62659 58.71421C19.9944 58.59296 20.30815 58.42734 20.5594 58.2164C20.8194 58.00578 21.01221 57.75015 21.151275 57.45421C21.28565 57.15828 21.352838 56.83109 21.352838 56.47671V55.10015L16.28596 55.72796V57.10453C16.28596 57.38234 16.33534 57.63359 16.43409 57.85328C16.52815 58.07296 16.66721 58.2614 16.84659 58.41828C17.03034 58.57078 17.25003 58.68734 17.51034 58.76796C17.77034 58.84859 18.0619 58.8889 18.38471 58.8889Z'/>
+<path d='M18.75221 61.3996L17.75221 61.47585C17.57315 61.47585 17.48346 61.38617 17.48346 61.20242V60.80773L22.030025 60.26085V61.04085L19.92721 61.2921C19.22315 61.47585 18.73878 61.71804 18.46971 62.01398C18.20065 62.31429 18.14252 62.65523 18.2994 63.04523L17.53252 63.18867C17.46096 63.02273 17.43846 62.85679 17.45628 62.69554C17.48346 62.53398 17.54596 62.3771 17.65378 62.2246C17.7569 62.0721 17.90471 61.92429 18.09315 61.7896C18.2769 61.64617 18.49659 61.52085 18.75221 61.3996ZM17.48784 64.7039V63.9192L22.030025 63.37203V64.1567L17.48784 64.7039ZM16.0619 65.0086C15.98565 65.0086 15.9094 64.9908 15.84221 64.9639C15.77034 64.928 15.70784 64.8877 15.65378 64.8383C15.60471 64.7889 15.56409 64.7308 15.53284 64.6589C15.50159 64.5961 15.48784 64.5245 15.48784 64.4527C15.48784 64.3855 15.50159 64.3183 15.53721 64.2508C15.56409 64.1836 15.60909 64.1255 15.66284 64.0761C15.71221 64.0267 15.77503 63.9864 15.84221 63.9548C15.9094 63.9236 15.98565 63.9102 16.0619 63.9102S16.21003 63.9236 16.28159 63.9548C16.3444 63.9864 16.40721 64.0223 16.46096 64.0761C16.51034 64.1208 16.55065 64.1792 16.58221 64.2464C16.61346 64.3136 16.6269 64.3808 16.6269 64.4483C16.6269 64.5198 16.61346 64.5873 16.58221 64.6589C16.55065 64.7217 16.51034 64.7845 16.46096 64.8383C16.40721 64.8877 16.3444 64.928 16.28159 64.9639C16.21003 64.9908 16.13815 65.0086 16.0619 65.0086ZM17.48784 69.5549V68.9362C17.48784 68.8824 17.50127 68.833 17.53721 68.7927C17.56409 68.7524 17.6044 68.7165 17.65378 68.694L20.57721 67.2905C20.69377 67.2415 20.80596 67.1965 20.91815 67.1562C21.030025 67.1159 21.137837 67.0799 21.249712 67.0487C21.137837 67.0396 21.02565 67.0305 20.91346 67.0171C20.80128 67.0037 20.6894 66.9902 20.57721 66.9724L17.65378 66.2996C17.60877 66.2862 17.56846 66.264 17.53721 66.228C17.50565 66.1921 17.48784 66.1427 17.48784 66.0846V65.4387L22.030025 66.6137V67.2771L17.48784 69.5549Z'/>
+<path d='M17.99909 71.8892C17.99909 72.0101 18.01252 72.1089 18.04815 72.1942C18.07534 72.2792 18.11565 72.3467 18.16503 72.4005C18.21409 72.4498 18.26346 72.4902 18.32628 72.5127C18.38002 72.5348 18.43846 72.5483 18.49221 72.5483C18.59971 72.5483 18.70284 72.5261 18.80159 72.4767S18.99003 72.3286 19.07971 72.1808C19.16034 72.0327 19.24096 71.8173 19.31284 71.5395C19.38909 71.2614 19.4519 70.8939 19.51003 70.432C19.2994 70.4814 19.09752 70.5486 18.91815 70.6336C18.72971 70.7189 18.57284 70.8264 18.43377 70.9476C18.2994 71.0686 18.1919 71.212 18.11565 71.3692C18.0394 71.5261 17.99909 71.7008 17.99909 71.8892ZM21.191588 73.1536L20.94502 72.9564C20.89565 72.9117 20.86878 72.8623 20.86878 72.8039C20.86878 72.7545 20.88221 72.7098 20.91346 72.6605C20.94502 72.6111 20.98065 72.5617 21.02565 72.508C21.065963 72.4498 21.115338 72.3914 21.169087 72.3198C21.218462 72.257 21.267838 72.1761 21.312525 72.0864C21.352838 72.0014 21.388775 71.8983 21.420338 71.7905C21.451588 71.6739 21.465025 71.5486 21.465025 71.4048C21.465025 71.0508 21.357525 70.7861 21.151275 70.6158C20.93596 70.4364 20.63096 70.3514 20.2319 70.3514C20.20065 70.3514 20.16471 70.3514 20.13784 70.3558C20.1019 70.3558 20.07065 70.3558 20.03909 70.3558C19.98096 70.9476 19.90002 71.432 19.80159 71.8086C19.70284 72.1852 19.58628 72.4811 19.45628 72.6964C19.32159 72.9117 19.1694 73.0595 19.00784 73.1402C18.83752 73.2211 18.65815 73.2614 18.46096 73.2614C18.34877 73.2614 18.23221 73.2345 18.11096 73.1805C17.99002 73.1314 17.87784 73.0505 17.77471 72.943C17.67159 72.8355 17.59096 72.6964 17.52377 72.5305C17.45628 72.3645 17.42503 72.1626 17.42503 71.9342C17.42503 71.692 17.46096 71.4676 17.53721 71.2526C17.61346 71.0464 17.71659 70.8489 17.8419 70.6786C17.97659 70.4992 18.12909 70.3467 18.30846 70.2123C18.48784 70.0733 18.68065 69.9611 18.89127 69.8627C19.1019 69.773 19.32159 69.7011 19.55503 69.6473C19.78346 69.6023 20.01659 69.5755 20.25003 69.5755C20.53252 69.5755 20.78346 69.6158 21.01221 69.692C21.240963 69.7683 21.433775 69.8805 21.59065 70.0239C21.7519 70.1673 21.877525 70.3423 21.962838 70.5486C22.047837 70.7548 22.092838 70.988 22.092838 71.248C22.092838 71.4408 22.074713 71.6202 22.039088 71.7817C22.007525 71.952 21.953775 72.1089 21.877525 72.257C21.801275 72.4095 21.707213 72.5573 21.599713 72.7055C21.482838 72.8533 21.348463 73.0014 21.191588 73.1536ZM18.75221 75.0093L17.75221 75.0855C17.57315 75.0855 17.48346 74.9959 17.48346 74.8121V74.4174L22.030025 73.8705V74.6505L19.92721 74.9018C19.22315 75.0855 18.73878 75.3277 18.46971 75.6237C18.20065 75.924 18.14252 76.2649 18.2994 76.6549L17.53252 76.7984C17.46096 76.6324 17.43846 76.4665 17.45628 76.3052C17.48346 76.1437 17.54596 75.9868 17.65378 75.8343C17.7569 75.6818 17.90471 75.534 18.09315 75.3993C18.2769 75.2559 18.49659 75.1305 18.75221 75.0093Z'/>
+<path d='M19.31284 83.5175L18.72971 83.5894V81.7553L16.80628 81.9884V81.3606L18.72971 81.1231V79.2981L19.31284 79.2266V81.0512L21.245338 80.8137V81.4459L19.31284 81.6837V83.5175Z'/>
+<path d='M18.36659 92.084C17.95877 92.084 17.58659 92.0255 17.25003 91.9046C16.9094 91.7834 16.61784 91.613 16.37128 91.3934C16.12909 91.1693 15.94096 90.9002 15.80628 90.5818C15.6719 90.2634 15.60471 89.9093 15.60471 89.5146V87.2952L22.030025 86.5059V88.7209C22.030025 89.2052 21.940338 89.6537 21.765338 90.0662C21.59065 90.4743 21.3394 90.8284 21.01659 91.129C20.69815 91.4293 20.31284 91.6624 19.85971 91.8327C19.41127 91.9987 18.91377 92.084 18.36659 92.084ZM18.38471 91.2184C18.84659 91.2184 19.26346 91.1602 19.62659 91.0437C19.9944 90.9224 20.30815 90.7568 20.5594 90.5459C20.8194 90.3352 21.01221 90.0796 21.151275 89.7837C21.28565 89.4877 21.352838 89.1605 21.352838 88.8062V87.4296L16.28596 88.0574V89.434C16.28596 89.7118 16.33534 89.963 16.43409 90.1827C16.52815 90.4024 16.66721 90.5909 16.84659 90.7477C17.03034 90.9002 17.25003 91.0168 17.51034 91.0974C17.77034 91.178 18.0619 91.2184 18.38471 91.2184ZM18.72534 94.912V94.0917L16.26378 94.3964V95.2486C16.26378 95.6564 16.34878 95.9658 16.52377 96.1676C16.69409 96.3739 16.94065 96.477 17.26815 96.477C17.47877 96.477 17.67628 96.4458 17.85096 96.3739C18.03034 96.3111 18.18284 96.208 18.31721 96.078C18.44284 95.9436 18.54596 95.7776 18.61784 95.5848C18.6894 95.392 18.72534 95.1676 18.72534 94.912ZM15.60471 95.3248V93.6342L22.030025 92.8495V93.6836L19.33534 94.0155V94.6073C19.33534 94.7195 19.34877 94.8001 19.38002 94.8495C19.41127 94.8986 19.46065 94.9436 19.5369 94.9839L21.85065 96.1945C21.971588 96.253 22.030025 96.3561 22.030025 96.5086V97.2527L19.46534 95.8673C19.34877 95.8045 19.25909 95.7239 19.19159 95.6295C19.13346 95.8895 19.0394 96.123 18.91815 96.3292C18.79253 96.5355 18.64002 96.7102 18.46534 96.8583C18.29034 97.0061 18.08877 97.1183 17.8644 97.1945C17.64034 97.2708 17.39815 97.3111 17.13815 97.3111C16.90502 97.3111 16.69409 97.2708 16.50596 97.1902C16.31315 97.1139 16.15159 96.9926 16.02159 96.8314C15.8869 96.6655 15.78378 96.4592 15.71221 96.2127C15.64034 95.9614 15.60471 95.6655 15.60471 95.3248ZM21.366275 100.2608V99.0008L19.09315 99.2786V100.5386C19.09315 100.9286 19.17815 101.2158 19.34877 101.4086C19.5144 101.5967 19.74315 101.6911 20.02565 101.6911C20.2319 101.6911 20.41596 101.6595 20.58159 101.6014C20.74753 101.543 20.88659 101.4533 21.00315 101.3367C21.119713 101.2158 21.2094 101.0677 21.272213 100.8883C21.335025 100.7089 21.366275 100.4983 21.366275 100.2608ZM16.26378 99.6283V100.7002C16.26378 101.0901 16.34003 101.377 16.4969 101.5611C16.6494 101.7448 16.87815 101.8389 17.18753 101.8389C17.38034 101.8389 17.5594 101.8077 17.72096 101.7492C17.88253 101.6911 18.02127 101.5967 18.13784 101.4801C18.25003 101.3548 18.33971 101.2067 18.4069 101.023C18.46971 100.8436 18.50128 100.6326 18.50128 100.3908V99.3548L16.26378 99.6283ZM15.60471 100.7764V98.8708L22.030025 98.0814V100.1933C22.030025 100.5567 21.98065 100.8795 21.8819 101.1664C21.783463 101.458 21.6444 101.6998 21.465025 101.9017S21.070338 102.2561 20.82846 102.3592C20.57721 102.4667 20.30815 102.5205 20.01221 102.5205C19.67596 102.5205 19.39784 102.422 19.18284 102.2336C18.96753 102.0364 18.81503 101.7492 18.72971 101.3636C18.66252 101.5833 18.56846 101.7761 18.45628 101.9467C18.34409 102.108 18.21409 102.247 18.06627 102.3592C17.91815 102.4667 17.76128 102.5473 17.5819 102.6014C17.41159 102.6595 17.22784 102.6864 17.0394 102.6864C16.81971 102.6864 16.62253 102.6505 16.44315 102.5742C16.26815 102.498 16.11565 102.3861 15.99471 102.2292C15.86909 102.072 15.77034 101.8748 15.70784 101.6326C15.63596 101.3951 15.60471 101.108 15.60471 100.7764ZM18.95409 106.8423L19.43377 106.7882C19.47878 106.7838 19.51909 106.7929 19.54596 106.8241C19.5819 106.8557 19.59534 106.896 19.59534 106.9498V107.8466L21.04815 107.6673C21.106275 107.5594 21.160025 107.4519 21.205025 107.3444C21.2544 107.2366 21.294713 107.1248 21.321588 107.0035C21.357525 106.8826 21.379713 106.7569 21.397838 106.6223C21.41565 106.4879 21.424713 106.3444 21.424713 106.1876C21.424713 105.9094 21.375338 105.6585 21.276588 105.4298C21.173463 105.201 21.030025 105.0082 20.8419 104.8466C20.65346 104.6854 20.42471 104.5598 20.15565 104.4748C19.88659 104.3851 19.5819 104.3401 19.24565 104.3401C18.79253 104.3401 18.38471 104.4029 18.0169 104.5194C17.64909 104.6451 17.33534 104.8154 17.07534 105.0307C16.81534 105.2548 16.61346 105.5148 16.4744 105.8198C16.33534 106.1291 16.26378 106.4654 16.26378 106.8332C16.26378 107.0573 16.28159 107.2501 16.32659 107.4069C16.36221 107.5641 16.41159 107.7029 16.47002 107.8151C16.52377 107.9273 16.58221 108.026 16.64034 108.1066C16.70315 108.1829 16.75253 108.2544 16.79284 108.3219C16.83315 108.3891 16.84659 108.4519 16.83315 108.5101C16.81971 108.5729 16.7794 108.6266 16.71659 108.6716L16.3669 108.9407C16.24565 108.8285 16.13815 108.7076 16.03502 108.5729C15.9319 108.4429 15.84659 108.2951 15.77034 108.1244C15.69409 107.9632 15.63596 107.7748 15.59565 107.5776C15.55534 107.3713 15.53284 107.1469 15.53284 106.896C15.53284 106.4026 15.62253 105.9454 15.80628 105.5329C15.99002 105.1113 16.24565 104.7526 16.57752 104.4476C16.90502 104.1473 17.2994 103.9098 17.76128 103.7391C18.21878 103.5644 18.72534 103.4791 19.2769 103.4791C19.6894 103.4791 20.07065 103.5419 20.41596 103.6585C20.76096 103.7841 21.061588 103.9544 21.312525 104.1788C21.559088 104.4029 21.7519 104.6719 21.89565 104.9904C22.030025 105.3085 22.1019 105.6585 22.1019 106.0485C22.1019 106.2951 22.088463 106.5238 22.0569 106.7344C22.030025 106.9454 21.985337 107.1469 21.931275 107.3354C21.868463 107.5282 21.7969 107.7076 21.711588 107.8823C21.626588 108.0529 21.523463 108.2188 21.4069 108.3801L18.95409 108.6851V106.8423ZM20.05253 110.2041C19.60877 110.2041 19.19628 110.2354 18.80159 110.2982C18.41596 110.3563 18.0394 110.446 17.68065 110.5626C17.3219 110.6794 16.97221 110.8229 16.63127 110.9932C16.29503 111.1635 15.9544 111.361 15.61346 111.5807C15.52846 111.6388 15.46096 111.6569 15.4119 111.6388C15.36253 111.621 15.32659 111.5941 15.29503 111.5538L15.0844 111.2354C15.56877 110.8857 16.02596 110.5985 16.4519 110.3788C16.88253 110.1591 17.2994 109.9844 17.70315 109.8588C18.10659 109.7288 18.50565 109.6435 18.90034 109.5941C19.2994 109.5448 19.70721 109.5226 20.1244 109.5226C20.37096 109.5226 20.63096 109.536 20.90003 109.5629C21.169087 109.5898 21.442525 109.6301 21.716275 109.6885C21.989712 109.7466 22.26315 109.8185 22.541275 109.9035C22.810338 109.9932 23.0794 110.101 23.33471 110.2263L23.12846 110.5898C23.09721 110.6388 23.06128 110.6748 23.0119 110.7016C22.962525 110.7332 22.895338 110.7285 22.80565 110.6973C22.604088 110.6166 22.388775 110.5448 22.160025 110.4819C21.931275 110.4191 21.693775 110.3701 21.455963 110.3251C21.218462 110.2891 20.98065 110.2579 20.73878 110.2354C20.50534 110.2129 20.27221 110.2041 20.05253 110.2041Z'/>
+<path d='M18.21409 114.57L17.92721 114.7719C17.77034 114.6237 17.64909 114.4444 17.55502 114.2381C17.46534 114.0275 17.42065 113.79 17.42065 113.5162C17.42065 113.2606 17.46096 113.0275 17.54596 112.8212C17.6269 112.6197 17.7344 112.4447 17.87346 112.3012C18.01252 112.1578 18.1694 112.05 18.34409 111.9694C18.52346 111.8975 18.70753 111.8572 18.90034 111.8572C19.12002 111.8572 19.29471 111.9022 19.42471 111.9962C19.55503 112.0903 19.66252 112.2069 19.74315 112.3459C19.82846 112.485 19.89565 112.6375 19.9494 112.7987C19.99878 112.9603 20.05721 113.1128 20.11534 113.2519C20.17377 113.3909 20.25003 113.5075 20.33971 113.6016C20.4294 113.6956 20.55034 113.7406 20.70284 113.7406C20.81503 113.7406 20.92253 113.7181 21.02565 113.6731C21.1244 113.6328 21.2094 113.57 21.28565 113.485C21.3619 113.4044 21.420338 113.3056 21.465025 113.1891C21.510025 113.0678 21.532213 112.9378 21.532213 112.79C21.532213 112.6241 21.510025 112.485 21.4694 112.3728C21.429088 112.2653 21.379713 112.1756 21.33065 112.1037C21.276588 112.0322 21.227525 111.9737 21.1869 111.9247C21.146588 111.8753 21.1244 111.8303 21.1244 111.7809C21.1244 111.7319 21.13315 111.6912 21.15565 111.6556C21.17815 111.6287 21.205025 111.5972 21.245338 111.5703L21.550338 111.3731C21.711588 111.5119 21.841588 111.6959 21.9494 111.9156C22.047837 112.1397 22.1019 112.3953 22.1019 112.6869C22.1019 112.9559 22.0569 113.1981 21.971588 113.4131C21.886588 113.6328 21.770025 113.8169 21.626588 113.9691C21.478463 114.1262 21.312525 114.2428 21.119713 114.3278C20.9269 114.4087 20.72971 114.4491 20.51909 114.4491C20.30377 114.4491 20.12878 114.4041 19.9944 114.31C19.85971 114.2159 19.74784 114.0994 19.66252 113.9603C19.57721 113.8212 19.50565 113.6687 19.44721 113.5075C19.38909 113.3459 19.33065 113.1934 19.26784 113.0544C19.20971 112.9156 19.13784 112.7987 19.05284 112.7047C18.96753 112.6106 18.85534 112.5656 18.71628 112.5656C18.61784 112.5656 18.52346 112.5881 18.43377 112.6331C18.34877 112.6734 18.27253 112.7362 18.20534 112.8125C18.13784 112.8931 18.08877 112.9872 18.04815 113.0994C18.01252 113.2116 17.9944 113.3325 17.9944 113.4669C17.9944 113.6106 18.01252 113.7316 18.04815 113.8347C18.07971 113.9378 18.12002 114.0231 18.15596 114.0947C18.20065 114.1619 18.23659 114.2203 18.26815 114.2741C18.2994 114.3191 18.31721 114.3681 18.31721 114.4087C18.31721 114.4444 18.30846 114.4759 18.29034 114.4984C18.2769 114.5206 18.25003 114.5475 18.21409 114.57Z'/>
+<path d='M18.36659 116.0846C18.78378 116.0846 19.18721 116.053 19.57284 115.9949C19.96284 115.9321 20.33971 115.8424 20.70284 115.7259C21.070338 115.6046 21.429088 115.4612 21.7744 115.2909C22.119713 115.1205 22.465025 114.9277 22.80565 114.708C22.85065 114.6765 22.890963 114.6587 22.9269 114.6496C22.95815 114.6405 22.989713 114.6405 23.016588 114.6452C23.03877 114.6496 23.06128 114.663 23.0794 114.6765C23.09721 114.6899 23.11503 114.708 23.12846 114.7302L23.33471 115.0487C22.85065 115.3984 22.39315 115.6855 21.967213 115.9052S21.1244 116.2996 20.72065 116.4252C20.31721 116.5509 19.91815 116.6362 19.51909 116.6852C19.1244 116.7346 18.71628 116.7571 18.2994 116.7571C18.04815 116.7571 17.78815 116.7437 17.51909 116.7168S16.97659 116.6496 16.70315 116.5955C16.42971 116.5374 16.15596 116.4655 15.88253 116.3805C15.60909 116.2909 15.3444 116.183 15.0844 116.0621L15.29503 115.6899C15.32659 115.6405 15.36253 115.6046 15.4119 115.5777C15.46096 115.5509 15.52846 115.5555 15.61346 115.5868C15.81534 115.6674 16.03065 115.7393 16.25909 115.7974C16.48784 115.8602 16.72565 115.914 16.96315 115.959C17.20096 115.9993 17.44284 116.0309 17.68065 116.053C17.91815 116.0755 18.1469 116.0846 18.36659 116.0846Z'/>
+<path d='M98.4844 144.965V122.516' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M98.484355 120.01979L99.83201 123.590101L98.484355 122.41432L97.1406 123.590101Z'/>
+<path d='M98.484355 120.01979L99.83201 123.590101L98.484355 122.41432L97.1406 123.590101Z' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M67.8368 131.42447C67.8368 131.86822 67.86805 132.28072 67.93086 132.6754C67.98899 133.06103 68.07868 133.43759 68.19524 133.79634C68.31211 134.15509 68.45555 134.50478 68.62586 134.84572C68.79618 135.18197 68.99368 135.52259 69.21336 135.86353C69.27149 135.94853 69.28961 136.01603 69.27149 136.06509C69.25368 136.11447 69.2268 136.1504 69.18649 136.18197L68.86805 136.39259C68.51836 135.90822 68.23118 135.45103 68.01149 135.02509C67.7918 134.59447 67.617114 134.17759 67.491489 133.77384C67.361489 133.3704 67.276176 132.97134 67.226801 132.57665C67.177426 132.17759 67.155239 131.76978 67.155239 131.35259C67.155239 131.10603 67.168676 130.84603 67.195551 130.57697C67.222426 130.307904 67.262739 130.034466 67.321176 129.760716C67.379301 129.487279 67.451176 129.213841 67.536176 128.935716C67.625864 128.666654 67.733676 128.39759 67.85899 128.14228L68.22243 128.34853C68.27149 128.37978 68.30743 128.41572 68.3343 128.465091C68.36586 128.514466 68.36118 128.581654 68.32993 128.671341C68.2493 128.872904 68.17743 129.088216 68.11461 129.316966C68.0518 129.545716 68.00274 129.783216 67.95774 130.021029C67.9218 130.258529 67.89055 130.49634 67.86805 130.73822C67.84555 130.97165 67.8368 131.20478 67.8368 131.42447Z'/>
+<path d='M73.17477 135.18634H75.99071L76.07602 135.87228H72.41727L71.6279 129.446966H75.29133L75.37664 130.128529H72.55602L72.82977 132.36165H75.09852L75.18383 133.02072H72.91039L73.17477 135.18634ZM80.169 134.87697L80.4156 135.23134C80.2452 135.45103 80.0299 135.62134 79.7656 135.74697C79.5009 135.87228 79.2049 135.93509 78.8777 135.93509C78.5549 135.93509 78.2634 135.88134 78.0034 135.76915C77.7477 135.65728 77.5281 135.50915 77.3487 135.3254S77.0302 134.92634 76.9362 134.68415C76.8418 134.44197 76.7927 134.19103 76.7927 133.92634C76.7927 133.68884 76.8284 133.49134 76.9002 133.33009C76.9721 133.16853 77.0662 133.03415 77.1827 132.92197C77.2993 132.80978 77.4337 132.72009 77.5818 132.64853C77.7296 132.57665 77.8821 132.51384 78.0393 132.45572C78.1962 132.39728 78.3487 132.34353 78.4965 132.28978C78.6446 132.23134 78.779 132.16884 78.8956 132.09259C79.0121 132.01634 79.1065 131.92665 79.1781 131.81447C79.2499 131.70697 79.2856 131.57228 79.2856 131.40634C79.2856 131.20915 79.2543 131.02978 79.1915 130.86384C79.1287 130.70259 79.039 130.56353 78.9271 130.446966C78.8102 130.330404 78.6668 130.240716 78.5056 130.173216C78.3352 130.106029 78.1512 130.074779 77.9449 130.074779C77.7209 130.074779 77.5324 130.110716 77.3846 130.173216C77.2365 130.245091 77.1109 130.316966 77.0077 130.397591C76.9046 130.4829 76.824 130.55884 76.7568 130.62165C76.68961 130.69353 76.63118 130.72478 76.57305 130.72478C76.53243 130.72478 76.49211 130.71603 76.45649 130.69353C76.42055 130.67103 76.38899 130.64415 76.3668 130.6129L76.07086 130.213841C76.26368 129.958216 76.51461 129.751966 76.8106 129.599466C77.1156 129.451341 77.4562 129.375091 77.8374 129.375091C78.1827 129.375091 78.4965 129.433529 78.7746 129.554466C79.0524 129.675716 79.2902 129.836966 79.4831 130.038841C79.6802 130.240716 79.8327 130.47822 79.9359 130.74728C80.039 131.02072 80.0927 131.3079 80.0927 131.61259C80.0927 131.83228 80.0568 132.02072 79.9852 132.17759C79.9134 132.33447 79.8193 132.46478 79.7027 132.57665C79.5862 132.68884 79.4515 132.77853 79.3037 132.85478C79.1512 132.93103 78.9987 132.99822 78.8418 133.06103C78.6849 133.11915 78.5324 133.17759 78.3799 133.2404C78.2321 133.29415 78.0974 133.36603 77.9809 133.43759C77.8643 133.51822 77.7702 133.6079 77.6984 133.71572C77.6265 133.81884 77.5909 133.94884 77.5909 134.10572C77.5909 134.26259 77.6177 134.41072 77.6715 134.54978C77.7252 134.68853 77.8059 134.80978 77.9046 134.90853C78.0121 135.01603 78.1377 135.09665 78.2859 135.15509C78.4337 135.21322 78.604 135.24478 78.7968 135.24478C78.9852 135.24478 79.1421 135.2179 79.2677 135.16853C79.3934 135.11478 79.5009 135.05634 79.5906 134.99822C79.6759 134.9354 79.7474 134.87697 79.8059 134.82759C79.864 134.77384 79.9181 134.74697 79.9671 134.74697C80.0077 134.74697 80.0434 134.75603 80.0749 134.7829C80.1062 134.80072 80.1377 134.83665 80.169 134.87697ZM84.7464 130.034466H83.5939L84.3114 135.88603H83.6792L81.7152 134.23134L81.9127 133.89509C81.9261 133.87697 81.9439 133.85915 81.9664 133.84134C81.9886 133.8279 82.0202 133.81415 82.047 133.8054C82.083 133.80072 82.1142 133.80072 82.1545 133.80978C82.1952 133.81884 82.2355 133.83665 82.2758 133.86822L83.4236 134.85447C83.4102 134.78728 83.4011 134.72447 83.3923 134.66165C83.3789 134.59884 83.3698 134.53634 83.3652 134.4779L82.8183 130.034466H81.5583L81.482 129.446966H84.6702L84.7464 130.034466ZM88.095 130.016341C87.9247 130.016341 87.7722 130.047904 87.6422 130.101654C87.5122 130.164466 87.4 130.245091 87.3103 130.352591C87.225 130.45572 87.1578 130.58134 87.1131 130.72947C87.0638 130.8729 87.0413 131.02978 87.0413 131.20009C87.0413 131.4154 87.0772 131.61728 87.1488 131.81009C87.2206 132.0029 87.3194 132.16884 87.4447 132.31228C87.5747 132.45572 87.7272 132.5679 87.9022 132.65759C88.0772 132.73822 88.2744 132.7829 88.485 132.7829C88.6509 132.7829 88.7991 132.75603 88.9334 132.70228C89.0634 132.64415 89.1756 132.5679 89.2697 132.46915C89.3641 132.36603 89.4356 132.24478 89.485 132.10134C89.5344 131.95353 89.5613 131.79197 89.5613 131.61259C89.5613 131.38415 89.5253 131.16884 89.4538 130.97603C89.3775 130.78322 89.2744 130.6129 89.1488 130.46915C89.0141 130.330404 88.8619 130.218216 88.6825 130.137591C88.5031 130.056654 88.3056 130.016341 88.095 130.016341ZM88.1128 133.45572L90.1666 135.8679H89.4806C89.3909 135.8679 89.3056 135.85009 89.2294 135.81415C89.1531 135.77822 89.0903 135.73353 89.0456 135.67947L87.2834 133.48259C87.1175 133.27634 86.9694 133.07884 86.8484 132.89072C86.7275 132.6979 86.6244 132.51384 86.5434 132.33009C86.4628 132.14634 86.4044 131.96697 86.3641 131.78759C86.3238 131.60822 86.3059 131.42447 86.3059 131.23603C86.3059 130.95353 86.3463 130.70259 86.4225 130.46915C86.5031 130.245091 86.6197 130.047904 86.7631 129.886341C86.9156 129.720404 87.095 129.595091 87.3103 129.509779C87.5209 129.420091 87.7631 129.375091 88.0322 129.375091C88.3594 129.375091 88.6644 129.437904 88.9513 129.554466C89.2294 129.680091 89.4759 129.841654 89.6822 130.056654C89.8884 130.262904 90.05 130.51415 90.1709 130.80103C90.2875 131.08822 90.3459 131.39759 90.3459 131.72915C90.3459 131.98947 90.3056 132.22259 90.2247 132.42415C90.1488 132.62603 90.0409 132.80103 89.9019 132.94009C89.7631 133.07884 89.6016 133.18665 89.4178 133.2629C89.2294 133.33915 89.0275 133.37478 88.8125 133.37478C88.6241 133.37478 88.4447 133.3479 88.2744 133.29415C88.1041 133.24478 87.9469 133.16853 87.7991 133.07447C87.8484 133.1329 87.9022 133.1954 87.9516 133.25822C88.0009 133.32103 88.0547 133.38822 88.1128 133.45572Z'/>
+<path d='M93.9247 133.1104C93.9247 132.69322 93.8931 132.28978 93.835 131.90415C93.7722 131.51415 93.6825 131.13728 93.5659 130.77415C93.4447 130.406654 93.3013 130.047904 93.1309 129.702591C92.9606 129.357279 92.7678 129.011966 92.5481 128.671341C92.5166 128.626341 92.4988 128.586029 92.4897 128.550091C92.4806 128.518841 92.4806 128.487279 92.4853 128.460404C92.4897 128.43822 92.5031 128.41572 92.5166 128.39759C92.53 128.37978 92.5481 128.36197 92.5703 128.34853L92.8888 128.14228C93.2384 128.626341 93.5256 129.083841 93.7453 129.509779C93.965 129.935716 94.1397 130.352591 94.2653 130.75634C94.3909 131.15978 94.4763 131.55884 94.5253 131.9579C94.5747 132.35259 94.5972 132.76072 94.5972 133.17759C94.5972 133.42884 94.5838 133.68884 94.5569 133.9579C94.53 134.22697 94.4897 134.5004 94.4356 134.77384C94.3775 135.04728 94.3056 135.32103 94.2206 135.59447C94.1309 135.8679 94.0231 136.13259 93.9022 136.39259L93.53 136.18197C93.4806 136.1504 93.4447 136.11447 93.4178 136.06509C93.3909 136.01603 93.3956 135.94853 93.4269 135.86353C93.5075 135.66165 93.5794 135.44634 93.6375 135.2179C93.7003 134.98915 93.7541 134.75134 93.7991 134.51384C93.8394 134.27603 93.8709 134.03415 93.8931 133.79634C93.9156 133.55884 93.9247 133.33009 93.9247 133.1104Z'/>
+<path d='M104.57775 133.93196C104.69869 133.93196 104.79744 133.91853 104.88275 133.8829C104.96775 133.85571 105.03525 133.8154 105.089 133.76603C105.13837 133.71696 105.17869 133.66759 105.20119 133.60478C105.22337 133.55103 105.23681 133.49259 105.23681 133.43884C105.23681 133.33134 105.21462 133.22821 105.16525 133.12946C105.11587 133.03071 105.01712 132.94103 104.86931 132.85134C104.72119 132.77071 104.50587 132.69009 104.22806 132.61821C103.94994 132.54196 103.58244 132.47915 103.12056 132.42103C103.16994 132.63165 103.23712 132.83353 103.32212 133.0129C103.40744 133.20134 103.51494 133.35821 103.63619 133.49728C103.75712 133.63165 103.90056 133.73915 104.05775 133.8154C104.21462 133.89165 104.38931 133.93196 104.57775 133.93196ZM105.84212 130.739464L105.64494 130.98603C105.60025 131.0354 105.55087 131.06228 105.49244 131.06228C105.44306 131.06228 105.39837 131.04884 105.349 131.01759C105.29962 130.98603 105.25025 130.9504 105.1965 130.9054C105.13837 130.865089 105.07994 130.815714 105.00837 130.761964C104.94556 130.712589 104.86462 130.663214 104.77494 130.618527C104.68994 130.578214 104.58681 130.542277 104.479 130.510714C104.36244 130.479464 104.23712 130.466027 104.09337 130.466027C103.73931 130.466027 103.47462 130.573527 103.30431 130.779777C103.12494 130.99509 103.03994 131.30009 103.03994 131.69915C103.03994 131.7304 103.03994 131.76634 103.04431 131.79321C103.04431 131.82915 103.04431 131.8604 103.04431 131.89196C103.63619 131.95009 104.12056 132.03103 104.49712 132.12946C104.87369 132.22821 105.16962 132.34478 105.38494 132.47478C105.60025 132.60946 105.74806 132.76165 105.82869 132.92321C105.90962 133.09353 105.94994 133.2729 105.94994 133.47009C105.94994 133.58228 105.92306 133.69884 105.869 133.82009C105.81994 133.94103 105.739 134.05321 105.6315 134.15634C105.524 134.25946 105.38494 134.34009 105.219 134.40728C105.05306 134.47478 104.85119 134.50603 104.62275 134.50603C104.38056 134.50603 104.15619 134.47009 103.94119 134.39384C103.73494 134.31759 103.53744 134.21446 103.36712 134.08915C103.18775 133.95446 103.03525 133.80196 102.900873 133.62259C102.761811 133.44321 102.649623 133.2504 102.551186 133.03978C102.461498 132.82915 102.389623 132.60946 102.335873 132.37603C102.290873 132.14759 102.263998 131.91446 102.263998 131.68103C102.263998 131.39853 102.304311 131.14759 102.380561 130.91884C102.456811 130.690089 102.568998 130.497277 102.712436 130.340402C102.855873 130.179152 103.03087 130.053527 103.23712 129.968214C103.44337 129.883214 103.6765 129.838214 103.9365 129.838214C104.12931 129.838214 104.30869 129.856339 104.47025 129.891964C104.64056 129.923527 104.79744 129.977277 104.94556 130.053527C105.09806 130.129777 105.24587 130.223839 105.394 130.331339C105.54181 130.448214 105.68994 130.582589 105.84212 130.739464ZM107.7022 133.2954L107.7697 134.17884C107.7697 134.3579 107.68001 134.44759 107.50064 134.44759H107.10595L106.55908 129.901027H107.3572L107.6172 132.20571C107.7022 132.45228 107.80095 132.68103 107.91751 132.87821C108.03876 133.08446 108.16408 133.25509 108.30314 133.39853C108.4422 133.54196 108.58126 133.65415 108.73376 133.7304C108.8772 133.80665 109.02501 133.84696 109.16845 133.84696C109.40189 133.84696 109.56314 133.76165 109.64845 133.58696C109.73345 133.41634 109.75595 133.15196 109.71564 132.79321L109.3747 129.901027H110.16845L110.50939 132.79321C110.54064 133.06665 110.54064 133.30884 110.50939 133.52415C110.47783 133.73478 110.41501 133.91415 110.32095 134.06196C110.23126 134.21009 110.1147 134.32228 109.97126 134.39384C109.82314 134.47478 109.6572 134.5104 109.46439 134.5104C109.14158 134.5104 108.82783 134.40728 108.52283 134.20571C108.21814 133.99946 107.94439 133.69446 107.7022 133.2954Z'/>
+<path d='M111.61236 130.757589C111.61704 130.456964 111.70673 130.223839 111.86798 130.066964C112.0386 129.910089 112.2627 129.829152 112.5542 129.829152C112.7424 129.829152 112.9308 129.865089 113.1145 129.936964C113.303 130.013214 113.4689 130.111652 113.6167 130.241652L113.4464 130.622902C113.433 130.649777 113.4195 130.667902 113.4105 130.681339C113.3927 130.694777 113.3745 130.699152 113.3477 130.699152C113.3255 130.699152 113.303 130.690089 113.2714 130.663214C113.2402 130.645402 113.2042 130.618527 113.1595 130.591652C113.1145 130.564777 113.0608 130.537589 113.007 130.519777C112.9442 130.492902 112.877 130.483839 112.7961 130.483839C112.6752 130.483839 112.5811 130.519777 112.5092 130.591652C112.4377 130.667902 112.4017 130.779777 112.4017 130.93228C112.4017 130.94134 112.4017 130.95478 112.4061 130.97259C112.4061 130.99071 112.4061 131.02196 112.4152 131.06696C112.4152 131.11165 112.4242 131.17009 112.433 131.24634C112.442 131.32228 112.4555 131.42103 112.4689 131.54228L112.7424 133.77509H113.9395L114.007 134.35353H112.8142L113.007 135.91853H112.5899C112.5408 135.91853 112.5049 135.90509 112.4689 135.87353C112.442 135.84665 112.4152 135.81071 112.4017 135.76603L112.0608 134.36259L111.36142 134.26821L111.32548 133.95009C111.32111 133.89165 111.32986 133.84696 111.35705 133.82009C111.37923 133.78853 111.41517 133.77509 111.45548 133.77509H111.96236L111.68423 131.50165C111.66642 131.3629 111.65298 131.24634 111.64392 131.16103C111.63048 131.07571 111.62579 131.00415 111.61704 130.9504C111.61704 130.896339 111.61236 130.856027 111.61236 130.824777V130.757589ZM115.5712 133.17884L115.6474 134.17884C115.6474 134.3579 115.5577 134.44759 115.374 134.44759H114.9793L114.4324 129.901027H115.2124L115.4637 132.00384C115.6474 132.7079 115.8896 133.19228 116.1856 133.46134C116.4859 133.7304 116.8268 133.78853 117.2168 133.63165L117.3602 134.39853C117.1943 134.47009 117.0284 134.49259 116.8671 134.47478C116.7056 134.44759 116.5487 134.38509 116.3962 134.27728C116.2437 134.17415 116.0959 134.02634 115.9612 133.8379C115.8177 133.65415 115.6924 133.43446 115.5712 133.17884Z'/>
+<path d='M119.1013 130.461652C118.7873 130.461652 118.5498 130.569152 118.3838 130.779777C118.2179 130.99509 118.1373 131.31353 118.1373 131.7304C118.1373 132.0129 118.1732 132.28634 118.2404 132.54665C118.3076 132.80665 118.4063 133.0354 118.532 133.23259C118.6573 133.42978 118.8098 133.58696 118.9892 133.70353C119.1642 133.82446 119.3657 133.8829 119.5857 133.8829C119.8951 133.8829 120.137 133.77509 120.2985 133.56884C120.4688 133.35353 120.5495 133.03978 120.5495 132.6229C120.5495 132.3404 120.5138 132.06665 120.4463 131.80665C120.3792 131.54665 120.2807 131.3179 120.1551 131.12071C120.0251 130.91884 119.8726 130.761964 119.6976 130.641027C119.5182 130.519777 119.321 130.461652 119.1013 130.461652ZM119.0251 129.838214C119.3523 129.838214 119.6573 129.910089 119.9398 130.062589C120.2223 130.206027 120.4688 130.407589 120.6751 130.663214C120.886 130.91884 121.0473 131.21478 121.1685 131.55103C121.2895 131.88728 121.3479 132.24603 121.3479 132.62728C121.3479 132.92321 121.3073 133.18759 121.2223 133.42103C121.137 133.65415 121.0204 133.85134 120.8726 134.0129C120.7245 134.17415 120.5451 134.2954 120.3388 134.38509C120.1326 134.46571 119.9038 134.5104 119.6573 134.5104C119.3301 134.5104 119.0251 134.43884 118.747 134.29071C118.4601 134.1429 118.2179 133.9454 118.0073 133.69446C117.7963 133.43884 117.6351 133.1429 117.5142 132.80665C117.3929 132.4704 117.3348 132.10696 117.3348 131.72603C117.3348 131.42571 117.3751 131.16103 117.4601 130.9279C117.5454 130.694777 117.662 130.497277 117.8101 130.336027C117.9579 130.174464 118.1373 130.053527 118.3435 129.963839C118.5498 129.883214 118.7785 129.838214 119.0251 129.838214ZM122.8849 130.896339L123.033 132.08478C123.118 132.34478 123.2211 132.58228 123.3377 132.80228C123.4589 133.02196 123.5845 133.21009 123.7233 133.36696C123.858 133.52415 123.997 133.64946 124.1449 133.73915C124.293 133.82446 124.4364 133.86915 124.5799 133.86915C124.813 133.86915 124.9924 133.77509 125.1224 133.59134S125.3152 133.13384 125.3152 132.77978C125.3152 132.6004 125.2974 132.42103 125.2658 132.23259C125.2345 132.05321 125.1852 131.87384 125.1224 131.70353C125.0642 131.52884 124.988 131.36728 124.8983 131.21915C124.8086 131.06696 124.7055 130.93228 124.5933 130.824777C124.4811 130.708214 124.3558 130.622902 124.2167 130.555714C124.0777 130.488527 123.9342 130.456964 123.7774 130.456964C123.6114 130.456964 123.4499 130.492902 123.293 130.555714C123.1361 130.627277 122.997 130.739464 122.8849 130.896339ZM123.127 133.21009L123.2033 134.17884C123.2033 134.3579 123.1136 134.44759 122.9342 134.44759H122.5395L121.7999 128.3629H122.5755L122.8177 130.345089C122.9477 130.183527 123.1002 130.057902 123.2839 129.972902C123.468 129.883214 123.6695 129.838214 123.8939 129.838214C124.1045 129.838214 124.3017 129.878527 124.4945 129.959464C124.6874 130.040089 124.8624 130.152277 125.0239 130.295714C125.1895 130.434464 125.3377 130.600402 125.472 130.797902C125.6024 130.98603 125.7142 131.19696 125.813 131.41665C125.9027 131.64071 125.9789 131.87384 126.0283 132.12071C126.0774 132.36728 126.1045 132.60946 126.1045 132.85603C126.1045 133.39853 125.9967 133.80665 125.7861 134.08915C125.5708 134.37165 125.2705 134.5104 124.8802 134.5104C124.7142 134.5104 124.5486 134.47915 124.387 134.42071C124.2302 134.3579 124.0733 134.26821 123.9252 134.15634C123.7774 134.04415 123.6336 133.90509 123.4992 133.74821C123.3649 133.58696 123.2392 133.40759 123.127 133.21009Z'/>
+<path d='M130.8012 134.44321H130.169C130.124 134.44321 130.0793 134.42978 130.039 134.4029C129.994 134.37165 129.9581 134.33571 129.9356 134.28634L128.5009 131.42103C128.4696 131.35821 128.4424 131.2954 128.4156 131.22821C128.3887 131.1654 128.3618 131.10259 128.3349 131.04009C128.3306 131.10259 128.3215 131.1654 128.3124 131.22821C128.3037 131.29103 128.2902 131.35384 128.2768 131.41665L127.5459 134.27728C127.5324 134.32665 127.5099 134.36696 127.4784 134.39384C127.4471 134.42978 127.4024 134.44321 127.3349 134.44321H126.6759L127.8552 130.170089L126.8687 128.3629H127.4562C127.5234 128.3629 127.5771 128.37634 127.6174 128.4079C127.6624 128.43915 127.7027 128.48415 127.734 128.54696L130.8012 134.44321Z'/>
+<path d='M172.18342 149.13729H171.44342L170.86498 144.45635C170.8606 144.40229 170.85592 144.34417 170.84717 144.28135C170.84717 144.21854 170.8381 144.15135 170.83373 144.08417L168.0581 148.99385C168.02217 149.05229 167.98623 149.0926 167.95498 149.11042C167.92342 149.12854 167.86967 149.13729 167.79342 149.13729H167.35873L166.569353 142.711979H167.30935L167.88779 147.46479C167.89217 147.51417 167.89654 147.56354 167.90123 147.61729C167.9056 147.66667 167.90998 147.7251 167.91467 147.78323L170.6856 142.868854C170.72592 142.815104 170.76623 142.774791 170.80685 142.747916C170.84717 142.725416 170.90529 142.711979 170.97248 142.711979H171.38967L172.18342 149.13729Z' fill='#800000'/>
+<path d='M174.39006 143.272604C174.07599 143.272604 173.83849 143.380104 173.67256 143.590729C173.50662 143.80604 173.42599 144.12448 173.42599 144.54135C173.42599 144.82385 173.46193 145.09729 173.52912 145.3576C173.59631 145.6176 173.69506 145.84635 173.82068 146.04354C173.94599 146.24073 174.09849 146.39792 174.27787 146.51448C174.45287 146.63542 174.65443 146.69385 174.87443 146.69385C175.18381 146.69385 175.42568 146.58604 175.58724 146.37979C175.75756 146.16448 175.83818 145.85073 175.83818 145.43385C175.83818 145.15135 175.80256 144.8776 175.73506 144.6176C175.66787 144.3576 175.56943 144.12885 175.44381 143.93167C175.31381 143.72979 175.16131 143.572916 174.98631 143.451979C174.80693 143.330729 174.60974 143.272604 174.39006 143.272604ZM174.31381 142.649166C174.64099 142.649166 174.94599 142.721041 175.22849 142.873541C175.51099 143.016979 175.75756 143.218541 175.96381 143.474166C176.1747 143.72979 176.336 144.02573 176.4572 144.36198C176.5782 144.69823 176.6366 145.05698 176.6366 145.43823C176.6366 145.73417 176.596 145.99854 176.511 146.23198C176.4257 146.4651 176.3091 146.66229 176.1613 146.82385C176.01318 146.9851 175.83381 147.10635 175.62756 147.19604C175.42131 147.27667 175.19256 147.32135 174.94599 147.32135C174.61881 147.32135 174.31381 147.24979 174.03568 147.10167C173.74881 146.95385 173.50662 146.75635 173.29599 146.50542C173.08506 146.24979 172.92381 145.95385 172.80287 145.6176C172.68162 145.28135 172.62349 144.91792 172.62349 144.53698C172.62349 144.23667 172.66381 143.97198 172.74881 143.73885C172.83412 143.505729 172.95068 143.308229 173.09881 143.146979C173.24662 142.985416 173.42599 142.864479 173.63224 142.774791C173.83849 142.694166 174.06724 142.649166 174.31381 142.649166Z' fill='#800000'/>
+<path d='M177.5536 143.568541C177.5583 143.267916 177.6479 143.034791 177.8092 142.877916C177.9798 142.721041 178.2039 142.640104 178.4954 142.640104C178.6836 142.640104 178.872 142.676041 179.0558 142.747916C179.2442 142.824166 179.4101 142.922604 179.5579 143.052604L179.3876 143.433854C179.3742 143.460729 179.3608 143.478854 179.3517 143.492291C179.3339 143.505729 179.3158 143.510104 179.2889 143.510104C179.2667 143.510104 179.2442 143.501041 179.2126 143.474166C179.1814 143.456354 179.1454 143.429479 179.1008 143.402604C179.0558 143.375729 179.002 143.348541 178.9483 143.330729C178.8854 143.303854 178.8183 143.294791 178.7373 143.294791C178.6164 143.294791 178.5223 143.330729 178.4504 143.402604C178.3789 143.478854 178.3429 143.590729 178.3429 143.74323C178.3429 143.75229 178.3429 143.76573 178.3473 143.78354C178.3473 143.80167 178.3473 143.83292 178.3564 143.87792C178.3564 143.9226 178.3654 143.98104 178.3742 144.05729C178.3833 144.13323 178.3967 144.23198 178.4101 144.35323L178.6836 146.58604H179.8808L179.9483 147.16448H178.7554L178.9483 148.72948H178.5311C178.482 148.72948 178.4461 148.71604 178.4101 148.68448C178.3833 148.6576 178.3564 148.62167 178.3429 148.57698L178.002 147.17354L177.3026 147.07917L177.2667 146.76104C177.2623 146.7026 177.2711 146.65792 177.2983 146.63104C177.3204 146.59948 177.3564 146.58604 177.3967 146.58604H177.9036L177.6254 144.3126C177.6076 144.17385 177.5942 144.05729 177.5851 143.97198C177.5717 143.88667 177.567 143.8151 177.5583 143.76135C177.5583 143.707291 177.5536 143.666979 177.5536 143.635729V143.568541Z' fill='#800000'/>
+<path d='M188.5715 146.37979C188.5715 146.78792 188.5131 147.16885 188.3922 147.50979C188.2756 147.85948 188.1053 148.15542 187.8856 148.40667C187.6659 148.6576 187.3969 148.8551 187.0828 148.99854C186.7644 149.13729 186.4103 149.20917 186.0156 149.20917C185.5359 149.20917 185.0875 149.1151 184.6794 148.93104C184.2669 148.74729 183.9081 148.48729 183.6078 148.15542C183.3075 147.82354 183.0697 147.42917 182.8994 146.97167C182.729 146.50979 182.6437 146.0076 182.6437 145.46073C182.6437 145.0526 182.7022 144.67604 182.8231 144.33073C182.9397 143.98542 183.11 143.689479 183.3344 143.438229C183.554 143.191666 183.8231 142.994479 184.1415 142.855416C184.4553 142.716354 184.8097 142.644791 185.204 142.644791C185.6884 142.644791 186.1369 142.738854 186.5447 142.918229C186.9572 143.106666 187.3159 143.362291 187.6119 143.689479C187.9169 144.02135 188.15 144.41573 188.3203 144.87323C188.4862 145.33073 188.5715 145.83292 188.5715 146.37979ZM187.7106 146.36198C187.7106 145.9001 187.6522 145.48292 187.5312 145.11542C187.4147 144.73885 187.2487 144.42479 187.0381 144.16479C186.8272 143.9001 186.5715 143.698541 186.2756 143.559479C185.9797 143.420416 185.6525 143.348541 185.2984 143.348541C185.0203 143.348541 184.769 143.397916 184.5494 143.501041C184.3297 143.599791 184.1415 143.74323 183.9844 143.92698C183.8275 144.11104 183.7109 144.3351 183.6303 144.59979C183.545 144.86417 183.5047 145.15573 183.5047 145.48292C183.5047 145.94479 183.5631 146.36198 183.684 146.72948C183.8006 147.10635 183.9665 147.4201 184.1772 147.68479C184.3925 147.94917 184.6481 148.15104 184.9397 148.2901C185.2356 148.43354 185.5584 148.5051 185.9125 148.5051C186.1906 148.5051 186.4415 148.45604 186.6612 148.3526C186.8856 148.24948 187.074 148.10604 187.2262 147.92229C187.3834 147.73854 187.5 147.50979 187.585 147.24979C187.6703 146.98073 187.7106 146.68917 187.7106 146.36198ZM190.6015 146.30823L190.9512 149.13729H190.1128L189.3281 142.711979H190.1622L190.5253 145.66229H190.8884C191.0187 145.66229 191.1128 145.64448 191.1709 145.6176C191.2294 145.58167 191.2831 145.53229 191.3281 145.45604L193.014 142.891354C193.0453 142.832916 193.0856 142.792604 193.1306 142.756666C193.1753 142.729791 193.2515 142.711979 193.3637 142.711979H194.0856L192.1484 145.75667C192.1037 145.84167 192.0544 145.90448 192.0006 145.95823C191.9422 146.00323 191.8794 146.04354 191.8078 146.07479C191.92 146.12417 192.0365 146.21854 192.1575 146.35729L194.7222 149.13729H194.0094C193.9197 149.13729 193.839 149.12385 193.7719 149.09698C193.7044 149.0701 193.6372 149.01635 193.5744 148.93573L191.3503 146.49635C191.2875 146.42917 191.2203 146.37979 191.1575 146.35292C191.0859 146.32167 191.0006 146.30823 190.8975 146.30823H190.6015ZM194.7302 143.205104C194.7302 143.124479 194.7436 143.052604 194.7705 142.981041C194.8021 142.918229 194.8424 142.855416 194.8874 142.806041C194.9411 142.756666 194.9993 142.716354 195.0665 142.685104C195.134 142.658229 195.2102 142.644791 195.2865 142.644791C195.3624 142.644791 195.4386 142.658229 195.5062 142.685104C195.5733 142.716354 195.6361 142.756666 195.6855 142.806041C195.7346 142.855416 195.7752 142.918229 195.8065 142.981041C195.8377 143.052604 195.8511 143.124479 195.8511 143.205104C195.8511 143.281354 195.8377 143.357604 195.8065 143.424791C195.7752 143.492291 195.7346 143.555104 195.6855 143.604166C195.6361 143.653541 195.5733 143.693854 195.5062 143.72542C195.4386 143.75667 195.3624 143.7701 195.2865 143.7701C195.2102 143.7701 195.134 143.75667 195.0665 143.72542C194.9993 143.693854 194.9411 143.653541 194.8874 143.604166C194.8424 143.555104 194.8021 143.492291 194.7705 143.424791C194.7436 143.357604 194.7302 143.281354 194.7302 143.205104ZM195.1071 146.56823C195.1071 146.48729 195.1205 146.41573 195.1474 146.34385C195.1787 146.28104 195.219 146.21854 195.264 146.16917C195.3177 146.11979 195.3761 146.07948 195.4433 146.04792C195.5105 146.02104 195.5868 146.0076 195.663 146.0076C195.7393 146.0076 195.8155 146.02104 195.8827 146.04792C195.9499 146.07948 196.0127 146.11979 196.0621 146.16917C196.1115 146.21854 196.1518 146.28104 196.183 146.34385C196.2146 146.41573 196.228 146.48729 196.228 146.56823C196.228 146.64448 196.2146 146.72073 196.183 146.78792C196.1518 146.8551 196.1115 146.91792 196.0621 146.96729C196.0127 147.01667 195.9499 147.05698 195.8827 147.08823C195.8155 147.11979 195.7393 147.13323 195.663 147.13323C195.5868 147.13323 195.5105 147.11979 195.4433 147.08823C195.3761 147.05698 195.3177 147.01667 195.264 146.96729C195.219 146.91792 195.1787 146.8551 195.1474 146.78792C195.1205 146.72073 195.1071 146.64448 195.1071 146.56823Z' fill='#800000'/>
+<path d='M166.128901 141.320312H196.6641' stroke='#800000' fill='none' stroke-width='.379' stroke-miterlimit='10'/>
+<path d='M138.1728 131.42552C138.1728 131.86927 138.20405 132.28177 138.26686 132.67646C138.32499 133.06209 138.41467 133.43865 138.53124 133.7974C138.64811 134.15615 138.79155 134.50584 138.96186 134.84677C139.13218 135.18302 139.32968 135.52365 139.54936 135.86459C139.60749 135.94959 139.62561 136.01709 139.60749 136.06615C139.58968 136.11552 139.5628 136.15146 139.52249 136.18302L139.20405 136.39365C138.85436 135.90927 138.56718 135.45209 138.34749 135.02615C138.1278 134.59552 137.953112 134.17865 137.827488 133.7749C137.697487 133.37146 137.612175 132.9724 137.5628 132.57771C137.513425 132.17865 137.491237 131.77084 137.491237 131.35365C137.491237 131.10709 137.504675 130.84709 137.53155 130.57802C137.558425 130.308962 137.598737 130.035524 137.657175 129.761774C137.7153 129.488337 137.787175 129.214899 137.872175 128.936774C137.961862 128.667712 138.069675 128.39865 138.19499 128.14334L138.55842 128.34959C138.60749 128.38084 138.64342 128.41677 138.6703 128.466149C138.70186 128.515524 138.69718 128.582712 138.66593 128.672399C138.5853 128.873962 138.51342 129.089274 138.45061 129.318024C138.3878 129.546774 138.33874 129.784274 138.29374 130.022087C138.2578 130.259587 138.22655 130.4974 138.20405 130.73927C138.18155 130.97271 138.1728 131.20584 138.1728 131.42552Z' fill='#800000'/>
+<path d='M144.14327 130.111774H142.88327L143.16108 132.3849H144.42108C144.81108 132.3849 145.09827 132.2999 145.29108 132.12927C145.47921 131.96365 145.57358 131.7349 145.57358 131.4524C145.57358 131.24615 145.54202 131.06209 145.48389 130.89646C145.42546 130.73052 145.33577 130.59146 145.21921 130.4749C145.09827 130.358337 144.95014 130.268649 144.77077 130.205837C144.59139 130.143024 144.38077 130.111774 144.14327 130.111774ZM143.51077 135.21427H144.58264C144.97264 135.21427 145.25952 135.13802 145.44358 134.98115C145.62733 134.82865 145.72139 134.5999 145.72139 134.29052C145.72139 134.09771 145.69014 133.91865 145.63171 133.75709C145.57358 133.59552 145.47921 133.45677 145.36264 133.34021C145.23733 133.22802 145.08921 133.13834 144.90546 133.07115C144.72608 133.00834 144.51514 132.97677 144.27327 132.97677H143.23733L143.51077 135.21427ZM144.65889 135.87334H142.75327L141.96389 129.448024H144.07577C144.43921 129.448024 144.76202 129.497399 145.04889 129.596149C145.34046 129.694587 145.58233 129.833649 145.78421 130.013024C145.98608 130.192399 146.13858 130.407712 146.24171 130.64959C146.34921 130.90084 146.40296 131.1699 146.40296 131.46584C146.40296 131.80209 146.30452 132.08021 146.11608 132.29521C145.91889 132.51052 145.63171 132.66302 145.24608 132.74834C145.46577 132.81552 145.65858 132.90959 145.82921 133.02177C145.99046 133.13396 146.12952 133.26396 146.24171 133.41177C146.34921 133.5599 146.42983 133.71677 146.48389 133.89615C146.54202 134.06646 146.56889 134.25021 146.56889 134.43865C146.56889 134.65834 146.53296 134.85552 146.45671 135.0349C146.38046 135.2099 146.26858 135.3624 146.11171 135.48334C145.95452 135.60896 145.75733 135.70771 145.51514 135.77021C145.27764 135.84209 144.99046 135.87334 144.65889 135.87334ZM148.2048 129.448024L148.9894 135.87334H148.1463L147.3616 129.448024H148.2048ZM153.4683 134.87802L153.7149 135.2324C153.5446 135.45209 153.3293 135.6224 153.0649 135.74802C152.8002 135.87334 152.5043 135.93615 152.1771 135.93615C151.8543 135.93615 151.5627 135.8824 151.3027 135.77021C151.0471 135.65834 150.8274 135.51021 150.648 135.32646C150.4687 135.14271 150.3296 134.9274 150.2355 134.68521C150.1412 134.44302 150.0921 134.19209 150.0921 133.9274C150.0921 133.6899 150.1277 133.4924 150.1996 133.33115C150.2715 133.16959 150.3655 133.03521 150.4821 132.92302C150.5987 132.81084 150.733 132.72115 150.8812 132.64959C151.029 132.57771 151.1815 132.5149 151.3387 132.45677C151.4955 132.39834 151.648 132.34459 151.7958 132.29084C151.944 132.2324 152.0783 132.1699 152.1949 132.09365S152.4058 131.92771 152.4774 131.81552C152.5493 131.70802 152.5849 131.57334 152.5849 131.4074C152.5849 131.21021 152.5537 131.03084 152.4908 130.8649C152.428 130.70365 152.3383 130.56459 152.2265 130.44802C152.1096 130.331462 151.9662 130.241774 151.8049 130.174274C151.6346 130.107087 151.4505 130.075837 151.2443 130.075837C151.0202 130.075837 150.8318 130.111774 150.684 130.174274C150.5358 130.246149 150.4102 130.318024 150.3071 130.398649C150.204 130.48396 150.1233 130.5599 150.0562 130.62271C149.989 130.69459 149.9305 130.72584 149.8724 130.72584C149.8318 130.72584 149.7915 130.71709 149.7558 130.69459C149.7199 130.67209 149.6883 130.64521 149.6662 130.61396L149.3702 130.214899C149.563 129.959274 149.814 129.753024 150.1099 129.600524C150.4149 129.452399 150.7555 129.376149 151.1368 129.376149C151.4821 129.376149 151.7958 129.434587 152.074 129.555524C152.3518 129.676774 152.5896 129.838024 152.7824 130.039899C152.9796 130.241774 153.1321 130.47927 153.2352 130.74834C153.3383 131.02177 153.3921 131.30896 153.3921 131.61365C153.3921 131.83334 153.3562 132.02177 153.2846 132.17865C153.2127 132.33552 153.1187 132.46584 153.0021 132.57771C152.8855 132.6899 152.7508 132.77959 152.603 132.85584C152.4505 132.93209 152.298 132.99927 152.1412 133.06209C151.9843 133.12021 151.8318 133.17865 151.6793 133.24146C151.5315 133.29521 151.3968 133.36709 151.2802 133.43865C151.1637 133.51927 151.0696 133.60896 150.9977 133.71677C150.9258 133.8199 150.8902 133.9499 150.8902 134.10677C150.8902 134.26365 150.9171 134.41177 150.9708 134.55084C151.0246 134.68959 151.1052 134.81084 151.204 134.90959C151.3115 135.01709 151.4371 135.09771 151.5852 135.15615C151.733 135.21427 151.9033 135.24584 152.0962 135.24584C152.2846 135.24584 152.4415 135.21896 152.5671 135.16959C152.6927 135.11584 152.8002 135.0574 152.8899 134.99927C152.9752 134.93646 153.0468 134.87802 153.1052 134.82865C153.1633 134.7749 153.2174 134.74802 153.2665 134.74802C153.3071 134.74802 153.3427 134.75709 153.3743 134.78396C153.4055 134.80177 153.4371 134.83771 153.4683 134.87802ZM158.9964 135.16959L159.0814 135.87334H154.4408L154.3598 135.16959H156.2611L155.5617 129.448024H156.3958L157.1042 135.16959H158.9964Z' fill='#800000'/>
+<path d='M161.5391 129.335837L164.7723 135.95427H164.4448C164.3507 135.95427 164.2654 135.9274 164.1891 135.87802C164.1129 135.82865 164.0548 135.75677 164.0098 135.67177L160.7591 129.039899H161.0863C161.1669 129.039899 161.2523 129.066774 161.3376 129.116149C161.4226 129.165524 161.4898 129.241774 161.5391 129.335837Z' fill='#800000'/>
+<path d='M175.5846 135.87334H174.9255C174.8537 135.87334 174.7865 135.85115 174.7237 135.81084C174.6652 135.77021 174.6249 135.72115 174.6115 135.67177L172.8046 131.1249C172.7777 131.04865 172.7508 130.96365 172.7237 130.87834C172.6968 130.79334 172.6699 130.69896 172.643 130.6049C172.634 130.69896 172.6252 130.79334 172.6162 130.87834C172.6071 130.96365 172.5937 131.04865 172.5802 131.1249L171.7777 135.67177C171.7643 135.7299 171.7327 135.77927 171.6924 135.81521C171.6477 135.85552 171.5893 135.87334 171.513 135.87334H171.3202C171.2487 135.87334 171.1858 135.85115 171.1321 135.81084C171.0783 135.77021 171.0377 135.72115 171.0155 135.67177L169.0962 131.1249C169.0649 131.04865 169.029 130.96365 169.0021 130.87396C168.9662 130.78427 168.9349 130.69021 168.9033 130.59146C168.899 130.68552 168.8899 130.7799 168.8855 130.87396C168.8812 130.96365 168.8721 131.04865 168.8677 131.1249L168.1727 135.67177C168.168 135.7299 168.1412 135.77927 168.0965 135.81521C168.0515 135.85552 167.9933 135.87334 167.9171 135.87334H167.258L168.3162 129.448024H169.0693L171.159 134.39365C171.1768 134.44302 171.1949 134.4924 171.2171 134.55084C171.2396 134.60896 171.2574 134.6674 171.2799 134.72552C171.2846 134.6674 171.2933 134.60896 171.298 134.55084C171.3068 134.4924 171.3158 134.44302 171.3202 134.39365L172.1902 129.448024H172.948L175.5846 135.87334Z' fill='#800000'/>
+<path d='M178.7977 131.82896H176.6052L177.8471 134.48334L177.9683 134.76584C178.013 134.86896 178.058 134.98552 178.1027 135.11115C178.1162 134.99021 178.1343 134.87365 178.1565 134.76584C178.179 134.66271 178.1968 134.56865 178.2105 134.48802L178.7977 131.82896ZM180.1924 129.448024L178.6183 135.87334H177.7665L174.6187 129.448024H175.2733C175.3405 129.448024 175.4033 129.465837 175.4574 129.510837C175.5155 129.546774 175.5558 129.596149 175.5827 129.649899L176.318 131.21927H178.9324L179.2821 129.649899C179.2999 129.591462 179.3315 129.542087 179.3718 129.501774C179.4121 129.465837 179.4702 129.448024 179.5465 129.448024H180.1924ZM181.8505 129.448024L182.6351 135.87334H181.792L181.0073 129.448024H181.8505ZM188.0872 135.16959L188.1722 135.87334H183.5316L183.4506 135.16959H185.3519L184.6525 129.448024H185.4865L186.195 135.16959H188.0872Z' fill='#800000'/>
+<path d='M190.6318 129.335837L193.8649 135.95427H193.5374C193.4433 135.95427 193.358 135.9274 193.2818 135.87802C193.2055 135.82865 193.1474 135.75677 193.1024 135.67177L189.8518 129.039899H190.179C190.2596 129.039899 190.3449 129.066774 190.4302 129.116149C190.5152 129.165524 190.5824 129.241774 190.6318 129.335837Z' fill='#800000'/>
+<path d='M201.8076 133.11146C201.8076 133.51927 201.7491 133.89146 201.6282 134.22802C201.5069 134.56865 201.3366 134.86021 201.1169 135.10677C200.8929 135.34896 200.6238 135.53709 200.3054 135.67177C199.9869 135.80615 199.6329 135.87334 199.2382 135.87334H197.0188L196.2294 129.448024H198.4444C198.9288 129.448024 199.3773 129.537712 199.7898 129.712712C200.1979 129.887399 200.5519 130.138649 200.8526 130.46146C201.1529 130.7799 201.386 131.16521 201.5563 131.61834C201.7223 132.06677 201.8076 132.56427 201.8076 133.11146ZM200.9419 133.09334C200.9419 132.63146 200.8838 132.21459 200.7673 131.85146C200.646 131.48365 200.4804 131.1699 200.2694 130.91865C200.0588 130.65865 199.8032 130.46584 199.5073 130.326774C199.2113 130.192399 198.8841 130.125212 198.5298 130.125212H197.1532L197.781 135.19209H199.1576C199.4354 135.19209 199.6866 135.14271 199.9063 135.04396C200.126 134.9499 200.3144 134.81084 200.4713 134.63146C200.6238 134.44771 200.7404 134.22802 200.821 133.96771C200.9016 133.70771 200.9419 133.41615 200.9419 133.09334ZM204.12 135.1874H206.9359L207.0212 135.87334H203.3625L202.5731 129.448024H206.2365L206.3219 130.129587H203.5012L203.775 132.36271H206.0437L206.1291 133.02177H203.8556L204.12 135.1874ZM210.8451 131.82896H208.6526L209.8945 134.48334L210.0158 134.76584C210.0605 134.86896 210.1055 134.98552 210.1501 135.11115C210.1636 134.99021 210.1817 134.87365 210.2039 134.76584C210.2264 134.66271 210.2442 134.56865 210.258 134.48802L210.8451 131.82896ZM212.2398 129.448024L210.6658 135.87334H209.8139L206.6661 129.448024H207.3208C207.388 129.448024 207.4508 129.465837 207.5048 129.510837C207.563 129.546774 207.6033 129.596149 207.6301 129.649899L208.3655 131.21927H210.9798L211.3295 129.649899C211.3473 129.591462 211.3789 129.542087 211.4192 129.501774C211.4595 129.465837 211.5176 129.448024 211.5939 129.448024H212.2398ZM218.6329 133.11146C218.6329 133.51927 218.5744 133.89146 218.4535 134.22802C218.3323 134.56865 218.1619 134.86021 217.9423 135.10677C217.7182 135.34896 217.4491 135.53709 217.1307 135.67177C216.8123 135.80615 216.4582 135.87334 216.0635 135.87334H213.8441L213.0548 129.448024H215.2698C215.7541 129.448024 216.2026 129.537712 216.6151 129.712712C217.0232 129.887399 217.3773 130.138649 217.6779 130.46146C217.9782 130.7799 218.2113 131.16521 218.3816 131.61834C218.5476 132.06677 218.6329 132.56427 218.6329 133.11146ZM217.7672 133.09334C217.7672 132.63146 217.7091 132.21459 217.5926 131.85146C217.4713 131.48365 217.3057 131.1699 217.0948 130.91865C216.8841 130.65865 216.6285 130.46584 216.3326 130.326774C216.0366 130.192399 215.7094 130.125212 215.3551 130.125212H213.9785L214.6063 135.19209H215.9829C216.2607 135.19209 216.5119 135.14271 216.7316 135.04396C216.9513 134.9499 217.1398 134.81084 217.2966 134.63146C217.4491 134.44771 217.5657 134.22802 217.6463 133.96771C217.7269 133.70771 217.7672 133.41615 217.7672 133.09334Z' fill='#800000'/>
+<path d='M222.3269 133.11146C222.3269 132.69427 222.2954 132.29084 222.2373 131.90521C222.1744 131.51521 222.0848 131.13834 221.9682 130.77521C221.8469 130.407712 221.7035 130.048962 221.5332 129.703649C221.3629 129.358337 221.1701 129.013024 220.9504 128.672399C220.9188 128.627399 220.901 128.587087 220.8919 128.551149C220.8829 128.519899 220.8829 128.488337 220.8876 128.461462C220.8919 128.43927 220.9054 128.41677 220.9188 128.39865C220.9323 128.38084 220.9504 128.36302 220.9726 128.34959L221.291 128.14334C221.6407 128.627399 221.9279 129.084899 222.1476 129.510837C222.3673 129.936774 222.5419 130.353649 222.6676 130.7574C222.7932 131.16084 222.8785 131.5599 222.9276 131.95896C222.9769 132.35365 222.9994 132.76177 222.9994 133.17865C222.9994 133.4299 222.986 133.6899 222.9591 133.95896C222.9323 134.22802 222.8919 134.50146 222.8379 134.7749C222.7798 135.04834 222.7079 135.32209 222.6229 135.59552C222.5332 135.86896 222.4254 136.13365 222.3044 136.39365L221.9323 136.18302C221.8829 136.15146 221.8469 136.11552 221.8201 136.06615C221.7932 136.01709 221.7979 135.94959 221.8291 135.86459C221.9098 135.66271 221.9816 135.4474 222.0398 135.21896C222.1026 134.99021 222.1563 134.7524 222.2013 134.5149C222.2416 134.27709 222.2732 134.03521 222.2954 133.7974C222.3179 133.5599 222.3269 133.33115 222.3269 133.11146Z' fill='#800000'/>
+<path d='M153.762 119.453H43.2109L51.7148 98.191H145.258Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M75.67291 106.86617H72.23509V109.30242H75.01541V110.05961H72.23509V112.43117H75.66791V113.21836H71.268844V106.078982H75.66791L75.67291 106.86617Z'/>
+<path d='M77.50689 110.39336L77.4372 110.94148C77.4072 111.06617 77.32752 111.12586 77.20314 111.12586H76.67002V106.078982H77.56189V109.79554C77.75595 110.00992 77.96533 110.18429 78.1897 110.30867C78.41877 110.43336 78.66283 110.49804 78.92689 110.49804C79.28064 110.49804 79.5447 110.39336 79.72408 110.18429C79.89345 109.96992 79.98314 109.67617 79.98314 109.29242V106.078982H80.875V109.29242C80.875 109.57648 80.84 109.84054 80.7653 110.07461C80.6906 110.30867 80.586 110.51304 80.4416 110.68242C80.30189 110.84679 80.12752 110.97648 79.91345 111.07117C79.70408 111.16086 79.46002 111.20554 79.18595 111.20554C79.00658 111.20554 78.8372 111.18554 78.68783 111.15086C78.52845 111.11086 78.38377 111.05617 78.24939 110.98148C78.1097 110.91179 77.98033 110.82711 77.85564 110.72742C77.73127 110.62773 77.61658 110.51804 77.50689 110.39336Z'/>
+<path d='M83.7082 105.999295C83.9376 105.999295 84.1617 106.038982 84.376 106.118982C84.5901 106.20367 84.7745 106.313045 84.9288 106.457732L84.6698 106.88117C84.6351 106.935857 84.5901 106.965857 84.5454 106.965857C84.5204 106.965857 84.4854 106.955857 84.4557 106.925857C84.4157 106.90617 84.376 106.87617 84.326 106.84617C84.2763 106.816482 84.2163 106.786482 84.1467 106.766482C84.082 106.736482 84.0023 106.726795 83.9076 106.726795C83.7432 106.726795 83.6135 106.776482 83.5088 106.88117C83.4045 106.985857 83.3545 107.14023 83.3545 107.35429V110.38367H84.8142V111.02617H83.3545V112.76492H82.906C82.8513 112.76492 82.8017 112.74992 82.7717 112.71523C82.7317 112.68523 82.712 112.64555 82.702 112.59554L82.4976 111.03617L81.6707 110.93148V110.57773C81.6707 110.51304 81.6904 110.46336 81.7254 110.43336C81.7604 110.39836 81.8051 110.38367 81.8598 110.38367H82.4676V107.29461C82.4676 106.87617 82.5723 106.55742 82.7917 106.333045C83.0007 106.108982 83.3098 105.999295 83.7082 105.999295ZM86.5723 110.11461L86.5126 110.88179C86.4976 110.97148 86.4726 111.03617 86.4379 111.07117C86.4029 111.10586 86.3332 111.12586 86.2385 111.12586H85.7304V106.078982H86.6223V109.26742C86.687 109.44179 86.7567 109.59648 86.8313 109.72586C86.911 109.86554 87.0007 109.97492 87.1004 110.06461C87.1951 110.15929 87.3098 110.22898 87.4292 110.27398C87.5588 110.31867 87.6982 110.34367 87.8579 110.34367C87.9723 110.34367 88.072 110.33367 88.1617 110.31367C88.2513 110.29398 88.321 110.28398 88.366 110.28398C88.4457 110.28398 88.4954 110.32367 88.5154 110.40836L88.5801 111.07117C88.5054 111.12086 88.4157 111.15586 88.316 111.18054C88.2213 111.20554 88.117 111.21554 88.0123 111.21554C87.6785 111.21554 87.3945 111.12086 87.1604 110.92148C86.926 110.73242 86.7317 110.45836 86.5723 110.11461Z'/>
+<path d='M91.2824 111.20554C90.9087 111.20554 90.5749 111.14586 90.2759 111.02117C89.9818 110.89679 89.7278 110.72242 89.5187 110.49804C89.3093 110.27398 89.1499 109.99992 89.0403 109.67617C88.9259 109.35711 88.8709 108.99867 88.8709 108.60492C88.8709 108.20648 88.9259 107.84773 89.0403 107.52867C89.1499 107.20992 89.3093 106.935857 89.5187 106.711795C89.7278 106.48742 89.9818 106.313045 90.2759 106.18867C90.5749 106.068982 90.9087 106.009295 91.2824 106.009295C91.6509 106.009295 91.9846 106.068982 92.2787 106.18867C92.5728 106.313045 92.8268 106.48742 93.0359 106.711795C93.2453 106.935857 93.4046 107.20992 93.5143 107.52867C93.629 107.84773 93.6837 108.20648 93.6837 108.60492C93.6837 108.99867 93.629 109.35711 93.5143 109.67617C93.4046 109.99992 93.2453 110.27398 93.0359 110.49804C92.8268 110.72242 92.5728 110.89679 92.2787 111.02117C91.9846 111.14586 91.6509 111.20554 91.2824 111.20554ZM91.2824 106.701795C90.779 106.701795 90.4006 106.86617 90.1562 107.20492C89.9071 107.53367 89.7828 108.00211 89.7828 108.59992C89.7828 108.89898 89.8124 109.16804 89.8774 109.40711C89.9371 109.64117 90.0268 109.84054 90.1562 110.00492C90.2759 110.16929 90.4353 110.29398 90.6246 110.37867C90.809 110.46336 91.0281 110.50804 91.2824 110.50804C91.7806 110.50804 92.1543 110.33867 92.3984 110.00492C92.6424 109.67117 92.7668 109.20273 92.7668 108.59992C92.7668 108.00211 92.6424 107.53367 92.3984 107.20492C92.1543 106.86617 91.7806 106.701795 91.2824 106.701795ZM95.6956 107.29461V109.73586C95.8799 109.97992 96.079 110.16429 96.2934 110.29898C96.5124 110.43336 96.7665 110.49804 97.0556 110.49804C97.2599 110.49804 97.4393 110.46336 97.5987 110.39336C97.7581 110.32367 97.8928 110.21429 98.0021 110.06461C98.1118 109.91023 98.1965 109.71586 98.2562 109.48179C98.3112 109.24773 98.3409 108.96367 98.3409 108.63492C98.3409 108.01211 98.2165 107.53367 97.9624 107.19992C97.7084 106.86617 97.3496 106.696795 96.8762 106.696795C96.6371 106.696795 96.4228 106.741482 96.2287 106.83117C96.0343 106.920857 95.8599 107.075545 95.6956 107.29461ZM95.6506 110.34367L95.5709 110.94148C95.5409 111.06617 95.4612 111.12586 95.3368 111.12586H94.8037V104.37023H95.6956V106.602107C95.8649 106.417732 96.0593 106.268357 96.2834 106.16867C96.5024 106.058982 96.7665 106.009295 97.0756 106.009295C97.4143 106.009295 97.7184 106.078982 97.9871 106.20867C98.2612 106.348045 98.4906 106.52742 98.6749 106.766482C98.864 106.995545 99.0087 107.27461 99.1084 107.59367C99.2077 107.91742 99.2578 108.26117 99.2578 108.63492C99.2578 109.05336 99.2128 109.42211 99.1231 109.74586S98.904 110.33867 98.7396 110.55304C98.5753 110.77211 98.3709 110.93648 98.1368 111.05117C97.9024 111.16086 97.6384 111.21554 97.3446 111.21554C96.9859 111.21554 96.6671 111.13586 96.3881 110.97648C96.109 110.81711 95.8649 110.60773 95.6506 110.34367Z'/>
+<path d='M104.6103 111.12586H103.9078C103.8481 111.12586 103.7931 111.11086 103.7484 111.07117C103.6984 111.04117 103.6637 110.99648 103.6437 110.94148L102.3334 107.76804C102.2787 107.62836 102.2287 107.47898 102.184 107.32461C102.149 107.47898 102.1043 107.62336 102.0493 107.76304L100.6993 110.94148C100.6843 110.98648 100.6493 111.03117 100.6096 111.07117C100.5596 111.10586 100.4999 111.12586 100.4253 111.12586H99.6581L101.7406 106.373045L100.8187 104.37023H101.4765C101.5712 104.37023 101.6359 104.38992 101.6859 104.42992C101.7256 104.46961 101.7656 104.52461 101.7953 104.58929L104.6103 111.12586Z'/>
+<path d='M110.2557 109.51679H109.1101V112.45617H110.2557C110.8288 112.45617 111.2523 112.32648 111.5313 112.07242C111.8151 111.81836 111.9548 111.45961 111.9548 111.00617C111.9548 110.78711 111.9198 110.58773 111.8451 110.40336C111.7704 110.2193 111.6607 110.06461 111.5213 109.93523C111.372 109.80054 111.1976 109.70086 110.9832 109.62617C110.7738 109.55148 110.5298 109.51679 110.2557 109.51679ZM110.2557 113.21836H108.1485V106.078982H109.1101V108.74929H110.2557C110.6892 108.74929 111.0679 108.80429 111.4017 108.91867C111.7304 109.02836 112.0095 109.18273 112.2288 109.38211C112.4579 109.58148 112.6273 109.82054 112.742 110.09461C112.8567 110.36867 112.9163 110.67242 112.9163 111.00617C112.9163 111.34023 112.8613 111.64398 112.757 111.91804C112.6473 112.19211 112.4829 112.42117 112.2635 112.61554C112.0445 112.80992 111.7704 112.95429 111.4317 113.06398C111.1029 113.16367 110.7092 113.21836 110.2557 113.21836Z'/>
+<path d='M115.7781 111.20554C115.4044 111.20554 115.0706 111.14586 114.7716 111.02117C114.4775 110.89679 114.2235 110.72242 114.0144 110.49804C113.805 110.27398 113.6456 109.99992 113.536 109.67617C113.4216 109.35711 113.3666 108.99867 113.3666 108.60492C113.3666 108.20648 113.4216 107.84773 113.536 107.52867C113.6456 107.20992 113.805 106.935857 114.0144 106.711795C114.2235 106.48742 114.4775 106.313045 114.7716 106.18867C115.0706 106.068982 115.4044 106.009295 115.7781 106.009295C116.1466 106.009295 116.4803 106.068982 116.7744 106.18867C117.0685 106.313045 117.3225 106.48742 117.5316 106.711795C117.741 106.935857 117.9003 107.20992 118.01 107.52867C118.1247 107.84773 118.1794 108.20648 118.1794 108.60492C118.1794 108.99867 118.1247 109.35711 118.01 109.67617C117.9003 109.99992 117.741 110.27398 117.5316 110.49804C117.3225 110.72242 117.0685 110.89679 116.7744 111.02117C116.4803 111.14586 116.1466 111.20554 115.7781 111.20554ZM115.7781 106.701795C115.2747 106.701795 114.8963 106.86617 114.6519 107.20492C114.4028 107.53367 114.2785 108.00211 114.2785 108.59992C114.2785 108.89898 114.3081 109.16804 114.3731 109.40711C114.4328 109.64117 114.5225 109.84054 114.6519 110.00492C114.7716 110.16929 114.931 110.29398 115.1203 110.37867C115.3047 110.46336 115.5238 110.50804 115.7781 110.50804C116.2763 110.50804 116.65 110.33867 116.8941 110.00492C117.1381 109.67117 117.2625 109.20273 117.2625 108.59992C117.2625 108.00211 117.1381 107.53367 116.8941 107.20492C116.65 106.86617 116.2763 106.701795 115.7781 106.701795ZM121.4269 111.20554C121.0531 111.20554 120.7194 111.14586 120.4203 111.02117C120.1263 110.89679 119.8722 110.72242 119.6631 110.49804C119.4538 110.27398 119.2944 109.99992 119.1847 109.67617C119.0703 109.35711 119.0153 108.99867 119.0153 108.60492C119.0153 108.20648 119.0703 107.84773 119.1847 107.52867C119.2944 107.20992 119.4538 106.935857 119.6631 106.711795C119.8722 106.48742 120.1263 106.313045 120.4203 106.18867C120.7194 106.068982 121.0531 106.009295 121.4269 106.009295C121.7953 106.009295 122.1291 106.068982 122.4231 106.18867C122.7172 106.313045 122.9713 106.48742 123.1803 106.711795C123.3897 106.935857 123.5491 107.20992 123.6588 107.52867C123.7735 107.84773 123.8281 108.20648 123.8281 108.60492C123.8281 108.99867 123.7735 109.35711 123.6588 109.67617C123.5491 109.99992 123.3897 110.27398 123.1803 110.49804C122.9713 110.72242 122.7172 110.89679 122.4231 111.02117C122.1291 111.14586 121.7953 111.20554 121.4269 111.20554ZM121.4269 106.701795C120.9235 106.701795 120.545 106.86617 120.3006 107.20492C120.0516 107.53367 119.9272 108.00211 119.9272 108.59992C119.9272 108.89898 119.9569 109.16804 120.0219 109.40711C120.0816 109.64117 120.1713 109.84054 120.3006 110.00492C120.4203 110.16929 120.5797 110.29398 120.7691 110.37867C120.9535 110.46336 121.1725 110.50804 121.4269 110.50804C121.925 110.50804 122.2988 110.33867 122.5428 110.00492C122.7869 109.67117 122.9113 109.20273 122.9113 108.59992C122.9113 108.00211 122.7869 107.53367 122.5428 107.20492C122.2988 106.86617 121.925 106.701795 121.4269 106.701795ZM125.8647 113.41773H124.9781V106.078982H125.8647V113.41773Z'/>
+<path d='M98.4844 98.191V75.742' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M98.484355 73.2461L99.83201 76.816415L98.484355 75.64454L97.1406 76.816415Z'/>
+<path d='M98.484355 73.2461L99.83201 76.816415L98.484355 75.64454L97.1406 76.816415Z' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M59.34622 83.968305L59.49435 85.15674C59.57935 85.41674 59.68247 85.65424 59.79903 85.87424C59.92028 86.09393 60.04591 86.28206 60.18466 86.43893C60.31935 86.59612 60.45841 86.72143 60.60622 86.81112C60.75435 86.89643 60.89778 86.94112 61.04122 86.94112C61.27435 86.94112 61.45372 86.84706 61.58372 86.66331S61.77653 86.20581 61.77653 85.85174C61.77653 85.67237 61.75872 85.49299 61.72716 85.30456C61.69591 85.12518 61.64653 84.94581 61.58372 84.77549C61.5256 84.60081 61.44935 84.43924 61.35966 84.29112C61.26997 84.13893 61.16685 84.00424 61.05466 83.896743C60.94247 83.78018 60.81716 83.694868 60.6781 83.62768C60.53903 83.560493 60.3956 83.52893 60.23872 83.52893C60.07278 83.52893 59.91122 83.564868 59.75435 83.62768C59.59747 83.699243 59.45841 83.81143 59.34622 83.968305ZM59.58841 86.28206L59.66466 87.25081C59.66466 87.42987 59.57497 87.51956 59.3956 87.51956H59.000909L58.261222 81.43487H59.036847L59.27903 83.417055C59.40903 83.255493 59.56153 83.129868 59.74528 83.044868C59.92935 82.95518 60.13091 82.91018 60.35528 82.91018C60.56591 82.91018 60.7631 82.950493 60.95591 83.03143C61.14872 83.112055 61.32372 83.224243 61.48528 83.36768C61.65091 83.50643 61.79903 83.672368 61.93341 83.869868C62.06372 84.05799 62.1756 84.26893 62.27435 84.48862C62.36403 84.71268 62.44028 84.94581 62.48966 85.19268C62.53872 85.43924 62.56591 85.68143 62.56591 85.92799C62.56591 86.47049 62.4581 86.87862 62.24747 87.16112C62.03216 87.44362 61.73185 87.58237 61.34153 87.58237C61.1756 87.58237 61.00997 87.55112 60.84841 87.49268C60.69153 87.42987 60.53466 87.34018 60.38653 87.22831C60.23872 87.11612 60.09497 86.97706 59.9606 86.82018C59.82622 86.65893 59.7006 86.47956 59.58841 86.28206ZM64.32708 86.25081L64.40333 87.25081C64.40333 87.42987 64.31364 87.51956 64.12989 87.51956H63.73521L63.18833 82.972993H63.96833L64.21958 85.07581C64.40333 85.77987 64.64552 86.26424 64.94146 86.53331C65.24177 86.80237 65.58271 86.86049 65.97271 86.70362L66.11614 87.47049C65.95021 87.54206 65.78427 87.56456 65.62302 87.54674C65.46146 87.51956 65.30458 87.45706 65.15208 87.34924C64.99958 87.24612 64.85177 87.09831 64.71708 86.90987C64.57364 86.72612 64.44833 86.50643 64.32708 86.25081Z'/>
+<path d='M67.8506 83.533618C67.53653 83.533618 67.29903 83.641118 67.1331 83.851743C66.96716 84.06706 66.88653 84.38549 66.88653 84.80237C66.88653 85.08487 66.92247 85.35831 66.98966 85.61862C67.05685 85.87862 67.1556 86.10737 67.28122 86.30456C67.40653 86.50174 67.55903 86.65893 67.73841 86.77549C67.91341 86.89643 68.11497 86.95487 68.335 86.95487C68.6443 86.95487 68.8862 86.84706 69.0478 86.64081C69.2181 86.42549 69.2987 86.11174 69.2987 85.69487C69.2987 85.41237 69.2631 85.13862 69.1956 84.87862C69.1284 84.61862 69.03 84.38987 68.9043 84.19268C68.7743 83.99081 68.6218 83.833931 68.4468 83.712993C68.2675 83.591743 68.07028 83.533618 67.8506 83.533618ZM67.77435 82.91018C68.10153 82.91018 68.4065 82.982055 68.689 83.134555C68.9715 83.277993 69.2181 83.479555 69.4243 83.735181C69.6353 83.99081 69.7965 84.28674 69.9178 84.62299C70.0387 84.95924 70.0972 85.31799 70.0972 85.69924C70.0972 85.99518 70.0565 86.25956 69.9715 86.49299C69.8862 86.72612 69.7697 86.92331 69.6218 87.08487C69.4737 87.24612 69.2943 87.36737 69.0881 87.45706C68.8818 87.53768 68.6531 87.58237 68.4065 87.58237C68.07935 87.58237 67.77435 87.51081 67.49622 87.36268C67.20935 87.21487 66.96716 87.01737 66.75653 86.76643C66.5456 86.51081 66.38435 86.21487 66.26341 85.87862C66.14216 85.54237 66.08403 85.17893 66.08403 84.79799C66.08403 84.49768 66.12435 84.23299 66.20935 83.99987C66.29466 83.766743 66.41122 83.569243 66.55935 83.407993C66.70716 83.24643 66.88653 83.125493 67.09278 83.035805C67.29903 82.95518 67.52778 82.91018 67.77435 82.91018ZM74.1407 83.78893L73.9435 84.03112C73.8985 84.08049 73.8491 84.10737 73.791 84.10737C73.7282 84.10737 73.6654 84.07612 73.6026 84.01768C73.5354 83.959555 73.4591 83.892055 73.365 83.824868C73.2707 83.753306 73.1588 83.685806 73.0197 83.62768C72.8854 83.569243 72.7194 83.537993 72.5176 83.537993C72.356 83.537993 72.2125 83.564868 72.096 83.62768C71.9704 83.68143 71.8719 83.766743 71.7866 83.869868C71.7016 83.97737 71.6388 84.10737 71.5982 84.25549C71.5579 84.40799 71.5357 84.57831 71.5357 84.76206C71.5357 85.06706 71.576 85.35393 71.6566 85.61862C71.7329 85.88299 71.8404 86.11612 71.9794 86.30893C72.1185 86.50174 72.2754 86.65893 72.4591 86.76643C72.6432 86.88299 72.836 86.93674 73.0422 86.93674C73.1947 86.93674 73.32 86.91893 73.4144 86.88299C73.5129 86.84268 73.5938 86.80237 73.661 86.75737C73.7282 86.70799 73.7819 86.66768 73.8179 86.63174C73.8629 86.59143 73.9032 86.57362 73.9435 86.57362C73.9747 86.57362 74.0063 86.58268 74.0332 86.59612C74.0554 86.60956 74.0779 86.63174 74.1004 86.65424L74.3516 86.95487C74.1991 87.15643 74.0197 87.31331 73.8179 87.42112C73.616 87.52424 73.3604 87.57799 73.06 87.57799C72.7238 87.57799 72.41 87.50174 72.1229 87.34487C71.8404 87.18799 71.5938 86.98174 71.3875 86.72143C71.1813 86.46143 71.02 86.16112 70.9032 85.82487C70.7913 85.48862 70.7329 85.13424 70.7329 84.76643C70.7329 84.49299 70.7688 84.23737 70.8407 84.01331C70.9079 83.78018 71.011 83.587368 71.1454 83.42143C71.2844 83.259868 71.4504 83.134555 71.6566 83.044868C71.8538 82.95518 72.0869 82.91018 72.3516 82.91018C72.5266 82.91018 72.6879 82.923618 72.8404 82.950493C72.9885 82.977368 73.1363 83.026743 73.2754 83.089555C73.4144 83.16143 73.5579 83.251118 73.6969 83.362993C73.8357 83.47518 73.9838 83.618618 74.1407 83.78893Z'/>
+<path d='M77.039 87.00393C77.1599 87.00393 77.2586 86.99049 77.344 86.95487C77.429 86.92768 77.4965 86.88737 77.5502 86.83799C77.5996 86.78893 77.6399 86.73956 77.6624 86.67674C77.6846 86.62299 77.698 86.56456 77.698 86.51081C77.698 86.40331 77.6758 86.30018 77.6265 86.20143C77.5771 86.10268 77.4783 86.01299 77.3305 85.92331C77.1824 85.84268 76.9671 85.76206 76.6893 85.69018C76.4111 85.61393 76.0436 85.55112 75.5818 85.49299C75.6311 85.70362 75.6983 85.90549 75.7833 86.08487C75.8686 86.27331 75.9761 86.43018 76.0974 86.56924C76.2183 86.70362 76.3618 86.81112 76.519 86.88737C76.6758 86.96362 76.8505 87.00393 77.039 87.00393ZM78.3033 83.81143L78.1061 84.05799C78.0615 84.10737 78.0121 84.13424 77.9536 84.13424C77.9043 84.13424 77.8596 84.12081 77.8102 84.08956C77.7608 84.05799 77.7115 84.02237 77.6577 83.97737C77.5996 83.937055 77.5411 83.88768 77.4696 83.833931C77.4068 83.784556 77.3258 83.735181 77.2361 83.690493C77.1511 83.65018 77.048 83.614243 76.9402 83.58268C76.8236 83.55143 76.6983 83.537993 76.5546 83.537993C76.2005 83.537993 75.9358 83.645493 75.7655 83.851743C75.5861 84.06706 75.5011 84.37206 75.5011 84.77112C75.5011 84.80237 75.5011 84.83831 75.5055 84.86518C75.5055 84.90112 75.5055 84.93237 75.5055 84.96393C76.0974 85.02206 76.5818 85.10299 76.9583 85.20143C77.3349 85.30018 77.6308 85.41674 77.8461 85.54674C78.0615 85.68143 78.2093 85.83362 78.2899 85.99518C78.3708 86.16549 78.4111 86.34487 78.4111 86.54206C78.4111 86.65424 78.3843 86.77081 78.3302 86.89206C78.2811 87.01299 78.2002 87.12518 78.0927 87.22831C77.9852 87.33143 77.8461 87.41206 77.6802 87.47924C77.5143 87.54674 77.3124 87.57799 77.084 87.57799C76.8418 87.57799 76.6174 87.54206 76.4024 87.46581C76.1961 87.38956 75.9986 87.28643 75.8283 87.16112C75.649 87.02643 75.4965 86.87393 75.3621 86.69456C75.223 86.51518 75.1108 86.32237 75.0124 86.11174C74.9227 85.90112 74.8508 85.68143 74.7971 85.44799C74.7521 85.21956 74.7252 84.98643 74.7252 84.75299C74.7252 84.47049 74.7655 84.21956 74.8418 83.99081C74.918 83.762055 75.0302 83.569243 75.1736 83.412368C75.3171 83.251118 75.4921 83.125493 75.6983 83.040181C75.9046 82.95518 76.1377 82.91018 76.3977 82.91018C76.5905 82.91018 76.7699 82.928305 76.9315 82.96393C77.1018 82.995493 77.2586 83.049243 77.4068 83.125493C77.5593 83.201743 77.7071 83.295805 77.8552 83.403305C78.003 83.52018 78.1511 83.654556 78.3033 83.81143ZM81.9481 86.78893L82.15 87.07581C82.0018 87.23268 81.8225 87.35393 81.6162 87.44799C81.4056 87.53768 81.1681 87.58237 80.8943 87.58237C80.6387 87.58237 80.4056 87.54206 80.1993 87.45706C79.9978 87.37612 79.8228 87.26862 79.6793 87.12956C79.5359 86.99049 79.4281 86.83362 79.3475 86.65893C79.2756 86.47956 79.2353 86.29549 79.2353 86.10268C79.2353 85.88299 79.2803 85.70831 79.3743 85.57831C79.4684 85.44799 79.585 85.34049 79.724 85.25987C79.8631 85.17456 80.0156 85.10737 80.1768 85.05362C80.3384 85.00424 80.4909 84.94581 80.63 84.88768C80.769 84.82924 80.8856 84.75299 80.9797 84.66331C81.0737 84.57362 81.1187 84.45268 81.1187 84.30018C81.1187 84.18799 81.0962 84.08049 81.0512 83.97737C81.0109 83.878618 80.9481 83.793618 80.8631 83.717368C80.7825 83.641118 80.6837 83.58268 80.5672 83.537993C80.4459 83.492993 80.3159 83.470805 80.1681 83.470805C80.0022 83.470805 79.8631 83.492993 79.7509 83.533618C79.6434 83.57393 79.5537 83.623306 79.4818 83.672368C79.4103 83.72643 79.3518 83.775493 79.3028 83.816118C79.2534 83.85643 79.2084 83.878618 79.159 83.878618C79.11 83.878618 79.0693 83.869868 79.0337 83.847368C79.0068 83.824868 78.9753 83.797993 78.9484 83.75768L78.7512 83.45268C78.89 83.29143 79.074 83.16143 79.2937 83.053618C79.5178 82.95518 79.7734 82.901118 80.065 82.901118C80.334 82.901118 80.5762 82.946118 80.7912 83.03143C81.0109 83.11643 81.195 83.232993 81.3472 83.37643C81.5043 83.524555 81.6209 83.690493 81.7059 83.883306C81.7868 84.07612 81.8272 84.27331 81.8272 84.48393C81.8272 84.69924 81.7822 84.87424 81.6881 85.00862C81.594 85.14331 81.4775 85.25518 81.3384 85.34049C81.1993 85.42581 81.0468 85.49737 80.8856 85.55581C80.724 85.61393 80.5715 85.67237 80.4325 85.73518C80.2937 85.79331 80.1768 85.86518 80.0828 85.95018C79.9887 86.03549 79.9437 86.14768 79.9437 86.28674C79.9437 86.38518 79.9662 86.47956 80.0112 86.56924C80.0515 86.65424 80.1143 86.73049 80.1906 86.79768C80.2712 86.86518 80.3653 86.91424 80.4775 86.95487C80.5897 86.99049 80.7106 87.00862 80.845 87.00862C80.9887 87.00862 81.1097 86.99049 81.2128 86.95487C81.3159 86.92331 81.4012 86.88299 81.4728 86.84706C81.54 86.80237 81.5984 86.76643 81.6522 86.73487C81.6972 86.70362 81.7462 86.68581 81.7868 86.68581C81.8225 86.68581 81.854 86.69456 81.8765 86.71268C81.8987 86.72612 81.9256 86.75299 81.9481 86.78893ZM85.5346 86.78893L85.7365 87.07581C85.5883 87.23268 85.409 87.35393 85.2027 87.44799C84.9921 87.53768 84.7546 87.58237 84.4808 87.58237C84.2252 87.58237 83.9921 87.54206 83.7858 87.45706C83.5843 87.37612 83.4093 87.26862 83.2658 87.12956C83.1224 86.99049 83.0146 86.83362 82.934 86.65893C82.8621 86.47956 82.8218 86.29549 82.8218 86.10268C82.8218 85.88299 82.8668 85.70831 82.9608 85.57831C83.0549 85.44799 83.1715 85.34049 83.3105 85.25987C83.4496 85.17456 83.6021 85.10737 83.7633 85.05362C83.9249 85.00424 84.0774 84.94581 84.2165 84.88768C84.3555 84.82924 84.4721 84.75299 84.5661 84.66331C84.6602 84.57362 84.7052 84.45268 84.7052 84.30018C84.7052 84.18799 84.6827 84.08049 84.6377 83.97737C84.5974 83.878618 84.5346 83.793618 84.4496 83.717368C84.369 83.641118 84.2702 83.58268 84.1536 83.537993C84.0324 83.492993 83.9024 83.470805 83.7546 83.470805C83.5886 83.470805 83.4496 83.492993 83.3374 83.533618C83.2299 83.57393 83.1402 83.623306 83.0683 83.672368C82.9968 83.72643 82.9383 83.775493 82.8893 83.816118C82.8399 83.85643 82.7949 83.878618 82.7455 83.878618C82.6965 83.878618 82.6558 83.869868 82.6202 83.847368C82.5933 83.824868 82.5618 83.797993 82.5349 83.75768L82.3377 83.45268C82.4765 83.29143 82.6605 83.16143 82.8802 83.053618C83.1043 82.95518 83.3599 82.901118 83.6515 82.901118C83.9205 82.901118 84.1627 82.946118 84.3777 83.03143C84.5974 83.11643 84.7815 83.232993 84.9336 83.37643C85.0908 83.524555 85.2074 83.690493 85.2924 83.883306C85.3733 84.07612 85.4136 84.27331 85.4136 84.48393C85.4136 84.69924 85.3686 84.87424 85.2746 85.00862C85.1805 85.14331 85.064 85.25518 84.9249 85.34049C84.7858 85.42581 84.6333 85.49737 84.4721 85.55581C84.3105 85.61393 84.158 85.67237 84.019 85.73518C83.8802 85.79331 83.7633 85.86518 83.6693 85.95018C83.5752 86.03549 83.5302 86.14768 83.5302 86.28674C83.5302 86.38518 83.5527 86.47956 83.5977 86.56924C83.638 86.65424 83.7008 86.73049 83.7771 86.79768C83.8577 86.86518 83.9518 86.91424 84.064 86.95487C84.1761 86.99049 84.2971 87.00862 84.4315 87.00862C84.5752 87.00862 84.6961 86.99049 84.7993 86.95487C84.9024 86.92331 84.9877 86.88299 85.0593 86.84706C85.1265 86.80237 85.1849 86.76643 85.2386 86.73487C85.2836 86.70362 85.3327 86.68581 85.3733 86.68581C85.409 86.68581 85.4405 86.69456 85.463 86.71268C85.4852 86.72612 85.5121 86.75299 85.5346 86.78893ZM88.5023 87.00393C88.6233 87.00393 88.722 86.99049 88.8073 86.95487C88.8923 86.92768 88.9598 86.88737 89.0136 86.83799C89.0629 86.78893 89.1033 86.73956 89.1258 86.67674C89.1479 86.62299 89.1614 86.56456 89.1614 86.51081C89.1614 86.40331 89.1392 86.30018 89.0898 86.20143S88.9417 86.01299 88.7939 85.92331C88.6458 85.84268 88.4304 85.76206 88.1526 85.69018C87.8745 85.61393 87.507 85.55112 87.0451 85.49299C87.0945 85.70362 87.1617 85.90549 87.2467 86.08487C87.332 86.27331 87.4395 86.43018 87.5608 86.56924C87.6817 86.70362 87.8251 86.81112 87.9823 86.88737C88.1392 86.96362 88.3139 87.00393 88.5023 87.00393ZM89.7667 83.81143L89.5695 84.05799C89.5248 84.10737 89.4754 84.13424 89.417 84.13424C89.3676 84.13424 89.3229 84.12081 89.2736 84.08956C89.2242 84.05799 89.1748 84.02237 89.1211 83.97737C89.0629 83.937055 89.0045 83.88768 88.9329 83.833931C88.8701 83.784556 88.7892 83.735181 88.6995 83.690493C88.6145 83.65018 88.5114 83.614243 88.4036 83.58268C88.287 83.55143 88.1617 83.537993 88.0179 83.537993C87.6639 83.537993 87.3992 83.645493 87.2289 83.851743C87.0495 84.06706 86.9645 84.37206 86.9645 84.77112C86.9645 84.80237 86.9645 84.83831 86.9689 84.86518C86.9689 84.90112 86.9689 84.93237 86.9689 84.96393C87.5608 85.02206 88.0451 85.10299 88.4217 85.20143C88.7983 85.30018 89.0942 85.41674 89.3095 85.54674C89.5248 85.68143 89.6726 85.83362 89.7533 85.99518C89.8342 86.16549 89.8745 86.34487 89.8745 86.54206C89.8745 86.65424 89.8476 86.77081 89.7936 86.89206C89.7445 87.01299 89.6636 87.12518 89.5561 87.22831C89.4486 87.33143 89.3095 87.41206 89.1436 87.47924C88.9776 87.54674 88.7758 87.57799 88.5473 87.57799C88.3051 87.57799 88.0808 87.54206 87.8658 87.46581C87.6595 87.38956 87.462 87.28643 87.2917 87.16112C87.1123 87.02643 86.9598 86.87393 86.8254 86.69456C86.6864 86.51518 86.5742 86.32237 86.4758 86.11174C86.3861 85.90112 86.3142 85.68143 86.2604 85.44799C86.2154 85.21956 86.1886 84.98643 86.1886 84.75299C86.1886 84.47049 86.2289 84.21956 86.3051 83.99081C86.3814 83.762055 86.4936 83.569243 86.637 83.412368C86.7804 83.251118 86.9554 83.125493 87.1617 83.040181C87.3679 82.95518 87.6011 82.91018 87.8611 82.91018C88.0539 82.91018 88.2333 82.928305 88.3948 82.96393C88.5651 82.995493 88.722 83.049243 88.8701 83.125493C89.0226 83.201743 89.1704 83.295805 89.3186 83.403305C89.4664 83.52018 89.6145 83.654556 89.7667 83.81143ZM93.6896 86.52424L93.5415 85.34487C93.4565 85.08487 93.3533 84.84737 93.2321 84.62768C93.1155 84.40799 92.9899 84.21956 92.8555 84.05799C92.7165 83.901118 92.5774 83.775493 92.4296 83.685806C92.2815 83.596118 92.138 83.55143 91.9946 83.55143C91.7571 83.55143 91.5777 83.645493 91.4477 83.833931C91.3221 84.01768 91.2593 84.29112 91.2593 84.64549C91.2593 84.91018 91.2952 85.18362 91.3668 85.45706C91.4386 85.73049 91.5418 85.98174 91.6718 86.20143C91.8061 86.42549 91.9677 86.60956 92.1561 86.74831C92.3443 86.88737 92.5552 86.95924 92.7927 86.95924C92.9586 86.95924 93.1202 86.92768 93.2771 86.86518C93.4383 86.79768 93.5774 86.68581 93.6896 86.52424ZM94.8465 89.57768H94.0661L93.7568 87.07581C93.6268 87.23706 93.4743 87.36268 93.2858 87.44799C93.1065 87.53768 92.9002 87.58237 92.6761 87.58237C92.4655 87.58237 92.268 87.54206 92.0752 87.46143C91.8871 87.38081 91.7121 87.26862 91.5461 87.12956C91.3802 86.99049 91.2324 86.82018 91.0977 86.63174C90.9677 86.43456 90.8555 86.22831 90.7571 86.00424C90.6674 85.77987 90.5911 85.54674 90.5418 85.30018C90.4924 85.05362 90.4655 84.81143 90.4655 84.56487C90.4655 84.02674 90.5733 83.618618 90.7883 83.331743C91.0036 83.053618 91.304 82.91018 91.6943 82.91018C91.8602 82.91018 92.0215 82.941743 92.183 82.999868C92.3399 83.06268 92.4968 83.152368 92.6402 83.264555C92.7927 83.37643 92.9318 83.515493 93.0661 83.672368C93.2008 83.829555 93.3265 84.00893 93.4383 84.20612L93.3533 83.251118C93.3533 83.174868 93.3711 83.107368 93.4071 83.053618C93.443 82.999868 93.5146 82.972993 93.6177 82.972993H94.0349L94.8465 89.57768Z'/>
+<path d='M102.905248 87.34862L103.39837 87.53706C103.45681 87.55956 103.5015 87.59081 103.51962 87.6355C103.5465 87.67144 103.5465 87.71644 103.524 87.76581C103.45681 87.918 103.42087 88.06612 103.42087 88.20956C103.4165 88.35769 103.43431 88.49206 103.47462 88.62206C103.51494 88.74769 103.56431 88.86425 103.63619 88.97175C103.699 89.07487 103.76619 89.16925 103.83337 89.2455C103.86494 89.28112 103.88712 89.308 103.90056 89.3305S103.91869 89.3755 103.91869 89.39769C103.91869 89.43831 103.90056 89.47394 103.86931 89.49644L103.65869 89.6355C103.46587 89.47862 103.30431 89.31269 103.16994 89.13331C103.03087 88.94956 102.927748 88.76112 102.855873 88.56831C102.788686 88.37112 102.757436 88.16925 102.757436 87.96737C102.766186 87.76112 102.811186 87.55487 102.905248 87.34862ZM104.15619 87.34862L104.64962 87.53706C104.70775 87.55956 104.74806 87.59081 104.77494 87.6355C104.79306 87.67144 104.79744 87.71644 104.77494 87.76581C104.70775 87.918 104.67181 88.06612 104.66744 88.20956C104.66744 88.35769 104.68525 88.49206 104.72587 88.62206C104.76619 88.74769 104.81994 88.86425 104.88275 88.97175C104.95431 89.07487 105.01712 89.16925 105.08431 89.2455C105.11587 89.28112 105.13837 89.308 105.15181 89.3305S105.16962 89.3755 105.16962 89.39769C105.16962 89.43831 105.15181 89.47394 105.12025 89.49644L104.90962 89.6355C104.71681 89.47862 104.55525 89.31269 104.4165 89.13331C104.28181 88.94956 104.17869 88.76112 104.1115 88.56831C104.03962 88.37112 104.00369 88.16925 104.01275 87.96737C104.01275 87.76112 104.06212 87.55487 104.15619 87.34862Z'/>
+<path d='M106.80345 86.67175H107.90626L107.98251 87.2455H106.84814L106.89751 87.66269C106.92001 87.8555 106.96033 88.02112 107.02314 88.15581C107.07689 88.29019 107.14876 88.398 107.23376 88.483C107.31908 88.56831 107.41314 88.62644 107.52533 88.66706C107.63283 88.70269 107.74939 88.72081 107.87939 88.72081H108.1397C108.20689 88.72081 108.2472 88.75206 108.26064 88.8105L108.33689 89.223C108.18001 89.28112 108.01408 89.31269 107.83001 89.31269C107.61033 89.31269 107.40408 89.27675 107.21126 89.20487C107.02314 89.13331 106.85283 89.0255 106.70908 88.89112C106.55689 88.74769 106.43564 88.57737 106.34158 88.37987C106.24283 88.17362 106.17564 87.94487 106.14408 87.68487L106.09033 87.2455H105.4447L105.40439 86.92269C105.40001 86.85987 105.40876 86.81519 105.4447 86.78362C105.47158 86.75237 105.51658 86.72987 105.57033 86.71644L106.01876 86.658L105.41783 81.67644H105.7272C105.83939 81.67644 105.92908 81.708 105.99189 81.76175C106.05908 81.824562 106.10845 81.905187 106.1397 82.012687L106.35033 82.941124L106.80345 86.67175ZM112.2777 87.33519H111.484L111.2015 84.97675C111.1165 84.73894 111.01775 84.51925 110.90119 84.32644C110.77994 84.12925 110.65462 83.96331 110.51994 83.82425C110.38556 83.685187 110.2465 83.582062 110.09837 83.505812C109.95056 83.429562 109.8115 83.393937 109.67244 83.393937C109.43494 83.393937 109.27806 83.478937 109.18837 83.653937C109.10744 83.82894 109.08525 84.09331 109.12556 84.44769L109.46619 87.33519H108.67275L108.33181 84.44769C108.29587 84.17394 108.29587 83.92737 108.32744 83.716749C108.35869 83.505812 108.4215 83.326437 108.51556 83.178624C108.60525 83.030499 108.72181 82.918624 108.86994 82.846749C109.01775 82.766124 109.18369 82.730187 109.3765 82.730187C109.69494 82.730187 110.00431 82.828937 110.30025 83.026124C110.60525 83.227999 110.87431 83.519249 111.11181 83.90956L111.04462 83.079874C111.04462 82.887062 111.14337 82.792999 111.33619 82.792999H111.73056L112.2777 87.33519ZM112.9404 82.792999H113.7251L114.5279 89.39769H113.7432L112.9404 82.792999ZM114.9578 82.792999H115.7425L116.5453 89.39769H115.7606L114.9578 82.792999Z'/>
+<path d='M121.3526 86.82394C121.4735 86.82394 121.5723 86.8105 121.6576 86.77487C121.7426 86.74769 121.8101 86.70737 121.8638 86.658C121.9132 86.60894 121.9535 86.55956 121.976 86.49675C121.9982 86.443 122.0117 86.38456 122.0117 86.33081C122.0117 86.22331 121.9895 86.12019 121.9401 86.02144S121.792 85.833 121.6442 85.74331C121.496 85.66269 121.2807 85.58206 121.0029 85.51019C120.7248 85.43394 120.3573 85.37112 119.8954 85.313C119.9448 85.52362 120.012 85.7255 120.097 85.90487C120.1823 86.09331 120.2898 86.25019 120.411 86.38925C120.532 86.52362 120.6754 86.63112 120.8326 86.70737C120.9895 86.78362 121.1642 86.82394 121.3526 86.82394ZM122.617 83.631437L122.4198 83.878C122.3751 83.92737 122.3257 83.95425 122.2673 83.95425C122.2179 83.95425 122.1732 83.94081 122.1238 83.90956C122.0745 83.878 122.0251 83.84237 121.9713 83.79737C121.9132 83.757062 121.8548 83.707687 121.7832 83.653937C121.7204 83.604562 121.6395 83.555187 121.5498 83.510499C121.4648 83.470187 121.3617 83.434249 121.2538 83.402687C121.1373 83.371437 121.012 83.357999 120.8682 83.357999C120.5142 83.357999 120.2495 83.465499 120.0792 83.671749C119.8998 83.88706 119.8148 84.19206 119.8148 84.59112C119.8148 84.62237 119.8148 84.65831 119.8192 84.68519C119.8192 84.72112 119.8192 84.75237 119.8192 84.78394C120.411 84.84206 120.8954 84.923 121.272 85.02144C121.6485 85.12019 121.9445 85.23675 122.1598 85.36675C122.3751 85.50144 122.5229 85.65362 122.6035 85.81519C122.6845 85.9855 122.7248 86.16487 122.7248 86.36206C122.7248 86.47425 122.6979 86.59081 122.6438 86.71206C122.5948 86.833 122.5138 86.94519 122.4063 87.04831C122.2988 87.15144 122.1598 87.23206 121.9938 87.29925C121.8279 87.36675 121.626 87.398 121.3976 87.398C121.1554 87.398 120.931 87.36206 120.716 87.28581C120.5098 87.20956 120.3123 87.10644 120.142 86.98112C119.9626 86.84644 119.8101 86.69394 119.6757 86.51456C119.5367 86.33519 119.4245 86.14237 119.326 85.93175C119.2363 85.72112 119.1645 85.50144 119.1107 85.268C119.0657 85.03956 119.0388 84.80644 119.0388 84.573C119.0388 84.2905 119.0792 84.03956 119.1554 83.81081C119.2317 83.582062 119.3438 83.389249 119.4873 83.232374C119.6307 83.071124 119.8057 82.945499 120.012 82.860187C120.2182 82.775187 120.4513 82.730187 120.7113 82.730187C120.9042 82.730187 121.0835 82.748312 121.2451 82.783937C121.4154 82.815499 121.5723 82.869249 121.7204 82.945499C121.8729 83.021749 122.0207 83.115812 122.1688 83.223312C122.3167 83.340187 122.4648 83.474562 122.617 83.631437ZM124.477 86.18737L124.5445 87.07081C124.5445 87.24987 124.4549 87.33956 124.2755 87.33956H123.8808L123.3339 82.792999H124.132L124.392 85.09769C124.477 85.34425 124.5758 85.573 124.6924 85.77019C124.8136 85.97644 124.9389 86.14706 125.078 86.2905C125.217 86.43394 125.3561 86.54612 125.5086 86.62237C125.652 86.69862 125.7999 86.73894 125.9433 86.73894C126.1767 86.73894 126.338 86.65362 126.4233 86.47894C126.5083 86.30831 126.5308 86.04394 126.4905 85.68519L126.1495 82.792999H126.9433L127.2842 85.68519C127.3155 85.95862 127.3155 86.20081 127.2842 86.41612C127.2527 86.62675 127.1899 86.80612 127.0958 86.95394C127.0061 87.10206 126.8895 87.21425 126.7461 87.28581C126.598 87.36675 126.432 87.40237 126.2392 87.40237C125.9164 87.40237 125.6027 87.29925 125.2977 87.09769C124.993 86.89144 124.7192 86.58644 124.477 86.18737Z'/>
+<path d='M128.3872 83.649562C128.3919 83.348937 128.4816 83.115812 128.6428 82.958937C128.8135 82.802062 129.0375 82.721124 129.3291 82.721124C129.5172 82.721124 129.7056 82.757062 129.8894 82.828937C130.0778 82.905187 130.2438 83.003624 130.3916 83.133624L130.2213 83.514874C130.2078 83.541749 130.1944 83.559874 130.1853 83.573312C130.1675 83.586749 130.1494 83.591124 130.1225 83.591124C130.1003 83.591124 130.0778 83.582062 130.0463 83.555187C130.015 83.537374 129.9791 83.510499 129.9344 83.483624C129.8894 83.456749 129.8356 83.429562 129.7819 83.411749C129.7191 83.384874 129.6519 83.375812 129.571 83.375812C129.45 83.375812 129.356 83.411749 129.2841 83.483624C129.2125 83.559874 129.1766 83.671749 129.1766 83.82425C129.1766 83.83331 129.1766 83.84675 129.181 83.86456C129.181 83.88269 129.181 83.91394 129.19 83.95894C129.19 84.00362 129.1991 84.06206 129.2078 84.13831C129.2169 84.21425 129.2303 84.313 129.2438 84.43425L129.5172 86.66706H130.7144L130.7819 87.2455H129.5891L129.7819 88.8105H129.3647C129.3156 88.8105 129.2797 88.79706 129.2438 88.7655C129.2169 88.73862 129.19 88.70269 129.1766 88.658L128.8356 87.25456L128.1363 87.16019L128.1003 86.84206C128.096 86.78362 128.1047 86.73894 128.1319 86.71206C128.1541 86.6805 128.19 86.66706 128.2303 86.66706H128.7372L128.4591 84.39362C128.4413 84.25487 128.4278 84.13831 128.4188 84.053C128.4053 83.96769 128.4006 83.89612 128.3919 83.84237C128.3919 83.788312 128.3872 83.747999 128.3872 83.716749V83.649562ZM132.346 86.07081L132.4223 87.07081C132.4223 87.24987 132.3326 87.33956 132.1488 87.33956H131.7542L131.2073 82.792999H131.9873L132.2385 84.89581C132.4223 85.59987 132.6645 86.08425 132.9604 86.35331C133.2607 86.62237 133.6017 86.6805 133.9917 86.52362L134.1351 87.2905C133.9692 87.36206 133.8032 87.38456 133.642 87.36675C133.4804 87.33956 133.3235 87.27706 133.171 87.16925C133.0185 87.06612 132.8707 86.91831 132.736 86.72987C132.5926 86.54612 132.4673 86.32644 132.346 86.07081Z'/>
+<path d='M135.8671 83.353624C135.5531 83.353624 135.3156 83.461124 135.1496 83.671749C134.9837 83.88706 134.9031 84.2055 134.9031 84.62237C134.9031 84.90487 134.939 85.17831 135.0062 85.43862C135.0734 85.69862 135.1721 85.92737 135.2977 86.12456C135.4231 86.32175 135.5756 86.47894 135.7549 86.5955C135.9299 86.71644 136.1315 86.77487 136.3515 86.77487C136.6609 86.77487 136.9027 86.66706 137.0643 86.46081C137.2346 86.2455 137.3152 85.93175 137.3152 85.51487C137.3152 85.23237 137.2796 84.95862 137.2121 84.69862C137.1449 84.43862 137.0465 84.20987 136.9209 84.01269C136.7909 83.81081 136.6384 83.653937 136.4634 83.532999C136.284 83.411749 136.0868 83.353624 135.8671 83.353624ZM135.7909 82.730187C136.1181 82.730187 136.4231 82.802062 136.7056 82.954562C136.9881 83.097999 137.2346 83.299562 137.4409 83.555187C137.6518 83.81081 137.8131 84.10675 137.9343 84.443C138.0552 84.77925 138.1137 85.138 138.1137 85.51925C138.1137 85.81519 138.0731 86.07956 137.9881 86.313C137.9027 86.54612 137.7862 86.74331 137.6384 86.90487C137.4902 87.06612 137.3109 87.18737 137.1046 87.27706C136.8984 87.35769 136.6696 87.40237 136.4231 87.40237C136.0959 87.40237 135.7909 87.33081 135.5127 87.18269C135.2259 87.03487 134.9837 86.83737 134.7731 86.58644C134.5621 86.33081 134.4009 86.03487 134.2799 85.69862C134.1587 85.36237 134.1006 84.99894 134.1006 84.618C134.1006 84.31769 134.1409 84.053 134.2259 83.81987C134.3112 83.586749 134.4277 83.389249 134.5759 83.227999C134.7237 83.066437 134.9031 82.945499 135.1093 82.855812C135.3156 82.775187 135.5443 82.730187 135.7909 82.730187ZM139.6506 83.788312L139.7988 84.97675C139.8838 85.23675 139.9869 85.47425 140.1035 85.69425C140.2247 85.91394 140.3503 86.10206 140.4891 86.25894C140.6238 86.41612 140.7628 86.54144 140.9106 86.63112C141.0588 86.71644 141.2022 86.76112 141.3456 86.76112C141.5788 86.76112 141.7581 86.66706 141.8881 86.48331S142.081 86.02581 142.081 85.67175C142.081 85.49237 142.0631 85.313 142.0316 85.12456C142.0003 84.94519 141.951 84.76581 141.8881 84.5955C141.83 84.42081 141.7538 84.25925 141.6641 84.11112C141.5744 83.95894 141.4713 83.82425 141.3591 83.716749C141.2469 83.600187 141.1216 83.514874 140.9825 83.447687C140.8435 83.380499 140.7 83.348937 140.5431 83.348937C140.3772 83.348937 140.2156 83.384874 140.0588 83.447687C139.9019 83.519249 139.7628 83.631437 139.6506 83.788312ZM139.8928 86.10206L139.9691 87.07081C139.9691 87.24987 139.8794 87.33956 139.7 87.33956H139.3053L138.5656 81.25487H139.3413L139.5835 83.237062C139.7134 83.075499 139.8659 82.949874 140.0497 82.864874C140.2338 82.775187 140.4353 82.730187 140.6597 82.730187C140.8703 82.730187 141.0675 82.770499 141.2603 82.851437C141.4531 82.932062 141.6281 83.044249 141.7897 83.187687C141.9553 83.326437 142.1035 83.492374 142.2378 83.689874C142.3681 83.878 142.48 84.08894 142.5788 84.30862C142.6685 84.53269 142.7447 84.76581 142.7941 85.01269C142.8431 85.25925 142.8703 85.50144 142.8703 85.748C142.8703 86.2905 142.7625 86.69862 142.5519 86.98112C142.3366 87.26362 142.0363 87.40237 141.646 87.40237C141.48 87.40237 141.3144 87.37112 141.1528 87.31269C140.996 87.24987 140.8391 87.16019 140.691 87.04831C140.5431 86.93612 140.3994 86.79706 140.265 86.64019C140.1306 86.47894 140.005 86.29956 139.8928 86.10206Z'/>
+<path d='M147.567 87.33519H146.9349C146.8899 87.33519 146.8452 87.32175 146.8049 87.29487C146.7599 87.26362 146.7239 87.22769 146.7014 87.17831L145.2667 84.313C145.2355 84.25019 145.2083 84.18737 145.1814 84.12019C145.1545 84.05737 145.1277 83.99456 145.1008 83.93206C145.0964 83.99456 145.0874 84.05737 145.0783 84.12019C145.0695 84.183 145.0561 84.24581 145.0427 84.30862L144.3117 87.16925C144.2983 87.21862 144.2758 87.25894 144.2442 87.28581C144.213 87.32175 144.1683 87.33519 144.1008 87.33519H143.4417L144.6211 83.062062L143.6345 81.25487H144.222C144.2892 81.25487 144.343 81.26831 144.3833 81.29987C144.4283 81.33112 144.4686 81.37612 144.4999 81.43894L147.567 87.33519ZM149.1042 89.53237L148.6111 89.34394C148.5527 89.32144 148.5124 89.28581 148.4855 89.24987C148.4677 89.20487 148.463 89.16456 148.4855 89.11519C148.5527 88.963 148.5886 88.81487 148.593 88.66706C148.593 88.52331 148.5752 88.38894 148.5349 88.25894C148.4945 88.12894 148.4405 88.01237 148.378 87.90456C148.3061 87.80144 148.2433 87.71175 148.1761 87.6355C148.1445 87.59987 148.1224 87.573 148.1089 87.5505C148.0955 87.528 148.0908 87.5055 148.0908 87.48331C148.0908 87.44269 148.1089 87.40706 148.1402 87.38456L148.3508 87.2455C148.5436 87.40237 148.7052 87.56831 148.8442 87.75237C148.9786 87.93144 149.0817 88.11987 149.1492 88.31706C149.2208 88.50987 149.2567 88.71175 149.2477 88.918C149.2477 89.11987 149.1983 89.32612 149.1042 89.53237ZM150.3552 89.53237L149.862 89.34394C149.8036 89.32144 149.7589 89.28581 149.7411 89.24987C149.7139 89.20487 149.7139 89.16456 149.7364 89.11519C149.8036 88.963 149.8395 88.81487 149.8395 88.66706C149.8442 88.52331 149.8261 88.38894 149.7858 88.25894S149.6961 88.01237 149.6242 87.90456C149.5617 87.80144 149.4942 87.71175 149.427 87.6355C149.3958 87.59987 149.3733 87.573 149.3599 87.5505C149.3464 87.528 149.342 87.5055 149.342 87.48331C149.342 87.44269 149.3599 87.40706 149.3911 87.38456L149.602 87.2455C149.7949 87.40237 149.9561 87.56831 150.0908 87.75237C150.2299 87.93144 150.333 88.11987 150.4045 88.31706C150.4717 88.50987 150.5033 88.71175 150.5033 88.918C150.4942 89.11987 150.4495 89.32612 150.3552 89.53237Z'/>
+<path d='M149.508 72.68V51.418H47.4609V72.68Z' fill='#f9f2ec'/>
+<path d='M149.508 72.68V51.418H47.4609V72.68Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M74.31376 60.78172C74.25907 60.78172 74.19907 60.75672 74.14439 60.70703C74.0197 60.59234 73.90032 60.49766 73.77064 60.41297C73.65126 60.33328 73.51157 60.268594 73.3722 60.213907C73.22283 60.158907 73.06814 60.124219 72.89376 60.094219C72.72439 60.074219 72.53501 60.059219 72.32095 60.059219C71.9722 60.059219 71.64845 60.124219 71.34939 60.248594C71.04564 60.37328 70.78657 60.55766 70.5622 60.80172C70.34314 61.04078 70.16876 61.33484 70.04408 61.68359C69.9147 62.03234 69.8497 62.43078 69.8497 62.87422C69.8497 63.31266 69.9097 63.70641 70.03408 64.05516C70.15876 64.40391 70.32814 64.69766 70.5522 64.94172C70.77158 65.18609 71.03564 65.37016 71.33939 65.49484C71.64345 65.62453 71.9822 65.68922 72.35095 65.68922C72.6547 65.68922 72.91376 65.65422 73.12314 65.59453C73.3322 65.52484 73.50658 65.45484 73.64626 65.37516C73.78564 65.29547 73.90032 65.22578 73.98501 65.15609C74.0697 65.09641 74.14439 65.06141 74.20407 65.06141C74.25907 65.06141 74.29876 65.07141 74.32876 65.09641C74.36345 65.11609 74.38845 65.14109 74.40845 65.17609L74.7272 65.61953C74.43345 65.89828 74.0897 66.11766 73.70095 66.28203C73.31251 66.44641 72.86407 66.52609 72.35595 66.52609C71.83751 66.52609 71.36439 66.43641 70.93595 66.26203C70.50751 66.08266 70.13876 65.83359 69.8347 65.50984C69.52595 65.18609 69.286888 64.80234 69.117513 64.35391C68.948138 63.90547 68.86345 63.41234 68.86345 62.87422C68.86345 62.33609 68.943138 61.84297 69.107512 61.39453C69.271887 60.94609 69.50095 60.56266 69.79501 60.243594C70.08907 59.919844 70.44751 59.670782 70.86626 59.496407C71.2847 59.317032 71.74783 59.227344 72.26126 59.227344C72.85408 59.227344 73.3572 59.322032 73.77064 59.511407C74.18908 59.700469 74.54282 59.964532 74.83689 60.303594L74.45314 60.71703C74.41345 60.76172 74.36845 60.78172 74.31376 60.78172Z'/>
+<path d='M76.55681 63.34266L76.49712 64.10984C76.48212 64.19953 76.45712 64.26422 76.42243 64.29922C76.38743 64.33391 76.31775 64.35391 76.22306 64.35391H75.71493V59.307032H76.60681V62.49547C76.6715 62.66984 76.74118 62.82453 76.81587 62.95391C76.89556 63.09359 76.98525 63.20297 77.08493 63.29266C77.17962 63.38734 77.29431 63.45703 77.41368 63.50203C77.54337 63.54672 77.68275 63.57172 77.84243 63.57172C77.95681 63.57172 78.0565 63.56172 78.14618 63.54172C78.23587 63.52203 78.30556 63.51203 78.35056 63.51203C78.4302 63.51203 78.4799 63.55172 78.4999 63.63641L78.5646 64.29922C78.4899 64.34891 78.4002 64.38391 78.30056 64.40859C78.20587 64.43359 78.1015 64.44359 77.99681 64.44359C77.66306 64.44359 77.379 64.34891 77.14493 64.14953C76.91056 63.96047 76.71618 63.68641 76.55681 63.34266ZM83.6956 64.35391H82.9931C82.9335 64.35391 82.8785 64.33891 82.8338 64.29922C82.7838 64.26922 82.7491 64.22453 82.7291 64.16953L81.4188 60.99609C81.3641 60.85641 81.3141 60.70703 81.2694 60.55266C81.2344 60.70703 81.1897 60.85141 81.1347 60.99109L79.7847 64.16953C79.7697 64.21453 79.7347 64.25922 79.695 64.29922C79.645 64.33391 79.5853 64.35391 79.5106 64.35391H78.7434L80.826 59.601094L79.9041 57.59828H80.5619C80.6566 57.59828 80.7213 57.61797 80.7713 57.65797C80.8109 57.69766 80.8509 57.75266 80.8806 57.81734L83.6956 64.35391ZM85.3688 60.52266V62.96391C85.5532 63.20797 85.7523 63.39234 85.9667 63.52703C86.1857 63.66141 86.4398 63.72609 86.7288 63.72609C86.9332 63.72609 87.1126 63.69141 87.272 63.62141C87.4313 63.55172 87.566 63.44234 87.6754 63.29266C87.7851 63.13828 87.8698 62.94391 87.9295 62.70984C87.9845 62.47578 88.0142 62.19172 88.0142 61.86297C88.0142 61.24016 87.8898 60.76172 87.6357 60.42797C87.3817 60.094219 87.0229 59.924844 86.5495 59.924844C86.3104 59.924844 86.096 59.969532 85.902 60.059219C85.7076 60.148907 85.5332 60.303594 85.3688 60.52266ZM85.3238 63.57172L85.2442 64.16953C85.2142 64.29422 85.1345 64.35391 85.0101 64.35391H84.477V57.59828H85.3688V59.830157C85.5382 59.645782 85.7326 59.496407 85.9567 59.396719C86.1757 59.287032 86.4398 59.237344 86.7488 59.237344C87.0876 59.237344 87.3917 59.307032 87.6604 59.436719C87.9345 59.576094 88.1638 59.755469 88.3482 59.994532C88.5373 60.223594 88.682 60.50266 88.7817 60.82172C88.881 61.14547 88.931 61.48922 88.931 61.86297C88.931 62.28141 88.886 62.65016 88.7963 62.97391C88.7067 63.29766 88.5773 63.56672 88.4129 63.78109C88.2485 64.00016 88.0442 64.16453 87.8101 64.27922C87.5757 64.38891 87.3117 64.44359 87.0179 64.44359C86.6592 64.44359 86.3404 64.36391 86.0613 64.20453C85.7823 64.04516 85.5382 63.83578 85.3238 63.57172Z'/>
+<path d='M91.5345 59.227344C91.7638 59.227344 91.9879 59.267032 92.2023 59.347032C92.4163 59.431719 92.6007 59.541094 92.7551 59.685782L92.496 60.109219C92.4613 60.163907 92.4163 60.193907 92.3717 60.193907C92.3467 60.193907 92.3117 60.183907 92.282 60.153907C92.242 60.134219 92.2023 60.104219 92.1523 60.074219C92.1026 60.044532 92.0426 60.014532 91.9729 59.994532C91.9082 59.964532 91.8285 59.954844 91.7338 59.954844C91.5695 59.954844 91.4398 60.004532 91.3351 60.109219C91.2307 60.213907 91.1807 60.36828 91.1807 60.58234V63.61172H92.6404V64.25422H91.1807V65.99297H90.7323C90.6776 65.99297 90.6279 65.97797 90.5979 65.94328C90.5579 65.91328 90.5382 65.87359 90.5282 65.82359L90.3238 64.26422L89.497 64.15953V63.80578C89.497 63.74109 89.5167 63.69141 89.5517 63.66141C89.5867 63.62641 89.6313 63.61172 89.686 63.61172H90.2938V60.52266C90.2938 60.104219 90.3985 59.785469 90.6179 59.561094C90.827 59.337032 91.136 59.227344 91.5345 59.227344Z'/>
+<path d='M95.663 64.43359C95.2892 64.43359 94.9555 64.37391 94.6564 64.24922C94.3624 64.12484 94.1083 63.95047 93.8992 63.72609C93.6899 63.50203 93.5305 63.22797 93.4208 62.90422C93.3064 62.58516 93.2514 62.22672 93.2514 61.83297C93.2514 61.43453 93.3064 61.07578 93.4208 60.75672C93.5305 60.43797 93.6899 60.163907 93.8992 59.939844C94.1083 59.715469 94.3624 59.541094 94.6564 59.416719C94.9555 59.297032 95.2892 59.237344 95.663 59.237344C96.0314 59.237344 96.3652 59.297032 96.6592 59.416719C96.9533 59.541094 97.2074 59.715469 97.4164 59.939844C97.6258 60.163907 97.7852 60.43797 97.8949 60.75672C98.0095 61.07578 98.0642 61.43453 98.0642 61.83297C98.0642 62.22672 98.0095 62.58516 97.8949 62.90422C97.7852 63.22797 97.6258 63.50203 97.4164 63.72609C97.2074 63.95047 96.9533 64.12484 96.6592 64.24922C96.3652 64.37391 96.0314 64.43359 95.663 64.43359ZM95.663 59.929844C95.1595 59.929844 94.7811 60.094219 94.5367 60.43297C94.2877 60.76172 94.1633 61.23016 94.1633 61.82797C94.1633 62.12703 94.193 62.39609 94.258 62.63516C94.3177 62.86922 94.4074 63.06859 94.5367 63.23297C94.6564 63.39734 94.8158 63.52203 95.0052 63.60672C95.1895 63.69141 95.4086 63.73609 95.663 63.73609C96.1611 63.73609 96.5349 63.56672 96.7789 63.23297C97.023 62.89922 97.1474 62.43078 97.1474 61.82797C97.1474 61.23016 97.023 60.76172 96.7789 60.43297C96.5349 60.094219 96.1611 59.929844 95.663 59.929844Z'/>
+<path d='M108.1315 62.87422C108.1315 63.40734 108.0468 63.89547 107.8771 64.33391C107.7077 64.77234 107.4687 65.14609 107.1599 65.46484C106.8509 65.77391 106.4821 66.01797 106.0437 66.19234C105.6152 66.36172 105.1321 66.44641 104.609 66.44641H101.9437V59.307032H104.609C105.1321 59.307032 105.6152 59.391719 106.0437 59.566094C106.4821 59.735469 106.8509 59.974532 107.1599 60.288594C107.4687 60.60234 107.7077 60.97609 107.8771 61.41453C108.0468 61.85297 108.1315 62.34109 108.1315 62.87422ZM107.1399 62.87422C107.1399 62.43578 107.0802 62.04234 106.9606 61.69859C106.8409 61.35484 106.6715 61.06078 106.4524 60.82172C106.2331 60.58734 105.969 60.40297 105.6552 60.278594C105.3415 60.153907 104.9927 60.089219 104.609 60.089219H102.9099V65.66422H104.609C104.9927 65.66422 105.3415 65.59953 105.6552 65.47484C105.969 65.35047 106.2331 65.16609 106.4524 64.92703C106.6715 64.68766 106.8409 64.39391 106.9606 64.05016C107.0802 63.70641 107.1399 63.31266 107.1399 62.87422ZM111.498 62.98891H110.4817V65.68422H111.5377C112.0958 65.68422 112.5142 65.57453 112.7933 65.36047C113.0724 65.14609 113.2117 64.82234 113.2117 64.39891C113.2117 64.18953 113.177 64.00016 113.102 63.82578C113.0274 63.65141 112.9227 63.50203 112.7733 63.38234C112.6339 63.25297 112.4545 63.15828 112.2352 63.09359C112.0261 63.02359 111.777 62.98891 111.498 62.98891ZM114.7961 59.307032L112.7136 62.14172C112.6239 62.27641 112.5192 62.37609 112.3949 62.44578C112.6686 62.51047 112.918 62.60016 113.132 62.72484C113.3514 62.84922 113.5355 62.99391 113.6902 63.17328C113.8395 63.34266 113.9542 63.54172 114.0339 63.76109C114.1136 63.98016 114.1533 64.21453 114.1533 64.46859C114.1533 64.77234 114.1036 65.04641 113.9989 65.28547C113.8942 65.53484 113.7399 65.73891 113.5208 65.91328C113.3114 66.08766 113.0374 66.21734 112.7086 66.31203C112.3799 66.40172 111.9911 66.44641 111.5377 66.44641H109.5202V59.307032H110.4817V62.28641H111.2139C111.3486 62.28641 111.448 62.26641 111.518 62.23641C111.5777 62.19672 111.6424 62.14172 111.6974 62.06203L113.5505 59.511407C113.6352 59.376719 113.7649 59.307032 113.9392 59.307032H114.7961ZM118.2677 60.074219H116.7233V62.56047H118.2677C118.7908 62.56047 119.1842 62.45578 119.4483 62.23641C119.7124 62.02734 119.842 61.73328 119.842 61.36453C119.842 61.17547 119.812 61.00109 119.7524 60.84141C119.6924 60.68703 119.598 60.55266 119.4733 60.43297C119.3436 60.32328 119.1792 60.233594 118.9802 60.168907C118.7808 60.104219 118.5417 60.074219 118.2677 60.074219ZM116.7233 65.68422H118.0383C118.5714 65.68422 118.9602 65.58453 119.2142 65.39516C119.4683 65.19578 119.593 64.89203 119.593 64.46859C119.593 64.28922 119.563 64.12484 119.4983 63.97016C119.4333 63.82078 119.3386 63.69141 119.2042 63.58672C119.0749 63.48203 118.9102 63.39734 118.7061 63.33766C118.5067 63.27766 118.2727 63.24797 117.9986 63.24797H116.7233V65.68422ZM118.0383 66.44641H115.7617V59.307032H118.2827C118.6811 59.307032 119.0349 59.356719 119.3486 59.456407C119.6627 59.551094 119.9217 59.690782 120.1408 59.870157C120.3502 60.049219 120.5145 60.263594 120.6292 60.51266C120.7386 60.76172 120.7936 61.03578 120.7936 61.33984C120.7936 61.78328 120.6589 62.14672 120.3999 62.41578C120.1308 62.69484 119.7374 62.87922 119.2142 62.97891C119.4383 63.04859 119.6377 63.13828 119.802 63.25297C119.9714 63.36234 120.1111 63.48703 120.2205 63.62641C120.3302 63.76609 120.4099 63.91547 120.4699 64.07984C120.5195 64.23922 120.5495 64.40859 120.5495 64.58297C120.5495 64.87203 120.4995 65.13109 120.4049 65.36516C120.3102 65.59453 120.1608 65.78891 119.9514 65.94828C119.7524 66.10766 119.4883 66.23234 119.1742 66.31703C118.8555 66.40172 118.4767 66.44641 118.0383 66.44641ZM128.0016 62.73984H125.8094V62.19172C125.8094 62.13703 125.8294 62.09203 125.8644 62.05703C125.9041 62.02234 125.9538 62.00234 126.0188 62.00234H127.1297V60.43297C126.8856 60.298594 126.6316 60.193907 126.3725 60.124219C126.1185 60.044532 125.8244 60.009532 125.4906 60.009532C125.0672 60.009532 124.6885 60.074219 124.3497 60.203907C124.0109 60.33328 123.7219 60.52266 123.4828 60.77172C123.2488 61.01578 123.0644 61.31984 122.9347 61.66859C122.8103 62.02734 122.7453 62.42578 122.7453 62.87422C122.7453 63.30766 122.8053 63.69641 122.9297 64.04016C123.0544 64.38891 123.2288 64.68766 123.4578 64.92703C123.6872 65.17609 123.966 65.36047 124.29 65.49484C124.6138 65.62453 124.9775 65.68922 125.381 65.68922C125.655 65.68922 125.8941 65.66922 126.0934 65.62453C126.2978 65.57953 126.4722 65.52984 126.6216 65.46484C126.7659 65.40516 126.8906 65.34047 126.9953 65.27578C127.0997 65.21078 127.1894 65.15109 127.2691 65.10609C127.3538 65.05641 127.4288 65.04141 127.4985 65.05641C127.5631 65.07641 127.6178 65.12109 127.6628 65.18609L127.9369 65.62453C127.7825 65.76391 127.6178 65.88828 127.4435 66.00297C127.2691 66.11266 127.075 66.20734 126.8706 66.28203C126.6663 66.36172 126.4422 66.42141 126.1981 66.46141C125.9538 66.50609 125.6947 66.52609 125.411 66.52609C124.8528 66.52609 124.3497 66.43641 123.8963 66.26203C123.4428 66.08766 123.0594 65.83859 122.7453 65.51484C122.4316 65.19578 122.1875 64.81234 122.0181 64.36391C121.8438 63.91547 121.7591 63.41734 121.7591 62.87422C121.7591 62.33609 121.8488 61.84297 122.0231 61.39453C122.1975 60.94609 122.4516 60.56266 122.7753 60.243594C123.1041 59.919844 123.4978 59.670782 123.9609 59.496407C124.4244 59.317032 124.9425 59.227344 125.5156 59.227344C125.9988 59.227344 126.4472 59.292032 126.8506 59.416719C127.2594 59.546094 127.6428 59.740469 128.0016 59.999532V62.73984Z'/>
+<path d='M98.4844 51.418V28.969' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M98.484355 26.47264L99.83201 30.046859L98.484355 28.87108L97.1406 30.046859Z'/>
+<path d='M98.484355 26.47264L99.83201 30.046859L98.484355 28.87108L97.1406 30.046859Z' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M57.87091 36.909402H55.3331L56.03716 42.62628H55.19872L54.40935 36.200964H57.78591L57.87091 36.909402Z'/>
+<path d='M59.84607 40.74315H59.06138L58.51419 36.200964H59.29888L59.84607 40.74315ZM60.15076 42.16909C60.15076 42.24534 60.13294 42.32159 60.10607 42.38878C60.07013 42.46065 60.02982 42.52315 59.98044 42.57721C59.93107 42.62628 59.87294 42.6669 59.80107 42.69815C59.73826 42.7294 59.66669 42.74315 59.59482 42.74315C59.52763 42.74315 59.46044 42.7294 59.39294 42.69378C59.32576 42.6669 59.26763 42.6219 59.21826 42.56815C59.16888 42.51878 59.12857 42.45596 59.09701 42.38878C59.06576 42.32159 59.05232 42.24534 59.05232 42.16909S59.06576 42.02096 59.09701 41.9494C59.12857 41.88659 59.16451 41.82378 59.21826 41.77003C59.26294 41.72065 59.32138 41.68034 59.38857 41.64878C59.45576 41.61753 59.52294 41.60409 59.59044 41.60409C59.66201 41.60409 59.72951 41.61753 59.80107 41.64878C59.86388 41.68034 59.92669 41.72065 59.98044 41.77003C60.02982 41.82378 60.07013 41.88659 60.10607 41.9494C60.13294 42.02096 60.15076 42.09284 60.15076 42.16909ZM61.42833 37.196277L61.57177 38.37128C61.65708 38.63128 61.76021 38.87346 61.88115 39.08846C61.99802 39.31284 62.12333 39.50128 62.2624 39.66253C62.40146 39.8194 62.54052 39.94503 62.68833 40.03471C62.83646 40.1244 62.9799 40.16909 63.12333 40.16909C63.35646 40.16909 63.53583 40.07503 63.66583 39.89128C63.79146 39.70753 63.85427 39.43378 63.85427 39.07971C63.85427 38.90034 63.83615 38.72096 63.80927 38.53253C63.77365 38.35315 63.72865 38.17378 63.66583 38.00346C63.60302 37.82878 63.52677 37.66721 63.44177 37.51909C63.35208 37.3669 63.24896 37.23221 63.13677 37.124714C63.02458 37.008151 62.89927 36.922839 62.76021 36.855651C62.62115 36.788464 62.47771 36.756901 62.32083 36.756901C62.15927 36.756901 61.99802 36.792839 61.83646 36.855651C61.67958 36.927214 61.54052 37.039401 61.42833 37.196277ZM61.7199 39.59096L62.1099 42.80565H61.3299L60.53177 36.200964H60.95302C61.0474 36.200964 61.11021 36.218776 61.14583 36.259402C61.18177 36.299714 61.21333 36.357839 61.23552 36.434089L61.29833 36.725651C61.42833 36.537214 61.5899 36.393776 61.78271 36.290652C61.97552 36.187526 62.19521 36.138151 62.4374 36.138151C62.64802 36.138151 62.84521 36.178464 63.03802 36.259402C63.23083 36.340026 63.40583 36.452214 63.5674 36.595652C63.73302 36.734401 63.88115 36.900339 64.0155 37.097839C64.1458 37.28596 64.2577 37.4969 64.3565 37.71659C64.4461 37.94065 64.5224 38.17378 64.5718 38.42065C64.6208 38.66721 64.648 38.9094 64.648 39.15596C64.648 39.69846 64.5402 40.10659 64.3249 40.38909C64.1099 40.67159 63.80927 40.81034 63.41927 40.81034C63.25771 40.81034 63.10083 40.78346 62.94396 40.72065C62.78708 40.6669 62.63896 40.5819 62.49552 40.47878C62.35208 40.37096 62.21302 40.24096 62.08771 40.09315C61.95302 39.94503 61.83208 39.77471 61.7199 39.59096ZM66.4092 39.47878L66.4854 40.47878C66.4854 40.65784 66.3958 40.74753 66.212 40.74753H65.8173L65.2704 36.200964H66.0504L66.3017 38.30378C66.4854 39.00784 66.7276 39.49221 67.0236 39.76128C67.3239 40.03034 67.6648 40.08846 68.0548 39.93159L68.1983 40.69846C68.0323 40.77003 67.8664 40.79253 67.7051 40.77471C67.5436 40.74753 67.3867 40.68503 67.2342 40.57721C67.0817 40.47409 66.9339 40.32628 66.7992 40.13784C66.6558 39.95409 66.5304 39.7344 66.4092 39.47878Z'/>
+<path d='M71.2022 40.18721L71.0094 38.63128C70.9244 38.36659 70.8304 38.12003 70.7226 37.89596C70.6151 37.67628 70.4985 37.48346 70.3729 37.3219C70.2429 37.155964 70.1082 37.030339 69.9694 36.936276C69.8304 36.846589 69.6869 36.801901 69.5388 36.801901C69.0769 36.801901 68.8482 37.160651 68.8482 37.88253C68.8482 38.08878 68.8707 38.29034 68.9201 38.48784C68.9694 38.68065 69.0366 38.8644 69.1172 39.0394C69.2069 39.21409 69.3057 39.37096 69.4266 39.51909C69.5479 39.66253 69.6779 39.78815 69.8257 39.89128C69.9738 39.9944 70.1307 40.07503 70.2966 40.13784C70.4626 40.19159 70.6376 40.22315 70.8166 40.22315C70.8794 40.22315 70.9422 40.21846 71.0094 40.21846C71.0722 40.20971 71.1351 40.20065 71.2022 40.18721ZM70.8976 37.39815L70.8122 36.479089C70.8122 36.402839 70.8304 36.335339 70.866 36.281589C70.9063 36.227839 70.9782 36.200964 71.0813 36.200964H71.4938L72.0363 40.59534C71.8569 40.67159 71.6732 40.72971 71.4938 40.75659C71.3054 40.79253 71.1172 40.80596 70.9244 40.80596C70.6554 40.80596 70.3997 40.76565 70.1532 40.69378C69.9066 40.61315 69.6779 40.50565 69.4672 40.37096C69.2519 40.22753 69.0591 40.06596 68.8841 39.87784C68.7094 39.68503 68.5613 39.47878 68.4357 39.25003C68.3147 39.02128 68.2207 38.78378 68.1488 38.52378C68.086 38.27253 68.0501 38.00784 68.0501 37.73909C68.0501 37.48346 68.0772 37.25471 68.1354 37.052839C68.1938 36.855651 68.2744 36.689714 68.3732 36.550651C68.4807 36.416276 68.6016 36.313151 68.7497 36.245652C68.8976 36.174089 69.0591 36.138151 69.2385 36.138151C69.4044 36.138151 69.5613 36.169714 69.7182 36.227839C69.8707 36.286276 70.0141 36.371276 70.1576 36.479089C70.2922 36.590964 70.4266 36.720964 70.5522 36.878152C70.6732 37.035027 70.7897 37.20534 70.8976 37.39815ZM73.8112 39.47878L73.8875 40.47878C73.8875 40.65784 73.7978 40.74753 73.614 40.74753H73.2193L72.6725 36.200964H73.4525L73.7037 38.30378C73.8875 39.00784 74.1297 39.49221 74.4256 39.76128C74.7259 40.03034 75.0668 40.08846 75.4569 39.93159L75.6003 40.69846C75.4343 40.77003 75.2684 40.79253 75.1072 40.77471C74.9456 40.74753 74.7887 40.68503 74.6362 40.57721C74.4837 40.47409 74.3359 40.32628 74.2012 40.13784C74.0578 39.95409 73.9325 39.7344 73.8112 39.47878ZM79.9224 40.74315H79.2902C79.2452 40.74315 79.2005 40.72971 79.1602 40.70284C79.1152 40.67159 79.0793 40.63565 79.0568 40.58628L77.6221 37.72096C77.5908 37.65815 77.5636 37.59534 77.5368 37.52815C77.5099 37.46534 77.483 37.40253 77.4561 37.34003C77.4518 37.40253 77.4427 37.46534 77.4336 37.52815C77.4249 37.59096 77.4115 37.65378 77.398 37.71659L76.6671 40.57721C76.6536 40.62659 76.6311 40.6669 76.5996 40.69378C76.5683 40.72971 76.5236 40.74315 76.4561 40.74315H75.7971L76.9765 36.470026L75.9899 34.66284H76.5774C76.6446 34.66284 76.6983 34.67628 76.7386 34.70784C76.7836 34.73909 76.824 34.78409 76.8552 34.8469L79.9224 40.74315Z'/>
+<path d='M85.753 38.5819H83.5605L84.8024 41.23628L84.9236 41.51878C84.9683 41.6219 85.0133 41.73846 85.058 41.86409C85.0715 41.74315 85.0896 41.62659 85.1118 41.51878C85.1343 41.41565 85.1521 41.32159 85.1658 41.24096L85.753 38.5819ZM87.1477 36.200964L85.5736 42.62628H84.7218L81.574 36.200964H82.2286C82.2958 36.200964 82.3586 36.218776 82.4127 36.263776C82.4708 36.299714 82.5111 36.349089 82.538 36.402839L83.2733 37.97221H85.8877L86.2374 36.402839C86.2552 36.344401 86.2868 36.295026 86.3271 36.254714C86.3674 36.218776 86.4255 36.200964 86.5018 36.200964H87.1477ZM90.1061 39.2769H89.1733L89.5051 41.96721H90.4379C90.6442 41.96721 90.8236 41.94034 90.9804 41.88659C91.1373 41.83721 91.2629 41.76096 91.3661 41.66253C91.4692 41.56815 91.5454 41.45159 91.5945 41.31253C91.6439 41.17378 91.6708 41.02128 91.6708 40.84628C91.6708 40.61753 91.6351 40.4069 91.5676 40.21846C91.5004 40.02128 91.3973 39.85971 91.2673 39.71628C91.1373 39.5819 90.9714 39.46971 90.7786 39.39346S90.3617 39.2769 90.1061 39.2769ZM90.5186 42.62628H88.7473L87.9626 36.200964H88.7967L89.0926 38.61346H90.0251C90.4245 38.61346 90.7786 38.67159 91.0836 38.78378C91.3973 38.90034 91.6573 39.06159 91.8636 39.26346C92.0789 39.46534 92.2358 39.70753 92.3479 39.9944C92.4601 40.27221 92.5139 40.58628 92.5139 40.92253C92.5139 41.17815 92.4736 41.41128 92.3929 41.6219C92.312 41.83284 92.1911 42.01221 92.0251 42.16003C91.8636 42.30815 91.6573 42.42471 91.4064 42.50534C91.1551 42.58596 90.8592 42.62628 90.5186 42.62628ZM93.8448 36.200964L94.6295 42.62628H93.7864L93.0017 36.200964H93.8448Z'/>
+<path d='M103.71681 39.79721L104.0665 42.62628H103.22806L102.443373 36.200964H103.27744L103.64056 39.15128H104.00369C104.134 39.15128 104.22806 39.13346 104.28619 39.10659C104.34462 39.07065 104.39837 39.02128 104.44337 38.94503L106.12931 36.380339C106.16056 36.321901 106.20087 36.281589 106.24587 36.245652C106.29056 36.218776 106.36681 36.200964 106.479 36.200964H107.20087L105.26369 39.24565C105.219 39.33065 105.16962 39.39346 105.11587 39.44721C105.05744 39.49221 104.99462 39.53253 104.92306 39.56378C105.03525 39.61315 105.15181 39.70753 105.27275 39.84628L107.83744 42.62628H107.12462C107.03494 42.62628 106.95431 42.61284 106.88712 42.58596C106.81962 42.55909 106.75244 42.50534 106.68962 42.42471L104.46556 39.98534C104.40275 39.91815 104.33556 39.86878 104.27275 39.8419C104.20119 39.81065 104.11587 39.79721 104.01275 39.79721H103.71681Z'/>
+<path d='M109.77611 40.2319C109.89704 40.2319 109.9958 40.21846 110.08111 40.18284C110.16611 40.15565 110.23361 40.11534 110.28736 40.06596C110.33673 40.0169 110.37704 39.96753 110.39955 39.90471C110.42173 39.85096 110.43517 39.79253 110.43517 39.73878C110.43517 39.63128 110.41298 39.52815 110.36361 39.4294C110.31423 39.33065 110.21548 39.24096 110.06767 39.15128C109.91954 39.07065 109.70423 38.99003 109.42642 38.91815C109.1483 38.8419 108.78079 38.77909 108.31892 38.72096C108.3683 38.93159 108.43548 39.13346 108.52048 39.31284C108.6058 39.50128 108.7133 39.65815 108.83454 39.79721C108.95548 39.93159 109.09892 40.03909 109.25611 40.11534C109.41298 40.19159 109.58767 40.2319 109.77611 40.2319ZM111.04048 37.039401L110.8433 37.28596C110.79861 37.33534 110.74923 37.36221 110.6908 37.36221C110.64142 37.36221 110.59673 37.34878 110.54736 37.31753C110.49798 37.28596 110.44861 37.25034 110.39486 37.20534C110.33673 37.165027 110.27829 37.115652 110.20673 37.061901C110.14392 37.012526 110.06298 36.963151 109.9733 36.918464C109.88829 36.878152 109.78517 36.842214 109.67736 36.810652C109.5608 36.779402 109.43548 36.765964 109.29173 36.765964C108.93767 36.765964 108.67298 36.873464 108.50267 37.079714C108.32329 37.29503 108.23829 37.60003 108.23829 37.99909C108.23829 38.03034 108.23829 38.06628 108.24267 38.09315C108.24267 38.12909 108.24267 38.16034 108.24267 38.1919C108.83454 38.25003 109.31892 38.33096 109.69548 38.4294C110.07204 38.52815 110.36798 38.64471 110.5833 38.77471C110.79861 38.9094 110.94642 39.06159 111.02704 39.22315C111.10798 39.39346 111.14829 39.57284 111.14829 39.77003C111.14829 39.88221 111.12142 39.99878 111.06736 40.12003C111.01829 40.24096 110.93736 40.35315 110.82986 40.45628C110.72236 40.5594 110.5833 40.64003 110.41736 40.70721C110.25142 40.77471 110.04954 40.80596 109.82111 40.80596C109.57892 40.80596 109.35454 40.77003 109.13955 40.69378C108.9333 40.61753 108.73579 40.5144 108.56548 40.38909C108.38611 40.2544 108.23361 40.1019 108.09923 39.92253C107.96017 39.74315 107.84798 39.55034 107.74954 39.33971C107.65986 39.12909 107.58798 38.9094 107.53423 38.67596C107.48923 38.44753 107.46236 38.2144 107.46236 37.98096C107.46236 37.69846 107.50267 37.44753 107.57892 37.21878C107.65517 36.990026 107.76736 36.797214 107.9108 36.640339C108.05423 36.479089 108.22923 36.353464 108.43548 36.268152C108.64173 36.183152 108.87486 36.138151 109.13486 36.138151C109.32767 36.138151 109.50705 36.156276 109.66861 36.191901C109.83892 36.223464 109.9958 36.277214 110.14392 36.353464C110.29642 36.429714 110.44423 36.523776 110.59236 36.631276C110.74017 36.748152 110.8883 36.882526 111.04048 37.039401ZM112.8962 39.47878L112.9724 40.47878C112.9724 40.65784 112.8827 40.74753 112.699 40.74753H112.3043L111.75744 36.200964H112.5374L112.7887 38.30378C112.9724 39.00784 113.2146 39.49221 113.5106 39.76128C113.8109 40.03034 114.1518 40.08846 114.5418 39.93159L114.6852 40.69846C114.5193 40.77003 114.3534 40.79253 114.1921 40.77471C114.0306 40.74753 113.8737 40.68503 113.7212 40.57721C113.5687 40.47409 113.4209 40.32628 113.2862 40.13784C113.1427 39.95409 113.0174 39.7344 112.8962 39.47878ZM115.967 39.59534L116.0345 40.47878C116.0345 40.65784 115.9449 40.74753 115.7655 40.74753H115.3708L114.8239 36.200964H115.622L115.882 38.50565C115.967 38.75221 116.0658 38.98096 116.1824 39.17815C116.3036 39.3844 116.4289 39.55503 116.568 39.69846C116.707 39.8419 116.8461 39.95409 116.9986 40.03034C117.142 40.10659 117.2899 40.1469 117.4333 40.1469C117.6667 40.1469 117.828 40.06159 117.9133 39.8869C117.9983 39.71628 118.0208 39.4519 117.9805 39.09315L117.6395 36.200964H118.4333L118.7742 39.09315C118.8055 39.36659 118.8055 39.60878 118.7742 39.82409C118.7427 40.03471 118.6799 40.21409 118.5858 40.3619C118.4961 40.51003 118.3795 40.62221 118.2361 40.69378C118.088 40.77471 117.922 40.81034 117.7292 40.81034C117.4064 40.81034 117.0927 40.70721 116.7877 40.50565C116.483 40.2994 116.2092 39.9944 115.967 39.59534ZM121.8852 40.2319C122.0061 40.2319 122.1049 40.21846 122.1902 40.18284C122.2752 40.15565 122.3427 40.11534 122.3964 40.06596C122.4458 40.0169 122.4861 39.96753 122.5086 39.90471C122.5308 39.85096 122.5442 39.79253 122.5442 39.73878C122.5442 39.63128 122.522 39.52815 122.4727 39.4294C122.4233 39.33065 122.3245 39.24096 122.1767 39.15128C122.0286 39.07065 121.8133 38.99003 121.5355 38.91815C121.2574 38.8419 120.8899 38.77909 120.428 38.72096C120.4774 38.93159 120.5445 39.13346 120.6295 39.31284C120.7149 39.50128 120.8224 39.65815 120.9436 39.79721C121.0645 39.93159 121.208 40.03909 121.3652 40.11534C121.522 40.19159 121.6967 40.2319 121.8852 40.2319ZM123.1495 37.039401L122.9524 37.28596C122.9077 37.33534 122.8583 37.36221 122.7999 37.36221C122.7505 37.36221 122.7058 37.34878 122.6564 37.31753C122.607 37.28596 122.5577 37.25034 122.5039 37.20534C122.4458 37.165027 122.3874 37.115652 122.3158 37.061901C122.253 37.012526 122.172 36.963151 122.0824 36.918464C121.9974 36.878152 121.8942 36.842214 121.7864 36.810652C121.6699 36.779402 121.5445 36.765964 121.4008 36.765964C121.0467 36.765964 120.782 36.873464 120.6117 37.079714C120.4324 37.29503 120.3474 37.60003 120.3474 37.99909C120.3474 38.03034 120.3474 38.06628 120.3517 38.09315C120.3517 38.12909 120.3517 38.16034 120.3517 38.1919C120.9436 38.25003 121.428 38.33096 121.8045 38.4294C122.1811 38.52815 122.477 38.64471 122.6924 38.77471C122.9077 38.9094 123.0555 39.06159 123.1361 39.22315C123.217 39.39346 123.2574 39.57284 123.2574 39.77003C123.2574 39.88221 123.2305 39.99878 123.1764 40.12003C123.1274 40.24096 123.0464 40.35315 122.9389 40.45628C122.8314 40.5594 122.6924 40.64003 122.5264 40.70721C122.3605 40.77471 122.1586 40.80596 121.9302 40.80596C121.688 40.80596 121.4636 40.77003 121.2486 40.69378C121.0424 40.61753 120.8449 40.5144 120.6745 40.38909C120.4952 40.2544 120.3427 40.1019 120.2083 39.92253C120.0692 39.74315 119.957 39.55034 119.8586 39.33971C119.7689 39.12909 119.697 38.9094 119.6433 38.67596C119.5983 38.44753 119.5714 38.2144 119.5714 37.98096C119.5714 37.69846 119.6117 37.44753 119.688 37.21878C119.7642 36.990026 119.8764 36.797214 120.0199 36.640339C120.1633 36.479089 120.3383 36.353464 120.5445 36.268152C120.7508 36.183152 120.9839 36.138151 121.2439 36.138151C121.4367 36.138151 121.6161 36.156276 121.7777 36.191901C121.948 36.223464 122.1049 36.277214 122.253 36.353464C122.4055 36.429714 122.5533 36.523776 122.7014 36.631276C122.8492 36.748152 122.9974 36.882526 123.1495 37.039401ZM123.8887 36.200964H124.6734L125.4762 42.80565H124.6915L123.8887 36.200964Z'/>
+<path d='M130.9031 40.0169L131.105 40.30378C130.9569 40.46065 130.7775 40.5819 130.5713 40.67596C130.3606 40.76565 130.1231 40.81034 129.8494 40.81034C129.5938 40.81034 129.3606 40.77003 129.1544 40.68503C128.9528 40.60409 128.7778 40.49659 128.6344 40.35753C128.491 40.21846 128.3831 40.06159 128.3025 39.8869C128.2306 39.70753 128.1903 39.52346 128.1903 39.33065C128.1903 39.11096 128.2353 38.93628 128.3294 38.80628C128.4235 38.67596 128.54 38.56846 128.6791 38.48784C128.8181 38.40253 128.9706 38.33534 129.1319 38.28159C129.2935 38.23221 129.446 38.17378 129.585 38.11565C129.7241 38.05721 129.8406 37.98096 129.9347 37.89128C130.0288 37.80159 130.0738 37.68065 130.0738 37.52815C130.0738 37.41596 130.0513 37.30846 130.0063 37.20534C129.966 37.106589 129.9031 37.021589 129.8181 36.945339C129.7375 36.869089 129.6388 36.810652 129.5222 36.765964C129.401 36.720964 129.271 36.698776 129.1231 36.698776C128.9572 36.698776 128.8181 36.720964 128.706 36.761589C128.5985 36.801901 128.5088 36.851276 128.4369 36.900339C128.3653 36.954402 128.3069 37.003464 128.2578 37.044089C128.2085 37.084402 128.1635 37.106589 128.1141 37.106589C128.065 37.106589 128.0244 37.097839 127.9888 37.075339C127.9619 37.052839 127.9303 37.025964 127.9035 36.985652L127.7063 36.680651C127.845 36.519401 128.0291 36.389401 128.2488 36.281589C128.4728 36.183152 128.7285 36.129089 129.02 36.129089C129.2891 36.129089 129.5313 36.174089 129.7463 36.259402C129.966 36.344401 130.15 36.460964 130.3022 36.604401C130.4594 36.752526 130.576 36.918464 130.661 37.111276C130.7419 37.30409 130.7822 37.50128 130.7822 37.7119C130.7822 37.92721 130.7372 38.10221 130.6431 38.23659C130.5491 38.37128 130.4325 38.48315 130.2935 38.56846C130.1544 38.65378 130.0019 38.72534 129.8406 38.78378C129.6791 38.8419 129.5266 38.90034 129.3875 38.96315C129.2488 39.02128 129.1319 39.09315 129.0378 39.17815C128.9438 39.26346 128.8988 39.37565 128.8988 39.51471C128.8988 39.61315 128.9213 39.70753 128.9663 39.79721C129.0066 39.88221 129.0694 39.95846 129.1456 40.02565C129.2263 40.09315 129.3203 40.14221 129.4325 40.18284C129.5447 40.21846 129.6656 40.23659 129.8 40.23659C129.9438 40.23659 130.0647 40.21846 130.1678 40.18284C130.271 40.15128 130.3563 40.11096 130.4278 40.07503C130.495 40.03034 130.5535 39.9944 130.6072 39.96284C130.6522 39.93159 130.7013 39.91378 130.7419 39.91378C130.7775 39.91378 130.8091 39.92253 130.8316 39.94065C130.8538 39.95409 130.8806 39.98096 130.9031 40.0169Z'/>
+<path d='M135.682 40.74315H135.0498C135.0048 40.74315 134.9601 40.72971 134.9198 40.70284C134.8748 40.67159 134.8388 40.63565 134.8163 40.58628L133.3817 37.72096C133.3504 37.65815 133.3232 37.59534 133.2963 37.52815C133.2695 37.46534 133.2426 37.40253 133.2157 37.34003C133.2113 37.40253 133.2023 37.46534 133.1932 37.52815C133.1845 37.59096 133.171 37.65378 133.1576 37.71659L132.4267 40.57721C132.4132 40.62659 132.3907 40.6669 132.3592 40.69378C132.3279 40.72971 132.2832 40.74315 132.2157 40.74315H131.5567L132.736 36.470026L131.7495 34.66284H132.337C132.4042 34.66284 132.4579 34.67628 132.4982 34.70784C132.5432 34.73909 132.5835 34.78409 132.6148 34.8469L135.682 40.74315Z'/>
+<path d='M138.6425 40.0169L138.8444 40.30378C138.6963 40.46065 138.5169 40.5819 138.3106 40.67596C138.1 40.76565 137.8625 40.81034 137.5888 40.81034C137.3331 40.81034 137.1 40.77003 136.8938 40.68503C136.6922 40.60409 136.5172 40.49659 136.3738 40.35753C136.2303 40.21846 136.1225 40.06159 136.0419 39.8869C135.97 39.70753 135.9297 39.52346 135.9297 39.33065C135.9297 39.11096 135.9747 38.93628 136.0688 38.80628C136.1628 38.67596 136.2794 38.56846 136.4185 38.48784C136.5575 38.40253 136.71 38.33534 136.8713 38.28159C137.0328 38.23221 137.1853 38.17378 137.3244 38.11565C137.4634 38.05721 137.58 37.98096 137.6741 37.89128C137.7681 37.80159 137.8131 37.68065 137.8131 37.52815C137.8131 37.41596 137.7906 37.30846 137.7456 37.20534C137.7053 37.106589 137.6425 37.021589 137.5575 36.945339C137.4769 36.869089 137.3781 36.810652 137.2616 36.765964C137.1403 36.720964 137.0103 36.698776 136.8625 36.698776C136.6966 36.698776 136.5575 36.720964 136.4453 36.761589C136.3378 36.801901 136.2481 36.851276 136.1763 36.900339C136.1047 36.954402 136.0463 37.003464 135.9972 37.044089C135.9478 37.084402 135.9028 37.106589 135.8535 37.106589C135.8044 37.106589 135.7638 37.097839 135.7281 37.075339C135.7013 37.052839 135.6697 37.025964 135.6428 36.985652L135.4456 36.680651C135.5844 36.519401 135.7685 36.389401 135.9881 36.281589C136.2122 36.183152 136.4678 36.129089 136.7594 36.129089C137.0285 36.129089 137.2706 36.174089 137.4856 36.259402C137.7053 36.344401 137.8894 36.460964 138.0416 36.604401C138.1988 36.752526 138.3153 36.918464 138.4003 37.111276C138.4813 37.30409 138.5216 37.50128 138.5216 37.7119C138.5216 37.92721 138.4766 38.10221 138.3825 38.23659C138.2885 38.37128 138.1719 38.48315 138.0328 38.56846C137.8938 38.65378 137.7413 38.72534 137.58 38.78378C137.4185 38.8419 137.266 38.90034 137.1269 38.96315C136.9881 39.02128 136.8713 39.09315 136.7772 39.17815C136.6831 39.26346 136.6381 39.37565 136.6381 39.51471C136.6381 39.61315 136.6606 39.70753 136.7056 39.79721C136.746 39.88221 136.8088 39.95846 136.885 40.02565C136.9656 40.09315 137.0597 40.14221 137.1719 40.18284C137.2841 40.21846 137.405 40.23659 137.5394 40.23659C137.6831 40.23659 137.8041 40.21846 137.9072 40.18284C138.0103 40.15128 138.0956 40.11096 138.1672 40.07503C138.2344 40.03034 138.2928 39.9944 138.3466 39.96284C138.3916 39.93159 138.4406 39.91378 138.4813 39.91378C138.5169 39.91378 138.5485 39.92253 138.571 39.94065C138.5931 39.95409 138.62 39.98096 138.6425 40.0169ZM142.7043 37.016902L142.5071 37.25909C142.4621 37.30846 142.4127 37.33534 142.3546 37.33534C142.2918 37.33534 142.229 37.30409 142.1662 37.24565C142.099 37.187526 142.0227 37.120026 141.9287 37.052839C141.8343 36.981276 141.7224 36.913776 141.5834 36.855651C141.449 36.797214 141.2831 36.765964 141.0812 36.765964C140.9196 36.765964 140.7762 36.792839 140.6596 36.855651C140.534 36.909402 140.4356 36.994714 140.3502 37.097839C140.2652 37.20534 140.2024 37.33534 140.1618 37.48346C140.1215 37.63596 140.0993 37.80628 140.0993 37.99003C140.0993 38.29503 140.1396 38.5819 140.2202 38.84659C140.2965 39.11096 140.404 39.34409 140.5431 39.5369C140.6821 39.72971 140.839 39.8869 141.0227 39.9944C141.2068 40.11096 141.3996 40.16471 141.6059 40.16471C141.7584 40.16471 141.8837 40.1469 141.9781 40.11096C142.0765 40.07065 142.1574 40.03034 142.2246 39.98534C142.2918 39.93596 142.3456 39.89565 142.3815 39.85971C142.4265 39.8194 142.4668 39.80159 142.5071 39.80159C142.5384 39.80159 142.5699 39.81065 142.5968 39.82409C142.619 39.83753 142.6415 39.85971 142.664 39.88221L142.9152 40.18284C142.7627 40.3844 142.5834 40.54128 142.3815 40.64909C142.1796 40.75221 141.924 40.80596 141.6237 40.80596C141.2874 40.80596 140.9737 40.72971 140.6865 40.57284C140.404 40.41596 140.1574 40.20971 139.9512 39.9494C139.7449 39.6894 139.5837 39.38909 139.4668 39.05284C139.3549 38.71659 139.2965 38.36221 139.2965 37.9944C139.2965 37.72096 139.3324 37.46534 139.4043 37.24128C139.4715 37.008151 139.5746 36.815339 139.709 36.649401C139.8481 36.487839 140.014 36.362526 140.2202 36.272839C140.4174 36.183152 140.6506 36.138151 140.9152 36.138151C141.0902 36.138151 141.2515 36.151589 141.404 36.178464C141.5521 36.205339 141.6999 36.254714 141.839 36.317526C141.9781 36.389401 142.1215 36.479089 142.2606 36.590964C142.3993 36.703151 142.5474 36.846589 142.7043 37.016902Z'/>
+<path d='M146.4236 40.18721L146.2308 38.63128C146.1458 38.36659 146.0517 38.12003 145.9439 37.89596C145.8364 37.67628 145.7199 37.48346 145.5942 37.3219C145.4642 37.155964 145.3295 37.030339 145.1908 36.936276C145.0517 36.846589 144.9083 36.801901 144.7602 36.801901C144.2983 36.801901 144.0695 37.160651 144.0695 37.88253C144.0695 38.08878 144.092 38.29034 144.1414 38.48784C144.1908 38.68065 144.258 38.8644 144.3386 39.0394C144.4283 39.21409 144.527 39.37096 144.648 39.51909C144.7692 39.66253 144.8992 39.78815 145.047 39.89128C145.1952 39.9944 145.352 40.07503 145.518 40.13784C145.6839 40.19159 145.8589 40.22315 146.038 40.22315C146.1008 40.22315 146.1636 40.21846 146.2308 40.21846C146.2936 40.20971 146.3564 40.20065 146.4236 40.18721ZM146.1189 37.39815L146.0336 36.479089C146.0336 36.402839 146.0517 36.335339 146.0874 36.281589C146.1277 36.227839 146.1995 36.200964 146.3027 36.200964H146.7152L147.2577 40.59534C147.0783 40.67159 146.8945 40.72971 146.7152 40.75659C146.5267 40.79253 146.3386 40.80596 146.1458 40.80596C145.8767 40.80596 145.6211 40.76565 145.3745 40.69378C145.128 40.61315 144.8992 40.50565 144.6886 40.37096C144.4733 40.22753 144.2805 40.06596 144.1055 39.87784C143.9308 39.68503 143.7827 39.47878 143.657 39.25003C143.5361 39.02128 143.442 38.78378 143.3702 38.52378C143.3074 38.27253 143.2714 38.00784 143.2714 37.73909C143.2714 37.48346 143.2986 37.25471 143.3567 37.052839C143.4152 36.855651 143.4958 36.689714 143.5945 36.550651C143.702 36.416276 143.823 36.313151 143.9711 36.245652C144.1189 36.174089 144.2805 36.138151 144.4599 36.138151C144.6258 36.138151 144.7827 36.169714 144.9395 36.227839C145.092 36.286276 145.2355 36.371276 145.3789 36.479089C145.5136 36.590964 145.648 36.720964 145.7736 36.878152C145.8945 37.035027 146.0111 37.20534 146.1189 37.39815ZM147.916 36.200964H148.7007L149.5035 42.80565H148.7188L147.916 36.200964ZM149.9335 36.200964H150.7181L151.521 42.80565H150.7363L149.9335 36.200964Z'/>
+<path d='M162.266 13.152C162.266 20.195 133.711 25.906 98.4844 25.906C63.2617 25.906 34.707 20.195 34.707 13.152C34.707 6.105 63.2617 .395 98.4844 .395C133.711 .395 162.266 6.105 162.266 13.152Z' fill='#e6e6e6'/>
+<path d='M162.266 13.152C162.266 20.195 133.711 25.906 98.4844 25.906C63.2617 25.906 34.707 20.195 34.707 13.152C34.707 6.105 63.2617 .395 98.4844 .395C133.711 .395 162.266 6.105 162.266 13.152Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M77.79243 12.94828H75.50055L76.37243 15.33453C76.41743 15.44422 76.46212 15.57391 76.50712 15.71828C76.5518 15.86766 76.5968 16.02703 76.64149 16.19672C76.68649 16.02703 76.73618 15.86766 76.78118 15.72328C76.82587 15.57891 76.87087 15.44922 76.91555 15.34453L77.79243 12.94828ZM80.15899 10.227971L77.32899 17.43203H75.96399L73.129304 10.227971H74.175554C74.28993 10.227971 74.38462 10.257971 74.4593 10.322659C74.5343 10.387346 74.58899 10.457034 74.61399 10.532034L75.1518 12.00172H78.13618L78.6743 10.532034C78.7093 10.447034 78.76399 10.372346 78.83868 10.317659C78.91337 10.257971 79.00805 10.227971 79.12274 10.227971H80.15899Z'/>
+<path d='M81.93048 11.55328V13.84516C82.08985 14.03922 82.25923 14.19391 82.4386 14.30328C82.61798 14.40797 82.83735 14.46266 83.09141 14.46266C83.2558 14.46266 83.4002 14.43297 83.5299 14.37297C83.6542 14.31328 83.7639 14.2186 83.8536 14.08922C83.9433 13.95953 84.013 13.79016 84.058 13.58578C84.1077 13.37672 84.1327 13.12266 84.1327 12.8236C84.1327 12.52985 84.1027 12.27078 84.048 12.05141C83.993 11.83735 83.9083 11.65797 83.8086 11.51328C83.6992 11.36891 83.5745 11.26422 83.4252 11.194534C83.2755 11.124846 83.1061 11.089846 82.92204 11.089846C82.72766 11.089846 82.55329 11.124846 82.38391 11.194534C82.22454 11.26422 82.06985 11.38391 81.93048 11.55328ZM81.86579 14.64203L81.7661 15.11547C81.7161 15.26485 81.61173 15.33953 81.45204 15.33953H80.69985V8.55891H81.93048V10.651409C82.08985 10.497034 82.26923 10.372346 82.4736 10.287659C82.67766 10.197971 82.92204 10.153284 83.2058 10.153284C83.5395 10.153284 83.8436 10.217971 84.1177 10.357659C84.3867 10.487034 84.6158 10.676409 84.8052 10.915471C84.9995 11.154534 85.1439 11.4386 85.2486 11.76235C85.3533 12.08641 85.403 12.44016 85.403 12.8236C85.403 13.24203 85.3583 13.61578 85.2636 13.93453C85.1739 14.2636 85.0442 14.53266 84.8749 14.75172C84.7105 14.9761 84.5111 15.14547 84.277 15.25985C84.048 15.37453 83.7939 15.43422 83.5149 15.43422C83.1561 15.43422 82.84204 15.35953 82.57798 15.21516C82.31423 15.07047 82.07485 14.87641 81.86579 14.64203ZM87.5892 11.55328V13.84516C87.7486 14.03922 87.918 14.19391 88.0974 14.30328C88.2767 14.40797 88.4961 14.46266 88.7502 14.46266C88.9145 14.46266 89.0589 14.43297 89.1886 14.37297C89.313 14.31328 89.4227 14.2186 89.5124 14.08922C89.602 13.95953 89.6717 13.79016 89.7167 13.58578C89.7664 13.37672 89.7914 13.12266 89.7914 12.8236C89.7914 12.52985 89.7614 12.27078 89.7067 12.05141C89.6517 11.83735 89.567 11.65797 89.4674 11.51328C89.358 11.36891 89.2333 11.26422 89.0839 11.194534C88.9342 11.124846 88.7649 11.089846 88.5808 11.089846C88.3864 11.089846 88.212 11.124846 88.0427 11.194534C87.8833 11.26422 87.7286 11.38391 87.5892 11.55328ZM87.5245 14.64203L87.4249 15.11547C87.3749 15.26485 87.2705 15.33953 87.1108 15.33953H86.3586V8.55891H87.5892V10.651409C87.7486 10.497034 87.928 10.372346 88.1324 10.287659C88.3364 10.197971 88.5808 10.153284 88.8645 10.153284C89.1983 10.153284 89.5024 10.217971 89.7764 10.357659C90.0455 10.487034 90.2745 10.676409 90.4639 10.915471C90.6583 11.154534 90.8027 11.4386 90.9074 11.76235C91.012 12.08641 91.0617 12.44016 91.0617 12.8236C91.0617 13.24203 91.017 13.61578 90.9224 13.93453C90.8327 14.2636 90.703 14.53266 90.5336 14.75172C90.3692 14.9761 90.1699 15.14547 89.9358 15.25985C89.7067 15.37453 89.4527 15.43422 89.1736 15.43422C88.8149 15.43422 88.5008 15.35953 88.2367 15.21516C87.973 15.07047 87.7336 14.87641 87.5245 14.64203ZM93.263 17.63141H92.0324V10.227971H93.263V17.63141ZM95.7684 15.33953H94.5331V10.227971H95.7684V15.33953ZM95.9377 16.82922C95.9377 16.93891 95.9181 17.0436 95.8731 17.13828C95.8284 17.23297 95.7734 17.31766 95.6987 17.38735C95.629 17.45703 95.5443 17.51172 95.4496 17.55172C95.3549 17.59641 95.2502 17.61641 95.1409 17.61641C95.0362 17.61641 94.9315 17.59641 94.8418 17.55172C94.7421 17.51172 94.6624 17.45703 94.5927 17.38735C94.5231 17.31766 94.4681 17.23297 94.4234 17.13828C94.3834 17.0436 94.3637 16.93891 94.3637 16.82922C94.3637 16.72453 94.3834 16.62516 94.4234 16.53047C94.4681 16.43578 94.5231 16.3561 94.5927 16.2861C94.6624 16.21641 94.7421 16.16172 94.8418 16.11672C94.9315 16.07703 95.0362 16.05703 95.1409 16.05703C95.2502 16.05703 95.3549 16.07703 95.4496 16.11672C95.5443 16.16172 95.629 16.21641 95.6987 16.2861C95.7734 16.3561 95.8284 16.43578 95.8731 16.53047C95.9181 16.62516 95.9377 16.72453 95.9377 16.82922ZM100.6854 14.2586L101.0091 14.70703C100.7801 14.9361 100.521 15.11047 100.232 15.23516C99.9479 15.35953 99.6141 15.41922 99.2307 15.41922C98.827 15.41922 98.4732 15.35453 98.1645 15.22016C97.8554 15.08547 97.5963 14.9011 97.3873 14.67203C97.1779 14.43297 97.0185 14.15891 96.9138 13.83516C96.8045 13.5161 96.7495 13.16735 96.7495 12.79391C96.7495 12.37516 96.8091 12.00172 96.9338 11.67266C97.0535 11.34891 97.2179 11.069846 97.427 10.845784C97.6363 10.621409 97.8804 10.447034 98.1595 10.327659C98.4385 10.212971 98.7373 10.153284 99.0513 10.153284C99.2307 10.153284 99.4101 10.168284 99.5945 10.192971C99.7735 10.217971 99.9479 10.267971 100.1223 10.327659C100.292 10.397346 100.4563 10.482034 100.6157 10.586721C100.7751 10.696409 100.9245 10.830784 101.0591 10.990159L100.7054 11.4386C100.6554 11.51328 100.5807 11.55328 100.481 11.55328C100.4063 11.55328 100.3366 11.52828 100.272 11.4836C100.212 11.4336 100.1423 11.37891 100.0576 11.32391C99.9729 11.26422 99.8732 11.209534 99.7538 11.164534C99.6291 11.114846 99.4698 11.089846 99.2754 11.089846S98.9016 11.124846 98.7473 11.204534C98.5929 11.27422 98.4585 11.38391 98.3488 11.53328C98.2391 11.67266 98.1545 11.85203 98.0998 12.06641C98.0398 12.28047 98.0101 12.51985 98.0101 12.79391C98.0101 13.05797 98.0348 13.29203 98.0898 13.49641C98.1445 13.70547 98.2241 13.88485 98.3288 14.02922C98.4385 14.17391 98.5729 14.28828 98.7373 14.36328C98.9016 14.44297 99.091 14.48266 99.3054 14.48266C99.4748 14.48266 99.6141 14.46266 99.7338 14.42297C99.8435 14.38797 99.9432 14.34328 100.0279 14.29328C100.1126 14.2486 100.1823 14.2036 100.242 14.16391C100.3016 14.12891 100.3616 14.10891 100.4263 14.10891S100.541 14.12391 100.5807 14.14891C100.6107 14.17391 100.6504 14.2136 100.6854 14.2586ZM104.5258 12.41016V11.54828C104.3514 11.36391 104.167 11.224534 103.9877 11.134846C103.7983 11.040159 103.5842 10.995159 103.3302 10.995159C103.1258 10.995159 102.9564 11.040159 102.8317 11.134846C102.7024 11.22953 102.6377 11.38391 102.6377 11.59797C102.6377 11.70766 102.6674 11.80735 102.7324 11.90203C102.797 11.99672 102.9017 12.07641 103.0461 12.1461C103.1905 12.21578 103.3849 12.27078 103.6289 12.32047C103.8733 12.36047 104.172 12.39516 104.5258 12.41016ZM101.7058 14.62735L101.9252 14.2336C101.9599 14.17391 102.0099 14.12391 102.0695 14.07422C102.1295 14.03422 102.2042 14.00953 102.2889 14.00953C102.3886 14.00953 102.4783 14.03422 102.563 14.07922C102.6427 14.12391 102.7324 14.17891 102.8317 14.2336C102.9314 14.29328 103.0461 14.34828 103.1805 14.39297C103.3102 14.43797 103.4745 14.46266 103.6739 14.46266C103.948 14.46266 104.162 14.38297 104.3067 14.2136C104.4511 14.05422 104.5258 13.80016 104.5258 13.45641V13.15735C104.1374 13.14766 103.7933 13.11766 103.4895 13.06766C103.1855 13.02297 102.9214 12.95828 102.6924 12.8836C102.4683 12.8086 102.2739 12.71891 102.1195 12.61453C101.9649 12.50985 101.8355 12.40016 101.7358 12.28547C101.6411 12.1711 101.5714 12.04641 101.5264 11.92203C101.4817 11.79235 101.4617 11.66297 101.4617 11.53328C101.4617 11.30422 101.4967 11.104846 101.5714 10.930471S101.7458 10.611721 101.8802 10.497034C102.0149 10.382346 102.1692 10.292659 102.3536 10.237971C102.538 10.178284 102.7374 10.148284 102.9514 10.148284C103.1358 10.148284 103.3002 10.163284 103.4495 10.197971C103.6042 10.227971 103.7436 10.272659 103.878 10.332659C104.0127 10.392346 104.1374 10.467034 104.2617 10.556721C104.3864 10.641409 104.5108 10.746096 104.6405 10.860784L104.7499 10.492034C104.7849 10.387346 104.8349 10.317659 104.8995 10.277659C104.9642 10.247971 105.0539 10.227971 105.1686 10.227971H105.7264V13.45641C105.7264 13.74547 105.6817 14.00953 105.602 14.2536C105.5124 14.49766 105.3927 14.70203 105.2283 14.88141C105.0639 15.05078 104.8645 15.19016 104.6305 15.28985C104.3964 15.38453 104.1274 15.43422 103.8283 15.43422C103.0014 15.43422 102.2939 15.16516 101.7058 14.62735Z'/>
+<path d='M108.5018 10.148284C108.7512 10.148284 108.9902 10.187971 109.2243 10.262971C109.4587 10.337659 109.6627 10.452034 109.8421 10.601721L109.4734 11.199534C109.4487 11.23422 109.4237 11.26422 109.3987 11.28422C109.3737 11.29922 109.344 11.30922 109.309 11.30922C109.2793 11.30922 109.2493 11.29922 109.2193 11.28422C109.1896 11.26422 109.1546 11.24422 109.1196 11.224534C109.0799 11.204534 109.0349 11.184534 108.9802 11.164534C108.9306 11.149534 108.8656 11.139846 108.7909 11.139846C108.6565 11.139846 108.5468 11.184534 108.4721 11.27422C108.3924 11.36391 108.3524 11.4886 108.3524 11.64797V14.41797H109.7177V15.29485H108.3524V16.90391H107.7149C107.6399 16.90391 107.5802 16.88422 107.5356 16.84922C107.4906 16.81422 107.4556 16.75953 107.4409 16.69485L107.1818 15.29985L106.3596 15.16516V14.67703C106.3596 14.59235 106.3846 14.52766 106.4293 14.48266C106.4743 14.43797 106.534 14.41797 106.5987 14.41797H107.1218V11.56328C107.1218 11.119846 107.2415 10.776096 107.4756 10.527034C107.7149 10.272659 108.0587 10.148284 108.5018 10.148284ZM111.7794 15.33953H110.5441V10.227971H111.7794V15.33953ZM111.9488 16.82922C111.9488 16.93891 111.9291 17.0436 111.8841 17.13828C111.8394 17.23297 111.7844 17.31766 111.7097 17.38735C111.64 17.45703 111.5553 17.51172 111.4606 17.55172C111.3659 17.59641 111.2613 17.61641 111.1519 17.61641C111.0472 17.61641 110.9425 17.59641 110.8528 17.55172C110.7531 17.51172 110.6734 17.45703 110.6038 17.38735C110.5341 17.31766 110.4791 17.23297 110.4344 17.13828C110.3944 17.0436 110.3747 16.93891 110.3747 16.82922C110.3747 16.72453 110.3944 16.62516 110.4344 16.53047C110.4791 16.43578 110.5341 16.3561 110.6038 16.2861C110.6734 16.21641 110.7531 16.16172 110.8528 16.11672C110.9425 16.07703 111.0472 16.05703 111.1519 16.05703C111.2613 16.05703 111.3659 16.07703 111.4606 16.11672C111.5553 16.16172 111.64 16.21641 111.7097 16.2861C111.7844 16.3561 111.8394 16.43578 111.8841 16.53047C111.9291 16.62516 111.9488 16.72453 111.9488 16.82922ZM115.2964 15.41922C114.9127 15.41922 114.5689 15.35953 114.2552 15.23516C113.9414 15.11047 113.6774 14.9361 113.453 14.71203C113.2339 14.48766 113.0645 14.2086 112.9449 13.88485C112.8202 13.5611 112.7605 13.19735 112.7605 12.79391C112.7605 12.39016 112.8202 12.02141 112.9449 11.69766C113.0645 11.37391 113.2339 11.094846 113.453 10.865784C113.6774 10.636409 113.9414 10.462034 114.2552 10.337659C114.5689 10.212971 114.9127 10.153284 115.2964 10.153284C115.6752 10.153284 116.0189 10.212971 116.3327 10.337659C116.6417 10.462034 116.9058 10.636409 117.1299 10.865784C117.3492 11.094846 117.5186 11.37391 117.638 11.69766C117.7577 12.02141 117.8174 12.39016 117.8174 12.79391C117.8174 13.19735 117.7577 13.5611 117.638 13.88485C117.5186 14.2086 117.3492 14.48766 117.1299 14.71203C116.9058 14.9361 116.6417 15.11047 116.3327 15.23516C116.0189 15.35953 115.6752 15.41922 115.2964 15.41922ZM115.2964 11.099846C114.863 11.099846 114.5442 11.24422 114.3398 11.53328C114.1305 11.81735 114.0261 12.23578 114.0261 12.78391C114.0261 13.33172 114.1305 13.75047 114.3398 14.04422C114.5442 14.33328 114.863 14.47766 115.2964 14.47766C115.7199 14.47766 116.0339 14.33328 116.243 14.04422C116.4424 13.75547 116.547 13.33672 116.547 12.78391C116.547 12.23078 116.4424 11.81235 116.243 11.52828C116.0339 11.24422 115.7199 11.099846 115.2964 11.099846ZM119.9089 14.71203L119.8242 15.11547C119.7742 15.26485 119.6699 15.33953 119.5102 15.33953H118.758V10.227971H119.9886V13.92485C120.153 14.08922 120.3323 14.2236 120.5167 14.31828C120.7011 14.41297 120.9002 14.46266 121.1145 14.46266C121.4086 14.46266 121.6227 14.37797 121.7674 14.2036C121.9117 14.03422 121.9814 13.79516 121.9814 13.48141V10.227971H123.212V13.48141C123.212 13.76516 123.172 14.02922 123.1024 14.2636C123.0227 14.50266 122.913 14.70703 122.7736 14.88141C122.6242 15.05078 122.4449 15.18016 122.2305 15.27985C122.0164 15.36953 121.7674 15.41922 121.4883 15.41922C121.3139 15.41922 121.1545 15.39953 121.0099 15.36953C120.8655 15.32953 120.7258 15.28485 120.6014 15.22016C120.4717 15.16016 120.3524 15.08547 120.2327 15.00078C120.123 14.9111 120.0136 14.81641 119.9089 14.71203Z'/>
+</g>
+</g>
+</svg>
diff --git a/src/images/es_noisetest.svg b/src/images/es_noisetest.svg
new file mode 100644
index 0000000..e38dcec
--- /dev/null
+++ b/src/images/es_noisetest.svg
@@ -0,0 +1,122 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- This file was generated by dvisvgm 2.11.1 -->
+<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='283.863pt' height='177.846pt' viewBox='0 -177.846 283.863 177.846'>
+<g id='page1'>
+<g transform='matrix(1 0 0 -1 0 0)'>
+<path d='M28.543 163.671871V177.8477H113.5859V163.671871Z' fill='#f2f2f2'/>
+<path d='M38.937919 173.36075V169.048563H38.695732C38.489482 169.048563 38.346044 168.958876 38.346044 168.761688C38.346044 168.591376 38.444794 168.466063 38.686669 168.466063H39.53854C39.59229 168.466063 39.66386 168.457001 39.72667 168.457001C39.94198 168.457001 40.06729 168.573563 40.06729 168.752938C40.06729 168.941063 39.94198 169.048563 39.72667 169.048563H39.47573L39.48448 173.28013C39.52042 173.10075 39.59229 172.91263 39.65511 172.74231C40.13011 171.45138 40.56948 170.14231 41.05354 168.851376C41.13417 168.645126 41.22386 168.466063 41.53761 168.466063H41.69011C41.96792 168.466063 42.00386 168.663251 42.00386 168.824501V173.36075H42.24573C42.45198 173.36075 42.59542 173.45044 42.59542 173.64763C42.59542 173.81794 42.49667 173.94356 42.25479 173.94356H41.40323C41.34917 173.94356 41.27761 173.95231 41.21479 173.95231C40.99073 173.95231 40.87417 173.827 40.87417 173.64763C40.87417 173.46825 40.99979 173.36075 41.21479 173.36075H41.46573V169.129501C41.41198 169.272938 41.36729 169.416376 41.32229 169.55981L41.08042 170.25888C40.72167 171.26294 40.35417 172.27606 39.98667 173.28013L39.87917 173.567C39.79854 173.87169 39.60104 173.94356 39.35011 173.94356H38.830107C38.776357 173.94356 38.722607 173.95231 38.668857 173.95231C38.489482 173.95231 38.346044 173.84481 38.346044 173.65669C38.346044 173.45044 38.489482 173.36075 38.686669 173.36075H38.937919ZM44.79183 174.042C44.08339 173.96138 43.4737 174.00606 43.3662 172.50013C43.33026 172.09669 43.33026 171.68419 43.33026 171.28106V170.63544C43.33026 170.10638 43.34839 169.56856 43.50089 169.102313C43.7337 168.394188 44.39714 168.367313 44.99776 168.367313H45.41933C45.84964 168.367313 46.32464 168.394188 46.62933 168.690126C46.99714 169.057626 47.02401 169.89138 47.02401 170.58169V171.57669C47.02401 172.02513 47.01495 172.48231 46.94308 172.91263C46.87151 173.38763 46.74589 173.81794 46.13651 173.97044C45.84964 174.042 45.5537 174.042 45.26683 174.042H44.79183ZM43.9937 170.69825C43.98495 170.76981 43.98495 170.83263 43.98495 170.9045C43.98495 171.43325 43.98495 171.95325 44.02964 172.47325C44.05651 172.71513 44.08339 173.02013 44.2537 173.20825C44.45995 173.44138 44.80964 173.4595 45.11433 173.4595H45.23089C45.51776 173.4595 45.84964 173.45044 46.06464 173.25325C46.24401 173.08294 46.2887 172.787 46.31558 172.55388C46.36058 172.17731 46.36058 171.80075 46.36058 171.4245V170.74294C46.36058 170.232 46.35151 169.58669 46.14526 169.290751C45.95714 168.977001 45.53589 168.950126 45.20401 168.950126C44.6662 168.950126 44.19995 168.986063 44.07464 169.72106C44.01183 170.04388 44.02964 170.37544 43.9937 170.69825ZM49.552 173.36075V169.048563H48.5479C48.3148 169.048563 48.2073 168.941063 48.2073 168.752938C48.2073 168.582626 48.3148 168.466063 48.521 168.466063H51.3179C51.4792 168.483876 51.5601 168.618251 51.5601 168.752938C51.5601 168.932001 51.4345 169.057626 51.2104 169.057626C51.1385 169.057626 51.067 169.048563 51.0132 169.048563H50.2154V173.36075H51.2192C51.4523 173.36075 51.5601 173.46825 51.5601 173.65669C51.5601 173.827 51.4523 173.94356 51.2464 173.94356H48.4492C48.2879 173.92544 48.2073 173.79106 48.2073 173.65669C48.2073 173.47731 48.3326 173.35169 48.5567 173.35169C48.6285 173.35169 48.6914 173.36075 48.7539 173.36075H49.552ZM53.335 168.752938C53.819 168.466063 54.2671 168.367313 54.7962 168.367313C55.7015 168.367313 56.4637 169.048563 56.4637 169.972C56.4637 170.58169 56.114 171.12856 55.5581 171.38856C54.7334 171.77388 53.335 171.61263 53.335 172.59888C53.335 173.14544 53.8996 173.4595 54.3837 173.4595C54.9396 173.4595 55.379 173.1545 55.5312 172.58075C55.594 172.32981 55.5762 172.12356 55.9078 172.12356C56.1856 172.12356 56.2306 172.30294 56.2306 172.46419V173.49513C56.2306 173.54888 56.2396 173.61169 56.2396 173.68356C56.2396 173.90763 56.1318 174.042 55.9437 174.042C55.7196 174.042 55.6387 173.83575 55.6031 173.65669C55.1815 173.91669 54.85 174.042 54.3837 174.042C53.55 174.042 52.779 173.50419 52.7075 172.66138V172.57169C52.7075 171.94419 53.1465 171.38856 53.7293 171.18231C54.5809 170.88638 55.8362 170.99419 55.8362 169.91825C55.8362 169.344501 55.3431 168.950126 54.7784 168.950126C54.2225 168.950126 53.4603 169.165126 53.3887 169.82856C53.344 170.10638 53.344 170.28575 53.03 170.28575C52.7343 170.28575 52.7075 170.08856 52.7075 169.90919V168.707938C52.7075 168.492938 52.815 168.367313 52.9943 168.367313C53.2184 168.367313 53.299 168.573563 53.335 168.752938ZM57.7904 173.36075V169.048563H57.5035C57.2973 169.048563 57.1448 168.967938 57.1448 168.761688C57.1448 168.573563 57.2704 168.457001 57.4854 168.457001C57.5573 168.457001 57.6289 168.466063 57.6917 168.466063H61.2057C61.3764 168.483876 61.457 168.636376 61.457 168.797626C61.457 168.860438 61.4479 168.932001 61.4479 168.986063V169.73013C61.4479 169.93606 61.3404 170.05263 61.1251 170.05263C60.9548 170.05263 60.7754 169.99888 60.7754 169.73888C60.7754 169.68513 60.7845 169.64044 60.7845 169.59544V169.048563H58.4535V171.012H59.5923C59.5923 170.95825 59.5832 170.9045 59.5832 170.84169C59.5832 170.58169 59.7357 170.50106 59.9239 170.50106C60.0942 170.50106 60.2557 170.55481 60.2557 170.82356V171.60356C60.2557 171.65731 60.2645 171.72013 60.2645 171.77388C60.2645 172.02513 60.1123 172.10575 59.9239 172.10575C59.7357 172.10575 59.5832 172.02513 59.5832 171.76513C59.5832 171.71138 59.5923 171.64856 59.5923 171.59481H58.4535V173.36075H60.5873V172.83169C60.5873 172.56294 60.7398 172.50013 60.9279 172.50013C61.152 172.50013 61.2507 172.62575 61.2507 172.84981V173.58481C61.2507 173.782 61.197 173.95231 60.9101 173.95231C60.8382 173.95231 60.7754 173.94356 60.7129 173.94356H57.5035C57.2704 173.94356 57.1448 173.84481 57.1448 173.64763C57.1448 173.42356 57.3151 173.36075 57.5035 173.36075H57.7904ZM62.434 168.259813C62.2637 168.232938 62.1559 168.071376 62.1559 167.919188C62.1559 167.730751 62.3084 167.596376 62.5593 167.596376H65.4462C65.7062 167.596376 65.8496 167.739813 65.8496 167.927938C65.8496 168.089501 65.7418 168.250751 65.5537 168.268876H62.6043C62.5506 168.268876 62.4878 168.268876 62.434 168.259813ZM67.257 173.36075H68.3776V169.048563H67.8576C67.6604 169.048563 67.5439 168.932001 67.5439 168.761688C67.5439 168.609501 67.6335 168.466063 67.8307 168.466063H69.5251C69.731 168.466063 69.8745 168.555751 69.8745 168.761688C69.8745 168.932001 69.7579 169.048563 69.5607 169.048563H69.041V173.36075H70.1614V172.75106C70.1795 172.55388 70.3317 172.50013 70.5023 172.50013C70.7173 172.50013 70.8248 172.60763 70.8248 172.84075V173.61169C70.8248 173.83575 70.6995 173.94356 70.5023 173.94356H66.9073C66.6651 173.94356 66.5935 173.80013 66.5935 173.57575V172.82294C66.5935 172.58075 66.737 172.50013 66.9164 172.50013C67.1045 172.50013 67.257 172.56294 67.257 172.82294V173.36075ZM71.9096 173.36075V169.048563H71.6228C71.4165 169.048563 71.264 168.967938 71.264 168.761688C71.264 168.573563 71.3896 168.457001 71.6046 168.457001C71.6765 168.457001 71.7481 168.466063 71.8109 168.466063H75.3249C75.4956 168.483876 75.5762 168.636376 75.5762 168.797626C75.5762 168.860438 75.5671 168.932001 75.5671 168.986063V169.73013C75.5671 169.93606 75.4596 170.05263 75.2443 170.05263C75.074 170.05263 74.8946 169.99888 74.8946 169.73888C74.8946 169.68513 74.9037 169.64044 74.9037 169.59544V169.048563H72.5728V171.012H73.7115C73.7115 170.95825 73.7025 170.9045 73.7025 170.84169C73.7025 170.58169 73.855 170.50106 74.0431 170.50106C74.2134 170.50106 74.3749 170.55481 74.3749 170.82356V171.60356C74.3749 171.65731 74.3837 171.72013 74.3837 171.77388C74.3837 172.02513 74.2315 172.10575 74.0431 172.10575C73.855 172.10575 73.7025 172.02513 73.7025 171.76513C73.7025 171.71138 73.7115 171.64856 73.7115 171.59481H72.5728V173.36075H74.7065V172.83169C74.7065 172.56294 74.859 172.50013 75.0471 172.50013C75.2712 172.50013 75.37 172.62575 75.37 172.84981V173.58481C75.37 173.782 75.3162 173.95231 75.0293 173.95231C74.9574 173.95231 74.8946 173.94356 74.8321 173.94356H71.6228C71.3896 173.94356 71.264 173.84481 71.264 173.64763C71.264 173.42356 71.4343 173.36075 71.6228 173.36075H71.9096ZM76.867 168.752938C77.351 168.466063 77.7992 168.367313 78.3282 168.367313C79.2335 168.367313 79.9957 169.048563 79.9957 169.972C79.9957 170.58169 79.646 171.12856 79.0901 171.38856C78.2654 171.77388 76.867 171.61263 76.867 172.59888C76.867 173.14544 77.4317 173.4595 77.9157 173.4595C78.4717 173.4595 78.911 173.1545 79.0632 172.58075C79.126 172.32981 79.1082 172.12356 79.4398 172.12356C79.7176 172.12356 79.7626 172.30294 79.7626 172.46419V173.49513C79.7626 173.54888 79.7717 173.61169 79.7717 173.68356C79.7717 173.90763 79.6639 174.042 79.4757 174.042C79.2517 174.042 79.1707 173.83575 79.1351 173.65669C78.7135 173.91669 78.382 174.042 77.9157 174.042C77.082 174.042 76.311 173.50419 76.2395 172.66138V172.57169C76.2395 171.94419 76.6785 171.38856 77.2614 171.18231C78.1129 170.88638 79.3682 170.99419 79.3682 169.91825C79.3682 169.344501 78.8751 168.950126 78.3104 168.950126C77.7545 168.950126 76.9923 169.165126 76.9207 169.82856C76.876 170.10638 76.876 170.28575 76.562 170.28575C76.2664 170.28575 76.2395 170.08856 76.2395 169.90919V168.707938C76.2395 168.492938 76.347 168.367313 76.5264 168.367313C76.7504 168.367313 76.831 168.573563 76.867 168.752938ZM81.3762 173.36075H82.4968V169.048563H81.9768C81.7796 169.048563 81.6631 168.932001 81.6631 168.761688C81.6631 168.609501 81.7528 168.466063 81.9499 168.466063H83.6443C83.8503 168.466063 83.9937 168.555751 83.9937 168.761688C83.9937 168.932001 83.8771 169.048563 83.6799 169.048563H83.1603V173.36075H84.2806V172.75106C84.2987 172.55388 84.4509 172.50013 84.6215 172.50013C84.8365 172.50013 84.944 172.60763 84.944 172.84075V173.61169C84.944 173.83575 84.8187 173.94356 84.6215 173.94356H81.0265C80.7843 173.94356 80.7128 173.80013 80.7128 173.57575V172.82294C80.7128 172.58075 80.8562 172.50013 81.0356 172.50013C81.2237 172.50013 81.3762 172.56294 81.3762 172.82294V173.36075Z'/>
+<path d='M90.4612 172.16856C90.3087 172.15044 90.1921 172.03388 90.1921 171.88169C90.1921 171.72013 90.3178 171.58575 90.515 171.58575C90.56 171.58575 90.6137 171.59481 90.6584 171.59481H93.9128C94.1009 171.59481 94.2265 171.71138 94.2265 171.89044C94.2265 172.06981 94.0831 172.1595 93.9215 172.17731H90.9362C90.8468 172.17731 90.7571 172.18638 90.6675 172.18638C90.5956 172.18638 90.524 172.17731 90.4612 172.16856ZM90.4165 170.80575C90.2818 170.80575 90.1921 170.63544 90.1921 170.52794C90.1921 170.34856 90.3446 170.232 90.5509 170.232H93.85C94.0381 170.232 94.2265 170.31263 94.2265 170.52794C94.2265 170.66231 94.1368 170.79669 93.9843 170.81481H90.5059C90.479 170.81481 90.4434 170.81481 90.4165 170.80575Z'/>
+<path d='M101.5034 174.042C100.2034 173.89856 99.6834 172.312 99.6834 171.19138C99.6834 170.66231 99.7821 170.13356 99.9971 169.64919C100.2753 169.021688 100.849 168.358251 101.5931 168.358251C102.2653 168.358251 102.8121 168.878251 103.1171 169.425126C103.4218 169.972 103.5384 170.5995 103.5384 171.21825C103.5384 171.747 103.4396 172.27606 103.2246 172.76013C102.9465 173.38763 102.364 174.05106 101.6287 174.05106C101.584 174.05106 101.5481 174.042 101.5034 174.042ZM100.3468 171.11044V171.23606C100.3468 171.98919 100.544 173.13669 101.369 173.4145C101.4496 173.44138 101.5212 173.45044 101.6018 173.45044C102.579 173.45044 102.875 171.96231 102.875 171.38856C102.875 170.47419 102.5521 168.977001 101.6287 168.950126H101.6109C100.8937 168.950126 100.5084 169.94513 100.3918 170.6445C100.3737 170.79669 100.365 170.95825 100.3468 171.11044Z'/>
+<path d='M61.71335 150.15459L61.65367 150.92178C61.63867 151.01146 61.61367 151.07615 61.57898 151.11115C61.54398 151.14584 61.47429 151.16584 61.3796 151.16584H60.871479V146.118964H61.76335V149.3074C61.82804 149.48178 61.89773 149.63646 61.97242 149.76584C62.0521 149.90553 62.14179 150.0149 62.24148 150.10459C62.33617 150.19928 62.45085 150.26896 62.57023 150.31396C62.69992 150.35865 62.83929 150.38365 62.99898 150.38365C63.11335 150.38365 63.21304 150.37365 63.30273 150.35365C63.39242 150.33396 63.4621 150.32396 63.5071 150.32396C63.58679 150.32396 63.63648 150.36365 63.65648 150.44834L63.72117 151.11115C63.64648 151.16084 63.55679 151.19584 63.4571 151.22053C63.36242 151.24553 63.25804 151.25553 63.15335 151.25553C62.8196 151.25553 62.53554 151.16084 62.30148 150.96146C62.0671 150.7724 61.87273 150.49834 61.71335 150.15459Z'/>
+<path d='M67.66507 149.19303H64.90507C64.96476 149.63146 65.11914 149.97521 65.36851 150.22428C65.61257 150.46834 65.95132 150.59303 66.37476 150.59303C66.57914 150.59303 66.75851 150.55803 66.91789 150.49334C67.07726 150.42365 67.21164 150.32396 67.32132 150.20428C67.43601 150.0749 67.5207 149.93021 67.58039 149.75584C67.63539 149.58646 67.66507 149.39709 67.66507 149.19303ZM68.38257 146.826464L68.13351 147.15021C68.09351 147.20521 68.03882 147.2349 67.96414 147.2349C67.90914 147.2349 67.83945 147.2099 67.75976 147.15521C67.68507 147.105526 67.58539 147.050526 67.4707 146.990839C67.35632 146.931151 67.21664 146.876151 67.05226 146.826464C66.89289 146.771776 66.70351 146.746776 66.47945 146.746776C66.24039 146.746776 66.02601 146.786464 65.83164 146.866151C65.63726 146.941151 65.47289 147.060526 65.33351 147.2149C65.19414 147.37459 65.08445 147.57365 65.00976 147.80803C64.93007 148.04209 64.88507 148.32115 64.87507 148.6399H68.24789C68.33289 148.6399 68.38757 148.6649 68.41757 148.70959C68.44726 148.75459 68.46226 148.84928 68.46226 148.98865C68.46226 149.3474 68.40757 149.66615 68.30289 149.94521C68.1982 150.22928 68.04882 150.46334 67.85945 150.65271C67.67507 150.84709 67.45101 150.99146 67.19195 151.09115C66.93789 151.19584 66.65882 151.24553 66.35476 151.24553C65.99101 151.24553 65.66226 151.18084 65.36851 151.05115C65.07445 150.92678 64.83039 150.7524 64.62601 150.52303C64.42164 150.30396 64.26726 150.0349 64.16257 149.73115C64.0532 149.42709 63.9982 149.09834 63.9982 148.74459C63.9982 148.31115 64.0582 147.9224 64.17757 147.58865C64.29726 147.2549 64.46164 146.970839 64.6807 146.746776C64.89007 146.517401 65.14914 146.343026 65.4382 146.228651C65.73695 146.108964 66.05601 146.049276 66.40476 146.049276C66.58914 146.049276 66.7732 146.064276 66.95757 146.098964C67.14195 146.128964 67.32132 146.173651 67.5007 146.238651C67.67007 146.303339 67.83445 146.383026 67.98882 146.477714C68.14351 146.577401 68.27289 146.691776 68.38257 146.826464ZM72.4869 150.33396L72.6862 150.65771C72.4919 150.84209 72.2628 150.98146 72.0037 151.09115C71.7347 151.19084 71.4406 151.24553 71.1069 151.24553C70.8228 151.24553 70.5687 151.20584 70.3447 151.12615C70.12031 151.04615 69.93593 150.94178 69.78156 150.80209C69.62718 150.67271 69.5125 150.51334 69.43281 150.33396C69.35312 150.15959 69.31343 149.97521 69.31343 149.78084C69.31343 149.56646 69.35312 149.3824 69.42281 149.22771C69.5025 149.07834 69.59718 148.95365 69.72187 148.84928C69.84656 148.74459 69.98593 148.6599 70.14031 148.59021C70.2997 148.52521 70.4591 148.46553 70.6287 148.41084C70.7881 148.35584 70.9525 148.30615 71.1069 148.26115C71.2662 148.21146 71.4059 148.15178 71.5303 148.09178C71.655 148.02209 71.7547 147.9474 71.8244 147.85271C71.9041 147.76303 71.9391 147.64834 71.9391 147.50896C71.9391 147.39428 71.9191 147.2899 71.8741 147.19021C71.8344 147.090526 71.7694 147.000839 71.6847 146.926151C71.6 146.851464 71.4906 146.786464 71.3609 146.746776C71.2316 146.696776 71.0819 146.677089 70.9075 146.677089C70.7034 146.677089 70.5341 146.701776 70.3994 146.746776C70.265 146.791464 70.15031 146.846464 70.05062 146.901151C69.96093 146.955839 69.87624 147.010839 69.81156 147.055526C69.74687 147.100526 69.68187 147.12521 69.62218 147.12521C69.56749 147.12521 69.51749 147.115526 69.48281 147.090526C69.44781 147.065526 69.41281 147.035526 69.38812 146.990839L69.17874 146.652089C69.37812 146.472714 69.62218 146.328339 69.90624 146.208651C70.1903 146.098964 70.5091 146.039276 70.8628 146.039276C71.1716 146.039276 71.4456 146.078964 71.6797 146.163651C71.9141 146.248651 72.1134 146.358026 72.2778 146.507714C72.4422 146.647089 72.5616 146.821464 72.6462 147.015839C72.7309 147.2149 72.7709 147.42928 72.7709 147.66334C72.7709 147.86771 72.7309 148.04209 72.6612 148.18146C72.5816 148.33115 72.4869 148.45053 72.3625 148.55021C72.2378 148.6499 72.0984 148.73459 71.9437 148.79928C71.7894 148.86428 71.625 148.92896 71.4656 148.97865C71.2962 149.03865 71.1369 149.08834 70.9822 149.13803C70.8278 149.18303 70.6884 149.23771 70.5637 149.3024C70.4394 149.3674 70.3397 149.44209 70.27 149.52678C70.1903 149.61146 70.15531 149.72115 70.15531 149.85053C70.15531 149.95521 70.1803 150.0499 70.22 150.13459C70.27 150.22428 70.3297 150.30396 70.4194 150.36865C70.4991 150.43334 70.6037 150.48834 70.7231 150.52303C70.8428 150.56303 70.9775 150.58303 71.1269 150.58303C71.3012 150.58303 71.4506 150.56303 71.5753 150.52303C71.6997 150.48834 71.8094 150.44334 71.9041 150.40365C71.9937 150.35365 72.0684 150.31396 72.1331 150.27896C72.1981 150.24428 72.2528 150.22428 72.3025 150.22428C72.3872 150.22428 72.4472 150.25928 72.4869 150.33396ZM77.2391 149.19303H74.4791C74.5387 149.63146 74.6931 149.97521 74.9425 150.22428C75.1866 150.46834 75.5253 150.59303 75.9487 150.59303C76.1531 150.59303 76.3325 150.55803 76.4919 150.49334C76.6512 150.42365 76.7856 150.32396 76.8953 150.20428C77.01 150.0749 77.0947 149.93021 77.1544 149.75584C77.2094 149.58646 77.2391 149.39709 77.2391 149.19303ZM77.9566 146.826464L77.7075 147.15021C77.6675 147.20521 77.6128 147.2349 77.5381 147.2349C77.4831 147.2349 77.4134 147.2099 77.3337 147.15521C77.2591 147.105526 77.1594 147.050526 77.0447 146.990839C76.9303 146.931151 76.7906 146.876151 76.6262 146.826464C76.4669 146.771776 76.2775 146.746776 76.0534 146.746776C75.8144 146.746776 75.6 146.786464 75.4056 146.866151C75.2112 146.941151 75.0469 147.060526 74.9075 147.2149C74.7681 147.37459 74.6584 147.57365 74.5837 147.80803C74.5041 148.04209 74.4591 148.32115 74.4491 148.6399H77.8219C77.9069 148.6399 77.9616 148.6649 77.9916 148.70959C78.0212 148.75459 78.0362 148.84928 78.0362 148.98865C78.0362 149.3474 77.9816 149.66615 77.8769 149.94521C77.7722 150.22928 77.6228 150.46334 77.4334 150.65271C77.2491 150.84709 77.025 150.99146 76.7659 151.09115C76.5119 151.19584 76.2328 151.24553 75.9287 151.24553C75.565 151.24553 75.2362 151.18084 74.9425 151.05115C74.6484 150.92678 74.4044 150.7524 74.2 150.52303C73.9956 150.30396 73.8412 150.0349 73.7366 149.73115C73.6272 149.42709 73.5722 149.09834 73.5722 148.74459C73.5722 148.31115 73.6322 147.9224 73.7516 147.58865C73.8712 147.2549 74.0356 146.970839 74.2547 146.746776C74.4641 146.517401 74.7231 146.343026 75.0122 146.228651C75.3109 146.108964 75.63 146.049276 75.9787 146.049276C76.1631 146.049276 76.3472 146.064276 76.5316 146.098964C76.7159 146.128964 76.8953 146.173651 77.0747 146.238651C77.2441 146.303339 77.4084 146.383026 77.5628 146.477714C77.7175 146.577401 77.8469 146.691776 77.9566 146.826464Z'/>
+<path d='M80.6349 146.039276C80.8643 146.039276 81.0884 146.078964 81.3027 146.158964C81.5168 146.243651 81.7012 146.353026 81.8555 146.497714L81.5965 146.921151C81.5618 146.975839 81.5168 147.005839 81.4721 147.005839C81.4471 147.005839 81.4121 146.995839 81.3824 146.965839C81.3424 146.946151 81.3027 146.916151 81.2527 146.886151C81.203 146.856464 81.143 146.826464 81.0734 146.806464C81.0087 146.776464 80.929 146.766776 80.8343 146.766776C80.6699 146.766776 80.5402 146.816464 80.4355 146.921151C80.3312 147.025839 80.2812 147.18021 80.2812 147.39428V150.42365H81.7409V151.06615H80.2812V152.8049H79.8327C79.778 152.8049 79.7284 152.7899 79.6984 152.75521C79.6584 152.72521 79.6387 152.68553 79.6287 152.63553L79.4243 151.07615L78.5974 150.97146V150.61771C78.5974 150.55303 78.6171 150.50334 78.6521 150.47334C78.6871 150.43834 78.7318 150.42365 78.7865 150.42365H79.3943V147.33459C79.3943 146.916151 79.499 146.597401 79.7184 146.373026C79.9274 146.148964 80.2365 146.039276 80.6349 146.039276Z'/>
+<path d='M80.66015 133.6055H61.46875C59.2695 133.6055 57.4844 131.8203 57.4844 129.6211V112.6836C57.4844 110.4844 59.2695 108.6992 61.46875 108.6992H80.66015C82.8594 108.6992 84.6445 110.4844 84.6445 112.6836V129.6211C84.6445 131.8203 82.8594 133.6055 80.66015 133.6055Z' fill='#e6ffff'/>
+<path d='M80.66015 133.6055H61.46875C59.2695 133.6055 57.4844 131.8203 57.4844 129.6211V112.6836C57.4844 110.4844 59.2695 108.6992 61.46875 108.6992H80.66015C82.8594 108.6992 84.6445 110.4844 84.6445 112.6836V129.6211C84.6445 131.8203 82.8594 133.6055 80.66015 133.6055Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M64.22379 118.360202H62.67941V120.84645H64.22379C64.74691 120.84645 65.14035 120.74176 65.40441 120.52239C65.66847 120.31333 65.79816 120.01927 65.79816 119.65051C65.79816 119.46145 65.76816 119.28708 65.70847 119.12739C65.64847 118.97301 65.5541 118.83864 65.42941 118.71895C65.29972 118.60926 65.13535 118.519577 64.93629 118.45489C64.73691 118.390202 64.49785 118.360202 64.22379 118.360202ZM62.67941 123.9702H63.99441C64.52754 123.9702 64.91629 123.87051 65.17035 123.68114C65.42441 123.48176 65.5491 123.17801 65.5491 122.75458C65.5491 122.5752 65.5191 122.41083 65.45441 122.25614C65.38941 122.10676 65.29472 121.97739 65.16035 121.8727C65.03097 121.76801 64.86629 121.68333 64.66222 121.62364C64.46285 121.56364 64.22879 121.53395 63.95472 121.53395H62.67941V123.9702ZM63.99441 124.73239H61.717849V117.593015H64.23879C64.63722 117.593015 64.99097 117.642702 65.30472 117.74239C65.61879 117.837077 65.87785 117.976765 66.09691 118.15614C66.30629 118.335202 66.47066 118.549577 66.58535 118.79864C66.69472 119.0477 66.74972 119.32177 66.74972 119.62583C66.74972 120.06926 66.61504 120.4327 66.35597 120.70176C66.08691 120.98083 65.69347 121.1652 65.17035 121.26489C65.39441 121.33458 65.59379 121.42426 65.75816 121.53895C65.92754 121.64833 66.06722 121.77302 66.1766 121.91239C66.28629 122.05208 66.36597 122.20145 66.42597 122.36583C66.47566 122.5252 66.50566 122.69458 66.50566 122.86895C66.50566 123.15801 66.45566 123.41708 66.36097 123.65114C66.26629 123.88052 66.11691 124.07489 65.90754 124.23426C65.70847 124.39364 65.44441 124.51833 65.13035 124.60302C64.8116 124.6877 64.43285 124.73239 63.99441 124.73239ZM69.12488 117.593015V124.73239H68.15863V117.593015H69.12488ZM74.6 123.61645L74.834 124.07489C74.585 124.31395 74.2959 124.49833 73.9721 124.6227C73.6434 124.74739 73.2796 124.81208 72.8809 124.81208C72.5271 124.81208 72.2084 124.75739 71.9393 124.6477C71.6603 124.53801 71.4312 124.39364 71.2418 124.20926C71.0575 124.02489 70.9131 123.81583 70.8134 123.58145C70.71871 123.34739 70.66902 123.10333 70.66902 122.84927C70.66902 122.5352 70.71871 122.26614 70.8134 122.05708C70.9131 121.8377 71.0425 121.66333 71.2021 121.51895C71.3615 121.37458 71.5459 121.25989 71.75 121.1702C71.9543 121.08051 72.1637 121.00083 72.3778 120.93114C72.5921 120.86614 72.8012 120.80145 73.0056 120.73176C73.21 120.67208 73.394 120.59239 73.5537 120.4977C73.7131 120.40301 73.8425 120.28833 73.9421 120.15395C74.0368 120.01426 74.0868 119.83489 74.0868 119.62083C74.0868 119.42645 74.0518 119.24708 73.9871 119.0877C73.9221 118.92833 73.8228 118.78864 73.7031 118.67926C73.5734 118.559577 73.424 118.47489 73.2446 118.410202C73.0653 118.345202 72.8612 118.315515 72.6318 118.315515C72.4475 118.315515 72.2831 118.330515 72.1387 118.370202C71.9943 118.400202 71.8596 118.44489 71.75 118.49989C71.6306 118.554577 71.5309 118.60926 71.4412 118.67426C71.3515 118.73895 71.2718 118.79364 71.2021 118.84864C71.1321 118.90333 71.0725 118.94801 71.0128 118.97802C70.9628 119.01801 70.9131 119.0327 70.8681 119.0327C70.8234 119.0327 70.7784 119.01801 70.74371 118.99801C70.70371 118.96801 70.66902 118.93833 70.64402 118.90333L70.36496 118.44489C70.63402 118.160827 70.9578 117.931765 71.3365 117.76239C71.7153 117.598015 72.1387 117.513328 72.6021 117.513328C72.9806 117.513328 73.3193 117.573015 73.6134 117.687703C73.9125 117.80239 74.1615 117.961765 74.3706 118.165827C74.57 118.370202 74.7293 118.60926 74.834 118.87833C74.9387 119.15739 74.9934 119.44645 74.9934 119.7602C74.9934 120.05426 74.9437 120.30333 74.849 120.5077C74.7493 120.71176 74.6196 120.88114 74.4603 121.02083C74.2959 121.1602 74.1115 121.27489 73.9125 121.36958C73.7031 121.45927 73.4937 121.53895 73.2846 121.61364C73.0653 121.68833 72.8562 121.75801 72.6568 121.8277C72.4475 121.8927 72.2681 121.97239 72.1087 122.06708C71.9443 122.16177 71.815 122.27114 71.7203 122.40583C71.6206 122.5352 71.5706 122.69958 71.5706 122.89895C71.5706 123.05333 71.6006 123.20301 71.6553 123.33239C71.7103 123.47208 71.795 123.58645 71.9096 123.68614C72.019 123.78583 72.1587 123.86551 72.3181 123.9202C72.4875 123.9802 72.6768 124.00989 72.8909 124.00989C73.1203 124.00989 73.3143 123.9802 73.474 123.9252C73.6384 123.87051 73.7728 123.80583 73.8925 123.74083C74.0021 123.67114 74.1015 123.60645 74.1765 123.55177C74.2512 123.49676 74.3209 123.46708 74.3756 123.46708C74.4256 123.46708 74.4703 123.48176 74.5003 123.50176C74.54 123.53177 74.57 123.56645 74.6 123.61645ZM81.1803 123.9202V124.73239H75.5903V123.9202H77.9071V117.593015H78.8687V123.9202H81.1803Z'/>
+<path d='M54.707 91.0859H30.7305C28.5273 91.0859 26.7461 89.3008 26.7461 87.1016V70.1641C26.7461 67.9648 28.5273 66.1797 30.7305 66.1797H54.707C56.9062 66.1797 58.6914 67.9648 58.6914 70.1641V87.1016C58.6914 89.3008 56.9062 91.0859 54.707 91.0859Z' fill='#ffc'/>
+<path d='M54.707 91.0859H30.7305C28.5273 91.0859 26.7461 89.3008 26.7461 87.1016V70.1641C26.7461 67.9648 28.5273 66.1797 30.7305 66.1797H54.707C56.9062 66.1797 58.6914 67.9648 58.6914 70.1641V87.1016C58.6914 89.3008 56.9062 91.0859 54.707 91.0859Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M40.2294 82.17536H39.47726C39.39257 82.17536 39.32288 82.15036 39.26288 82.10567C39.2082 82.06067 39.16851 82.00598 39.15351 81.9463L37.67382 76.98411C37.64882 76.89942 37.62882 76.80473 37.60882 76.70505C37.58913 76.60536 37.56913 76.50067 37.55413 76.39098C37.52913 76.50067 37.50945 76.60536 37.47945 76.70505C37.45945 76.80473 37.42976 76.89942 37.39976 76.98411L35.7257 81.9463C35.7007 82.01098 35.66101 82.06567 35.60601 82.11067C35.55132 82.15536 35.48163 82.17536 35.39695 82.17536H35.11788C35.0332 82.17536 34.96351 82.15036 34.90851 82.10067C34.84882 82.05567 34.80913 82.00098 34.78913 81.9463L33.11007 76.98411C33.08007 76.89942 33.05538 76.79973 33.02538 76.70005C33.00538 76.59036 32.9807 76.48067 32.9557 76.3663C32.9357 76.48067 32.9157 76.59036 32.89601 76.69505C32.87101 76.79973 32.85101 76.89442 32.82601 76.98411L31.35132 81.9463C31.33632 82.01098 31.29663 82.06567 31.24195 82.11067C31.18195 82.15536 31.10726 82.17536 31.022571 82.17536H30.220383L32.44757 75.035983H33.31445L35.13288 80.48161C35.14788 80.5363 35.16757 80.59098 35.18257 80.65098C35.19757 80.71067 35.21757 80.77536 35.23257 80.84005L35.27726 80.65098C35.29726 80.59098 35.31226 80.5363 35.32726 80.48161L37.1357 75.035983H38.00257L40.2294 82.17536Z'/>
+<path d='M44.6532 77.68661H41.9879L43.1088 80.58598C43.1835 80.76536 43.2532 80.98973 43.3229 81.2588C43.3579 81.12911 43.3929 81.00473 43.4276 80.89505C43.4626 80.77536 43.4973 80.67567 43.5323 80.59098L44.6532 77.68661ZM46.666 75.035983L43.8113 82.17536H42.8348L39.98007 75.035983H40.7273C40.8119 75.035983 40.8816 75.060983 40.9366 75.105671C40.9913 75.150671 41.0313 75.205358 41.051 75.265046L41.7188 76.98911H44.9223L45.5898 75.265046C45.6148 75.200358 45.6548 75.145671 45.7094 75.100671C45.7641 75.055983 45.8338 75.035983 45.9188 75.035983H46.666ZM48.5728 75.035983V82.17536H47.6066V75.035983H48.5728ZM55.2235 81.36317V82.17536H49.6335V81.36317H51.9504V75.035983H52.9119V81.36317H55.2235Z'/>
+<path d='M110.1055 91.0859H88.7187C86.5195 91.0859 84.7344 89.3008 84.7344 87.1016V70.1641C84.7344 67.9648 86.5195 66.1797 88.7187 66.1797H110.1055C112.3047 66.1797 114.0898 67.9648 114.0898 70.1641V87.1016C114.0898 89.3008 112.3047 91.0859 110.1055 91.0859Z' fill='#cfc'/>
+<path d='M110.1055 91.0859H88.7187C86.5195 91.0859 84.7344 89.3008 84.7344 87.1016V70.1641C84.7344 67.9648 86.5195 66.1797 88.7187 66.1797H110.1055C112.3047 66.1797 114.0898 67.9648 114.0898 70.1641V87.1016C114.0898 89.3008 112.3047 91.0859 110.1055 91.0859Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M93.36995 75.860212H89.93214V78.29646H92.71245V79.05365H89.93214V81.42521H93.36495V82.2124H88.965889V75.073024H93.36495L93.36995 75.860212ZM98.3711 81.09646L98.6052 81.5549C98.3561 81.79396 98.0671 81.97834 97.74331 82.10271C97.41456 82.2274 97.05081 82.29209 96.65206 82.29209C96.29831 82.29209 95.97956 82.2374 95.7105 82.12771C95.43144 82.01802 95.20237 81.87365 95.013 81.68927C94.82862 81.5049 94.68425 81.29584 94.58456 81.06146C94.48987 80.8274 94.44019 80.58334 94.44019 80.32927C94.44019 80.01521 94.48987 79.74615 94.58456 79.53709C94.68425 79.31771 94.81362 79.14334 94.97331 78.99896C95.13269 78.85459 95.31706 78.7399 95.52112 78.65021C95.7255 78.56052 95.93487 78.48084 96.14894 78.41115C96.36331 78.34615 96.57237 78.28146 96.77675 78.21177C96.98112 78.15209 97.16519 78.0724 97.32487 77.97771C97.48425 77.88302 97.61362 77.76834 97.71331 77.63396C97.808 77.49427 97.858 77.3149 97.858 77.10084C97.858 76.90646 97.823 76.72709 97.75831 76.56771C97.69331 76.40834 97.59394 76.26865 97.47425 76.15927C97.34456 76.039587 97.19519 75.954899 97.01581 75.890212C96.83644 75.825212 96.63237 75.795524 96.403 75.795524C96.21862 75.795524 96.05425 75.810524 95.90987 75.850212C95.7655 75.880212 95.63081 75.924899 95.52112 75.979899C95.40175 76.034587 95.30206 76.08927 95.21237 76.15427C95.12269 76.21896 95.043 76.27365 94.97331 76.32865C94.90331 76.38334 94.84362 76.42802 94.78394 76.45802C94.73394 76.49802 94.68425 76.51271 94.63925 76.51271C94.59456 76.51271 94.54956 76.49802 94.51487 76.47802C94.47487 76.44802 94.44019 76.41834 94.41519 76.38334L94.13612 75.924899C94.40519 75.640837 94.72894 75.411774 95.10769 75.242399C95.48644 75.078024 95.90987 74.993337 96.37331 74.993337C96.75175 74.993337 97.0905 75.053024 97.38456 75.167712C97.68362 75.282399 97.93269 75.441774 98.1417 75.645837C98.3411 75.850212 98.5005 76.08927 98.6052 76.35834C98.7099 76.6374 98.7646 76.92646 98.7646 77.24021C98.7646 77.53427 98.7149 77.78334 98.6202 77.98771C98.5205 78.19177 98.3908 78.36115 98.2314 78.50084C98.0671 78.64021 97.88269 78.7549 97.68362 78.84959C97.47425 78.93927 97.26487 79.01896 97.05581 79.09365C96.83644 79.16834 96.62737 79.23802 96.428 79.30771C96.21862 79.37271 96.03925 79.4524 95.87987 79.54709C95.7155 79.64177 95.58612 79.75115 95.49144 79.88584C95.39175 80.01521 95.34175 80.17959 95.34175 80.37896C95.34175 80.53334 95.37175 80.68302 95.42644 80.8124C95.48144 80.95209 95.56612 81.06646 95.68081 81.16615C95.79019 81.26584 95.92987 81.34552 96.08925 81.40021C96.25862 81.46021 96.448 81.4899 96.66206 81.4899C96.89144 81.4899 97.0855 81.46021 97.24519 81.40521C97.40956 81.35052 97.54394 81.28584 97.66362 81.22084C97.77331 81.15115 97.87269 81.08646 97.94769 81.03177C98.02237 80.97677 98.0921 80.94709 98.1467 80.94709C98.1967 80.94709 98.2414 80.96177 98.2714 80.98177C98.3111 81.01177 98.3411 81.04646 98.3711 81.09646ZM104.2839 75.750524H102.8789V82.2274H102.1564L100.0292 80.38896L100.308 80.00521C100.323 79.98052 100.348 79.96052 100.378 79.94052C100.4127 79.92052 100.4477 79.90584 100.4824 79.90084C100.5174 79.89584 100.5574 79.89584 100.6021 79.90584C100.6471 79.91052 100.6867 79.93552 100.7317 79.97052L102.0021 81.06146C101.9921 80.91209 101.9871 80.76271 101.9871 80.61802V75.750524H100.4577V75.073024H104.2839V75.750524ZM107.87 75.730524C107.636 75.730524 107.4216 75.770524 107.2422 75.840212C107.0528 75.919899 106.8985 76.024587 106.7741 76.15927C106.6444 76.29365 106.5447 76.45802 106.48 76.6474C106.4153 76.83677 106.3803 77.04584 106.3803 77.27521C106.3803 77.46959 106.4153 77.65865 106.485 77.84302C106.5597 78.0224 106.6644 78.18177 106.7938 78.32146C106.9335 78.45584 107.0928 78.56552 107.2872 78.65021C107.4813 78.7299 107.6957 78.7699 107.9347 78.7699C108.1591 78.7699 108.3632 78.7349 108.5475 78.66521C108.7319 78.59552 108.8963 78.49584 109.026 78.36115C109.1653 78.23177 109.265 78.0724 109.3397 77.88302C109.4144 77.69865 109.4494 77.48927 109.4494 77.25521C109.4494 77.03584 109.4144 76.83177 109.3347 76.6474C109.265 76.46302 109.1553 76.29865 109.016 76.16396C108.8813 76.029587 108.7169 75.919899 108.5178 75.845212C108.3285 75.770524 108.1091 75.730524 107.87 75.730524ZM107.3519 79.53709L109.4694 82.2124H108.6822C108.5775 82.2124 108.4828 82.1924 108.3982 82.14771C108.3185 82.10771 108.2538 82.05802 108.2088 81.99834L106.3953 79.56177C106.0913 79.15834 105.8722 78.77959 105.7375 78.43084C105.5982 78.0724 105.5285 77.74334 105.5285 77.42959C105.5285 77.05584 105.5832 76.72209 105.6978 76.41834C105.8075 76.11927 105.9669 75.865212 106.1663 75.650837C106.3753 75.441774 106.6194 75.282399 106.9135 75.162712C107.2075 75.053024 107.5313 74.993337 107.89 74.993337C108.2538 74.993337 108.5825 75.053024 108.8863 75.172712C109.1853 75.292087 109.4444 75.456774 109.6535 75.665837C109.8728 75.875212 110.0372 76.11927 110.1569 76.40334C110.2763 76.68709 110.3363 76.99115 110.3363 77.3199C110.3363 77.65865 110.2813 77.96271 110.1669 78.22177C110.0522 78.49084 109.9028 78.7099 109.7135 78.88927C109.5191 79.07365 109.295 79.20834 109.041 79.30771C108.7866 79.3974 108.5128 79.4474 108.2238 79.4474C107.9847 79.4474 107.7653 79.4174 107.5613 79.35271C107.3569 79.28802 107.1725 79.19834 107.0032 79.08365C107.0578 79.15834 107.1128 79.22802 107.1725 79.30771C107.2272 79.37771 107.2872 79.4574 107.3519 79.53709Z'/>
+<path d='M126.59148 78.65416C126.59148 79.00791 126.55148 79.34166 126.47179 79.66041C126.3971 79.97916 126.28273 80.27323 126.13304 80.54729C125.98367 80.82135 125.80429 81.06541 125.58523 81.28948C125.37585 81.50885 125.13179 81.69823 124.86273 81.8476C124.59367 82.00698 124.2996 82.12666 123.97585 82.20635C123.6521 82.29604 123.30835 82.33573 122.9446 82.33573C122.40148 82.33573 121.90335 82.24604 121.45492 82.05698C121.00648 81.8776 120.62273 81.61854 120.30398 81.28948C119.98023 80.96073 119.731167 80.57229 119.556792 80.12385C119.382417 79.67041 119.292729 79.18229 119.292729 78.65416C119.292729 78.12604 119.382417 77.6376 119.556792 77.18448C119.731167 76.73604 119.98023 76.34729 120.30398 76.018538C120.62273 75.689788 121.00648 75.430726 121.45492 75.251351C121.90335 75.061976 122.40148 74.972288 122.9446 74.972288C123.49273 74.972288 123.99085 75.061976 124.43929 75.251351C124.88773 75.430726 125.27117 75.689788 125.58992 76.018538C125.90898 76.34729 126.15304 76.73604 126.33242 77.18448C126.50179 77.6376 126.59148 78.12604 126.59148 78.65416ZM125.22148 78.65416C125.22148 78.26041 125.16648 77.90166 125.0621 77.59291C124.95742 77.27416 124.80273 77.0101 124.60867 76.79573C124.41429 76.57666 124.17523 76.40698 123.89117 76.2926C123.6121 76.17791 123.29835 76.11823 122.9446 76.11823S122.27679 76.17791 121.99804 76.2926C121.71398 76.40698 121.47492 76.57666 121.28054 76.79573C121.08117 77.0101 120.92679 77.27416 120.8221 77.59291C120.71742 77.90166 120.66273 78.26041 120.66273 78.65416C120.66273 79.0476 120.71742 79.40635 120.8221 79.7151C120.92679 80.03416 121.08117 80.29823 121.28054 80.51729C121.47492 80.73666 121.71398 80.90604 121.99804 81.02073C122.27679 81.1351 122.59085 81.1951 122.9446 81.1951S123.6121 81.1351 123.89117 81.02073C124.17523 80.90604 124.41429 80.73666 124.60867 80.51729C124.80273 80.29823 124.95742 80.03416 125.0621 79.7151C125.16648 79.40635 125.22148 79.0476 125.22148 78.65416ZM129.1109 79.23698V82.25604H127.77093V75.051976H129.1109V78.22073H129.5347C129.6891 78.22073 129.8084 78.20073 129.8931 78.16573C129.9778 78.13104 130.0478 78.06604 130.1125 77.97635L132.1503 75.316038C132.205 75.231351 132.2697 75.161663 132.3494 75.121663C132.4241 75.071976 132.5437 75.051976 132.7031 75.051976H133.8841L131.3828 78.42479C131.3031 78.53948 131.2184 78.63416 131.1337 78.70885C131.0441 78.77854 130.9444 78.83354 130.835 78.87323C130.9894 78.94791 131.1337 79.0776 131.2784 79.26198L133.7047 82.25604H132.5487C132.4094 82.25604 132.2947 82.23635 132.2 82.19635C132.1103 82.15166 132.0256 82.07666 131.9409 81.97229L129.9531 79.45604C129.8931 79.38135 129.8234 79.32666 129.7387 79.28666C129.6541 79.25698 129.5494 79.23698 129.425 79.23698H129.1109ZM135.7809 82.25604H134.6252V79.40635C134.6252 79.1026 134.6399 78.80854 134.6699 78.51948C134.6999 78.22573 134.7396 77.91666 134.7846 77.59291H135.6215C135.6665 77.91666 135.7062 78.22573 135.7362 78.51948C135.7659 78.80854 135.7809 79.1026 135.7809 79.40635V82.25604ZM134.4309 75.729476C134.4309 75.624788 134.4509 75.525413 134.4855 75.430726C134.5255 75.341038 134.5802 75.261351 134.6449 75.196351C134.7146 75.131663 134.7946 75.076976 134.889 75.041976C134.9837 75.002288 135.0834 74.982288 135.188 74.982288C135.2927 74.982288 135.3874 75.002288 135.4821 75.041976C135.5768 75.076976 135.6565 75.131663 135.7212 75.196351C135.7909 75.261351 135.8459 75.341038 135.8855 75.430726C135.9255 75.525413 135.9452 75.624788 135.9452 75.729476C135.9452 75.834163 135.9255 75.928851 135.8855 76.023538C135.8459 76.11823 135.7909 76.19791 135.7212 76.2626C135.6565 76.32729 135.5768 76.38229 135.4821 76.42198C135.3874 76.46198 135.2927 76.48198 135.188 76.48198C135.0834 76.48198 134.9837 76.46198 134.889 76.42198C134.7946 76.38229 134.7146 76.32729 134.6449 76.2626C134.5802 76.19791 134.5255 76.11823 134.4855 76.023538C134.4509 75.928851 134.4309 75.834163 134.4309 75.729476Z'/>
+<path d='M84.2266 48.566H57.9023C55.7031 48.566 53.918 46.781 53.918 44.582V27.645C53.918 25.441 55.7031 23.66 57.9023 23.66H84.2266C86.4258 23.66 88.2109 25.441 88.2109 27.645V44.582C88.2109 46.781 86.4258 48.566 84.2266 48.566Z' fill='#fcc'/>
+<path d='M84.2266 48.566H57.9023C55.7031 48.566 53.918 46.781 53.918 44.582V27.645C53.918 25.441 55.7031 23.66 57.9023 23.66H84.2266C86.4258 23.66 88.2109 25.441 88.2109 27.645V44.582C88.2109 46.781 86.4258 48.566 84.2266 48.566Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M64.33965 36.08318C64.33965 36.61631 64.25497 37.10443 64.08528 37.54287C63.9159 37.9813 63.67684 38.35506 63.36809 38.6738C63.05903 38.98287 62.69028 39.22693 62.25184 39.4013C61.8234 39.57068 61.34028 39.65537 60.81715 39.65537H58.151841V32.515992H60.81715C61.34028 32.515992 61.8234 32.60068 62.25184 32.775055C62.69028 32.94443 63.05903 33.183492 63.36809 33.497555C63.67684 33.8113 63.9159 34.18505 64.08528 34.62349C64.25497 35.06193 64.33965 35.55005 64.33965 36.08318ZM63.34809 36.08318C63.34809 35.64474 63.2884 35.2513 63.16872 34.90755C63.04903 34.5638 62.87965 34.26974 62.66059 34.03068C62.44122 33.7963 62.17715 33.61193 61.8634 33.487555C61.54965 33.362867 61.2009 33.29818 60.81715 33.29818H59.11809V38.87318H60.81715C61.2009 38.87318 61.54965 38.80849 61.8634 38.6838C62.17715 38.55943 62.44122 38.37506 62.66059 38.13599C62.87965 37.89662 63.04903 37.60287 63.16872 37.25912C63.2884 36.91537 63.34809 36.52162 63.34809 36.08318ZM70.1324 33.30318H66.69457V35.73943H69.4749V36.49662H66.69457V38.86818H70.1274V39.65537H65.72833V32.515992H70.1274L70.1324 33.30318ZM75.2729 35.16662H72.6076L73.7286 38.06599C73.8032 38.24537 73.8729 38.46974 73.9426 38.73881C73.9776 38.60912 74.0126 38.48474 74.0473 38.37506C74.0823 38.25537 74.117 38.15568 74.152 38.07099L75.2729 35.16662ZM77.2857 32.515992L74.4311 39.65537H73.4545L70.5998 32.515992H71.347C71.4317 32.515992 71.5014 32.540992 71.5564 32.58568C71.6111 32.63068 71.6511 32.685367 71.6707 32.745055L72.3386 34.46912H75.542L76.2095 32.745055C76.2345 32.680367 76.2745 32.62568 76.3292 32.58068C76.3839 32.535992 76.4536 32.515992 76.5386 32.515992H77.2857ZM84.4141 36.08318C84.4141 36.61631 84.3294 37.10443 84.1597 37.54287C83.9904 37.9813 83.7513 38.35506 83.4425 38.6738C83.1335 38.98287 82.7647 39.22693 82.3263 39.4013C81.8979 39.57068 81.4147 39.65537 80.8916 39.65537H78.2263V32.515992H80.8916C81.4147 32.515992 81.8979 32.60068 82.3263 32.775055C82.7647 32.94443 83.1335 33.183492 83.4425 33.497555C83.7513 33.8113 83.9904 34.18505 84.1597 34.62349C84.3294 35.06193 84.4141 35.55005 84.4141 36.08318ZM83.4225 36.08318C83.4225 35.64474 83.3629 35.2513 83.2432 34.90755S82.9541 34.26974 82.735 34.03068C82.5157 33.7963 82.2516 33.61193 81.9379 33.487555C81.6241 33.362867 81.2754 33.29818 80.8916 33.29818H79.1925V38.87318H80.8916C81.2754 38.87318 81.6241 38.80849 81.9379 38.6838C82.2516 38.55943 82.5157 38.37506 82.735 38.13599C82.9541 37.89662 83.1235 37.60287 83.2432 37.25912S83.4225 36.52162 83.4225 36.08318Z'/>
+<path d='M51.3942 9.26866L51.61858 9.58773C51.4542 9.7621 51.25483 9.89648 51.02576 10.00116C50.79139 10.10085 50.52733 10.15054 50.22358 10.15054C49.93951 10.15054 49.68045 10.10585 49.45139 10.01116C49.22701 9.92148 49.03264 9.80179 48.87326 9.64741C48.713888 9.49304 48.594201 9.31866 48.504513 9.12429C48.424826 8.92491 48.380138 8.72085 48.380138 8.50648C48.380138 8.26241 48.429826 8.06804 48.534513 7.92366C48.639201 7.77898 48.768576 7.6596 48.92326 7.56991C49.07764 7.47523 49.24701 7.40054 49.42639 7.34054C49.60576 7.28585 49.77514 7.22116 49.92951 7.15648C50.08389 7.09148 50.21358 7.00679 50.31826 6.9071C50.42264 6.80773 50.47264 6.67304 50.47264 6.50366C50.47264 6.37929 50.44764 6.2596 50.39795 6.14491C50.35295 6.03523 50.28326 5.940852 50.18858 5.856164C50.09889 5.771164 49.9892 5.706477 49.85983 5.656789C49.72514 5.606789 49.58076 5.582102 49.41639 5.582102C49.23201 5.582102 49.07764 5.606789 48.95295 5.651789C48.833576 5.696477 48.733888 5.751477 48.654201 5.806164C48.574513 5.865852 48.509513 5.920852 48.454826 5.965539C48.400138 6.010539 48.350138 6.03523 48.295451 6.03523C48.240451 6.03523 48.195763 6.025539 48.155763 6.000539C48.126076 5.975539 48.091076 5.945539 48.061388 5.900852L47.842013 5.562102C47.996388 5.382727 48.200763 5.238352 48.444826 5.118664C48.693888 5.008977 48.97795 4.949289 49.3017 4.949289C49.60076 4.949289 49.86983 4.998977 50.10889 5.093664C50.35295 5.188352 50.55733 5.318039 50.7267 5.477414C50.90108 5.641789 51.03045 5.826164 51.12514 6.04023C51.21483 6.2546 51.25983 6.47366 51.25983 6.70804C51.25983 6.9471 51.20983 7.14148 51.10545 7.29085C51.00076 7.44023 50.87108 7.56491 50.7167 7.6596C50.56233 7.75429 50.39295 7.83398 50.21358 7.89866C50.0342 7.96335 49.86483 8.02835 49.71045 8.09804C49.55576 8.16273 49.42639 8.24241 49.3217 8.3371S49.16733 8.55648 49.16733 8.71085C49.16733 8.82054 49.19233 8.92491 49.24201 9.0246C49.2867 9.11929 49.3567 9.20398 49.44139 9.27866C49.53108 9.35335 49.63545 9.40835 49.76014 9.45304C49.88483 9.49304 50.0192 9.51304 50.16858 9.51304C50.32826 9.51304 50.46264 9.49304 50.57733 9.45304C50.6917 9.41835 50.78639 9.37335 50.86608 9.33366C50.94108 9.28366 51.00576 9.24398 51.06545 9.20898C51.11545 9.17398 51.17014 9.15429 51.21483 9.15429C51.25483 9.15429 51.28983 9.16429 51.31451 9.18398C51.33951 9.19898 51.36951 9.22898 51.3942 9.26866ZM52.52451 5.980539C52.52951 5.646789 52.6292 5.387727 52.80858 5.213352C52.99795 5.038977 53.24701 4.949289 53.57076 4.949289C53.78014 4.949289 53.9892 4.988977 54.19358 5.068977C54.40295 5.153664 54.58701 5.263039 54.7517 5.407727L54.56233 5.831164C54.54733 5.860852 54.53233 5.880852 54.52233 5.895852C54.50233 5.910852 54.48264 5.915852 54.45264 5.915852C54.42764 5.915852 54.40295 5.905852 54.36795 5.875852C54.33295 5.856164 54.29326 5.826164 54.24326 5.796164C54.19358 5.766477 54.13389 5.736477 54.07389 5.716477C54.0042 5.686477 53.92951 5.676789 53.83983 5.676789C53.70545 5.676789 53.60076 5.716477 53.52108 5.796164C53.44139 5.880852 53.40139 6.005539 53.40139 6.17491C53.40139 6.18491 53.40139 6.19991 53.40639 6.2196C53.40639 6.2396 53.40639 6.2746 53.41639 6.32429C53.41639 6.37429 53.42639 6.43898 53.43639 6.52366C53.44608 6.60835 53.46108 6.71804 53.47608 6.85241L53.78014 9.33366H55.11014L55.18514 9.97616H53.85983L54.07389 11.71491H53.61076C53.55576 11.71491 53.51608 11.69991 53.47608 11.66523C53.44608 11.63523 53.41639 11.59554 53.40139 11.54554L53.02264 9.98616L52.24545 9.88148L52.20576 9.52773C52.20076 9.46304 52.21076 9.41335 52.24045 9.38335C52.26545 9.34835 52.30545 9.33366 52.35014 9.33366H52.91326L52.6042 6.80773C52.5842 6.65304 52.56951 6.52366 52.55951 6.42898C52.54451 6.33429 52.53951 6.2546 52.52951 6.19491C52.52951 6.13491 52.52451 6.09023 52.52451 6.05523V5.980539Z' fill='#f00'/>
+<path d='M59.0245 9.45804L58.8101 7.72929C58.7158 7.43523 58.6111 7.16148 58.4914 6.9121C58.3717 6.66804 58.2423 6.45398 58.103 6.2746C57.9583 6.09023 57.80889 5.950539 57.65451 5.846164C57.49983 5.746477 57.34045 5.696477 57.17608 5.696477C56.66295 5.696477 56.40889 6.09523 56.40889 6.89741C56.40889 7.12648 56.43389 7.35054 56.48858 7.56991C56.54326 7.78398 56.61826 7.98835 56.70795 8.18273C56.80733 8.3771 56.91701 8.55148 57.0517 8.71585C57.18608 8.87523 57.33045 9.0146 57.49514 9.12929C57.65951 9.24398 57.83389 9.33366 58.0183 9.40335C58.2023 9.46304 58.3967 9.49804 58.5961 9.49804C58.6658 9.49804 58.7355 9.49304 58.8101 9.49304C58.8801 9.48304 58.9498 9.47304 59.0245 9.45804ZM58.6858 6.35929L58.5911 5.337727C58.5911 5.253039 58.6111 5.178352 58.6508 5.118664C58.6958 5.058977 58.7755 5.028977 58.8901 5.028977H59.3483L59.9511 9.91148C59.752 9.99616 59.5476 10.06085 59.3483 10.09085C59.1392 10.13054 58.9298 10.14554 58.7158 10.14554C58.4167 10.14554 58.1326 10.10085 57.8586 10.02116C57.58451 9.93148 57.33045 9.81179 57.09639 9.66241C56.85733 9.50304 56.64295 9.32366 56.44889 9.11429C56.25451 8.90023 56.09014 8.67085 55.95045 8.41679C55.81608 8.16273 55.71139 7.89866 55.6317 7.6096C55.56201 7.33085 55.52201 7.03679 55.52201 6.73773C55.52201 6.45398 55.55201 6.19991 55.6167 5.975539C55.68139 5.756477 55.77108 5.572102 55.88076 5.417727C56.00045 5.268039 56.13483 5.153664 56.2992 5.078664C56.46358 4.998977 56.64295 4.959289 56.84233 4.959289C57.0267 4.959289 57.20108 4.993977 57.37545 5.058977C57.54483 5.123664 57.7042 5.218352 57.8636 5.337727C58.0133 5.462414 58.1626 5.606789 58.302 5.781164C58.4367 5.955539 58.5661 6.14491 58.6858 6.35929ZM65.306 10.07585H64.6035C64.5538 10.07585 64.5041 10.06085 64.4591 10.03116C64.4094 9.99616 64.3694 9.95616 64.3444 9.90148L62.7504 6.71804C62.7154 6.64804 62.6854 6.57835 62.6557 6.50366C62.6257 6.43398 62.5957 6.36429 62.566 6.29429C62.561 6.36429 62.551 6.43398 62.541 6.50366C62.531 6.57335 62.516 6.64304 62.501 6.71304L61.6891 9.89148C61.6741 9.94648 61.6491 9.99116 61.6144 10.02116C61.5794 10.06085 61.5297 10.07585 61.4547 10.07585H60.7226L62.0329 5.328039L60.9366 3.32023H61.5894C61.6641 3.32023 61.7238 3.33491 61.7688 3.36991C61.8185 3.40491 61.8635 3.4546 61.8982 3.52429L65.306 10.07585Z' fill='#f00'/>
+<path d='M68.5937 9.26866L68.8181 9.58773C68.6537 9.7621 68.4544 9.89648 68.2253 10.00116C67.9909 10.10085 67.7269 10.15054 67.4231 10.15054C67.139 10.15054 66.88 10.10585 66.6509 10.01116C66.4265 9.92148 66.2322 9.80179 66.0728 9.64741C65.9134 9.49304 65.7937 9.31866 65.704 9.12429C65.6244 8.92491 65.5797 8.72085 65.5797 8.50648C65.5797 8.26241 65.6294 8.06804 65.734 7.92366C65.8387 7.77898 65.9681 7.6596 66.1228 7.56991C66.2772 7.47523 66.4465 7.40054 66.6259 7.34054C66.8053 7.28585 66.9747 7.22116 67.129 7.15648C67.2834 7.09148 67.4131 7.00679 67.5178 6.9071C67.6222 6.80773 67.6722 6.67304 67.6722 6.50366C67.6722 6.37929 67.6472 6.2596 67.5975 6.14491C67.5525 6.03523 67.4828 5.940852 67.3881 5.856164C67.2984 5.771164 67.1887 5.706477 67.0594 5.656789C66.9247 5.606789 66.7803 5.582102 66.6159 5.582102C66.4315 5.582102 66.2772 5.606789 66.1525 5.651789C66.0331 5.696477 65.9334 5.751477 65.8537 5.806164C65.774 5.865852 65.709 5.920852 65.6544 5.965539C65.5997 6.010539 65.5497 6.03523 65.495 6.03523C65.44 6.03523 65.3953 6.025539 65.3553 6.000539C65.3256 5.975539 65.2906 5.945539 65.2609 5.900852L65.0415 5.562102C65.1959 5.382727 65.4003 5.238352 65.6444 5.118664C65.8934 5.008977 66.1775 4.949289 66.5012 4.949289C66.8003 4.949289 67.0694 4.998977 67.3084 5.093664C67.5525 5.188352 67.7569 5.318039 67.9262 5.477414C68.1006 5.641789 68.23 5.826164 68.3247 6.04023C68.4144 6.2546 68.4594 6.47366 68.4594 6.70804C68.4594 6.9471 68.4094 7.14148 68.305 7.29085C68.2003 7.44023 68.0706 7.56491 67.9162 7.6596C67.7619 7.75429 67.5925 7.83398 67.4131 7.89866C67.2337 7.96335 67.0644 8.02835 66.91 8.09804C66.7553 8.16273 66.6259 8.24241 66.5212 8.3371S66.3669 8.55648 66.3669 8.71085C66.3669 8.82054 66.3919 8.92491 66.4415 9.0246C66.4862 9.11929 66.5562 9.20398 66.6409 9.27866C66.7306 9.35335 66.835 9.40835 66.9597 9.45304C67.0844 9.49304 67.2187 9.51304 67.3681 9.51304C67.5278 9.51304 67.6622 9.49304 67.7769 9.45304C67.8912 9.41835 67.9859 9.37335 68.0656 9.33366C68.1406 9.28366 68.2053 9.24398 68.265 9.20898C68.315 9.17398 68.3697 9.15429 68.4144 9.15429C68.4544 9.15429 68.4894 9.16429 68.514 9.18398C68.539 9.19898 68.569 9.22898 68.5937 9.26866Z' fill='#f00'/>
+<path d='M75.2184 8.97491L75.054 7.6646C74.9594 7.37554 74.8447 7.11148 74.7103 6.86741C74.5806 6.62335 74.4412 6.41398 74.2915 6.2346C74.1372 6.06023 73.9828 5.920852 73.8184 5.821164C73.654 5.721477 73.4947 5.671789 73.335 5.671789C73.0709 5.671789 72.8719 5.776164 72.7272 5.985539C72.5878 6.18991 72.5181 6.49366 72.5181 6.88741C72.5181 7.18116 72.5578 7.48523 72.6375 7.78898C72.7172 8.09304 72.8319 8.3721 72.9762 8.61616C73.1259 8.86523 73.3053 9.0696 73.5144 9.22398C73.7237 9.37835 73.9578 9.45804 74.2219 9.45804C74.4062 9.45804 74.5856 9.42335 74.76 9.35335C74.9394 9.27866 75.0937 9.15429 75.2184 8.97491ZM76.5037 12.36773H75.6369L75.2931 9.58773C75.1487 9.7671 74.9794 9.90648 74.77 10.00116C74.5706 10.10085 74.3415 10.15054 74.0925 10.15054C73.8581 10.15054 73.639 10.10585 73.4247 10.01616C73.2156 9.92648 73.0212 9.80179 72.8369 9.64741C72.6525 9.49304 72.4881 9.30366 72.3387 9.09429C72.194 8.87523 72.0697 8.64616 71.96 8.39679C71.8603 8.14773 71.7756 7.88866 71.7209 7.6146S71.6362 7.07179 71.6362 6.79773C71.6362 6.19991 71.7556 5.746477 71.995 5.427414C72.234 5.118664 72.5678 4.959289 73.0012 4.959289C73.1856 4.959289 73.365 4.993977 73.5444 5.058977C73.7187 5.128664 73.8931 5.228352 74.0525 5.352727C74.2219 5.477414 74.3762 5.631789 74.5259 5.806164C74.6753 5.980539 74.8147 6.17991 74.9394 6.39898L74.8447 5.337727C74.8447 5.253039 74.8647 5.178352 74.9044 5.118664C74.9444 5.058977 75.024 5.028977 75.1387 5.028977H75.6019L76.5037 12.36773ZM79.492 9.50804C79.6267 9.50804 79.7361 9.49304 79.8308 9.45304C79.9254 9.42335 80.0001 9.37835 80.0601 9.32366C80.1148 9.26866 80.1598 9.21398 80.1845 9.14429C80.2095 9.08429 80.2245 9.0196 80.2245 8.95991C80.2245 8.84023 80.1995 8.72585 80.1448 8.61616C80.0898 8.50648 79.9804 8.40679 79.8158 8.3071C79.6514 8.21741 79.4123 8.12773 79.1036 8.04804C78.7945 7.96335 78.3861 7.89366 77.873 7.82898C77.9276 8.06304 78.0023 8.28741 78.097 8.48648C78.1917 8.69585 78.3114 8.87023 78.4458 9.0246C78.5804 9.17398 78.7398 9.29366 78.9142 9.37835S79.283 9.50804 79.492 9.50804ZM80.897 5.960539L80.678 6.2346C80.628 6.2896 80.5733 6.31929 80.5086 6.31929C80.4536 6.31929 80.4039 6.30429 80.3489 6.2696C80.2942 6.2346 80.2395 6.19491 80.1795 6.14491C80.1148 6.10023 80.0501 6.04523 79.9705 5.985539C79.9008 5.930852 79.8111 5.875852 79.7114 5.826164C79.6167 5.781164 79.502 5.741477 79.3823 5.706477C79.253 5.671789 79.1136 5.656789 78.9539 5.656789C78.5605 5.656789 78.2664 5.776164 78.077 6.005539C77.878 6.2446 77.7833 6.58335 77.7833 7.02679C77.7833 7.06179 77.7833 7.10148 77.7883 7.13148C77.7883 7.17116 77.7883 7.20616 77.7883 7.24116C78.4458 7.30585 78.9839 7.39554 79.4023 7.50523C79.8208 7.6146 80.1498 7.74429 80.3889 7.88866C80.628 8.03804 80.7923 8.20773 80.882 8.38679C80.9717 8.57616 81.0167 8.77554 81.0167 8.99491C81.0167 9.11929 80.9867 9.24898 80.927 9.38335C80.872 9.51773 80.7823 9.64241 80.663 9.7571C80.5433 9.87148 80.3889 9.96116 80.2045 10.03616C80.0201 10.11085 79.7961 10.14554 79.542 10.14554C79.273 10.14554 79.0239 10.10585 78.7845 10.02116C78.5555 9.93648 78.3361 9.82179 78.147 9.68241C77.9476 9.53273 77.7783 9.36335 77.6289 9.16429C77.4742 8.96491 77.3498 8.75054 77.2401 8.51648C77.1405 8.28241 77.0608 8.03804 77.0011 7.77898C76.9511 7.52491 76.9214 7.26585 76.9214 7.00679C76.9214 6.69304 76.9661 6.41398 77.0508 6.15991C77.1355 5.905852 77.2601 5.691477 77.4195 5.517102C77.5789 5.337727 77.7733 5.198352 78.0023 5.103664C78.2317 5.008977 78.4908 4.959289 78.7795 4.959289C78.9939 4.959289 79.1933 4.979289 79.3726 5.018977C79.5617 5.053977 79.7361 5.113664 79.9008 5.198352C80.0701 5.283039 80.2345 5.387727 80.3989 5.507414C80.5633 5.636789 80.7276 5.786164 80.897 5.960539ZM85.1509 9.45804L84.9365 7.72929C84.8422 7.43523 84.7375 7.16148 84.6178 6.9121C84.4981 6.66804 84.3687 6.45398 84.2294 6.2746C84.0847 6.09023 83.9353 5.950539 83.7809 5.846164C83.6262 5.746477 83.4669 5.696477 83.3025 5.696477C82.7894 5.696477 82.5353 6.09523 82.5353 6.89741C82.5353 7.12648 82.5603 7.35054 82.615 7.56991C82.6697 7.78398 82.7447 7.98835 82.8344 8.18273C82.9337 8.3771 83.0434 8.55148 83.1781 8.71585C83.3125 8.87523 83.4569 9.0146 83.6215 9.12929C83.7859 9.24398 83.9603 9.33366 84.1447 9.40335C84.3287 9.46304 84.5231 9.49804 84.7225 9.49804C84.7922 9.49804 84.8619 9.49304 84.9365 9.49304C85.0065 9.48304 85.0762 9.47304 85.1509 9.45804ZM84.8122 6.35929L84.7175 5.337727C84.7175 5.253039 84.7375 5.178352 84.7772 5.118664C84.8222 5.058977 84.9019 5.028977 85.0165 5.028977H85.4747L86.0775 9.91148C85.8784 9.99616 85.674 10.06085 85.4747 10.09085C85.2656 10.13054 85.0562 10.14554 84.8422 10.14554C84.5431 10.14554 84.259 10.10085 83.985 10.02116C83.7109 9.93148 83.4569 9.81179 83.2228 9.66241C82.9837 9.50304 82.7694 9.32366 82.5753 9.11429C82.3809 8.90023 82.2165 8.67085 82.0769 8.41679C81.9425 8.16273 81.8378 7.89866 81.7581 7.6096C81.6884 7.33085 81.6484 7.03679 81.6484 6.73773C81.6484 6.45398 81.6784 6.19991 81.7431 5.975539C81.8078 5.756477 81.8975 5.572102 82.0072 5.417727C82.1269 5.268039 82.2612 5.153664 82.4256 5.078664C82.59 4.998977 82.7694 4.959289 82.9687 4.959289C83.1531 4.959289 83.3275 4.993977 83.5019 5.058977C83.6712 5.123664 83.8306 5.218352 83.99 5.337727C84.1397 5.462414 84.289 5.606789 84.4284 5.781164C84.5631 5.955539 84.6925 6.14491 84.8122 6.35929ZM90.3465 8.97491L90.1821 7.6646C90.0874 7.37554 89.9727 7.11148 89.8383 6.86741C89.7087 6.62335 89.5693 6.41398 89.4196 6.2346C89.2652 6.06023 89.1108 5.920852 88.9465 5.821164C88.7821 5.721477 88.6227 5.671789 88.463 5.671789C88.199 5.671789 87.9999 5.776164 87.8552 5.985539C87.7158 6.18991 87.6462 6.49366 87.6462 6.88741C87.6462 7.18116 87.6858 7.48523 87.7655 7.78898C87.8452 8.09304 87.9599 8.3721 88.1043 8.61616C88.254 8.86523 88.4333 9.0696 88.6424 9.22398C88.8518 9.37835 89.0858 9.45804 89.3499 9.45804C89.5343 9.45804 89.7137 9.42335 89.888 9.35335C90.0674 9.27866 90.2218 9.15429 90.3465 8.97491ZM91.6318 12.36773H90.7649L90.4212 9.58773C90.2768 9.7671 90.1074 9.90648 89.898 10.00116C89.6987 10.10085 89.4696 10.15054 89.2205 10.15054C88.9862 10.15054 88.7671 10.10585 88.5527 10.01616C88.3437 9.92648 88.1493 9.80179 87.9649 9.64741C87.7805 9.49304 87.6162 9.30366 87.4668 9.09429C87.3221 8.87523 87.1977 8.64616 87.088 8.39679C86.9883 8.14773 86.9037 7.88866 86.849 7.6146S86.7643 7.07179 86.7643 6.79773C86.7643 6.19991 86.8837 5.746477 87.123 5.427414C87.3621 5.118664 87.6958 4.959289 88.1293 4.959289C88.3137 4.959289 88.493 4.993977 88.6724 5.058977C88.8468 5.128664 89.0212 5.228352 89.1805 5.352727C89.3499 5.477414 89.5043 5.631789 89.654 5.806164C89.8033 5.980539 89.9427 6.17991 90.0674 6.39898L89.9727 5.337727C89.9727 5.253039 89.9927 5.178352 90.0324 5.118664C90.0724 5.058977 90.1521 5.028977 90.2668 5.028977H90.7299L91.6318 12.36773ZM93.9026 12.16835H93.0907L92.7419 9.30866C92.7219 9.15929 92.7069 9.0146 92.6969 8.87523C92.6819 8.73085 92.6722 8.59116 92.6672 8.44679C92.6572 8.3021 92.6472 8.15773 92.6472 8.00335C92.6372 7.84898 92.6372 7.68929 92.6322 7.51491H93.2101C93.2501 7.68929 93.2851 7.84898 93.3197 8.00335C93.3547 8.15773 93.3844 8.3021 93.4144 8.44679C93.4394 8.59116 93.4641 8.73085 93.4891 8.87523C93.5141 9.0146 93.5341 9.15929 93.5538 9.30866L93.9026 12.16835ZM92.1341 5.577102C92.1341 5.487414 92.1491 5.407727 92.1788 5.328039C92.2138 5.258039 92.2585 5.188352 92.3085 5.133664C92.3682 5.078664 92.4279 5.033977 92.5076 4.998977C92.5776 4.969289 92.6622 4.954289 92.7519 4.954289C92.8366 4.954289 92.9163 4.969289 92.996 4.998977C93.0657 5.033977 93.1354 5.078664 93.1904 5.133664C93.2451 5.188352 93.2897 5.258039 93.3247 5.328039C93.3597 5.407727 93.3744 5.487414 93.3744 5.577102C93.3744 5.661789 93.3597 5.746477 93.3247 5.821164C93.2897 5.895852 93.2451 5.965539 93.1904 6.020539C93.1354 6.07523 93.0657 6.11991 92.996 6.15491C92.9163 6.18991 92.8366 6.20491 92.7519 6.20491C92.6622 6.20491 92.5776 6.18991 92.5076 6.15491C92.4279 6.11991 92.3682 6.07523 92.3085 6.020539C92.2585 5.965539 92.2138 5.895852 92.1788 5.821164C92.1491 5.746477 92.1341 5.661789 92.1341 5.577102Z' fill='#f00'/>
+<path d='M71.066404 142.5234V137.5898' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M71.066404 134.0036C71.265623 135.0661 71.863279 136.79266 72.55859 137.987973H69.57031C70.269529 136.79266 70.867185 135.0661 71.066404 134.0036'/>
+<path d='M62.5 108.3008L53.2734 94.4687' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M51.281251 91.484406C52.039062 92.257836 53.49219 93.363308 54.73828 93.968774L52.250002 95.628935C52.167972 94.246122 51.707035 92.480501 51.281251 91.484406'/>
+<path d='M79.63281 108.3008L88.8555 94.4687' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M90.847651 91.484395C90.421871 92.480492 89.960935 94.246117 89.878907 95.628932L87.394534 93.968771C88.636717 93.363304 90.089841 92.257837 90.847651 91.484395'/>
+<path d='M59.0898 88.0781C66.69922 92.1797 73.8789 92.5078 81.1875 89.0508' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M84.33589 87.332058C83.492147 88.01174 82.253866 89.355497 81.531208 90.53518L80.117144 87.90237C81.499962 87.949244 83.304644 87.660181 84.33589 87.332058'/>
+<path d='M84.3359 69.9336C76.98047 65.3906 69.83203 64.6367 62.33594 67.6562' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M59.089812 69.187476C59.968714 68.558572 61.285121 67.289039 62.078087 66.156224L63.331999 68.867167C61.956997 68.738258 60.136685 68.921851 59.089812 69.187476'/>
+<path d='M57.0859 115.5625C1.4062 93.2891 .2227 65.6602 50.1953 44.496' stroke='#f00' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M53.519494 43.128878C52.613237 43.718721 51.246051 44.929657 50.406209 46.031219L49.265582 43.265595C50.636677 43.457 52.4609 43.347623 53.519494 43.128878' fill='#f00'/>
+<path d='M51.2852 65.7812L60.5117 51.949' stroke='#f00' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M62.499993 48.964897C62.078118 49.957084 61.617181 51.72661 61.531248 53.109424L59.046874 51.449267C60.28906 50.843797 61.746093 49.738327 62.499993 48.964897' fill='#f00'/>
+<path d='M90.8437 65.7812L81.6211 51.949' stroke='#f00' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M79.62891 48.964895C80.386726 49.738334 81.839844 50.843804 83.082035 51.449271L80.597658 53.109424C80.515626 51.726618 80.05469 49.957087 79.62891 48.964895' fill='#f00'/>
+<path d='M73.33203 23.262C75.07812 13.375 68.71484 12.18 68.5 19.68' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M68.796894 23.261746C68.52737 22.214875 67.808625 20.531277 67.031275 19.386744L70.011743 19.18362C69.398467 20.421902 68.921902 22.187531 68.796894 23.261746'/>
+<path d='M21.10383 42.84567H22.32945L22.41414 43.48317H21.15383L21.20851 43.94661C21.23351 44.16067 21.2782 44.34505 21.3482 44.49473C21.40789 44.64411 21.48758 44.7638 21.58226 44.85817C21.67695 44.95286 21.78164 45.01786 21.90601 45.06255C22.0257 45.10255 22.15508 45.12223 22.29976 45.12223H22.58851C22.66351 45.12223 22.7082 45.15723 22.7232 45.22192L22.80789 45.68036C22.63351 45.74505 22.44914 45.78005 22.24476 45.78005C22.0007 45.78005 21.77164 45.74005 21.55726 45.66036C21.3482 45.58067 21.15883 45.4613 20.99945 45.31161C20.83008 45.15223 20.69539 44.96286 20.5907 44.7438C20.48133 44.51442 20.40633 44.26036 20.37164 43.97161L20.31195 43.48317H19.594452L19.549452 43.12442C19.544452 43.05473 19.554452 43.00505 19.594452 42.97005C19.624139 42.93536 19.674139 42.91036 19.733827 42.89536L20.23195 42.83067L19.564452 37.29536H19.908202C20.032889 37.29536 20.132577 37.33036 20.20226 37.39005C20.27695 37.45973 20.33164 37.54942 20.36664 37.669108L20.6007 38.700358L21.10383 42.84567Z' fill='#f00'/>
+<path d='M25.83984 42.96505L25.62547 41.2363C25.53109 40.94223 25.4264 40.66848 25.30672 40.41911C25.18703 40.17505 25.05766 39.96098 24.91828 39.78161C24.77359 39.59723 24.62422 39.457545 24.46984 39.35317C24.31515 39.253483 24.15578 39.203483 23.9914 39.203483C23.47828 39.203483 23.22422 39.60223 23.22422 40.40442C23.22422 40.63348 23.24922 40.85755 23.3039 41.07692C23.35859 41.29098 23.43359 41.49536 23.52328 41.68973C23.62265 41.88411 23.73234 42.05848 23.86703 42.22286C24.00141 42.38223 24.14578 42.52161 24.31047 42.6363C24.47484 42.75098 24.64922 42.84067 24.83359 42.91036C25.01765 42.97005 25.21203 43.00505 25.4114 43.00505C25.48109 43.00505 25.55078 43.00005 25.62547 43.00005C25.69547 42.99005 25.76516 42.98005 25.83984 42.96505ZM25.50109 39.8663L25.4064 38.844733C25.4064 38.760045 25.4264 38.685358 25.46609 38.62567C25.51109 38.565983 25.59078 38.535983 25.70547 38.535983H26.16359L26.7664 43.41848C26.56734 43.50317 26.36297 43.56786 26.16359 43.59786C25.95453 43.63755 25.74516 43.65255 25.53109 43.65255C25.23203 43.65255 24.94797 43.60786 24.6739 43.52817C24.39984 43.43848 24.14578 43.3188 23.91172 43.16942C23.67265 43.01005 23.45828 42.83067 23.26422 42.6213C23.06984 42.40723 22.90547 42.17786 22.76578 41.9238C22.6314 41.66973 22.52672 41.40567 22.44703 41.11661C22.37734 40.83786 22.33734 40.5438 22.33734 40.24473C22.33734 39.96098 22.36734 39.70692 22.43203 39.482545C22.49672 39.263483 22.5864 39.079108 22.69609 38.924733C22.81578 38.775045 22.95015 38.66067 23.11453 38.58567C23.2789 38.505983 23.45828 38.466295 23.65766 38.466295C23.84203 38.466295 24.0164 38.500983 24.19078 38.565983C24.36015 38.63067 24.51953 38.725358 24.6789 38.844733C24.82859 38.96942 24.97797 39.113795 25.11734 39.28817C25.25203 39.462545 25.38141 39.65192 25.50109 39.8663ZM27.87164 39.487545C27.87664 39.153795 27.97633 38.894733 28.1557 38.720358C28.34508 38.545983 28.59414 38.456295 28.91789 38.456295C29.12726 38.456295 29.3363 38.495983 29.5407 38.575983C29.7501 38.66067 29.9341 38.770045 30.0988 38.914733L29.9095 39.33817C29.8945 39.367858 29.8795 39.387858 29.8695 39.402858C29.8495 39.417858 29.8298 39.422858 29.7998 39.422858C29.7748 39.422858 29.7501 39.412858 29.7151 39.382858C29.6801 39.36317 29.6404 39.33317 29.5904 39.30317C29.5407 39.273483 29.481 39.243483 29.421 39.223483C29.3513 39.193483 29.2766 39.183795 29.187 39.183795C29.05258 39.183795 28.94789 39.223483 28.8682 39.30317C28.78851 39.387858 28.74851 39.512545 28.74851 39.68192C28.74851 39.69192 28.74851 39.70692 28.75351 39.72661C28.75351 39.74661 28.75351 39.78161 28.76351 39.8313C28.76351 39.8813 28.77351 39.94598 28.78351 40.03067C28.7932 40.11536 28.8082 40.22505 28.8232 40.35942L29.12726 42.84067H30.4573L30.5323 43.48317H29.207L29.421 45.22192H28.95789C28.90289 45.22192 28.8632 45.20692 28.8232 45.17223C28.7932 45.14223 28.76351 45.10255 28.74851 45.05255L28.36976 43.49317L27.59258 43.38848L27.55289 43.03473C27.54789 42.97005 27.55789 42.92036 27.58758 42.89036C27.61258 42.85536 27.65258 42.84067 27.69726 42.84067H28.26039L27.95133 40.31473C27.93133 40.16005 27.91664 40.03067 27.90664 39.93598C27.89164 39.8413 27.88664 39.76161 27.87664 39.70192C27.87664 39.64192 27.87164 39.59723 27.87164 39.56223V39.487545Z' fill='#f00'/>
+<path d='M34.3713 42.96505L34.157 41.2363C34.0626 40.94223 33.9579 40.66848 33.8382 40.41911C33.7185 40.17505 33.5891 39.96098 33.4498 39.78161C33.3051 39.59723 33.1557 39.457545 33.0013 39.35317C32.8466 39.253483 32.6873 39.203483 32.5229 39.203483C32.0098 39.203483 31.7557 39.60223 31.7557 40.40442C31.7557 40.63348 31.7807 40.85755 31.8354 41.07692C31.8901 41.29098 31.9651 41.49536 32.0548 41.68973C32.1541 41.88411 32.2638 42.05848 32.3985 42.22286C32.5329 42.38223 32.6773 42.52161 32.842 42.6363C33.0063 42.75098 33.1807 42.84067 33.3651 42.91036C33.5491 42.97005 33.7435 43.00505 33.9429 43.00505C34.0126 43.00505 34.0823 43.00005 34.157 43.00005C34.227 42.99005 34.2966 42.98005 34.3713 42.96505ZM34.0326 39.8663L33.9379 38.844733C33.9379 38.760045 33.9579 38.685358 33.9976 38.62567C34.0426 38.565983 34.1223 38.535983 34.237 38.535983H34.6951L35.2979 43.41848C35.0988 43.50317 34.8945 43.56786 34.6951 43.59786C34.486 43.63755 34.2766 43.65255 34.0626 43.65255C33.7635 43.65255 33.4795 43.60786 33.2054 43.52817C32.9313 43.43848 32.6773 43.3188 32.4432 43.16942C32.2041 43.01005 31.9898 42.83067 31.7957 42.6213C31.6013 42.40723 31.437 42.17786 31.2973 41.9238C31.1629 41.66973 31.0582 41.40567 30.9785 41.11661C30.9088 40.83786 30.8688 40.5438 30.8688 40.24473C30.8688 39.96098 30.8988 39.70692 30.9635 39.482545C31.0282 39.263483 31.1179 39.079108 31.2276 38.924733C31.3473 38.775045 31.4816 38.66067 31.646 38.58567C31.8104 38.505983 31.9898 38.466295 32.1891 38.466295C32.3735 38.466295 32.5479 38.500983 32.7223 38.565983C32.8916 38.63067 33.051 38.725358 33.2104 38.844733C33.3601 38.96942 33.5095 39.113795 33.6488 39.28817C33.7835 39.462545 33.9129 39.65192 34.0326 39.8663ZM36.0294 38.535983H36.9012L37.7931 45.87473H36.9212L36.0294 38.535983Z' fill='#f00'/>
+<path d='M21.4177 31.06008C21.55239 31.06008 21.66176 31.04508 21.75645 31.00508C21.85114 30.9754 21.92582 30.9304 21.98582 30.87571C22.04051 30.82071 22.08551 30.76602 22.1102 30.69633C22.1352 30.63633 22.1502 30.57165 22.1502 30.51196C22.1502 30.39227 22.1252 30.2779 22.07051 30.16821C22.01551 30.05852 21.90614 29.95883 21.74145 29.85915C21.57707 29.76946 21.33801 29.67977 21.02926 29.60008C20.7202 29.5154 20.31176 29.44571 19.79864 29.38102C19.85332 29.61508 19.92801 29.83946 20.0227 30.03852C20.11739 30.2479 20.23707 30.42227 20.37145 30.57665C20.50614 30.72602 20.66551 30.84571 20.83989 30.9304C21.01426 31.01508 21.20864 31.06008 21.4177 31.06008ZM22.8227 27.512583L22.60364 27.78665C22.55364 27.84165 22.49895 27.87133 22.43426 27.87133C22.37926 27.87133 22.32957 27.85633 22.27457 27.82165C22.21989 27.78665 22.1652 27.74696 22.1052 27.69696C22.04051 27.65227 21.97582 27.59727 21.89614 27.537583C21.82645 27.482895 21.73676 27.427895 21.63707 27.378208C21.54239 27.333208 21.4277 27.29352 21.30801 27.25852C21.17864 27.223833 21.03926 27.208833 20.87957 27.208833C20.48614 27.208833 20.19207 27.328208 20.0027 27.557583C19.80364 27.79665 19.70895 28.1354 19.70895 28.57883C19.70895 28.61383 19.70895 28.65352 19.71395 28.68352C19.71395 28.72321 19.71395 28.75821 19.71395 28.79321C20.37145 28.8579 20.90957 28.94758 21.32801 29.05727C21.74645 29.16665 22.07551 29.29633 22.31457 29.44071C22.55364 29.59008 22.71801 29.75977 22.8077 29.93883C22.89739 30.12821 22.94239 30.32758 22.94239 30.54696C22.94239 30.67133 22.91239 30.80102 22.8527 30.9354C22.7977 31.06977 22.70801 31.19446 22.58864 31.30915C22.46895 31.42352 22.31457 31.51321 22.1302 31.58821C21.94582 31.6629 21.72176 31.69758 21.4677 31.69758C21.19864 31.69758 20.94957 31.6579 20.7102 31.57321C20.48114 31.48852 20.26176 31.37383 20.0727 31.23446C19.87332 31.08477 19.70395 30.9154 19.554574 30.71633C19.399887 30.51696 19.275512 30.30258 19.165824 30.06852C19.066137 29.83446 18.986449 29.59008 18.926762 29.33102C18.876762 29.07696 18.847074 28.8179 18.847074 28.55883C18.847074 28.24508 18.891762 27.96602 18.976449 27.71196C19.061137 27.457895 19.185824 27.24352 19.345199 27.069145C19.504574 26.88977 19.69895 26.750395 19.92801 26.655708C20.15739 26.56102 20.41645 26.511333 20.7052 26.511333C20.91957 26.511333 21.11895 26.531333 21.29832 26.57102C21.48739 26.60602 21.66176 26.665708 21.82645 26.750395C21.99582 26.835083 22.1602 26.93977 22.32457 27.059458C22.48895 27.188833 22.65332 27.338208 22.8227 27.512583ZM24.88442 30.2229L24.96911 31.33383C24.96911 31.53321 24.86942 31.6329 24.66536 31.6329H24.22692L23.61911 26.58102H24.48598L24.76473 28.91758C24.96911 29.69977 25.23817 30.2379 25.56692 30.53696C25.90067 30.83571 26.27942 30.9004 26.71286 30.72602L26.87223 31.57821C26.68786 31.6579 26.50379 31.68258 26.32442 31.6629C26.14504 31.6329 25.97067 31.56321 25.80129 31.44352C25.63192 31.32915 25.46723 31.16446 25.31786 30.9554C25.15848 30.75102 25.01911 30.50696 24.88442 30.2229ZM28.29161 30.2229L28.37629 31.33383C28.37629 31.53321 28.27661 31.6329 28.07254 31.6329H27.63411L27.02629 26.58102H27.89317L28.17192 28.91758C28.37629 29.69977 28.6454 30.2379 28.9741 30.53696C29.3079 30.83571 29.6866 30.9004 30.12 30.72602L30.2794 31.57821C30.095 31.6579 29.911 31.68258 29.7316 31.6629C29.5522 31.6329 29.3779 31.56321 29.2085 31.44352C29.0391 31.32915 28.8744 31.16446 28.725 30.9554C28.5657 30.75102 28.42629 30.50696 28.29161 30.2229Z' fill='#f00'/>
+<path d='M32.2136 27.203833C31.8649 27.203833 31.6008 27.323208 31.4164 27.557583C31.2321 27.79665 31.1424 28.1504 31.1424 28.61383C31.1424 28.92758 31.1824 29.23165 31.2571 29.5204C31.3318 29.80946 31.4414 30.06352 31.5808 30.2829C31.7205 30.50196 31.8899 30.67633 32.0893 30.80602C32.2833 30.9404 32.5077 31.00508 32.7518 31.00508C33.0955 31.00508 33.3646 30.88571 33.5439 30.65633C33.7333 30.41727 33.823 30.06852 33.823 29.60508C33.823 29.29133 33.783 28.98727 33.7083 28.69852C33.6336 28.40946 33.5239 28.1554 33.3846 27.93602C33.2399 27.71196 33.0705 27.537583 32.8764 27.403208C32.6771 27.26852 32.4577 27.203833 32.2136 27.203833ZM32.1289 26.511333C32.4927 26.511333 32.8314 26.59102 33.1452 26.760395C33.4593 26.91977 33.7333 27.144145 33.9624 27.427895C34.1964 27.71196 34.3758 28.04071 34.5105 28.41446C34.6449 28.78821 34.7096 29.18665 34.7096 29.61008C34.7096 29.93883 34.6649 30.2329 34.5702 30.49196S34.3461 30.9704 34.1818 31.14977C34.0171 31.32915 33.818 31.46352 33.5886 31.56321C33.3596 31.6529 33.1055 31.70258 32.8314 31.70258C32.4677 31.70258 32.1289 31.6229 31.8202 31.45852C31.5011 31.29415 31.2321 31.07477 30.998 30.79602C30.7639 30.51196 30.5846 30.18321 30.4499 29.80946C30.3155 29.43571 30.2508 29.03227 30.2508 28.60883C30.2508 28.27508 30.2955 27.98102 30.3902 27.72196C30.4849 27.462895 30.6143 27.24352 30.7789 27.064145C30.9433 26.885083 31.1424 26.750395 31.3718 26.650708C31.6008 26.56102 31.8549 26.511333 32.1289 26.511333ZM36.6867 30.2229L36.7714 31.33383C36.7714 31.53321 36.6717 31.6329 36.4676 31.6329H36.0292L35.4214 26.58102H36.2882L36.567 28.91758C36.7714 29.69977 37.0404 30.2379 37.3692 30.53696C37.7029 30.83571 38.0817 30.9004 38.5151 30.72602L38.6745 31.57821C38.4901 31.6579 38.3061 31.68258 38.1267 31.6629C37.9473 31.6329 37.7729 31.56321 37.6036 31.44352C37.4342 31.32915 37.2695 31.16446 37.1201 30.9554C36.9607 30.75102 36.8214 30.50696 36.6867 30.2229Z' fill='#f00'/>
+<path d='M57.0859 118.6875C48.3477 117.1445 47.1562 123.2773 53.5156 123.8281' stroke='#00f' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='.3985,.99628'/>
+<path d='M57.085968 123.617289C56.031291 123.859475 54.332067 124.523535 53.164099 125.269632L53.046911 122.281353C54.269567 122.929789 56.015666 123.46104 57.085968 123.617289' fill='#00f'/>
+<path d='M42.7187 91.4844C42.7187 87.4453 42.7187 99.3906 54.2383 109.1719' stroke='#00f' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='.3985,.99628'/>
+<path d='M57.085935 111.370751C56.125002 110.874657 54.398441 110.280907 53.027341 110.097307L54.863278 107.741842C55.378902 109.026997 56.371096 110.558253 57.085935 111.370751' fill='#00f'/>
+<path d='M99.4102 91.4844C99.4102 87.4453 99.4102 99.3906 87.8945 109.1719' stroke='#00f' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='.3985,.99628'/>
+<path d='M85.042976 111.370753C85.757815 110.558256 86.753913 109.026997 87.265625 107.741836L89.105473 110.097306C87.734374 110.280907 86.003909 110.874659 85.042976 111.370753' fill='#00f'/>
+<path d='M96.1254 113.17357L96.20009 114.15482C96.20009 114.35419 96.1004 114.45388 95.90134 114.45388H95.462905L94.855092 109.402007H95.74165L96.03072 111.96294C96.1254 112.23669 96.23509 112.49107 96.36447 112.71013C96.49915 112.93919 96.63853 113.12857 96.7929 113.28794C96.94759 113.44763 97.10197 113.57201 97.27134 113.65669C97.43072 113.74138 97.59509 113.78638 97.75447 113.78638C98.01353 113.78638 98.1929 113.69169 98.28759 113.49732C98.38228 113.30794 98.40728 113.01419 98.36228 112.61544L97.98384 109.402007H98.86572L99.24416 112.61544C99.27915 112.91951 99.27915 113.18857 99.24416 113.42763C99.20947 113.66169 99.13947 113.86107 99.03509 114.02544C98.9354 114.18982 98.80572 114.31451 98.64634 114.39419C98.48197 114.48388 98.29759 114.52357 98.08353 114.52357C97.72478 114.52357 97.37603 114.40919 97.03728 114.18482C96.69822 113.95576 96.39447 113.61701 96.1254 113.17357ZM102.09806 110.024819C101.74931 110.024819 101.48525 110.144194 101.30087 110.378569C101.1165 110.61763 101.02681 110.97138 101.02681 111.43482C101.02681 111.74857 101.06681 112.05263 101.1415 112.34138C101.21619 112.63044 101.32587 112.88451 101.46525 113.10388C101.60494 113.32294 101.77431 113.49732 101.97369 113.62701C102.16775 113.76138 102.39212 113.82607 102.63619 113.82607C102.97994 113.82607 103.249 113.70669 103.42837 113.47732C103.61775 113.23826 103.70744 112.88951 103.70744 112.42607C103.70744 112.11232 103.66744 111.80826 103.59275 111.51951C103.51806 111.23044 103.40837 110.97638 103.269 110.75701C103.12431 110.53294 102.95494 110.358569 102.76087 110.224194C102.5615 110.089507 102.34212 110.024819 102.09806 110.024819ZM102.01337 109.332319C102.37712 109.332319 102.71587 109.412007 103.02962 109.581382C103.34369 109.740757 103.61775 109.965132 103.84681 110.248882C104.08087 110.53294 104.26025 110.86169 104.39494 111.23544C104.52931 111.60919 104.594 112.00763 104.594 112.43107C104.594 112.75982 104.54931 113.05388 104.45462 113.31294C104.35994 113.57201 104.23056 113.79138 104.06619 113.97076C103.9015 114.15013 103.70244 114.28451 103.47306 114.38419C103.244 114.47388 102.98994 114.52357 102.71587 114.52357C102.35212 114.52357 102.01337 114.44388 101.70462 114.27951C101.38556 114.11513 101.1165 113.89576 100.88244 113.61701C100.64837 113.33294 100.469 113.00419 100.33431 112.63044C100.19994 112.25669 100.13525 111.85326 100.13525 111.42982C100.13525 111.09607 100.17994 110.80201 100.27462 110.54294C100.36931 110.283882 100.49869 110.064507 100.66337 109.885132C100.82775 109.706069 101.02681 109.571382 101.25619 109.471694C101.48525 109.382007 101.73931 109.332319 102.01337 109.332319ZM106.5761 113.17357L106.6508 114.15482C106.6508 114.35419 106.5511 114.45388 106.352 114.45388H105.9136L105.3058 109.402007H106.1924L106.4814 111.96294C106.5761 112.23669 106.6858 112.49107 106.8152 112.71013C106.9499 112.93919 107.0892 113.12857 107.2436 113.28794C107.3983 113.44763 107.5527 113.57201 107.722 113.65669C107.8814 113.74138 108.0458 113.78638 108.2052 113.78638C108.4642 113.78638 108.6436 113.69169 108.7383 113.49732C108.833 113.30794 108.858 113.01419 108.813 112.61544L108.4345 109.402007H109.3164L109.6949 112.61544C109.7299 112.91951 109.7299 113.18857 109.6949 113.42763C109.6602 113.66169 109.5902 113.86107 109.4858 114.02544C109.3861 114.18982 109.2564 114.31451 109.097 114.39419C108.9327 114.48388 108.7483 114.52357 108.5342 114.52357C108.1755 114.52357 107.8267 114.40919 107.488 114.18482C107.1489 113.95576 106.8452 113.61701 106.5761 113.17357ZM110.9397 112.75013L110.85 112.02263H113.1266L113.2163 112.75013H110.9397ZM115.7565 113.71169H116.9821L117.0668 114.34919H115.8065L115.8612 114.81263C115.8862 115.02669 115.9309 115.21107 116.0009 115.36076C116.0606 115.51013 116.1402 115.62982 116.2349 115.72419C116.3296 115.81888 116.4343 115.88388 116.5587 115.92857C116.6784 115.96857 116.8077 115.98826 116.9524 115.98826H117.2412C117.3162 115.98826 117.3609 116.02326 117.3759 116.08794L117.4606 116.54638C117.2862 116.61107 117.1018 116.64607 116.8974 116.64607C116.6534 116.64607 116.4243 116.60607 116.2099 116.52638C116.0009 116.44669 115.8115 116.32732 115.6521 116.17763C115.4827 116.01826 115.3481 115.82888 115.2434 115.60982C115.134 115.38044 115.059 115.12638 115.0243 114.83763L114.9646 114.34919H114.2471L114.2021 113.99044C114.1971 113.92076 114.2071 113.87107 114.2471 113.83607C114.2768 113.80138 114.3268 113.77638 114.3865 113.76138L114.8846 113.69669L114.2171 108.16138H114.5609C114.6856 108.16138 114.7852 108.19638 114.8549 108.25607C114.9296 108.32576 114.9843 108.415444 115.0193 108.535132L115.2534 109.566382L115.7565 113.71169Z' fill='#00f'/>
+<path d='M120.4936 113.83107L120.2792 112.10232C120.1849 111.80826 120.0802 111.53451 119.9605 111.28513C119.8408 111.04107 119.7114 110.82701 119.572 110.64763C119.4274 110.46326 119.278 110.323569 119.1236 110.219194C118.9689 110.119507 118.8095 110.069507 118.6452 110.069507C118.132 110.069507 117.878 110.46826 117.878 111.27044C117.878 111.49951 117.903 111.72357 117.9577 111.94294C118.0124 112.15701 118.0874 112.36138 118.177 112.55576C118.2764 112.75013 118.3861 112.92451 118.5208 113.08888C118.6552 113.24826 118.7995 113.38763 118.9642 113.50232C119.1286 113.61701 119.303 113.70669 119.4874 113.77638C119.6714 113.83607 119.8658 113.87107 120.0652 113.87107C120.1349 113.87107 120.2045 113.86607 120.2792 113.86607C120.3492 113.85607 120.4189 113.84607 120.4936 113.83107ZM120.1549 110.73232L120.0602 109.710757C120.0602 109.626069 120.0802 109.551382 120.1199 109.491694C120.1649 109.432007 120.2445 109.402007 120.3592 109.402007H120.8174L121.4202 114.28451C121.2211 114.36919 121.0167 114.43388 120.8174 114.46388C120.6083 114.50357 120.3989 114.51857 120.1849 114.51857C119.8858 114.51857 119.6017 114.47388 119.3277 114.39419C119.0536 114.30451 118.7995 114.18482 118.5655 114.03544C118.3264 113.87607 118.112 113.69669 117.918 113.48732C117.7236 113.27326 117.5592 113.04388 117.4195 112.78982C117.2852 112.53576 117.1805 112.27169 117.1008 111.98263C117.0311 111.70388 116.9911 111.40982 116.9911 111.11076C116.9911 110.82701 117.0211 110.57294 117.0858 110.348569C117.1505 110.129507 117.2402 109.945132 117.3499 109.790757C117.4695 109.641069 117.6039 109.526694 117.7683 109.451694C117.9327 109.372007 118.112 109.332319 118.3114 109.332319C118.4958 109.332319 118.6702 109.367007 118.8445 109.432007C119.0139 109.496694 119.1733 109.591382 119.3327 109.710757C119.4824 109.835444 119.6317 109.979819 119.7711 110.154194C119.9058 110.328569 120.0352 110.51794 120.1549 110.73232ZM122.5254 110.353569C122.5304 110.019819 122.6301 109.760757 122.8095 109.586382C122.9988 109.412007 123.2479 109.322319 123.5717 109.322319C123.781 109.322319 123.9901 109.362007 124.1945 109.442007C124.4038 109.526694 124.5879 109.636069 124.7526 109.780757L124.5632 110.204194C124.5482 110.233882 124.5332 110.253882 124.5232 110.268882C124.5032 110.283882 124.4835 110.288882 124.4535 110.288882C124.4285 110.288882 124.4038 110.278882 124.3688 110.248882C124.3338 110.229194 124.2942 110.199194 124.2442 110.169194C124.1945 110.139507 124.1348 110.109507 124.0748 110.089507C124.0051 110.059507 123.9304 110.049819 123.8407 110.049819C123.7063 110.049819 123.6017 110.089507 123.522 110.169194C123.4423 110.253882 123.4023 110.378569 123.4023 110.54794C123.4023 110.55794 123.4023 110.57294 123.4073 110.59263C123.4073 110.61263 123.4073 110.64763 123.4173 110.69732C123.4173 110.74732 123.4273 110.81201 123.4373 110.89669C123.447 110.98138 123.462 111.09107 123.477 111.22544L123.781 113.70669H125.111L125.186 114.34919H123.8607L124.0748 116.08794H123.6117C123.5567 116.08794 123.517 116.07294 123.477 116.03826C123.447 116.00826 123.4173 115.96857 123.4023 115.91857L123.0235 114.35919L122.2463 114.25451L122.2067 113.90076C122.2017 113.83607 122.2117 113.78638 122.2413 113.75638C122.2663 113.72138 122.3063 113.70669 122.351 113.70669H122.9142L122.6051 111.18076C122.5851 111.02607 122.5704 110.89669 122.5604 110.80201C122.5454 110.70732 122.5404 110.62763 122.5304 110.56794C122.5304 110.50794 122.5254 110.46326 122.5254 110.42826V110.353569Z' fill='#00f'/>
+<path d='M129.015 113.83107L128.8006 112.10232C128.7063 111.80826 128.6016 111.53451 128.4819 111.28513C128.3622 111.04107 128.2328 110.82701 128.0935 110.64763C127.9488 110.46326 127.7994 110.323569 127.645 110.219194C127.4903 110.119507 127.331 110.069507 127.1666 110.069507C126.6535 110.069507 126.3994 110.46826 126.3994 111.27044C126.3994 111.49951 126.4244 111.72357 126.4791 111.94294C126.5338 112.15701 126.6088 112.36138 126.6985 112.55576C126.7978 112.75013 126.9075 112.92451 127.0422 113.08888C127.1766 113.24826 127.321 113.38763 127.4856 113.50232C127.65 113.61701 127.8244 113.70669 128.0088 113.77638C128.1928 113.83607 128.3872 113.87107 128.5866 113.87107C128.6563 113.87107 128.726 113.86607 128.8006 113.86607C128.8706 113.85607 128.9403 113.84607 129.015 113.83107ZM128.6763 110.73232L128.5816 109.710757C128.5816 109.626069 128.6016 109.551382 128.6413 109.491694C128.6863 109.432007 128.766 109.402007 128.8806 109.402007H129.3388L129.9416 114.28451C129.7425 114.36919 129.5381 114.43388 129.3388 114.46388C129.1297 114.50357 128.9203 114.51857 128.7063 114.51857C128.4072 114.51857 128.1231 114.47388 127.8491 114.39419C127.575 114.30451 127.321 114.18482 127.0869 114.03544C126.8478 113.87607 126.6335 113.69669 126.4394 113.48732C126.245 113.27326 126.0806 113.04388 125.941 112.78982C125.8066 112.53576 125.7019 112.27169 125.6222 111.98263C125.5525 111.70388 125.5125 111.40982 125.5125 111.11076C125.5125 110.82701 125.5425 110.57294 125.6072 110.348569C125.6719 110.129507 125.7616 109.945132 125.8713 109.790757C125.991 109.641069 126.1253 109.526694 126.2897 109.451694C126.4541 109.372007 126.6335 109.332319 126.8328 109.332319C127.0172 109.332319 127.1916 109.367007 127.366 109.432007C127.5353 109.496694 127.6947 109.591382 127.8541 109.710757C128.0038 109.835444 128.1531 109.979819 128.2925 110.154194C128.4272 110.328569 128.5566 110.51794 128.6763 110.73232ZM130.6731 109.402007H131.5449L132.4368 116.74076H131.5649L130.6731 109.402007Z' fill='#00f'/>
+<path d='M105.50058 101.87603L105.28621 100.14728C105.19183 99.85322 105.08714 99.57947 104.96746 99.33009C104.84777 99.08603 104.71839 98.87197 104.57902 98.69259C104.43433 98.50822 104.28496 98.368529 104.13058 98.264154C103.97589 98.164466 103.81652 98.114466 103.65214 98.114466C103.13902 98.114466 102.88496 98.51322 102.88496 99.3154C102.88496 99.54447 102.90996 99.76853 102.96464 99.9879C103.01933 100.20197 103.09433 100.40634 103.18402 100.60072C103.28339 100.79509 103.39308 100.96947 103.52777 101.13384C103.66214 101.29322 103.80652 101.43259 103.97121 101.54728C104.13558 101.66197 104.30996 101.75165 104.49433 101.82134C104.67839 101.88103 104.87277 101.91603 105.07214 101.91603C105.14183 101.91603 105.21152 101.91103 105.28621 101.91103C105.35621 101.90103 105.42589 101.89103 105.50058 101.87603ZM105.16183 98.77728L105.06714 97.755716C105.06714 97.671029 105.08714 97.596341 105.12683 97.536654C105.17183 97.476966 105.25152 97.446966 105.36621 97.446966H105.82433L106.42714 102.32947C106.22808 102.41415 106.02371 102.47884 105.82433 102.50884C105.61527 102.54853 105.40589 102.56353 105.19183 102.56353C104.89277 102.56353 104.60871 102.51884 104.33464 102.43915C104.06058 102.34947 103.80652 102.22978 103.57246 102.0804C103.33339 101.92103 103.11902 101.74165 102.92496 101.53228C102.730582 101.31822 102.566207 101.08884 102.42652 100.83478C102.292145 100.58072 102.187457 100.31665 102.10777 100.02759C102.038082 99.74884 101.998082 99.45478 101.998082 99.15572C101.998082 98.87197 102.028082 98.6179 102.09277 98.393529C102.157457 98.174466 102.247145 97.990091 102.356832 97.835716C102.47652 97.686029 102.610895 97.571654 102.77527 97.496654C102.93964 97.416966 103.11902 97.377279 103.31839 97.377279C103.50277 97.377279 103.67714 97.411966 103.85152 97.476966C104.02089 97.541654 104.18027 97.636341 104.33964 97.755716C104.48933 97.880404 104.63871 98.024779 104.77808 98.199154C104.91277 98.373529 105.04214 98.5629 105.16183 98.77728ZM107.15863 97.446966H108.0305L108.92238 104.78572H108.0505L107.15863 97.446966ZM112.833 101.87603L112.6186 100.14728C112.5243 99.85322 112.4196 99.57947 112.2999 99.33009C112.1802 99.08603 112.0508 98.87197 111.9114 98.69259C111.7668 98.50822 111.61738 98.368529 111.463 98.264154C111.30832 98.164466 111.14894 98.114466 110.98457 98.114466C110.47144 98.114466 110.21738 98.51322 110.21738 99.3154C110.21738 99.54447 110.24238 99.76853 110.29707 99.9879C110.35175 100.20197 110.42675 100.40634 110.51644 100.60072C110.61582 100.79509 110.7255 100.96947 110.86019 101.13384C110.99457 101.29322 111.13894 101.43259 111.30363 101.54728C111.468 101.66197 111.64238 101.75165 111.8268 101.82134C112.0108 101.88103 112.2052 101.91603 112.4046 101.91603C112.4743 101.91603 112.5439 101.91103 112.6186 101.91103C112.6886 101.90103 112.7583 101.89103 112.833 101.87603ZM112.4943 98.77728L112.3996 97.755716C112.3996 97.671029 112.4196 97.596341 112.4593 97.536654C112.5043 97.476966 112.5839 97.446966 112.6986 97.446966H113.1568L113.7596 102.32947C113.5605 102.41415 113.3561 102.47884 113.1568 102.50884C112.9477 102.54853 112.7383 102.56353 112.5243 102.56353C112.2252 102.56353 111.9411 102.51884 111.66707 102.43915C111.393 102.34947 111.13894 102.22978 110.90488 102.0804C110.66582 101.92103 110.45144 101.74165 110.25738 101.53228C110.063 101.31822 109.89863 101.08884 109.75894 100.83478C109.62457 100.58072 109.51988 100.31665 109.44019 100.02759C109.3705 99.74884 109.3305 99.45478 109.3305 99.15572C109.3305 98.87197 109.3605 98.6179 109.42519 98.393529C109.48988 98.174466 109.57957 97.990091 109.68925 97.835716C109.80894 97.686029 109.94332 97.571654 110.10769 97.496654C110.27207 97.416966 110.45144 97.377279 110.65082 97.377279C110.83519 97.377279 111.00957 97.411966 111.18394 97.476966C111.35332 97.541654 111.51269 97.636341 111.67207 97.755716C111.8218 97.880404 111.9711 98.024779 112.1105 98.199154C112.2452 98.373529 112.3746 98.5629 112.4943 98.77728ZM115.7317 101.08884L115.8164 102.19978C115.8164 102.39915 115.7167 102.49884 115.5126 102.49884H115.0742L114.4664 97.446966H115.3332L115.612 99.78353C115.8164 100.56572 116.0854 101.10384 116.4142 101.4029C116.7479 101.70165 117.1267 101.76634 117.5601 101.59197L117.7195 102.44415C117.5351 102.52384 117.3511 102.54853 117.1717 102.52884C116.9923 102.49884 116.8179 102.42915 116.6486 102.30947C116.4792 102.19509 116.3145 102.0304 116.1651 101.82134C116.0057 101.61697 115.8664 101.3729 115.7317 101.08884ZM117.8736 97.446966H118.7404L119.0542 100.07759C119.1489 100.35165 119.2486 100.59572 119.3632 100.81478C119.4776 101.02915 119.5973 101.21353 119.7317 101.3629C119.8614 101.51728 120.0007 101.63197 120.1504 101.71165C120.2948 101.79134 120.4492 101.83134 120.6086 101.83134C120.8576 101.83134 121.0123 101.73665 121.077 101.54228C121.1417 101.3479 121.1467 101.05415 121.097 100.6604L120.7182 97.446966H121.5951L121.9189 100.18728V100.19228C122.0086 100.45603 122.1132 100.6954 122.2229 100.89447C122.3423 101.10384 122.462 101.27322 122.5964 101.4129C122.7311 101.54728 122.8654 101.65197 123.0101 101.72165C123.1495 101.79634 123.2889 101.83134 123.4336 101.83134C123.6826 101.83134 123.842 101.73665 123.9167 101.54228C123.9864 101.3479 123.9964 101.05415 123.9517 100.6604L123.5679 97.446966H124.4448L124.8236 100.6604C124.8982 101.26822 124.8436 101.73665 124.6642 102.0704S124.1807 102.56853 123.7473 102.56853C123.3986 102.56853 123.0698 102.45884 122.7511 102.23978C122.442 102.01572 122.1579 101.67665 121.9089 101.21353C121.9089 101.64697 121.8292 101.98072 121.6648 102.21978C121.5004 102.44915 121.2514 102.56853 120.9076 102.56853C120.5839 102.56853 120.2698 102.45884 119.9711 102.24978C119.677 102.0304 119.4029 101.71665 119.1539 101.30322L119.2236 102.19978C119.2236 102.39915 119.1239 102.49884 118.9198 102.49884H118.4814L117.8736 97.446966Z' fill='#00f'/>
+<path d='M141.9336 135.3281V21.937' stroke='#808080' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M170.2773 163.671871V177.8477H255.32V163.671871Z' fill='#f2f2f2'/>
+<path d='M180.669967 173.36075V169.048563H180.427779C180.221529 169.048563 180.078092 168.958876 180.078092 168.761688C180.078092 168.591376 180.176842 168.466063 180.418717 168.466063H181.27059C181.32434 168.466063 181.3959 168.457001 181.45872 168.457001C181.67403 168.457001 181.79934 168.573563 181.79934 168.752938C181.79934 168.941063 181.67403 169.048563 181.45872 169.048563H181.20778L181.21653 173.28013C181.25247 173.10075 181.32434 172.91263 181.38715 172.74231C181.86215 171.45138 182.30153 170.14231 182.78559 168.851376C182.86622 168.645126 182.9559 168.466063 183.26965 168.466063H183.42215C183.69997 168.466063 183.7359 168.663251 183.7359 168.824501V173.36075H183.97778C184.18403 173.36075 184.32747 173.45044 184.32747 173.64763C184.32747 173.81794 184.22872 173.94356 183.98684 173.94356H183.13528C183.08122 173.94356 183.00965 173.95231 182.94684 173.95231C182.72278 173.95231 182.60622 173.827 182.60622 173.64763C182.60622 173.46825 182.73184 173.36075 182.94684 173.36075H183.19778V169.129501C183.14403 169.272938 183.09934 169.416376 183.05434 169.55981L182.81247 170.25888C182.45372 171.26294 182.08622 172.27606 181.71872 173.28013L181.61122 173.567C181.53059 173.87169 181.33309 173.94356 181.08215 173.94356H180.562154C180.508404 173.94356 180.454654 173.95231 180.400904 173.95231C180.221529 173.95231 180.078092 173.84481 180.078092 173.65669C180.078092 173.45044 180.221529 173.36075 180.418717 173.36075H180.669967ZM186.52387 174.042C185.81544 173.96138 185.20575 174.00606 185.09825 172.50013C185.06231 172.09669 185.06231 171.68419 185.06231 171.28106V170.63544C185.06231 170.10638 185.08044 169.56856 185.23294 169.102313C185.46575 168.394188 186.12919 168.367313 186.72981 168.367313H187.15137C187.58169 168.367313 188.05669 168.394188 188.36137 168.690126C188.72919 169.057626 188.75606 169.89138 188.75606 170.58169V171.57669C188.75606 172.02513 188.747 172.48231 188.67512 172.91263C188.60356 173.38763 188.47794 173.81794 187.86856 173.97044C187.58169 174.042 187.28575 174.042 186.99887 174.042H186.52387ZM185.72575 170.69825C185.717 170.76981 185.717 170.83263 185.717 170.9045C185.717 171.43325 185.717 171.95325 185.76169 172.47325C185.78856 172.71513 185.81544 173.02013 185.98575 173.20825C186.192 173.44138 186.54169 173.4595 186.84637 173.4595H186.96294C187.24981 173.4595 187.58169 173.45044 187.79669 173.25325C187.97606 173.08294 188.02075 172.787 188.04762 172.55388C188.09262 172.17731 188.09262 171.80075 188.09262 171.4245V170.74294C188.09262 170.232 188.08356 169.58669 187.87731 169.290751C187.68919 168.977001 187.26794 168.950126 186.93606 168.950126C186.39825 168.950126 185.932 168.986063 185.80669 169.72106C185.74387 170.04388 185.76169 170.37544 185.72575 170.69825ZM191.284 173.36075V169.048563H190.28C190.0468 169.048563 189.9393 168.941063 189.9393 168.752938C189.9393 168.582626 190.0468 168.466063 190.2531 168.466063H193.05C193.2112 168.483876 193.2922 168.618251 193.2922 168.752938C193.2922 168.932001 193.1665 169.057626 192.9425 169.057626C192.8706 169.057626 192.799 169.048563 192.7453 169.048563H191.9475V173.36075H192.9512C193.1843 173.36075 193.2922 173.46825 193.2922 173.65669C193.2922 173.827 193.1843 173.94356 192.9784 173.94356H190.1812C190.02 173.92544 189.9393 173.79106 189.9393 173.65669C189.9393 173.47731 190.0647 173.35169 190.2887 173.35169C190.3606 173.35169 190.4234 173.36075 190.4859 173.36075H191.284ZM195.067 168.752938C195.5511 168.466063 195.9992 168.367313 196.5282 168.367313C197.4336 168.367313 198.1957 169.048563 198.1957 169.972C198.1957 170.58169 197.8461 171.12856 197.2901 171.38856C196.4654 171.77388 195.067 171.61263 195.067 172.59888C195.067 173.14544 195.6317 173.4595 196.1157 173.4595C196.6717 173.4595 197.1111 173.1545 197.2632 172.58075C197.3261 172.32981 197.3082 172.12356 197.6398 172.12356C197.9176 172.12356 197.9626 172.30294 197.9626 172.46419V173.49513C197.9626 173.54888 197.9717 173.61169 197.9717 173.68356C197.9717 173.90763 197.8639 174.042 197.6757 174.042C197.4517 174.042 197.3707 173.83575 197.3351 173.65669C196.9136 173.91669 196.582 174.042 196.1157 174.042C195.282 174.042 194.5111 173.50419 194.4395 172.66138V172.57169C194.4395 171.94419 194.8786 171.38856 195.4614 171.18231C196.3129 170.88638 197.5682 170.99419 197.5682 169.91825C197.5682 169.344501 197.0751 168.950126 196.5104 168.950126C195.9545 168.950126 195.1923 169.165126 195.1207 169.82856C195.0761 170.10638 195.0761 170.28575 194.762 170.28575C194.4664 170.28575 194.4395 170.08856 194.4395 169.90919V168.707938C194.4395 168.492938 194.547 168.367313 194.7264 168.367313C194.9504 168.367313 195.0311 168.573563 195.067 168.752938ZM199.5225 173.36075V169.048563H199.2356C199.0293 169.048563 198.8768 168.967938 198.8768 168.761688C198.8768 168.573563 199.0025 168.457001 199.2175 168.457001C199.2893 168.457001 199.3609 168.466063 199.4237 168.466063H202.9378C203.1084 168.483876 203.189 168.636376 203.189 168.797626C203.189 168.860438 203.18 168.932001 203.18 168.986063V169.73013C203.18 169.93606 203.0725 170.05263 202.8572 170.05263C202.6868 170.05263 202.5075 169.99888 202.5075 169.73888C202.5075 169.68513 202.5165 169.64044 202.5165 169.59544V169.048563H200.1856V171.012H201.3243C201.3243 170.95825 201.3153 170.9045 201.3153 170.84169C201.3153 170.58169 201.4678 170.50106 201.6559 170.50106C201.8262 170.50106 201.9878 170.55481 201.9878 170.82356V171.60356C201.9878 171.65731 201.9965 171.72013 201.9965 171.77388C201.9965 172.02513 201.8443 172.10575 201.6559 172.10575C201.4678 172.10575 201.3153 172.02513 201.3153 171.76513C201.3153 171.71138 201.3243 171.64856 201.3243 171.59481H200.1856V173.36075H202.3193V172.83169C202.3193 172.56294 202.4718 172.50013 202.66 172.50013C202.884 172.50013 202.9828 172.62575 202.9828 172.84981V173.58481C202.9828 173.782 202.929 173.95231 202.6422 173.95231C202.5703 173.95231 202.5075 173.94356 202.445 173.94356H199.2356C199.0025 173.94356 198.8768 173.84481 198.8768 173.64763C198.8768 173.42356 199.0472 173.36075 199.2356 173.36075H199.5225ZM204.1661 168.259813C203.9957 168.232938 203.8879 168.071376 203.8879 167.919188C203.8879 167.730751 204.0404 167.596376 204.2914 167.596376H207.1782C207.4382 167.596376 207.5817 167.739813 207.5817 167.927938C207.5817 168.089501 207.4739 168.250751 207.2857 168.268876H204.3364C204.2826 168.268876 204.2198 168.268876 204.1661 168.259813ZM208.989 173.36075H210.1097V169.048563H209.5897C209.3925 169.048563 209.2759 168.932001 209.2759 168.761688C209.2759 168.609501 209.3656 168.466063 209.5628 168.466063H211.2572C211.4631 168.466063 211.6065 168.555751 211.6065 168.761688C211.6065 168.932001 211.49 169.048563 211.2928 169.048563H210.7731V173.36075H211.8934V172.75106C211.9115 172.55388 212.0637 172.50013 212.2343 172.50013C212.4493 172.50013 212.5568 172.60763 212.5568 172.84075V173.61169C212.5568 173.83575 212.4315 173.94356 212.2343 173.94356H208.6393C208.3972 173.94356 208.3256 173.80013 208.3256 173.57575V172.82294C208.3256 172.58075 208.469 172.50013 208.6484 172.50013C208.8365 172.50013 208.989 172.56294 208.989 172.82294V173.36075ZM213.6417 173.36075V169.048563H213.3548C213.1486 169.048563 212.9961 168.967938 212.9961 168.761688C212.9961 168.573563 213.1217 168.457001 213.3367 168.457001C213.4086 168.457001 213.4801 168.466063 213.5429 168.466063H217.057C217.2276 168.483876 217.3082 168.636376 217.3082 168.797626C217.3082 168.860438 217.2992 168.932001 217.2992 168.986063V169.73013C217.2992 169.93606 217.1917 170.05263 216.9764 170.05263C216.8061 170.05263 216.6267 169.99888 216.6267 169.73888C216.6267 169.68513 216.6357 169.64044 216.6357 169.59544V169.048563H214.3048V171.012H215.4436C215.4436 170.95825 215.4345 170.9045 215.4345 170.84169C215.4345 170.58169 215.587 170.50106 215.7751 170.50106C215.9454 170.50106 216.107 170.55481 216.107 170.82356V171.60356C216.107 171.65731 216.1157 171.72013 216.1157 171.77388C216.1157 172.02513 215.9636 172.10575 215.7751 172.10575C215.587 172.10575 215.4345 172.02513 215.4345 171.76513C215.4345 171.71138 215.4436 171.64856 215.4436 171.59481H214.3048V173.36075H216.4386V172.83169C216.4386 172.56294 216.5911 172.50013 216.7792 172.50013C217.0032 172.50013 217.102 172.62575 217.102 172.84981V173.58481C217.102 173.782 217.0482 173.95231 216.7614 173.95231C216.6895 173.95231 216.6267 173.94356 216.5642 173.94356H213.3548C213.1217 173.94356 212.9961 173.84481 212.9961 173.64763C212.9961 173.42356 213.1664 173.36075 213.3548 173.36075H213.6417ZM218.599 168.752938C219.0831 168.466063 219.5312 168.367313 220.0603 168.367313C220.9656 168.367313 221.7278 169.048563 221.7278 169.972C221.7278 170.58169 221.3781 171.12856 220.8222 171.38856C219.9975 171.77388 218.599 171.61263 218.599 172.59888C218.599 173.14544 219.1637 173.4595 219.6478 173.4595C220.2037 173.4595 220.6431 173.1545 220.7953 172.58075C220.8581 172.32981 220.8403 172.12356 221.1718 172.12356C221.4497 172.12356 221.4947 172.30294 221.4947 172.46419V173.49513C221.4947 173.54888 221.5037 173.61169 221.5037 173.68356C221.5037 173.90763 221.3959 174.042 221.2078 174.042C220.9837 174.042 220.9028 173.83575 220.8672 173.65669C220.4456 173.91669 220.114 174.042 219.6478 174.042C218.814 174.042 218.0431 173.50419 217.9715 172.66138V172.57169C217.9715 171.94419 218.4106 171.38856 218.9934 171.18231C219.845 170.88638 221.1003 170.99419 221.1003 169.91825C221.1003 169.344501 220.6072 168.950126 220.0425 168.950126C219.4865 168.950126 218.7243 169.165126 218.6528 169.82856C218.6081 170.10638 218.6081 170.28575 218.294 170.28575C217.9984 170.28575 217.9715 170.08856 217.9715 169.90919V168.707938C217.9715 168.492938 218.079 168.367313 218.2584 168.367313C218.4825 168.367313 218.5631 168.573563 218.599 168.752938ZM223.1082 173.36075H224.2289V169.048563H223.7089C223.5117 169.048563 223.3951 168.932001 223.3951 168.761688C223.3951 168.609501 223.4848 168.466063 223.682 168.466063H225.3764C225.5823 168.466063 225.7257 168.555751 225.7257 168.761688C225.7257 168.932001 225.6092 169.048563 225.412 169.048563H224.8923V173.36075H226.0126V172.75106C226.0307 172.55388 226.1829 172.50013 226.3536 172.50013C226.5686 172.50013 226.6761 172.60763 226.6761 172.84075V173.61169C226.6761 173.83575 226.5507 173.94356 226.3536 173.94356H222.7586C222.5164 173.94356 222.4448 173.80013 222.4448 173.57575V172.82294C222.4448 172.58075 222.5882 172.50013 222.7676 172.50013C222.9557 172.50013 223.1082 172.56294 223.1082 172.82294V173.36075Z'/>
+<path d='M232.1932 172.16856C232.0407 172.15044 231.9242 172.03388 231.9242 171.88169C231.9242 171.72013 232.0498 171.58575 232.247 171.58575C232.292 171.58575 232.3457 171.59481 232.3904 171.59481H235.6448C235.8329 171.59481 235.9586 171.71138 235.9586 171.89044C235.9586 172.06981 235.8151 172.1595 235.6536 172.17731H232.6682C232.5789 172.17731 232.4892 172.18638 232.3995 172.18638C232.3276 172.18638 232.2561 172.17731 232.1932 172.16856ZM232.1486 170.80575C232.0139 170.80575 231.9242 170.63544 231.9242 170.52794C231.9242 170.34856 232.0767 170.232 232.2829 170.232H235.582C235.7701 170.232 235.9586 170.31263 235.9586 170.52794C235.9586 170.66231 235.8689 170.79669 235.7164 170.81481H232.2379C232.2111 170.81481 232.1754 170.81481 232.1486 170.80575Z'/>
+<path d='M243.1457 172.73325V169.048563H242.3119C242.0969 169.048563 241.9713 168.941063 241.9713 168.761688C241.9713 168.600438 242.0788 168.457001 242.276 168.457001C242.321 168.457001 242.3657 168.466063 242.4107 168.466063H244.7325C244.8938 168.474813 244.9835 168.618251 244.9835 168.761688C244.9835 168.932001 244.8579 169.048563 244.6429 169.048563H243.8091V173.50419C243.8091 173.55794 243.8182 173.62075 243.8182 173.68356C243.8182 173.88981 243.7194 174.042 243.5132 174.042C243.2982 174.042 243.2444 173.84481 243.1725 173.69231C243.0022 173.37856 242.7422 173.05606 242.3747 172.96638C242.1594 172.92138 241.9175 172.9395 241.9175 172.65263V172.62575C241.9175 172.41044 242.1147 172.36575 242.2491 172.36575H242.3029C242.6166 172.39263 242.9035 172.527 243.1457 172.73325Z'/>
+<path d='M222.395 133.6055H203.203C201.004 133.6055 199.219 131.8203 199.219 129.6211V112.6836C199.219 110.4844 201.004 108.6992 203.203 108.6992H222.395C224.594 108.6992 226.379 110.4844 226.379 112.6836V129.6211C226.379 131.8203 224.594 133.6055 222.395 133.6055Z' fill='#e6ffff'/>
+<path d='M222.395 133.6055H203.203C201.004 133.6055 199.219 131.8203 199.219 129.6211V112.6836C199.219 110.4844 201.004 108.6992 203.203 108.6992H222.395C224.594 108.6992 226.379 110.4844 226.379 112.6836V129.6211C226.379 131.8203 224.594 133.6055 222.395 133.6055Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M205.95583 118.360202H204.41146V120.84645H205.95583C206.47896 120.84645 206.8724 120.74176 207.13646 120.52239C207.40052 120.31333 207.53021 120.01927 207.53021 119.65051C207.53021 119.46145 207.50021 119.28708 207.44052 119.12739C207.38052 118.97301 207.28615 118.83864 207.16146 118.71895C207.03177 118.60926 206.8674 118.519577 206.66833 118.45489C206.46896 118.390202 206.2299 118.360202 205.95583 118.360202ZM204.41146 123.9702H205.72646C206.25958 123.9702 206.64833 123.87051 206.9024 123.68114C207.15646 123.48176 207.28115 123.17801 207.28115 122.75458C207.28115 122.5752 207.25115 122.41083 207.18646 122.25614C207.12146 122.10676 207.02677 121.97739 206.8924 121.8727C206.76302 121.76801 206.59833 121.68333 206.39427 121.62364C206.1949 121.56364 205.96083 121.53395 205.68677 121.53395H204.41146V123.9702ZM205.72646 124.73239H203.449896V117.593015H205.97083C206.36927 117.593015 206.72302 117.642702 207.03677 117.74239C207.35083 117.837077 207.6099 117.976765 207.82896 118.15614C208.03833 118.335202 208.20271 118.549577 208.3174 118.79864C208.42677 119.0477 208.48177 119.32177 208.48177 119.62583C208.48177 120.06926 208.34708 120.4327 208.08802 120.70176C207.81896 120.98083 207.42552 121.1652 206.9024 121.26489C207.12646 121.33458 207.32583 121.42426 207.49021 121.53895C207.65958 121.64833 207.79927 121.77302 207.90865 121.91239C208.01833 122.05208 208.09802 122.20145 208.15802 122.36583C208.20771 122.5252 208.23771 122.69458 208.23771 122.86895C208.23771 123.15801 208.18771 123.41708 208.09302 123.65114C207.99833 123.88052 207.84896 124.07489 207.63958 124.23426C207.44052 124.39364 207.17646 124.51833 206.8624 124.60302C206.54365 124.6877 206.1649 124.73239 205.72646 124.73239ZM210.85693 117.593015V124.73239H209.89068V117.593015H210.85693ZM216.332 123.61645L216.5661 124.07489C216.317 124.31395 216.0279 124.49833 215.7042 124.6227C215.3754 124.74739 215.0117 124.81208 214.6129 124.81208C214.2592 124.81208 213.9404 124.75739 213.6714 124.6477C213.3923 124.53801 213.1633 124.39364 212.9739 124.20926C212.7895 124.02489 212.6451 123.81583 212.5454 123.58145C212.45076 123.34739 212.40107 123.10333 212.40107 122.84927C212.40107 122.5352 212.45076 122.26614 212.5454 122.05708C212.6451 121.8377 212.7745 121.66333 212.9342 121.51895C213.0936 121.37458 213.2779 121.25989 213.482 121.1702C213.6864 121.08051 213.8958 121.00083 214.1098 120.93114C214.3242 120.86614 214.5333 120.80145 214.7376 120.73176C214.942 120.67208 215.1261 120.59239 215.2858 120.4977C215.4451 120.40301 215.5745 120.28833 215.6742 120.15395C215.7689 120.01426 215.8189 119.83489 215.8189 119.62083C215.8189 119.42645 215.7839 119.24708 215.7192 119.0877C215.6542 118.92833 215.5548 118.78864 215.4351 118.67926C215.3054 118.559577 215.1561 118.47489 214.9767 118.410202C214.7973 118.345202 214.5933 118.315515 214.3639 118.315515C214.1795 118.315515 214.0151 118.330515 213.8708 118.370202C213.7264 118.400202 213.5917 118.44489 213.482 118.49989C213.3626 118.554577 213.2629 118.60926 213.1733 118.67426C213.0836 118.73895 213.0039 118.79364 212.9342 118.84864C212.8642 118.90333 212.8045 118.94801 212.7448 118.97802C212.6948 119.01801 212.6451 119.0327 212.6001 119.0327C212.5554 119.0327 212.51044 119.01801 212.47576 118.99801C212.43576 118.96801 212.40107 118.93833 212.37607 118.90333L212.09701 118.44489C212.36607 118.160827 212.6898 117.931765 213.0686 117.76239C213.4473 117.598015 213.8708 117.513328 214.3342 117.513328C214.7126 117.513328 215.0514 117.573015 215.3454 117.687703C215.6445 117.80239 215.8936 117.961765 216.1026 118.165827C216.302 118.370202 216.4614 118.60926 216.5661 118.87833C216.6708 119.15739 216.7254 119.44645 216.7254 119.7602C216.7254 120.05426 216.6758 120.30333 216.5811 120.5077C216.4814 120.71176 216.3517 120.88114 216.1923 121.02083C216.0279 121.1602 215.8436 121.27489 215.6445 121.36958C215.4351 121.45927 215.2258 121.53895 215.0167 121.61364C214.7973 121.68833 214.5883 121.75801 214.3889 121.8277C214.1795 121.8927 214.0001 121.97239 213.8408 122.06708C213.6764 122.16177 213.547 122.27114 213.4523 122.40583C213.3526 122.5352 213.3026 122.69958 213.3026 122.89895C213.3026 123.05333 213.3326 123.20301 213.3873 123.33239C213.4423 123.47208 213.527 123.58645 213.6417 123.68614C213.7511 123.78583 213.8908 123.86551 214.0501 123.9202C214.2195 123.9802 214.4089 124.00989 214.6229 124.00989C214.8523 124.00989 215.0464 123.9802 215.2061 123.9252C215.3704 123.87051 215.5048 123.80583 215.6245 123.74083C215.7342 123.67114 215.8336 123.60645 215.9086 123.55177C215.9833 123.49676 216.0529 123.46708 216.1076 123.46708C216.1576 123.46708 216.2023 123.48176 216.2323 123.50176C216.272 123.53177 216.302 123.56645 216.332 123.61645ZM222.9123 123.9202V124.73239H217.3223V123.9202H219.6392V117.593015H220.6008V123.9202H222.9123Z'/>
+<path d='M226.777 123.6172C235.516 125.1602 236.707 119.0273 230.352 118.4766' stroke='#00f' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='.3985,.99628'/>
+<path d='M226.777456 118.687756C227.832134 118.445571 229.535265 117.78151 230.699325 117.039325L230.816505 120.023691C229.597763 119.375255 227.847756 118.844004 226.777456 118.687756' fill='#00f'/>
+<path d='M225.961 48.566H199.637C197.437 48.566 195.652 46.781 195.652 44.582V27.645C195.652 25.441 197.437 23.66 199.637 23.66H225.961C228.16 23.66 229.945 25.441 229.945 27.645V44.582C229.945 46.781 228.16 48.566 225.961 48.566Z' fill='#fcc'/>
+<path d='M225.961 48.566H199.637C197.437 48.566 195.652 46.781 195.652 44.582V27.645C195.652 25.441 197.437 23.66 199.637 23.66H225.961C228.16 23.66 229.945 25.441 229.945 27.645V44.582C229.945 46.781 228.16 48.566 225.961 48.566Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M206.0717 36.08318C206.0717 36.61631 205.98701 37.10443 205.81733 37.54287C205.64795 37.9813 205.40889 38.35506 205.10014 38.6738C204.79108 38.98287 204.42233 39.22693 203.98389 39.4013C203.55545 39.57068 203.07233 39.65537 202.5492 39.65537H199.883888V32.515992H202.5492C203.07233 32.515992 203.55545 32.60068 203.98389 32.775055C204.42233 32.94443 204.79108 33.183492 205.10014 33.497555C205.40889 33.8113 205.64795 34.18505 205.81733 34.62349C205.98701 35.06193 206.0717 35.55005 206.0717 36.08318ZM205.08014 36.08318C205.08014 35.64474 205.02045 35.2513 204.90076 34.90755C204.78108 34.5638 204.6117 34.26974 204.39264 34.03068C204.17326 33.7963 203.9092 33.61193 203.59545 33.487555C203.2817 33.362867 202.93295 33.29818 202.5492 33.29818H200.85014V38.87318H202.5492C202.93295 38.87318 203.2817 38.80849 203.59545 38.6838C203.9092 38.55943 204.17326 38.37506 204.39264 38.13599C204.6117 37.89662 204.78108 37.60287 204.90076 37.25912C205.02045 36.91537 205.08014 36.52162 205.08014 36.08318ZM211.8644 33.30318H208.42662V35.73943H211.2069V36.49662H208.42662V38.86818H211.8594V39.65537H207.46037V32.515992H211.8594L211.8644 33.30318ZM217.005 35.16662H214.3397L215.4606 38.06599C215.5353 38.24537 215.605 38.46974 215.6747 38.73881C215.7097 38.60912 215.7447 38.48474 215.7794 38.37506C215.8144 38.25537 215.849 38.15568 215.884 38.07099L217.005 35.16662ZM219.0178 32.515992L216.1631 39.65537H215.1865L212.3319 32.515992H213.079C213.1637 32.515992 213.2334 32.540992 213.2884 32.58568C213.3431 32.63068 213.3831 32.685367 213.4028 32.745055L214.0706 34.46912H217.274L217.9415 32.745055C217.9665 32.680367 218.0065 32.62568 218.0612 32.58068C218.1159 32.535992 218.1856 32.515992 218.2706 32.515992H219.0178ZM226.1462 36.08318C226.1462 36.61631 226.0615 37.10443 225.8918 37.54287C225.7224 37.9813 225.4833 38.35506 225.1746 38.6738C224.8655 38.98287 224.4968 39.22693 224.0583 39.4013C223.6299 39.57068 223.1468 39.65537 222.6237 39.65537H219.9583V32.515992H222.6237C223.1468 32.515992 223.6299 32.60068 224.0583 32.775055C224.4968 32.94443 224.8655 33.183492 225.1746 33.497555C225.4833 33.8113 225.7224 34.18505 225.8918 34.62349C226.0615 35.06193 226.1462 35.55005 226.1462 36.08318ZM225.1546 36.08318C225.1546 35.64474 225.0949 35.2513 224.9752 34.90755S224.6862 34.26974 224.4671 34.03068C224.2477 33.7963 223.9837 33.61193 223.6699 33.487555C223.3562 33.362867 223.0074 33.29818 222.6237 33.29818H220.9246V38.87318H222.6237C223.0074 38.87318 223.3562 38.80849 223.6699 38.6838C223.9837 38.55943 224.2477 38.37506 224.4671 38.13599C224.6862 37.89662 224.8555 37.60287 224.9752 37.25912S225.1546 36.52162 225.1546 36.08318Z'/>
+<path d='M215.066 23.262C216.812 13.375 210.449 12.18 210.234 19.68' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M210.531397 23.26174C210.257947 22.214872 209.543107 20.531276 208.76577 19.386744L211.746231 19.18362C211.13295 20.421901 210.656379 22.187524 210.531397 23.26174'/>
+<path d='M226.777 115.5625C282.457 93.2891 283.641 65.6602 233.668 44.496' stroke='#f00' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M230.343937 43.12888C231.402544 43.34762 233.226756 43.456994 234.597858 43.265595L233.457229 46.031219C232.617386 44.929651 231.250196 43.71872 230.343937 43.12888' fill='#f00'/>
+<path d='M198.82 126.7422C157.2227 143.3828 129.2539 143.8203 88.3711 128.0508' stroke='#808080' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M85.042943 126.741969C86.105443 126.941183 87.929654 127.015399 89.296849 126.804466L88.207006 129.585717C87.347623 128.499778 85.960909 127.31228 85.042943 126.741969' fill='#808080'/>
+<path d='M106.8419 143.073116C107.04815 143.073116 107.24972 143.109053 107.44253 143.180928C107.63534 143.257178 107.80128 143.355616 107.94034 143.485616L107.70722 143.866866C107.67565 143.916241 107.63534 143.943116 107.59503 143.943116C107.57253 143.943116 107.54128 143.934053 107.5144 143.907178C107.47847 143.889366 107.44253 143.862491 107.39784 143.835616C107.35284 143.808741 107.29909 143.781553 107.23628 143.763741C107.17815 143.736866 107.10628 143.727803 107.02097 143.727803C106.87315 143.727803 106.75659 143.772803 106.66253 143.866866C106.56815 143.960928 106.52347 144.099991 106.52347 144.2928V147.01905H107.83722V147.59749H106.52347V149.16249H106.11972C106.07065 149.16249 106.02565 149.14905 105.99878 149.11749C105.96284 149.09062 105.94503 149.05468 105.93597 149.00999L105.752216 147.60655L105.007841 147.51218V147.19405C105.007841 147.13562 105.025653 147.09093 105.057216 147.06405C105.088466 147.03249 105.128778 147.01905 105.178153 147.01905H105.725341V144.23905C105.725341 143.862491 105.8194 143.575303 106.01659 143.373741C106.20503 143.171866 106.48315 143.073116 106.8419 143.073116Z' fill='#808080'/>
+<path d='M111.68018 145.91155H109.19612C109.25018 146.30624 109.38893 146.61562 109.61331 146.83968C109.833 147.05937 110.138 147.17155 110.51893 147.17155C110.70268 147.17155 110.86425 147.1403 111.00768 147.08187C111.15112 147.01905 111.27237 146.92937 111.37081 146.82187C111.47393 146.7053 111.55018 146.5753 111.60425 146.41812C111.65331 146.26593 111.68018 146.0953 111.68018 145.91155ZM112.32612 143.781553L112.10175 144.073116C112.06581 144.122491 112.01675 144.14937 111.94925 144.14937C111.90018 144.14937 111.83737 144.126866 111.7655 144.077491C111.69831 144.032803 111.60862 143.983428 111.5055 143.929678C111.40237 143.875928 111.27675 143.826553 111.12893 143.781553C110.98518 143.732491 110.81487 143.709991 110.61331 143.709991C110.398 143.709991 110.20518 143.745928 110.03018 143.817491C109.8555 143.884991 109.70737 143.992491 109.58175 144.131553C109.45643 144.27499 109.35768 144.45437 109.2905 144.66499C109.21862 144.87593 109.17831 145.12687 109.16925 145.41374H112.20487C112.28112 145.41374 112.3305 145.43624 112.35737 145.47655C112.38425 145.51687 112.39768 145.60218 112.39768 145.7278C112.39768 146.05062 112.34831 146.33749 112.25425 146.58874C112.16018 146.84437 112.0255 147.05499 111.85518 147.2253C111.68925 147.4003 111.48737 147.5303 111.25425 147.61999C111.02581 147.71405 110.77456 147.75905 110.50112 147.75905C110.17362 147.75905 109.87768 147.70062 109.61331 147.58405C109.34862 147.47187 109.12893 147.31499 108.94518 147.10874C108.76143 146.91155 108.62237 146.66937 108.528 146.39593C108.42956 146.12218 108.38018 145.82624 108.38018 145.50812C108.38018 145.1178 108.43393 144.76812 108.54143 144.4678C108.64925 144.16718 108.79706 143.911866 108.99456 143.709991C109.18268 143.503741 109.41581 143.346866 109.67612 143.243741C109.94518 143.135928 110.23206 143.082178 110.54581 143.082178C110.71175 143.082178 110.87768 143.095616 111.04362 143.127178C111.20956 143.154053 111.37081 143.194366 111.53237 143.252491C111.68487 143.310928 111.83268 143.382491 111.97175 143.467803C112.11081 143.557491 112.22737 143.660616 112.32612 143.781553ZM116.02 146.93843L116.1994 147.22999C116.0244 147.39562 115.8182 147.52124 115.585 147.61999C115.3428 147.70968 115.0785 147.75905 114.77784 147.75905C114.52222 147.75905 114.29378 147.72312 114.0919 147.65124C113.89003 147.57968 113.72409 147.4853 113.58534 147.35999C113.44628 147.24343 113.34315 147.09968 113.27128 146.93843C113.19972 146.78155 113.16378 146.61562 113.16378 146.44062C113.16378 146.2478 113.19972 146.08187 113.26222 145.9428C113.33409 145.80843 113.4194 145.69624 113.53128 145.60218C113.64347 145.50812 113.76909 145.43187 113.90815 145.36905C114.05159 145.31062 114.19503 145.25687 114.34753 145.20749C114.49097 145.15843 114.63878 145.11343 114.77784 145.07312C114.9213 145.02812 115.0469 144.97437 115.1591 144.92062C115.2713 144.8578 115.361 144.79062 115.4235 144.7053C115.4953 144.62468 115.5266 144.52155 115.5266 144.39593C115.5266 144.2928 115.5088 144.19874 115.4685 144.109053C115.4325 144.019366 115.3744 143.938741 115.2982 143.871241C115.2219 143.804053 115.1232 143.745928 115.0066 143.709991C114.89 143.664991 114.75565 143.647178 114.59847 143.647178C114.41472 143.647178 114.26222 143.669678 114.14128 143.709991C114.02003 143.750303 113.9169 143.799678 113.82722 143.849053C113.74659 143.898428 113.67034 143.947491 113.61222 143.988116C113.55378 144.028428 113.49565 144.050616 113.44159 144.050616C113.39253 144.050616 113.34753 144.041866 113.31628 144.019366C113.28472 143.996866 113.25347 143.969991 113.23097 143.929678L113.04253 143.624678C113.2219 143.463428 113.44159 143.333428 113.69722 143.225616C113.95284 143.127178 114.23972 143.073116 114.55815 143.073116C114.8363 143.073116 115.0828 143.109053 115.2935 143.185303C115.5044 143.261553 115.6838 143.360303 115.8316 143.494678C115.9797 143.620303 116.0872 143.777178 116.1635 143.952178C116.2397 144.131553 116.2757 144.32437 116.2757 144.53499C116.2757 144.71874 116.2397 144.87593 116.1769 145.00124C116.105 145.13593 116.02 145.24343 115.9078 145.33312C115.7957 145.4228 115.6703 145.49905 115.5313 145.55749C115.3922 145.61562 115.2441 145.67405 115.1007 145.71874C114.9482 145.77249 114.80472 145.81749 114.66597 145.86218C114.5269 145.90249 114.40128 145.95187 114.28909 146.0103C114.17722 146.06843 114.08753 146.13562 114.02472 146.21187C113.95284 146.28812 113.92159 146.38687 113.92159 146.50343C113.92159 146.59749 113.94378 146.6828 113.97972 146.75905C114.02472 146.83968 114.07847 146.91155 114.15909 146.96968C114.23097 147.02812 114.32503 147.07749 114.43253 147.10874C114.54034 147.14468 114.66128 147.16249 114.79597 147.16249C114.9528 147.16249 115.0872 147.14468 115.1994 147.10874C115.3116 147.07749 115.41 147.03718 115.4953 147.00124C115.576 146.95624 115.6435 146.9203 115.7016 146.88905C115.76 146.8578 115.8091 146.83968 115.8541 146.83968C115.9303 146.83968 115.9841 146.87124 116.02 146.93843ZM118.6515 143.073116C118.8578 143.073116 119.0593 143.109053 119.2521 143.180928C119.4449 143.257178 119.6109 143.355616 119.7499 143.485616L119.5168 143.866866C119.4853 143.916241 119.4449 143.943116 119.4046 143.943116C119.3821 143.943116 119.3509 143.934053 119.324 143.907178C119.2881 143.889366 119.2521 143.862491 119.2075 143.835616C119.1625 143.808741 119.1087 143.781553 119.0459 143.763741C118.9878 143.736866 118.9159 143.727803 118.8306 143.727803C118.6828 143.727803 118.5662 143.772803 118.4721 143.866866C118.3778 143.960928 118.3331 144.099991 118.3331 144.2928V147.01905H119.6468V147.59749H118.3331V149.16249H117.9293C117.8803 149.16249 117.8353 149.14905 117.8084 149.11749C117.7724 149.09062 117.7546 149.05468 117.7456 149.00999L117.5618 147.60655L116.8174 147.51218V147.19405C116.8174 147.13562 116.8353 147.09093 116.8668 147.06405C116.8981 147.03249 116.9384 147.01905 116.9878 147.01905H117.5349V144.23905C117.5349 143.862491 117.629 143.575303 117.8262 143.373741C118.0146 143.171866 118.2928 143.073116 118.6515 143.073116Z' fill='#808080'/>
+<path d='M122.7559 143.144991H123.5587V146.5303C123.6975 146.71405 123.8546 146.8578 124.0203 146.9653C124.1862 147.06843 124.3703 147.12218 124.5674 147.12218C124.85 147.12218 125.0606 147.03249 125.2087 146.85312C125.3565 146.67374 125.4284 146.4003 125.4284 146.03718V143.144991H126.2309V146.03718C126.2309 146.21655 126.2578 146.37343 126.3118 146.5078C126.3609 146.64687 126.4328 146.75905 126.5225 146.84874C126.6121 146.93843 126.7153 147.00562 126.8318 147.05499C126.9528 147.09968 127.0784 147.12218 127.2084 147.12218C127.4999 147.12218 127.724 147.02812 127.8812 146.84874C128.0381 146.6603 128.1143 146.39124 128.1143 146.03718V143.144991H128.9168V146.03718C128.9168 146.31062 128.8809 146.55718 128.8137 146.76812C128.7465 146.98312 128.6434 147.16249 128.5178 147.31062C128.3834 147.45843 128.2262 147.56624 128.0424 147.64687C127.854 147.71874 127.639 147.75905 127.4012 147.75905C127.2534 147.75905 127.1053 147.74093 126.9575 147.70499C126.814 147.66937 126.6793 147.61093 126.5493 147.53468S126.3028 147.35999 126.204 147.23874C126.0965 147.1178 126.0159 146.97874 125.9484 146.8128C125.8634 147.10437 125.7287 147.33312 125.5406 147.50343C125.3478 147.67374 125.1009 147.75905 124.7962 147.75905C124.5225 147.75905 124.2806 147.69155 124.0696 147.56155C123.859 147.43155 123.6706 147.26124 123.5046 147.05499L123.4465 147.52124C123.4196 147.63343 123.3478 147.68718 123.2356 147.68718H122.7559V143.144991ZM132.0454 147.75905C131.7092 147.75905 131.4085 147.70499 131.1398 147.59312C130.8751 147.48093 130.6464 147.32405 130.4582 147.12218C130.2698 146.9203 130.1264 146.67374 130.0276 146.38249C129.9245 146.0953 129.8751 145.77249 129.8751 145.41843C129.8751 145.05968 129.9245 144.73687 130.0276 144.44968C130.1264 144.1628 130.2698 143.916241 130.4582 143.714366C130.6464 143.512803 130.8751 143.355616 131.1398 143.243741C131.4085 143.135928 131.7092 143.082178 132.0454 143.082178C132.3773 143.082178 132.6776 143.135928 132.9423 143.243741C133.2067 143.355616 133.4354 143.512803 133.6239 143.714366C133.812 143.916241 133.9554 144.1628 134.0542 144.44968C134.1573 144.73687 134.2067 145.05968 134.2067 145.41843C134.2067 145.77249 134.1573 146.0953 134.0542 146.38249C133.9554 146.67374 133.812 146.9203 133.6239 147.12218C133.4354 147.32405 133.2067 147.48093 132.9423 147.59312C132.6776 147.70499 132.3773 147.75905 132.0454 147.75905ZM132.0454 143.705616C131.5926 143.705616 131.2517 143.853428 131.032 144.15843C130.8079 144.45437 130.6957 144.87593 130.6957 145.41374C130.6957 145.6828 130.7226 145.92499 130.781 146.1403C130.8348 146.35093 130.9154 146.5303 131.032 146.67843C131.1398 146.82624 131.2832 146.93843 131.4535 147.01468C131.6195 147.09093 131.8167 147.13124 132.0454 147.13124C132.4939 147.13124 132.8301 146.97874 133.0498 146.67843C133.2695 146.3778 133.3817 145.95655 133.3817 145.41374C133.3817 144.87593 133.2695 144.45437 133.0498 144.15843C132.8301 143.853428 132.4939 143.705616 132.0454 143.705616ZM138.174 146.60655V144.41405C138.0081 144.19437 137.8287 144.028428 137.6315 143.907178C137.4387 143.786241 137.21 143.727803 136.9456 143.727803C136.7615 143.727803 136.6003 143.759366 136.4568 143.822178C136.3134 143.884991 136.1921 143.983428 136.0934 144.122491C135.995 144.25687 135.9187 144.42749 135.8693 144.64249C135.8199 144.84874 135.7931 145.10437 135.7931 145.4003C135.7931 145.96093 135.9053 146.39124 136.134 146.69187C136.3624 146.99218 136.6853 147.14468 137.1068 147.14468C137.3221 147.14468 137.515 147.10437 137.69 147.02812C137.8646 146.94749 138.0262 146.80843 138.174 146.60655ZM138.9721 149.74968H138.174V147.23437C138.0171 147.4003 137.8421 147.5303 137.6406 147.62905C137.4431 147.71874 137.2056 147.7678 136.9274 147.7678C136.6228 147.7678 136.349 147.70968 136.1071 147.58405C135.8603 147.46749 135.654 147.29718 135.4881 147.08624C135.3225 146.87562 135.1921 146.62437 135.1025 146.33749C135.0128 146.04624 134.9681 145.73655 134.9681 145.4003C134.9681 145.02374 135.0084 144.69187 135.089 144.40062C135.1699 144.109053 135.2865 143.866866 135.4343 143.674053C135.5825 143.481241 135.7662 143.333428 135.9768 143.234678C136.1878 143.131553 136.4253 143.082178 136.6853 143.082178C137.0128 143.082178 137.2996 143.154053 137.5462 143.297491C137.7931 143.440928 138.0171 143.629366 138.21 143.862491L138.2818 143.310928C138.3131 143.198741 138.385 143.144991 138.4968 143.144991H138.9721V149.74968ZM143.2758 145.91155H140.7917C140.8458 146.30624 140.9846 146.61562 141.2089 146.83968C141.4286 147.05937 141.7336 147.17155 142.1146 147.17155C142.2983 147.17155 142.4599 147.1403 142.6033 147.08187C142.7467 147.01905 142.868 146.92937 142.9664 146.82187C143.0696 146.7053 143.1458 146.5753 143.1999 146.41812C143.2489 146.26593 143.2758 146.0953 143.2758 145.91155ZM143.9217 143.781553L143.6974 144.073116C143.6614 144.122491 143.6124 144.14937 143.5449 144.14937C143.4958 144.14937 143.433 144.126866 143.3611 144.077491C143.2939 144.032803 143.2042 143.983428 143.1011 143.929678S142.8724 143.826553 142.7246 143.781553C142.5808 143.732491 142.4105 143.709991 142.2089 143.709991C141.9936 143.709991 141.8008 143.745928 141.6258 143.817491C141.4511 143.884991 141.303 143.992491 141.1774 144.131553C141.0521 144.27499 140.9533 144.45437 140.8861 144.66499C140.8142 144.87593 140.7739 145.12687 140.7649 145.41374H143.8005C143.8767 145.41374 143.9261 145.43624 143.953 145.47655C143.9799 145.51687 143.9933 145.60218 143.9933 145.7278C143.9933 146.05062 143.9439 146.33749 143.8499 146.58874C143.7558 146.84437 143.6211 147.05499 143.4508 147.2253C143.2849 147.4003 143.083 147.5303 142.8499 147.61999C142.6214 147.71405 142.3702 147.75905 142.0967 147.75905C141.7692 147.75905 141.4733 147.70062 141.2089 147.58405C140.9442 147.47187 140.7246 147.31499 140.5408 147.10874C140.3571 146.91155 140.218 146.66937 140.1236 146.39593C140.0252 146.12218 139.9758 145.82624 139.9758 145.50812C139.9758 145.1178 140.0296 144.76812 140.1371 144.4678C140.2449 144.16718 140.3927 143.911866 140.5902 143.709991C140.7783 143.503741 141.0114 143.346866 141.2717 143.243741C141.5408 143.135928 141.8277 143.082178 142.1414 143.082178C142.3074 143.082178 142.4733 143.095616 142.6392 143.127178C142.8052 143.154053 142.9664 143.194366 143.128 143.252491C143.2805 143.310928 143.4283 143.382491 143.5674 143.467803C143.7064 143.557491 143.823 143.660616 143.9217 143.781553Z' fill='#808080'/>
+<path d='M150.2049 146.60655V144.41405C150.0389 144.19437 149.8596 144.028428 149.6624 143.907178C149.4696 143.786241 149.2408 143.727803 148.9764 143.727803C148.7924 143.727803 148.6311 143.759366 148.4877 143.822178C148.3442 143.884991 148.223 143.983428 148.1242 144.122491C148.0258 144.25687 147.9496 144.42749 147.9002 144.64249C147.8508 144.84874 147.8239 145.10437 147.8239 145.4003C147.8239 145.96093 147.9361 146.39124 148.1649 146.69187C148.3933 146.99218 148.7161 147.14468 149.1377 147.14468C149.353 147.14468 149.5458 147.10437 149.7208 147.02812C149.8955 146.94749 150.0571 146.80843 150.2049 146.60655ZM151.003 149.74968H150.2049V147.23437C150.048 147.4003 149.873 147.5303 149.6714 147.62905C149.4739 147.71874 149.2364 147.7678 148.9583 147.7678C148.6536 147.7678 148.3799 147.70968 148.138 147.58405C147.8911 147.46749 147.6849 147.29718 147.5189 147.08624C147.3533 146.87562 147.223 146.62437 147.1333 146.33749C147.0436 146.04624 146.9989 145.73655 146.9989 145.4003C146.9989 145.02374 147.0392 144.69187 147.1199 144.40062C147.2008 144.109053 147.3174 143.866866 147.4652 143.674053C147.6133 143.481241 147.7971 143.333428 148.0077 143.234678C148.2186 143.131553 148.4561 143.082178 148.7161 143.082178C149.0436 143.082178 149.3305 143.154053 149.5771 143.297491C149.8239 143.440928 150.048 143.629366 150.2408 143.862491L150.3127 143.310928C150.3439 143.198741 150.4158 143.144991 150.5277 143.144991H151.003V149.74968ZM153.1098 147.68718H152.3117V143.144991H153.1098V147.68718ZM153.2801 149.11312C153.2801 149.18937 153.2667 149.26562 153.2307 149.3328C153.2039 149.40468 153.1592 149.46718 153.1051 149.52124C153.0557 149.5703 152.9932 149.61093 152.9257 149.64218C152.8542 149.67343 152.7779 149.68718 152.7017 149.68718C152.6254 149.68718 152.5492 149.67343 152.4864 149.64218C152.4148 149.61093 152.3564 149.5703 152.307 149.52124C152.2576 149.46718 152.2173 149.40468 152.186 149.3328C152.1545 149.26562 152.141 149.18937 152.141 149.11312S152.1545 148.96499 152.186 148.89343C152.2173 148.83062 152.2576 148.7678 152.307 148.71405C152.3564 148.66468 152.4148 148.62437 152.4864 148.5928C152.5492 148.56155 152.6254 148.54812 152.7017 148.54812C152.7779 148.54812 152.8542 148.56155 152.9257 148.5928C152.9932 148.62437 153.0557 148.66468 153.1051 148.71405C153.1592 148.7678 153.2039 148.83062 153.2307 148.89343C153.2667 148.96499 153.2801 149.03687 153.2801 149.11312ZM157.0642 146.93843L157.2435 147.22999C157.0685 147.39562 156.8623 147.52124 156.6292 147.61999C156.387 147.70968 156.1226 147.75905 155.822 147.75905C155.5664 147.75905 155.3379 147.72312 155.136 147.65124C154.9342 147.57968 154.7682 147.4853 154.6295 147.35999C154.4904 147.24343 154.3873 147.09968 154.3154 146.93843C154.2439 146.78155 154.2079 146.61562 154.2079 146.44062C154.2079 146.2478 154.2439 146.08187 154.3064 145.9428C154.3782 145.80843 154.4635 145.69624 154.5754 145.60218C154.6876 145.50812 154.8132 145.43187 154.9523 145.36905C155.0957 145.31062 155.2392 145.25687 155.3917 145.20749C155.5351 145.15843 155.6829 145.11343 155.822 145.07312C155.9654 145.02812 156.091 144.97437 156.2032 144.92062C156.3154 144.8578 156.4051 144.79062 156.4676 144.7053C156.5395 144.62468 156.5707 144.52155 156.5707 144.39593C156.5707 144.2928 156.5529 144.19874 156.5126 144.109053C156.4767 144.019366 156.4185 143.938741 156.3423 143.871241C156.266 143.804053 156.1673 143.745928 156.0507 143.709991C155.9342 143.664991 155.7998 143.647178 155.6426 143.647178C155.4589 143.647178 155.3064 143.669678 155.1854 143.709991C155.0642 143.750303 154.961 143.799678 154.8714 143.849053C154.7907 143.898428 154.7145 143.947491 154.6564 143.988116C154.5979 144.028428 154.5398 144.050616 154.4857 144.050616C154.4367 144.050616 154.3917 144.041866 154.3604 144.019366C154.3289 143.996866 154.2976 143.969991 154.2751 143.929678L154.0867 143.624678C154.266 143.463428 154.4857 143.333428 154.7414 143.225616C154.997 143.127178 155.2839 143.073116 155.6023 143.073116C155.8804 143.073116 156.127 143.109053 156.3376 143.185303C156.5485 143.261553 156.7279 143.360303 156.8757 143.494678C157.0239 143.620303 157.1314 143.777178 157.2076 143.952178C157.2839 144.131553 157.3198 144.32437 157.3198 144.53499C157.3198 144.71874 157.2839 144.87593 157.221 145.00124C157.1492 145.13593 157.0642 145.24343 156.952 145.33312C156.8398 145.4228 156.7145 145.49905 156.5754 145.55749C156.4364 145.61562 156.2882 145.67405 156.1448 145.71874C155.9923 145.77249 155.8489 145.81749 155.7101 145.86218C155.571 145.90249 155.4454 145.95187 155.3332 146.0103C155.2214 146.06843 155.1317 146.13562 155.0689 146.21187C154.997 146.28812 154.9657 146.38687 154.9657 146.50343C154.9657 146.59749 154.9879 146.6828 155.0239 146.75905C155.0689 146.83968 155.1226 146.91155 155.2032 146.96968C155.2751 147.02812 155.3692 147.07749 155.4767 147.10874C155.5845 147.14468 155.7054 147.16249 155.8401 147.16249C155.997 147.16249 156.1314 147.14468 156.2435 147.10874C156.3557 147.07749 156.4542 147.03718 156.5395 147.00124C156.6201 146.95624 156.6876 146.9203 156.7457 146.88905C156.8042 146.8578 156.8532 146.83968 156.8982 146.83968C156.9745 146.83968 157.0282 146.87124 157.0642 146.93843ZM160.7628 145.18968V144.24812C160.6732 144.15374 160.5835 144.068741 160.4847 143.992491C160.395 143.916241 160.2963 143.853428 160.1888 143.799678C160.09 143.745928 159.9782 143.705616 159.8613 143.674053C159.7447 143.647178 159.6147 143.633741 159.4757 143.633741C159.3725 143.633741 159.2741 143.647178 159.1844 143.674053C159.09 143.696553 159.0141 143.736866 158.9422 143.790616C158.8794 143.849053 158.8257 143.920616 158.7853 144.005928C158.745 144.091241 158.7269 144.19437 158.7269 144.3153C158.7269 144.44093 158.7628 144.5528 158.8347 144.65593C158.911 144.75905 159.0275 144.84437 159.1935 144.92062C159.3547 144.99687 159.5653 145.05499 159.821 145.09999C160.0813 145.14937 160.395 145.17624 160.7628 145.18968ZM158.1844 147.04593L158.3278 146.7903C158.3547 146.74999 158.3863 146.71405 158.4266 146.68718C158.4669 146.65593 158.5119 146.64249 158.5657 146.64249C158.6328 146.64249 158.7047 146.66937 158.7719 146.71405C158.8435 146.76812 158.9288 146.82187 159.0228 146.88468C159.1216 146.9428 159.2382 147.00124 159.3725 147.04593C159.5028 147.09968 159.6685 147.12218 159.866 147.12218C160.1572 147.12218 160.3816 147.03249 160.5341 146.84874C160.6866 146.66937 160.7628 146.40468 160.7628 146.05062V145.69624C160.2469 145.6828 159.8075 145.63812 159.4535 145.55749C159.0991 145.47218 158.8078 145.36905 158.5878 145.23905C158.3682 145.10905 158.2069 144.96562 158.1082 144.79499C158.0094 144.63374 157.9603 144.45874 157.9603 144.27937C157.9603 144.073116 157.9916 143.893741 158.0635 143.745928C158.1263 143.593428 158.2203 143.467803 158.3325 143.369053C158.4491 143.270616 158.5835 143.198741 158.7403 143.144991C158.8975 143.100303 159.0632 143.073116 159.2382 143.073116S159.57 143.09124 159.7135 143.118116C159.8525 143.154053 159.9869 143.198741 160.1125 143.252491C160.2382 143.315303 160.3591 143.387178 160.4713 143.467803C160.5835 143.557491 160.7 143.651553 160.821 143.763741L160.9107 143.333428C160.9332 143.257178 160.9691 143.207803 161.0094 143.180928C161.0497 143.158428 161.1125 143.144991 161.1888 143.144991H161.5428V146.05062C161.5428 146.30624 161.5069 146.53937 161.4397 146.74999C161.3725 146.96093 161.2694 147.14468 161.1347 147.29249C161.0003 147.44062 160.8344 147.55718 160.6372 147.64249C160.4397 147.72749 160.2157 147.7678 159.96 147.7678C159.606 147.7678 159.2875 147.70968 158.996 147.58843C158.7047 147.46749 158.4357 147.28812 158.1844 147.04593ZM163.56 144.23905V146.43624C163.7257 146.65593 163.9007 146.82187 164.0978 146.9428C164.2863 147.06405 164.515 147.12218 164.775 147.12218C165.1472 147.12218 165.4341 146.99218 165.6403 146.73218C165.8378 146.46749 165.941 146.05968 165.941 145.50343C165.941 144.90718 165.8288 144.45437 165.6 144.15374C165.3713 143.853428 165.0441 143.700928 164.6182 143.700928C164.4072 143.700928 164.2144 143.741241 164.0441 143.822178C163.8647 143.902803 163.7078 144.041866 163.56 144.23905ZM163.56 147.03249V149.74968H162.7572V143.144991H163.2728C163.385 143.144991 163.4569 143.203428 163.4791 143.315303L163.5194 143.727803C163.6719 143.521553 163.8513 143.360303 164.0532 143.252491C164.2594 143.135928 164.5103 143.082178 164.811 143.082178C165.1113 143.082178 165.3847 143.140616 165.6269 143.261553C165.8691 143.378116 166.0753 143.544053 166.2413 143.754678C166.4116 143.969991 166.5416 144.22999 166.6313 144.53062C166.721 144.83093 166.766 145.16718 166.766 145.53499C166.766 145.8803 166.7257 146.18968 166.6447 146.46312C166.5685 146.73655 166.4519 146.97437 166.3041 147.16249C166.156 147.35999 165.9722 147.50343 165.7569 147.60655C165.5463 147.70968 165.3041 147.75905 165.0397 147.75905C164.7257 147.75905 164.4478 147.69155 164.2057 147.56155C163.9678 147.43155 163.7528 147.25218 163.56 147.03249ZM168.6034 149.74968H167.8053V143.144991H168.6034V149.74968ZM172.9344 145.91155H170.4503C170.5044 146.30624 170.6432 146.61562 170.8675 146.83968C171.0872 147.05937 171.3922 147.17155 171.7732 147.17155C171.9569 147.17155 172.1185 147.1403 172.2619 147.08187C172.4053 147.01905 172.5266 146.92937 172.625 146.82187C172.7282 146.7053 172.8044 146.5753 172.8585 146.41812C172.9075 146.26593 172.9344 146.0953 172.9344 145.91155ZM173.5803 143.781553L173.356 144.073116C173.32 144.122491 173.271 144.14937 173.2035 144.14937C173.1544 144.14937 173.0916 144.126866 173.0197 144.077491C172.9525 144.032803 172.8628 143.983428 172.7597 143.929678S172.531 143.826553 172.3832 143.781553C172.2394 143.732491 172.0691 143.709991 171.8675 143.709991C171.6522 143.709991 171.4594 143.745928 171.2844 143.817491C171.1097 143.884991 170.9616 143.992491 170.836 144.131553C170.7107 144.27499 170.6119 144.45437 170.5447 144.66499C170.4728 144.87593 170.4325 145.12687 170.4235 145.41374H173.4591C173.5353 145.41374 173.5847 145.43624 173.6116 145.47655C173.6385 145.51687 173.6519 145.60218 173.6519 145.7278C173.6519 146.05062 173.6025 146.33749 173.5085 146.58874C173.4144 146.84437 173.2797 147.05499 173.1094 147.2253C172.9435 147.4003 172.7416 147.5303 172.5085 147.61999C172.28 147.71405 172.0288 147.75905 171.7553 147.75905C171.4278 147.75905 171.1319 147.70062 170.8675 147.58405C170.6028 147.47187 170.3832 147.31499 170.1994 147.10874C170.0157 146.91155 169.8766 146.66937 169.7822 146.39593C169.6838 146.12218 169.6344 145.82624 169.6344 145.50812C169.6344 145.1178 169.6882 144.76812 169.7957 144.4678C169.9035 144.16718 170.0513 143.911866 170.2488 143.709991C170.4369 143.503741 170.67 143.346866 170.9303 143.243741C171.1994 143.135928 171.4863 143.082178 171.8 143.082178C171.966 143.082178 172.1319 143.095616 172.2978 143.127178C172.4638 143.154053 172.625 143.194366 172.7866 143.252491C172.9391 143.310928 173.0869 143.382491 173.226 143.467803C173.365 143.557491 173.4816 143.660616 173.5803 143.781553ZM177.588 146.60655V144.41405C177.4221 144.19437 177.2427 144.028428 177.0455 143.907178C176.8527 143.786241 176.6239 143.727803 176.3596 143.727803C176.1755 143.727803 176.0142 143.759366 175.8708 143.822178C175.7274 143.884991 175.6061 143.983428 175.5074 144.122491C175.4089 144.25687 175.3327 144.42749 175.2833 144.64249C175.2339 144.84874 175.2071 145.10437 175.2071 145.4003C175.2071 145.96093 175.3192 146.39124 175.548 146.69187C175.7764 146.99218 176.0992 147.14468 176.5208 147.14468C176.7361 147.14468 176.9289 147.10437 177.1039 147.02812C177.2786 146.94749 177.4402 146.80843 177.588 146.60655ZM178.3861 149.74968H177.588V147.23437C177.4311 147.4003 177.2561 147.5303 177.0546 147.62905C176.8571 147.71874 176.6196 147.7678 176.3414 147.7678C176.0367 147.7678 175.763 147.70968 175.5211 147.58405C175.2742 147.46749 175.068 147.29718 174.9021 147.08624C174.7364 146.87562 174.6061 146.62437 174.5164 146.33749C174.4267 146.04624 174.3821 145.73655 174.3821 145.4003C174.3821 145.02374 174.4224 144.69187 174.503 144.40062C174.5839 144.109053 174.7005 143.866866 174.8483 143.674053C174.9964 143.481241 175.1802 143.333428 175.3908 143.234678C175.6017 143.131553 175.8392 143.082178 176.0992 143.082178C176.4267 143.082178 176.7136 143.154053 176.9602 143.297491C177.2071 143.440928 177.4311 143.629366 177.6239 143.862491L177.6958 143.310928C177.7271 143.198741 177.7989 143.144991 177.9108 143.144991H178.3861V149.74968Z' fill='#808080'/>
+<path d='M195.254 29.977C157.2422 16.668 129.4141 16.281 91.9961 28.816' stroke='#808080' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M88.609357 29.97656C89.55076 29.441405 90.992168 28.320308 91.898424 27.273433L92.863268 30.101556C91.507799 29.828118 89.679669 29.820307 88.609357 29.97656' fill='#808080'/>
+<path d='M106.8419 9.630157C107.04815 9.630157 107.24972 9.666095 107.44253 9.73797C107.63534 9.81422 107.80128 9.912657 107.94034 10.042657L107.70722 10.423907C107.67565 10.473282 107.63534 10.500157 107.59503 10.500157C107.57253 10.500157 107.54128 10.491095 107.5144 10.46422C107.47847 10.446407 107.44253 10.419532 107.39784 10.392657C107.35284 10.365782 107.29909 10.338595 107.23628 10.320782C107.17815 10.293907 107.10628 10.284845 107.02097 10.284845C106.87315 10.284845 106.75659 10.329845 106.66253 10.423907C106.56815 10.51797 106.52347 10.657032 106.52347 10.84984V13.57609H107.83722V14.15453H106.52347V15.71953H106.11972C106.07065 15.71953 106.02565 15.70609 105.99878 15.67453C105.96284 15.64766 105.94503 15.61172 105.93597 15.56703L105.752216 14.16359L105.007841 14.06922V13.75109C105.007841 13.69266 105.025653 13.64797 105.057216 13.62109C105.088466 13.58953 105.128778 13.57609 105.178153 13.57609H105.725341V10.79609C105.725341 10.419532 105.8194 10.132345 106.01659 9.930782C106.20503 9.728907 106.48315 9.630157 106.8419 9.630157Z' fill='#808080'/>
+<path d='M111.68018 12.46859H109.19612C109.25018 12.86328 109.38893 13.17266 109.61331 13.39672C109.833 13.61641 110.138 13.72859 110.51893 13.72859C110.70268 13.72859 110.86425 13.69734 111.00768 13.63891C111.15112 13.57609 111.27237 13.48641 111.37081 13.37891C111.47393 13.26234 111.55018 13.13234 111.60425 12.97516C111.65331 12.82297 111.68018 12.65234 111.68018 12.46859ZM112.32612 10.338595L112.10175 10.630157C112.06581 10.679532 112.01675 10.70641 111.94925 10.70641C111.90018 10.70641 111.83737 10.683907 111.7655 10.634532C111.69831 10.589845 111.60862 10.54047 111.5055 10.48672C111.40237 10.43297 111.27675 10.383595 111.12893 10.338595C110.98518 10.289532 110.81487 10.267032 110.61331 10.267032C110.398 10.267032 110.20518 10.30297 110.03018 10.374532C109.8555 10.442032 109.70737 10.549532 109.58175 10.688595C109.45643 10.83203 109.35768 11.01141 109.2905 11.22203C109.21862 11.43297 109.17831 11.68391 109.16925 11.97078H112.20487C112.28112 11.97078 112.3305 11.99328 112.35737 12.03359C112.38425 12.07391 112.39768 12.15922 112.39768 12.28484C112.39768 12.60766 112.34831 12.89453 112.25425 13.14578C112.16018 13.40141 112.0255 13.61203 111.85518 13.78234C111.68925 13.95734 111.48737 14.08734 111.25425 14.17703C111.02581 14.27109 110.77456 14.31609 110.50112 14.31609C110.17362 14.31609 109.87768 14.25766 109.61331 14.1411C109.34862 14.02891 109.12893 13.87203 108.94518 13.66578C108.76143 13.46859 108.62237 13.22641 108.528 12.95297C108.42956 12.67922 108.38018 12.38328 108.38018 12.06516C108.38018 11.67484 108.43393 11.32516 108.54143 11.02484C108.64925 10.72422 108.79706 10.468907 108.99456 10.267032C109.18268 10.060782 109.41581 9.903907 109.67612 9.800782C109.94518 9.69297 110.23206 9.63922 110.54581 9.63922C110.71175 9.63922 110.87768 9.652657 111.04362 9.68422C111.20956 9.711095 111.37081 9.751407 111.53237 9.809532C111.68487 9.86797 111.83268 9.939532 111.97175 10.024845C112.11081 10.114532 112.22737 10.217657 112.32612 10.338595ZM116.02 13.49547L116.1994 13.78703C116.0244 13.95266 115.8182 14.07828 115.585 14.17703C115.3428 14.26672 115.0785 14.31609 114.77784 14.31609C114.52222 14.31609 114.29378 14.28016 114.0919 14.20828C113.89003 14.13672 113.72409 14.04234 113.58534 13.91703C113.44628 13.80047 113.34315 13.65672 113.27128 13.49547C113.19972 13.33859 113.16378 13.17266 113.16378 12.99766C113.16378 12.80484 113.19972 12.63891 113.26222 12.49984C113.33409 12.36547 113.4194 12.25328 113.53128 12.15922C113.64347 12.06516 113.76909 11.98891 113.90815 11.92609C114.05159 11.86766 114.19503 11.81391 114.34753 11.76453C114.49097 11.71547 114.63878 11.67047 114.77784 11.63016C114.9213 11.58516 115.0469 11.53141 115.1591 11.47766C115.2713 11.41484 115.361 11.34766 115.4235 11.26234C115.4953 11.18172 115.5266 11.07859 115.5266 10.95297C115.5266 10.84984 115.5088 10.75578 115.4685 10.666095C115.4325 10.576407 115.3744 10.495782 115.2982 10.428282C115.2219 10.361095 115.1232 10.30297 115.0066 10.267032C114.89 10.222032 114.75565 10.20422 114.59847 10.20422C114.41472 10.20422 114.26222 10.22672 114.14128 10.267032C114.02003 10.307345 113.9169 10.35672 113.82722 10.406095C113.74659 10.45547 113.67034 10.504532 113.61222 10.545157C113.55378 10.58547 113.49565 10.607657 113.44159 10.607657C113.39253 10.607657 113.34753 10.598907 113.31628 10.576407C113.28472 10.553907 113.25347 10.527032 113.23097 10.48672L113.04253 10.18172C113.2219 10.02047 113.44159 9.89047 113.69722 9.782657C113.95284 9.68422 114.23972 9.630157 114.55815 9.630157C114.8363 9.630157 115.0828 9.666095 115.2935 9.742345C115.5044 9.818595 115.6838 9.917345 115.8316 10.05172C115.9797 10.177345 116.0872 10.33422 116.1635 10.50922C116.2397 10.688595 116.2757 10.88141 116.2757 11.09203C116.2757 11.27578 116.2397 11.43297 116.1769 11.55828C116.105 11.69297 116.02 11.80047 115.9078 11.89016C115.7957 11.97984 115.6703 12.05609 115.5313 12.11453C115.3922 12.17266 115.2441 12.23109 115.1007 12.27578C114.9482 12.32953 114.80472 12.37453 114.66597 12.41922C114.5269 12.45953 114.40128 12.50891 114.28909 12.56734C114.17722 12.62547 114.08753 12.69266 114.02472 12.76891C113.95284 12.84516 113.92159 12.94391 113.92159 13.06047C113.92159 13.15453 113.94378 13.23984 113.97972 13.31609C114.02472 13.39672 114.07847 13.46859 114.15909 13.52672C114.23097 13.58516 114.32503 13.63453 114.43253 13.66578C114.54034 13.70172 114.66128 13.71953 114.79597 13.71953C114.9528 13.71953 115.0872 13.70172 115.1994 13.66578C115.3116 13.63453 115.41 13.59422 115.4953 13.55828C115.576 13.51328 115.6435 13.47734 115.7016 13.44609C115.76 13.41484 115.8091 13.39672 115.8541 13.39672C115.9303 13.39672 115.9841 13.42828 116.02 13.49547ZM118.6515 9.630157C118.8578 9.630157 119.0593 9.666095 119.2521 9.73797C119.4449 9.81422 119.6109 9.912657 119.7499 10.042657L119.5168 10.423907C119.4853 10.473282 119.4449 10.500157 119.4046 10.500157C119.3821 10.500157 119.3509 10.491095 119.324 10.46422C119.2881 10.446407 119.2521 10.419532 119.2075 10.392657C119.1625 10.365782 119.1087 10.338595 119.0459 10.320782C118.9878 10.293907 118.9159 10.284845 118.8306 10.284845C118.6828 10.284845 118.5662 10.329845 118.4721 10.423907C118.3778 10.51797 118.3331 10.657032 118.3331 10.84984V13.57609H119.6468V14.15453H118.3331V15.71953H117.9293C117.8803 15.71953 117.8353 15.70609 117.8084 15.67453C117.7724 15.64766 117.7546 15.61172 117.7456 15.56703L117.5618 14.16359L116.8174 14.06922V13.75109C116.8174 13.69266 116.8353 13.64797 116.8668 13.62109C116.8981 13.58953 116.9384 13.57609 116.9878 13.57609H117.5349V10.79609C117.5349 10.419532 117.629 10.132345 117.8262 9.930782C118.0146 9.728907 118.2928 9.630157 118.6515 9.630157Z' fill='#808080'/>
+<path d='M122.7559 9.702032H123.5587V13.08734C123.6975 13.27109 123.8546 13.41484 124.0203 13.52234C124.1862 13.62547 124.3703 13.67922 124.5674 13.67922C124.85 13.67922 125.0606 13.58953 125.2087 13.41016C125.3565 13.23078 125.4284 12.95734 125.4284 12.59422V9.702032H126.2309V12.59422C126.2309 12.77359 126.2578 12.93047 126.3118 13.06484C126.3609 13.20391 126.4328 13.31609 126.5225 13.40578C126.6121 13.49547 126.7153 13.56266 126.8318 13.61203C126.9528 13.65672 127.0784 13.67922 127.2084 13.67922C127.4999 13.67922 127.724 13.58516 127.8812 13.40578C128.0381 13.21734 128.1143 12.94828 128.1143 12.59422V9.702032H128.9168V12.59422C128.9168 12.86766 128.8809 13.11422 128.8137 13.32516C128.7465 13.54016 128.6434 13.71953 128.5178 13.86766C128.3834 14.01547 128.2262 14.12328 128.0424 14.20391C127.854 14.27578 127.639 14.31609 127.4012 14.31609C127.2534 14.31609 127.1053 14.29797 126.9575 14.26203C126.814 14.22641 126.6793 14.16797 126.5493 14.09172S126.3028 13.91703 126.204 13.79578C126.0965 13.67484 126.0159 13.53578 125.9484 13.36984C125.8634 13.66141 125.7287 13.89016 125.5406 14.06047C125.3478 14.23078 125.1009 14.31609 124.7962 14.31609C124.5225 14.31609 124.2806 14.24859 124.0696 14.11859C123.859 13.98859 123.6706 13.81828 123.5046 13.61203L123.4465 14.07828C123.4196 14.19047 123.3478 14.24422 123.2356 14.24422H122.7559V9.702032ZM132.0454 14.31609C131.7092 14.31609 131.4085 14.26203 131.1398 14.15016C130.8751 14.03797 130.6464 13.88109 130.4582 13.67922C130.2698 13.47734 130.1264 13.23078 130.0276 12.93953C129.9245 12.65234 129.8751 12.32953 129.8751 11.97547C129.8751 11.61672 129.9245 11.29391 130.0276 11.00672C130.1264 10.71984 130.2698 10.473282 130.4582 10.271407C130.6464 10.069845 130.8751 9.912657 131.1398 9.800782C131.4085 9.69297 131.7092 9.63922 132.0454 9.63922C132.3773 9.63922 132.6776 9.69297 132.9423 9.800782C133.2067 9.912657 133.4354 10.069845 133.6239 10.271407C133.812 10.473282 133.9554 10.71984 134.0542 11.00672C134.1573 11.29391 134.2067 11.61672 134.2067 11.97547C134.2067 12.32953 134.1573 12.65234 134.0542 12.93953C133.9554 13.23078 133.812 13.47734 133.6239 13.67922C133.4354 13.88109 133.2067 14.03797 132.9423 14.15016C132.6776 14.26203 132.3773 14.31609 132.0454 14.31609ZM132.0454 10.262657C131.5926 10.262657 131.2517 10.41047 131.032 10.71547C130.8079 11.01141 130.6957 11.43297 130.6957 11.97078C130.6957 12.23984 130.7226 12.48203 130.781 12.69734C130.8348 12.90797 130.9154 13.08734 131.032 13.23547C131.1398 13.38328 131.2832 13.49547 131.4535 13.57172C131.6195 13.64797 131.8167 13.68828 132.0454 13.68828C132.4939 13.68828 132.8301 13.53578 133.0498 13.23547C133.2695 12.93484 133.3817 12.51359 133.3817 11.97078C133.3817 11.43297 133.2695 11.01141 133.0498 10.71547C132.8301 10.41047 132.4939 10.262657 132.0454 10.262657ZM138.174 13.16359V10.97109C138.0081 10.75141 137.8287 10.58547 137.6315 10.46422C137.4387 10.343282 137.21 10.284845 136.9456 10.284845C136.7615 10.284845 136.6003 10.316407 136.4568 10.37922C136.3134 10.442032 136.1921 10.54047 136.0934 10.679532C135.995 10.81391 135.9187 10.98453 135.8693 11.19953C135.8199 11.40578 135.7931 11.66141 135.7931 11.95734C135.7931 12.51797 135.9053 12.94828 136.134 13.24891C136.3624 13.54922 136.6853 13.70172 137.1068 13.70172C137.3221 13.70172 137.515 13.66141 137.69 13.58516C137.8646 13.50453 138.0262 13.36547 138.174 13.16359ZM138.9721 16.30672H138.174V13.79141C138.0171 13.95734 137.8421 14.08734 137.6406 14.18609C137.4431 14.27578 137.2056 14.32484 136.9274 14.32484C136.6228 14.32484 136.349 14.26672 136.1071 14.1411C135.8603 14.02453 135.654 13.85422 135.4881 13.64328C135.3225 13.43266 135.1921 13.18141 135.1025 12.89453C135.0128 12.60328 134.9681 12.29359 134.9681 11.95734C134.9681 11.58078 135.0084 11.24891 135.089 10.95766C135.1699 10.666095 135.2865 10.423907 135.4343 10.231095C135.5825 10.038282 135.7662 9.89047 135.9768 9.79172C136.1878 9.688595 136.4253 9.63922 136.6853 9.63922C137.0128 9.63922 137.2996 9.711095 137.5462 9.854532C137.7931 9.99797 138.0171 10.186407 138.21 10.419532L138.2818 9.86797C138.3131 9.755782 138.385 9.702032 138.4968 9.702032H138.9721V16.30672Z' fill='#808080'/>
+<path d='M143.2596 12.46859H140.7755C140.8296 12.86328 140.9683 13.17266 141.1927 13.39672C141.4124 13.61641 141.7174 13.72859 142.0983 13.72859C142.2821 13.72859 142.4436 13.69734 142.5871 13.63891C142.7305 13.57609 142.8517 13.48641 142.9502 13.37891C143.0533 13.26234 143.1296 13.13234 143.1836 12.97516C143.2327 12.82297 143.2596 12.65234 143.2596 12.46859ZM143.9055 10.338595L143.6811 10.630157C143.6452 10.679532 143.5961 10.70641 143.5286 10.70641C143.4796 10.70641 143.4167 10.683907 143.3449 10.634532C143.2777 10.589845 143.188 10.54047 143.0849 10.48672C142.9817 10.43297 142.8561 10.383595 142.7083 10.338595C142.5646 10.289532 142.3942 10.267032 142.1927 10.267032C141.9774 10.267032 141.7846 10.30297 141.6096 10.374532C141.4349 10.442032 141.2867 10.549532 141.1611 10.688595C141.0358 10.83203 140.9371 11.01141 140.8699 11.22203C140.798 11.43297 140.7577 11.68391 140.7486 11.97078H143.7842C143.8605 11.97078 143.9099 11.99328 143.9367 12.03359C143.9636 12.07391 143.9771 12.15922 143.9771 12.28484C143.9771 12.60766 143.9277 12.89453 143.8336 13.14578C143.7396 13.40141 143.6049 13.61203 143.4346 13.78234C143.2686 13.95734 143.0667 14.08734 142.8336 14.17703C142.6052 14.27109 142.3539 14.31609 142.0805 14.31609C141.753 14.31609 141.4571 14.25766 141.1927 14.1411C140.928 14.02891 140.7083 13.87203 140.5246 13.66578C140.3408 13.46859 140.2017 13.22641 140.1074 12.95297C140.0089 12.67922 139.9596 12.38328 139.9596 12.06516C139.9596 11.67484 140.0133 11.32516 140.1208 11.02484C140.2286 10.72422 140.3764 10.468907 140.5739 10.267032C140.7621 10.060782 140.9952 9.903907 141.2555 9.800782C141.5246 9.69297 141.8114 9.63922 142.1252 9.63922C142.2911 9.63922 142.4571 9.652657 142.623 9.68422C142.7889 9.711095 142.9502 9.751407 143.1117 9.809532C143.2642 9.86797 143.4121 9.939532 143.5511 10.024845C143.6902 10.114532 143.8067 10.217657 143.9055 10.338595Z' fill='#808080'/>
+<path d='M150.2049 13.16359V10.97109C150.0389 10.75141 149.8596 10.58547 149.6624 10.46422C149.4696 10.343282 149.2408 10.284845 148.9764 10.284845C148.7924 10.284845 148.6311 10.316407 148.4877 10.37922C148.3442 10.442032 148.223 10.54047 148.1242 10.679532C148.0258 10.81391 147.9496 10.98453 147.9002 11.19953C147.8508 11.40578 147.8239 11.66141 147.8239 11.95734C147.8239 12.51797 147.9361 12.94828 148.1649 13.24891C148.3933 13.54922 148.7161 13.70172 149.1377 13.70172C149.353 13.70172 149.5458 13.66141 149.7208 13.58516C149.8955 13.50453 150.0571 13.36547 150.2049 13.16359ZM151.003 16.30672H150.2049V13.79141C150.048 13.95734 149.873 14.08734 149.6714 14.18609C149.4739 14.27578 149.2364 14.32484 148.9583 14.32484C148.6536 14.32484 148.3799 14.26672 148.138 14.1411C147.8911 14.02453 147.6849 13.85422 147.5189 13.64328C147.3533 13.43266 147.223 13.18141 147.1333 12.89453C147.0436 12.60328 146.9989 12.29359 146.9989 11.95734C146.9989 11.58078 147.0392 11.24891 147.1199 10.95766C147.2008 10.666095 147.3174 10.423907 147.4652 10.231095C147.6133 10.038282 147.7971 9.89047 148.0077 9.79172C148.2186 9.688595 148.4561 9.63922 148.7161 9.63922C149.0436 9.63922 149.3305 9.711095 149.5771 9.854532C149.8239 9.99797 150.048 10.186407 150.2408 10.419532L150.3127 9.86797C150.3439 9.755782 150.4158 9.702032 150.5277 9.702032H151.003V16.30672ZM153.1098 14.24422H152.3117V9.702032H153.1098V14.24422ZM153.2801 15.67016C153.2801 15.74641 153.2667 15.82266 153.2307 15.88984C153.2039 15.96172 153.1592 16.02422 153.1051 16.07828C153.0557 16.12734 152.9932 16.16797 152.9257 16.19922C152.8542 16.23047 152.7779 16.24422 152.7017 16.24422C152.6254 16.24422 152.5492 16.23047 152.4864 16.19922C152.4148 16.16797 152.3564 16.12734 152.307 16.07828C152.2576 16.02422 152.2173 15.96172 152.186 15.88984C152.1545 15.82266 152.141 15.74641 152.141 15.67016S152.1545 15.52203 152.186 15.45047C152.2173 15.38766 152.2576 15.32484 152.307 15.27109C152.3564 15.22172 152.4148 15.18141 152.4864 15.14984C152.5492 15.11859 152.6254 15.10516 152.7017 15.10516C152.7779 15.10516 152.8542 15.11859 152.9257 15.14984C152.9932 15.18141 153.0557 15.22172 153.1051 15.27109C153.1592 15.32484 153.2039 15.38766 153.2307 15.45047C153.2667 15.52203 153.2801 15.59391 153.2801 15.67016ZM157.0642 13.49547L157.2435 13.78703C157.0685 13.95266 156.8623 14.07828 156.6292 14.17703C156.387 14.26672 156.1226 14.31609 155.822 14.31609C155.5664 14.31609 155.3379 14.28016 155.136 14.20828C154.9342 14.13672 154.7682 14.04234 154.6295 13.91703C154.4904 13.80047 154.3873 13.65672 154.3154 13.49547C154.2439 13.33859 154.2079 13.17266 154.2079 12.99766C154.2079 12.80484 154.2439 12.63891 154.3064 12.49984C154.3782 12.36547 154.4635 12.25328 154.5754 12.15922C154.6876 12.06516 154.8132 11.98891 154.9523 11.92609C155.0957 11.86766 155.2392 11.81391 155.3917 11.76453C155.5351 11.71547 155.6829 11.67047 155.822 11.63016C155.9654 11.58516 156.091 11.53141 156.2032 11.47766C156.3154 11.41484 156.4051 11.34766 156.4676 11.26234C156.5395 11.18172 156.5707 11.07859 156.5707 10.95297C156.5707 10.84984 156.5529 10.75578 156.5126 10.666095C156.4767 10.576407 156.4185 10.495782 156.3423 10.428282C156.266 10.361095 156.1673 10.30297 156.0507 10.267032C155.9342 10.222032 155.7998 10.20422 155.6426 10.20422C155.4589 10.20422 155.3064 10.22672 155.1854 10.267032C155.0642 10.307345 154.961 10.35672 154.8714 10.406095C154.7907 10.45547 154.7145 10.504532 154.6564 10.545157C154.5979 10.58547 154.5398 10.607657 154.4857 10.607657C154.4367 10.607657 154.3917 10.598907 154.3604 10.576407C154.3289 10.553907 154.2976 10.527032 154.2751 10.48672L154.0867 10.18172C154.266 10.02047 154.4857 9.89047 154.7414 9.782657C154.997 9.68422 155.2839 9.630157 155.6023 9.630157C155.8804 9.630157 156.127 9.666095 156.3376 9.742345C156.5485 9.818595 156.7279 9.917345 156.8757 10.05172C157.0239 10.177345 157.1314 10.33422 157.2076 10.50922C157.2839 10.688595 157.3198 10.88141 157.3198 11.09203C157.3198 11.27578 157.2839 11.43297 157.221 11.55828C157.1492 11.69297 157.0642 11.80047 156.952 11.89016C156.8398 11.97984 156.7145 12.05609 156.5754 12.11453C156.4364 12.17266 156.2882 12.23109 156.1448 12.27578C155.9923 12.32953 155.8489 12.37453 155.7101 12.41922C155.571 12.45953 155.4454 12.50891 155.3332 12.56734C155.2214 12.62547 155.1317 12.69266 155.0689 12.76891C154.997 12.84516 154.9657 12.94391 154.9657 13.06047C154.9657 13.15453 154.9879 13.23984 155.0239 13.31609C155.0689 13.39672 155.1226 13.46859 155.2032 13.52672C155.2751 13.58516 155.3692 13.63453 155.4767 13.66578C155.5845 13.70172 155.7054 13.71953 155.8401 13.71953C155.997 13.71953 156.1314 13.70172 156.2435 13.66578C156.3557 13.63453 156.4542 13.59422 156.5395 13.55828C156.6201 13.51328 156.6876 13.47734 156.7457 13.44609C156.8042 13.41484 156.8532 13.39672 156.8982 13.39672C156.9745 13.39672 157.0282 13.42828 157.0642 13.49547ZM160.7628 11.74672V10.80516C160.6732 10.71078 160.5835 10.625782 160.4847 10.549532C160.395 10.473282 160.2963 10.41047 160.1888 10.35672C160.09 10.30297 159.9782 10.262657 159.8613 10.231095C159.7447 10.20422 159.6147 10.190782 159.4757 10.190782C159.3725 10.190782 159.2741 10.20422 159.1844 10.231095C159.09 10.253595 159.0141 10.293907 158.9422 10.347657C158.8794 10.406095 158.8257 10.477657 158.7853 10.56297C158.745 10.648282 158.7269 10.75141 158.7269 10.87234C158.7269 10.99797 158.7628 11.10984 158.8347 11.21297C158.911 11.31609 159.0275 11.40141 159.1935 11.47766C159.3547 11.55391 159.5653 11.61203 159.821 11.65703C160.0813 11.70641 160.395 11.73328 160.7628 11.74672ZM158.1844 13.60297L158.3278 13.34734C158.3547 13.30703 158.3863 13.27109 158.4266 13.24422C158.4669 13.21297 158.5119 13.19953 158.5657 13.19953C158.6328 13.19953 158.7047 13.22641 158.7719 13.27109C158.8435 13.32516 158.9288 13.37891 159.0228 13.44172C159.1216 13.49984 159.2382 13.55828 159.3725 13.60297C159.5028 13.65672 159.6685 13.67922 159.866 13.67922C160.1572 13.67922 160.3816 13.58953 160.5341 13.40578C160.6866 13.22641 160.7628 12.96172 160.7628 12.60766V12.25328C160.2469 12.23984 159.8075 12.19516 159.4535 12.11453C159.0991 12.02922 158.8078 11.92609 158.5878 11.79609C158.3682 11.66609 158.2069 11.52266 158.1082 11.35203C158.0094 11.19078 157.9603 11.01578 157.9603 10.83641C157.9603 10.630157 157.9916 10.450782 158.0635 10.30297C158.1263 10.15047 158.2203 10.024845 158.3325 9.926095C158.4491 9.827657 158.5835 9.755782 158.7403 9.702032C158.8975 9.657345 159.0632 9.630157 159.2382 9.630157S159.57 9.648282 159.7135 9.675157C159.8525 9.711095 159.9869 9.755782 160.1125 9.809532C160.2382 9.872345 160.3591 9.94422 160.4713 10.024845C160.5835 10.114532 160.7 10.208595 160.821 10.320782L160.9107 9.89047C160.9332 9.81422 160.9691 9.764845 161.0094 9.73797C161.0497 9.71547 161.1125 9.702032 161.1888 9.702032H161.5428V12.60766C161.5428 12.86328 161.5069 13.09641 161.4397 13.30703C161.3725 13.51797 161.2694 13.70172 161.1347 13.84953C161.0003 13.99766 160.8344 14.11422 160.6372 14.19953C160.4397 14.28453 160.2157 14.32484 159.96 14.32484C159.606 14.32484 159.2875 14.26672 158.996 14.14547C158.7047 14.02453 158.4357 13.84516 158.1844 13.60297ZM163.56 10.79609V12.99328C163.7257 13.21297 163.9007 13.37891 164.0978 13.49984C164.2863 13.62109 164.515 13.67922 164.775 13.67922C165.1472 13.67922 165.4341 13.54922 165.6403 13.28922C165.8378 13.02453 165.941 12.61672 165.941 12.06047C165.941 11.46422 165.8288 11.01141 165.6 10.71078C165.3713 10.41047 165.0441 10.25797 164.6182 10.25797C164.4072 10.25797 164.2144 10.298282 164.0441 10.37922C163.8647 10.459845 163.7078 10.598907 163.56 10.79609ZM163.56 13.58953V16.30672H162.7572V9.702032H163.2728C163.385 9.702032 163.4569 9.76047 163.4791 9.872345L163.5194 10.284845C163.6719 10.078595 163.8513 9.917345 164.0532 9.809532C164.2594 9.69297 164.5103 9.63922 164.811 9.63922C165.1113 9.63922 165.3847 9.697657 165.6269 9.818595C165.8691 9.935157 166.0753 10.101095 166.2413 10.31172C166.4116 10.527032 166.5416 10.78703 166.6313 11.08766C166.721 11.38797 166.766 11.72422 166.766 12.09203C166.766 12.43734 166.7257 12.74672 166.6447 13.02016C166.5685 13.29359 166.4519 13.53141 166.3041 13.71953C166.156 13.91703 165.9722 14.06047 165.7569 14.16359C165.5463 14.26672 165.3041 14.31609 165.0397 14.31609C164.7257 14.31609 164.4478 14.24859 164.2057 14.11859C163.9678 13.98859 163.7528 13.80922 163.56 13.58953ZM168.6034 16.30672H167.8053V9.702032H168.6034V16.30672ZM172.9344 12.46859H170.4503C170.5044 12.86328 170.6432 13.17266 170.8675 13.39672C171.0872 13.61641 171.3922 13.72859 171.7732 13.72859C171.9569 13.72859 172.1185 13.69734 172.2619 13.63891C172.4053 13.57609 172.5266 13.48641 172.625 13.37891C172.7282 13.26234 172.8044 13.13234 172.8585 12.97516C172.9075 12.82297 172.9344 12.65234 172.9344 12.46859ZM173.5803 10.338595L173.356 10.630157C173.32 10.679532 173.271 10.70641 173.2035 10.70641C173.1544 10.70641 173.0916 10.683907 173.0197 10.634532C172.9525 10.589845 172.8628 10.54047 172.7597 10.48672S172.531 10.383595 172.3832 10.338595C172.2394 10.289532 172.0691 10.267032 171.8675 10.267032C171.6522 10.267032 171.4594 10.30297 171.2844 10.374532C171.1097 10.442032 170.9616 10.549532 170.836 10.688595C170.7107 10.83203 170.6119 11.01141 170.5447 11.22203C170.4728 11.43297 170.4325 11.68391 170.4235 11.97078H173.4591C173.5353 11.97078 173.5847 11.99328 173.6116 12.03359C173.6385 12.07391 173.6519 12.15922 173.6519 12.28484C173.6519 12.60766 173.6025 12.89453 173.5085 13.14578C173.4144 13.40141 173.2797 13.61203 173.1094 13.78234C172.9435 13.95734 172.7416 14.08734 172.5085 14.17703C172.28 14.27109 172.0288 14.31609 171.7553 14.31609C171.4278 14.31609 171.1319 14.25766 170.8675 14.1411C170.6028 14.02891 170.3832 13.87203 170.1994 13.66578C170.0157 13.46859 169.8766 13.22641 169.7822 12.95297C169.6838 12.67922 169.6344 12.38328 169.6344 12.06516C169.6344 11.67484 169.6882 11.32516 169.7957 11.02484C169.9035 10.72422 170.0513 10.468907 170.2488 10.267032C170.4369 10.060782 170.67 9.903907 170.9303 9.800782C171.1994 9.69297 171.4863 9.63922 171.8 9.63922C171.966 9.63922 172.1319 9.652657 172.2978 9.68422C172.4638 9.711095 172.625 9.751407 172.7866 9.809532C172.9391 9.86797 173.0869 9.939532 173.226 10.024845C173.365 10.114532 173.4816 10.217657 173.5803 10.338595ZM177.588 13.16359V10.97109C177.4221 10.75141 177.2427 10.58547 177.0455 10.46422C176.8527 10.343282 176.6239 10.284845 176.3596 10.284845C176.1755 10.284845 176.0142 10.316407 175.8708 10.37922C175.7274 10.442032 175.6061 10.54047 175.5074 10.679532C175.4089 10.81391 175.3327 10.98453 175.2833 11.19953C175.2339 11.40578 175.2071 11.66141 175.2071 11.95734C175.2071 12.51797 175.3192 12.94828 175.548 13.24891C175.7764 13.54922 176.0992 13.70172 176.5208 13.70172C176.7361 13.70172 176.9289 13.66141 177.1039 13.58516C177.2786 13.50453 177.4402 13.36547 177.588 13.16359ZM178.3861 16.30672H177.588V13.79141C177.4311 13.95734 177.2561 14.08734 177.0546 14.18609C176.8571 14.27578 176.6196 14.32484 176.3414 14.32484C176.0367 14.32484 175.763 14.26672 175.5211 14.1411C175.2742 14.02453 175.068 13.85422 174.9021 13.64328C174.7364 13.43266 174.6061 13.18141 174.5164 12.89453C174.4267 12.60328 174.3821 12.29359 174.3821 11.95734C174.3821 11.58078 174.4224 11.24891 174.503 10.95766C174.5839 10.666095 174.7005 10.423907 174.8483 10.231095C174.9964 10.038282 175.1802 9.89047 175.3908 9.79172C175.6017 9.688595 175.8392 9.63922 176.0992 9.63922C176.4267 9.63922 176.7136 9.711095 176.9602 9.854532C177.2071 9.99797 177.4311 10.186407 177.6239 10.419532L177.6958 9.86797C177.7271 9.755782 177.7989 9.702032 177.9108 9.702032H178.3861V16.30672Z' fill='#808080'/>
+<path d='M149.12315 127.33159H146.63909C146.69315 127.72628 146.8319 128.03565 147.05628 128.25972C147.27596 128.4794 147.58096 128.59159 147.9619 128.59159C148.14565 128.59159 148.30721 128.56034 148.45065 128.5019C148.59409 128.43909 148.71534 128.3494 148.81378 128.2419C148.9169 128.12534 148.99315 127.99534 149.04721 127.83815C149.09628 127.68597 149.12315 127.51534 149.12315 127.33159ZM149.76909 125.201591L149.54471 125.493153C149.50878 125.542528 149.45971 125.5694 149.39221 125.5694C149.34315 125.5694 149.28034 125.546903 149.20846 125.497528C149.14128 125.452841 149.05159 125.403466 148.94846 125.349716C148.84534 125.295966 148.71971 125.246591 148.5719 125.201591C148.42815 125.152528 148.25784 125.130028 148.05628 125.130028C147.84096 125.130028 147.64815 125.165966 147.47315 125.237528C147.29846 125.305028 147.15034 125.412528 147.02471 125.551591C146.8994 125.69503 146.80065 125.8744 146.73346 126.08503C146.66159 126.29597 146.62128 126.5469 146.61221 126.83378H149.64784C149.72409 126.83378 149.77346 126.85628 149.80034 126.89659C149.82721 126.9369 149.84065 127.02222 149.84065 127.14784C149.84065 127.47065 149.79128 127.75753 149.69721 128.00878C149.60315 128.2644 149.46846 128.47503 149.29815 128.64534C149.13221 128.82034 148.93034 128.95034 148.69721 129.04003C148.46878 129.13409 148.21753 129.17909 147.94409 129.17909C147.61659 129.17909 147.32065 129.12065 147.05628 129.00409C146.79159 128.8919 146.5719 128.73503 146.388152 128.52878C146.204402 128.33159 146.065339 128.0894 145.970964 127.81597C145.872527 127.54222 145.823152 127.24628 145.823152 126.92815C145.823152 126.53784 145.876902 126.18815 145.984402 125.88784C146.092214 125.58722 146.240027 125.331903 146.437527 125.130028C146.62565 124.923778 146.85878 124.766903 147.11909 124.663778C147.38815 124.555966 147.67503 124.502216 147.98878 124.502216C148.15471 124.502216 148.32065 124.515653 148.48659 124.547216C148.65253 124.574091 148.81378 124.614403 148.97534 124.672528C149.12784 124.730966 149.27565 124.802528 149.41471 124.887841C149.55378 124.977528 149.67034 125.080653 149.76909 125.201591ZM151.57081 128.44815L151.508 128.94128C151.48112 129.05347 151.40925 129.10722 151.29706 129.10722H150.81737V124.565028H151.62018V127.91003C151.79487 128.10284 151.98331 128.25972 152.18487 128.3719C152.39112 128.48409 152.61112 128.54222 152.84862 128.54222C153.16706 128.54222 153.40456 128.44815 153.56612 128.25972C153.71862 128.0669 153.79925 127.80253 153.79925 127.45722V124.565028H154.60175V127.45722C154.60175 127.71284 154.5705 127.95034 154.50331 128.16128C154.43581 128.3719 154.34175 128.55565 154.21175 128.70815C154.08612 128.85628 153.92925 128.97284 153.73643 129.05784C153.548 129.13878 153.32831 129.17909 153.08175 129.17909C152.9205 129.17909 152.768 129.16097 152.63331 129.12972C152.48987 129.09378 152.35987 129.0444 152.23893 128.97722C152.11331 128.9144 151.99675 128.83815 151.88456 128.74847C151.77237 128.65878 151.66925 128.56034 151.57081 128.44815ZM158.2824 126.60972V125.66815C158.1928 125.57378 158.1031 125.488778 158.0043 125.412528C157.9146 125.336278 157.8159 125.273466 157.7084 125.219716C157.6096 125.165966 157.4978 125.125653 157.3809 125.094091C157.2643 125.067216 157.1343 125.053778 156.9953 125.053778C156.8921 125.053778 156.7937 125.067216 156.704 125.094091C156.6096 125.116591 156.5337 125.156903 156.4618 125.210653C156.399 125.269091 156.3453 125.340653 156.3049 125.425966C156.2646 125.511278 156.2465 125.6144 156.2465 125.73534C156.2465 125.86097 156.2824 125.97284 156.3543 126.07597C156.4306 126.17909 156.5471 126.2644 156.7131 126.34065C156.8743 126.4169 157.0849 126.47503 157.3406 126.52003C157.6009 126.5694 157.9146 126.59628 158.2824 126.60972ZM155.704 128.46597L155.8474 128.21034C155.8743 128.17003 155.9059 128.13409 155.9462 128.10722C155.9865 128.07597 156.0315 128.06253 156.0853 128.06253C156.1524 128.06253 156.2243 128.0894 156.2915 128.13409C156.3631 128.18815 156.4484 128.2419 156.5424 128.30472C156.6412 128.36284 156.7578 128.42128 156.8921 128.46597C157.0224 128.51972 157.1881 128.54222 157.3856 128.54222C157.6768 128.54222 157.9012 128.45253 158.0537 128.26878C158.2062 128.0894 158.2824 127.82472 158.2824 127.47065V127.11628C157.7665 127.10284 157.3271 127.05815 156.9731 126.97753C156.6187 126.89222 156.3274 126.78909 156.1074 126.65909C155.8878 126.52909 155.7265 126.38565 155.6278 126.21503C155.529 126.05378 155.4799 125.87878 155.4799 125.6994C155.4799 125.493153 155.5112 125.313778 155.5831 125.165966C155.6459 125.013466 155.7399 124.887841 155.8521 124.789091C155.9687 124.690653 156.1031 124.618778 156.2599 124.565028C156.4171 124.520341 156.5828 124.493153 156.7578 124.493153S157.0896 124.511278 157.2331 124.538153C157.3721 124.574091 157.5065 124.618778 157.6321 124.672528C157.7578 124.735341 157.8787 124.807216 157.9909 124.887841C158.1031 124.977528 158.2196 125.071591 158.3406 125.183778L158.4303 124.753466C158.4528 124.677216 158.4887 124.627841 158.529 124.600966C158.5693 124.578466 158.6321 124.565028 158.7084 124.565028H159.0624V127.47065C159.0624 127.72628 159.0265 127.9594 158.9593 128.17003C158.8921 128.38097 158.789 128.56472 158.6543 128.71253C158.5199 128.86065 158.354 128.97722 158.1568 129.06253C157.9593 129.14753 157.7353 129.18784 157.4796 129.18784C157.1256 129.18784 156.8071 129.12972 156.5156 129.00847C156.2243 128.88753 155.9553 128.70815 155.704 128.46597ZM161.0796 125.65909V127.85628C161.2453 128.07597 161.4203 128.2419 161.6174 128.36284C161.8059 128.48409 162.0346 128.54222 162.2946 128.54222C162.6668 128.54222 162.9537 128.41222 163.1599 128.15222C163.3574 127.88753 163.4606 127.47972 163.4606 126.92347C163.4606 126.32722 163.3484 125.8744 163.1196 125.57378C162.8909 125.273466 162.5637 125.120966 162.1378 125.120966C161.9268 125.120966 161.734 125.161278 161.5637 125.242216C161.3843 125.322841 161.2274 125.461903 161.0796 125.65909ZM161.0796 128.45253V131.16972H160.2768V124.565028H160.7924C160.9046 124.565028 160.9765 124.623466 160.9987 124.735341L161.039 125.147841C161.1915 124.941591 161.3709 124.780341 161.5728 124.672528C161.779 124.555966 162.0299 124.502216 162.3306 124.502216C162.6309 124.502216 162.9043 124.560653 163.1465 124.681591C163.3887 124.798153 163.5949 124.964091 163.7609 125.174716C163.9312 125.390028 164.0612 125.65003 164.1509 125.95065C164.2406 126.25097 164.2856 126.58722 164.2856 126.95503C164.2856 127.30034 164.2453 127.60972 164.1643 127.88315C164.0881 128.15659 163.9715 128.3944 163.8237 128.58253C163.6756 128.78003 163.4918 128.92347 163.2765 129.02659C163.0659 129.12972 162.8237 129.17909 162.5593 129.17909C162.2453 129.17909 161.9674 129.11159 161.7253 128.98159C161.4874 128.85159 161.2724 128.67222 161.0796 128.45253ZM166.123 131.16972H165.3249V124.565028H166.123V131.16972ZM170.454 127.33159H167.9699C168.024 127.72628 168.1628 128.03565 168.3871 128.25972C168.6068 128.4794 168.9118 128.59159 169.2928 128.59159C169.4765 128.59159 169.6381 128.56034 169.7815 128.5019C169.9249 128.43909 170.0462 128.3494 170.1446 128.2419C170.2478 128.12534 170.324 127.99534 170.3781 127.83815C170.4271 127.68597 170.454 127.51534 170.454 127.33159ZM171.0999 125.201591L170.8756 125.493153C170.8396 125.542528 170.7906 125.5694 170.7231 125.5694C170.674 125.5694 170.6112 125.546903 170.5393 125.497528C170.4721 125.452841 170.3824 125.403466 170.2793 125.349716S170.0506 125.246591 169.9028 125.201591C169.759 125.152528 169.5887 125.130028 169.3871 125.130028C169.1718 125.130028 168.979 125.165966 168.804 125.237528C168.6293 125.305028 168.4812 125.412528 168.3556 125.551591C168.2303 125.69503 168.1315 125.8744 168.0643 126.08503C167.9924 126.29597 167.9521 126.5469 167.9431 126.83378H170.9787C171.0549 126.83378 171.1043 126.85628 171.1312 126.89659S171.1715 127.02222 171.1715 127.14784C171.1715 127.47065 171.1221 127.75753 171.0281 128.00878C170.934 128.2644 170.7993 128.47503 170.629 128.64534C170.4631 128.82034 170.2612 128.95034 170.0281 129.04003C169.7996 129.13409 169.5484 129.17909 169.2749 129.17909C168.9474 129.17909 168.6515 129.12065 168.3871 129.00409C168.1224 128.8919 167.9028 128.73503 167.719 128.52878C167.5353 128.33159 167.3962 128.0894 167.3018 127.81597C167.2034 127.54222 167.154 127.24628 167.154 126.92815C167.154 126.53784 167.2078 126.18815 167.3153 125.88784C167.4231 125.58722 167.5709 125.331903 167.7684 125.130028C167.9565 124.923778 168.1896 124.766903 168.4499 124.663778C168.719 124.555966 169.0059 124.502216 169.3196 124.502216C169.4856 124.502216 169.6515 124.515653 169.8174 124.547216C169.9834 124.574091 170.1446 124.614403 170.3062 124.672528C170.4587 124.730966 170.6065 124.802528 170.7456 124.887841C170.8846 124.977528 171.0012 125.080653 171.0999 125.201591ZM175.1076 128.02659V125.83409C174.9417 125.6144 174.7623 125.448466 174.5651 125.327216C174.3723 125.206278 174.1435 125.147841 173.8792 125.147841C173.6951 125.147841 173.5339 125.179403 173.3904 125.242216C173.247 125.305028 173.1257 125.403466 173.027 125.542528C172.9285 125.6769 172.8523 125.84753 172.8029 126.06253C172.7535 126.26878 172.7267 126.5244 172.7267 126.82034C172.7267 127.38097 172.8389 127.81128 173.0676 128.1119C173.296 128.41222 173.6189 128.56472 174.0404 128.56472C174.2557 128.56472 174.4485 128.5244 174.6235 128.44815C174.7982 128.36753 174.9598 128.22847 175.1076 128.02659ZM175.9057 131.16972H175.1076V128.6544C174.9507 128.82034 174.7757 128.95034 174.5742 129.04909C174.3767 129.13878 174.1392 129.18784 173.861 129.18784C173.5564 129.18784 173.2826 129.12972 173.0407 129.00409C172.7939 128.88753 172.5876 128.71722 172.4217 128.50628C172.256 128.29565 172.1257 128.0444 172.036 127.75753C171.9464 127.46628 171.9017 127.15659 171.9017 126.82034C171.9017 126.44378 171.942 126.1119 172.0226 125.82065C172.1035 125.529091 172.2201 125.286903 172.3679 125.094091C172.516 124.901278 172.6998 124.753466 172.9104 124.654716C173.1214 124.551591 173.3589 124.502216 173.6189 124.502216C173.9464 124.502216 174.2332 124.574091 174.4798 124.717528C174.7267 124.860966 174.9507 125.049403 175.1435 125.282528L175.2154 124.730966C175.2467 124.618778 175.3185 124.565028 175.4304 124.565028H175.9057V131.16972ZM177.0978 125.058153C177.0978 124.977528 177.1113 124.905653 177.1382 124.834091C177.1694 124.771278 177.2097 124.708466 177.2547 124.659091C177.3085 124.609716 177.3666 124.569403 177.4341 124.538153C177.5013 124.511278 177.5775 124.497841 177.6538 124.497841C177.73 124.497841 177.8063 124.511278 177.8735 124.538153C177.9407 124.569403 178.0035 124.609716 178.0528 124.659091C178.1022 124.708466 178.1425 124.771278 178.1738 124.834091C178.2053 124.905653 178.2188 124.977528 178.2188 125.058153C178.2188 125.134403 178.2053 125.210653 178.1738 125.277841C178.1425 125.345341 178.1022 125.408153 178.0528 125.457216C178.0035 125.506591 177.9407 125.546903 177.8735 125.57847C177.8063 125.60972 177.73 125.62315 177.6538 125.62315C177.5775 125.62315 177.5013 125.60972 177.4341 125.57847C177.3666 125.546903 177.3085 125.506591 177.2547 125.457216C177.2097 125.408153 177.1694 125.345341 177.1382 125.277841C177.1113 125.210653 177.0978 125.134403 177.0978 125.058153ZM177.0978 128.42128C177.0978 128.34034 177.1113 128.26878 177.1382 128.1969C177.1694 128.13409 177.2097 128.07159 177.2547 128.02222C177.3085 127.97284 177.3666 127.93253 177.4341 127.90097C177.5013 127.87409 177.5775 127.86065 177.6538 127.86065C177.73 127.86065 177.8063 127.87409 177.8735 127.90097C177.9407 127.93253 178.0035 127.97284 178.0528 128.02222C178.1022 128.07159 178.1425 128.13409 178.1738 128.1969C178.2053 128.26878 178.2188 128.34034 178.2188 128.42128C178.2188 128.49753 178.2053 128.57378 178.1738 128.64097C178.1425 128.70815 178.1022 128.77097 178.0528 128.82034C178.0035 128.86972 177.9407 128.91003 177.8735 128.94128C177.8063 128.97284 177.73 128.98628 177.6538 128.98628C177.5775 128.98628 177.5013 128.97284 177.4341 128.94128C177.3666 128.91003 177.3085 128.86972 177.2547 128.82034C177.2097 128.77097 177.1694 128.70815 177.1382 128.64097C177.1113 128.57378 177.0978 128.49753 177.0978 128.42128Z' fill='#808080'/>
+<path d='M145.449215 123.171878H178.7773' stroke='#808080' fill='none' stroke-width='.379' stroke-miterlimit='10'/>
+<path d='M148.5269 112.97065H147.1369V115.20815H148.5269C148.99784 115.20815 149.3519 115.11378 149.58971 114.91659C149.82721 114.72815 149.94378 114.46377 149.94378 114.1319C149.94378 113.96159 149.9169 113.80471 149.86315 113.66096C149.8094 113.52221 149.72409 113.40096 149.6119 113.29346C149.49534 113.194713 149.34753 113.114088 149.16815 113.05565C148.98878 112.997525 148.77346 112.97065 148.5269 112.97065ZM147.1369 118.0194H148.32065C148.80034 118.0194 149.15034 117.92971 149.37878 117.7594C149.60753 117.58002 149.71971 117.30659 149.71971 116.92534C149.71971 116.76409 149.69284 116.61596 149.6344 116.4769C149.57628 116.34252 149.49096 116.22596 149.37003 116.13159C149.25346 116.03752 149.10534 115.96128 148.92159 115.90753C148.74221 115.85378 148.53128 115.8269 148.28471 115.8269H147.1369V118.0194ZM148.32065 118.70534H146.271589V112.280025H148.54034C148.89909 112.280025 149.21753 112.324713 149.50003 112.4144C149.78253 112.499713 150.01565 112.625338 150.21284 112.786588C150.40128 112.94815 150.54909 113.140963 150.65221 113.36503C150.75096 113.5894 150.80034 113.83596 150.80034 114.1094C150.80034 114.50846 150.67909 114.83596 150.44596 115.07784C150.20378 115.32909 149.84971 115.49502 149.37878 115.58471C149.58065 115.64753 149.76003 115.72815 149.90784 115.83128C150.06034 115.93003 150.18596 116.0419 150.28471 116.16753C150.38315 116.29315 150.45503 116.42752 150.50878 116.57565C150.55378 116.71909 150.58065 116.87159 150.58065 117.02846C150.58065 117.28846 150.53565 117.52159 150.45065 117.73253C150.36534 117.93877 150.23096 118.11346 150.04253 118.25721C149.86315 118.40065 149.62565 118.51252 149.34315 118.58877C149.05596 118.66503 148.71534 118.70534 148.32065 118.70534ZM152.938 112.280025V118.70534H152.06831V112.280025H152.938ZM157.8654 117.70096L158.0764 118.11346C157.852 118.32878 157.592 118.49471 157.3004 118.6069C157.0045 118.71909 156.6773 118.77721 156.3185 118.77721C156.0001 118.77721 155.7132 118.72784 155.471 118.6294C155.2201 118.53065 155.01385 118.40065 154.84323 118.23471C154.67729 118.06877 154.54729 117.88034 154.45761 117.66971C154.37261 117.45909 154.32761 117.2394 154.32761 117.01065C154.32761 116.72815 154.37261 116.48596 154.45761 116.29753C154.54729 116.10034 154.66386 115.94346 154.8076 115.81346C154.95104 115.68346 155.11698 115.58034 155.30073 115.4994C155.4845 115.41878 155.6729 115.3469 155.8657 115.2844C156.0585 115.22596 156.2467 115.16753 156.4307 115.10503C156.6145 115.05096 156.7804 114.9794 156.9239 114.89409C157.0673 114.80909 157.1839 114.70596 157.2735 114.58471C157.3589 114.45909 157.4035 114.29784 157.4035 114.10503C157.4035 113.93003 157.3723 113.76878 157.3139 113.62534C157.2557 113.48159 157.166 113.35627 157.0585 113.257525C156.9417 113.150025 156.8073 113.073775 156.6457 113.015337C156.4845 112.957213 156.3007 112.930338 156.0945 112.930338C155.9285 112.930338 155.7804 112.943775 155.6504 112.9794C155.5204 113.006275 155.39948 113.0469 155.30073 113.095963C155.19323 113.145338 155.10354 113.194713 155.0226 113.25315C154.94198 113.31128 154.8701 113.36065 154.8076 113.41003C154.74479 113.4594 154.69073 113.49971 154.63698 113.52659C154.59229 113.56253 154.54729 113.57596 154.50698 113.57596S154.42636 113.56253 154.39479 113.5444C154.35917 113.51752 154.32761 113.49065 154.30542 113.4594L154.05417 113.0469C154.29636 112.791275 154.58761 112.585025 154.92854 112.432525C155.26917 112.2844 155.6504 112.20815 156.0676 112.20815C156.4082 112.20815 156.7132 112.262213 156.9776 112.365337C157.2467 112.468463 157.471 112.6119 157.6592 112.79565C157.8385 112.9794 157.982 113.194713 158.0764 113.4369C158.1704 113.68784 158.2198 113.94815 158.2198 114.23065C158.2198 114.49502 158.1748 114.7194 158.0898 114.90315C158.0001 115.0869 157.8835 115.2394 157.7401 115.36503C157.592 115.49065 157.426 115.59378 157.2467 115.67878C157.0585 115.7594 156.8701 115.83128 156.6817 115.89846C156.4845 115.96596 156.296 116.02846 156.1167 116.09128C155.9285 116.14971 155.767 116.22128 155.6235 116.30659C155.4754 116.3919 155.35886 116.49034 155.27385 116.61159C155.18417 116.72815 155.13917 116.87596 155.13917 117.05534C155.13917 117.1944 155.16604 117.32878 155.21542 117.44565C155.26479 117.57096 155.34104 117.67409 155.44417 117.76378C155.5429 117.85346 155.6682 117.92534 155.812 117.97471C155.9642 118.02846 156.1348 118.05534 156.3276 118.05534C156.5339 118.05534 156.7085 118.02846 156.8523 117.97909C157.0001 117.92971 157.121 117.87159 157.2289 117.81315C157.3273 117.75034 157.417 117.69221 157.4845 117.64284C157.5517 117.59346 157.6145 117.56659 157.6639 117.56659C157.7085 117.56659 157.7489 117.58002 157.7757 117.59784C157.8117 117.62471 157.8385 117.65628 157.8654 117.70096ZM163.7881 117.97471V118.70534H158.7568V117.97471H160.8421V112.280025H161.7074V117.97471H163.7881Z' fill='#808080'/>
+<path d='M154.59815 107.3323H153.92096C153.84471 107.3323 153.78221 107.31011 153.72815 107.2698C153.67909 107.22917 153.64315 107.18011 153.62971 107.12605L152.29784 102.66011C152.27565 102.58386 152.25753 102.49886 152.23971 102.40917C152.22159 102.31948 152.20378 102.22511 152.19034 102.12667C152.16784 102.22511 152.15003 102.31948 152.12315 102.40917C152.10503 102.49886 152.07815 102.58386 152.05128 102.66011L150.54471 107.12605C150.52221 107.18448 150.48628 107.23386 150.43721 107.27417C150.38784 107.31449 150.32503 107.3323 150.24878 107.3323H149.99753C149.92159 107.3323 149.85878 107.31011 149.8094 107.26511C149.75565 107.2248 149.71971 107.17542 149.70159 107.12605L148.19065 102.66011C148.16378 102.58386 148.14128 102.49417 148.1144 102.40448C148.09659 102.30605 148.07409 102.2073 148.05159 102.10417C148.03378 102.2073 148.01565 102.30605 147.99784 102.40011C147.97534 102.49417 147.95753 102.57948 147.93503 102.66011L146.60784 107.12605C146.5944 107.18448 146.55846 107.23386 146.50909 107.27417C146.45534 107.31449 146.388152 107.3323 146.311902 107.3323H145.590027L147.5944 100.906985H148.3744L150.01096 105.80792C150.02471 105.8573 150.04253 105.90667 150.05596 105.96042C150.0694 106.01417 150.08721 106.07261 150.10065 106.13073L150.14128 105.96042C150.15909 105.90667 150.17253 105.8573 150.18596 105.80792L151.81378 100.906985H152.59378L154.59815 107.3323Z' fill='#808080'/>
+<path d='M158.5795 103.2923H156.1807L157.1895 105.90199C157.2567 106.06355 157.3195 106.26542 157.3823 106.5073C157.4135 106.39074 157.4451 106.27886 157.4764 106.18011C157.5079 106.07261 157.5392 105.98292 157.5707 105.90667L158.5795 103.2923ZM160.391 100.906985L157.8217 107.3323H156.9429L154.37354 100.906985H155.04604C155.12229 100.906985 155.18511 100.929485 155.23448 100.969797C155.28386 101.01011 155.31979 101.059485 155.33761 101.113235L155.9385 102.6648H158.8217L159.4226 101.113235C159.4448 101.05511 159.4807 101.005735 159.5301 100.965422C159.5795 100.924797 159.6423 100.906985 159.7185 100.906985H160.391ZM162.1072 100.906985V107.3323H161.2375V100.906985H162.1072ZM168.0931 106.60167V107.3323H163.0618V106.60167H165.1471V100.906985H166.0124V106.60167H168.0931Z' fill='#808080'/>
+<path d='M150.23534 90.311409H147.14128V92.50422H149.64346V93.18547H147.14128V95.31985H150.23096V96.02828H146.271589V89.602971H150.23096L150.23534 90.311409ZM154.7362 95.02391L154.94714 95.43641C154.72276 95.65172 154.46276 95.81766 154.1712 95.92985C153.87526 96.04203 153.54807 96.10016 153.18932 96.10016C152.87089 96.10016 152.58401 96.05078 152.34182 95.95235C152.09089 95.8536 151.88464 95.7236 151.71401 95.55766C151.54807 95.39172 151.41807 95.20328 151.32839 94.99266C151.24339 94.78203 151.19839 94.56235 151.19839 94.3336C151.19839 94.0511 151.24339 93.80891 151.32839 93.62047C151.41807 93.42328 151.53464 93.26641 151.67839 93.13641C151.82182 93.00641 151.98776 92.90328 152.17151 92.82235C152.35526 92.74172 152.5437 92.66985 152.73651 92.60735C152.92932 92.54891 153.11745 92.49047 153.30151 92.42797C153.48526 92.37391 153.6512 92.30235 153.79464 92.21703C153.93807 92.13203 154.05464 92.02891 154.14432 91.90766C154.22964 91.78203 154.27432 91.62078 154.27432 91.42797C154.27432 91.25297 154.24307 91.09172 154.18464 90.94828C154.12651 90.80453 154.03682 90.67922 153.92932 90.580471C153.81245 90.472971 153.67807 90.396721 153.51651 90.338284C153.35526 90.280159 153.17151 90.253284 152.96526 90.253284C152.79932 90.253284 152.6512 90.266721 152.5212 90.302346C152.3912 90.329221 152.27026 90.369846 152.17151 90.418909C152.06401 90.468284 151.97432 90.517659 151.89339 90.576096C151.81276 90.63422 151.74089 90.6836 151.67839 90.73297C151.61557 90.78235 151.56151 90.82266 151.50776 90.84953C151.46307 90.88547 151.41807 90.89891 151.37776 90.89891S151.29714 90.88547 151.26557 90.86735C151.22995 90.84047 151.19839 90.8136 151.1762 90.78235L150.92495 90.369846C151.16714 90.114221 151.45839 89.907971 151.79932 89.755471C152.13995 89.607346 152.5212 89.531096 152.93839 89.531096C153.27901 89.531096 153.58401 89.585159 153.84839 89.688284C154.11745 89.791409 154.34182 89.934846 154.52995 90.118596C154.70932 90.302346 154.85276 90.517659 154.94714 90.75985C155.0412 91.01078 155.09057 91.2711 155.09057 91.5536C155.09057 91.81797 155.04557 92.04235 154.96057 92.2261C154.87089 92.40985 154.75432 92.56235 154.61089 92.68797C154.46276 92.8136 154.29682 92.91672 154.11745 93.00172C153.92932 93.08235 153.74089 93.15422 153.55245 93.22141C153.35526 93.28891 153.16682 93.35141 152.98745 93.41422C152.79932 93.47266 152.63776 93.54422 152.49432 93.62953C152.3462 93.71485 152.22964 93.81328 152.14464 93.93453C152.05495 94.0511 152.00995 94.19891 152.00995 94.37828C152.00995 94.51735 152.03682 94.65172 152.0862 94.7686C152.13557 94.89391 152.21182 94.99703 152.31495 95.08672C152.4137 95.17641 152.53901 95.24828 152.68276 95.29766C152.83495 95.35141 153.00557 95.37828 153.19839 95.37828C153.40464 95.37828 153.57932 95.35141 153.72307 95.30203C153.87089 95.25266 153.99182 95.19453 154.09964 95.1361C154.19807 95.07328 154.28776 95.01516 154.35526 94.96578C154.42245 94.91641 154.48526 94.88953 154.53464 94.88953C154.57932 94.88953 154.61964 94.90297 154.64651 94.92078C154.68245 94.94766 154.70932 94.97922 154.7362 95.02391ZM160.0579 90.212659H158.7935V96.04203H158.1432L156.2285 94.38735L156.4798 94.04203C156.4932 94.01953 156.5154 94.00172 156.5426 93.98391C156.5739 93.96578 156.6051 93.95235 156.6367 93.94797C156.6679 93.94328 156.7039 93.94328 156.7442 93.95235C156.7845 93.95672 156.8204 93.97922 156.8607 94.01078L158.0042 94.99266C157.9951 94.85828 157.9907 94.7236 157.9907 94.5936V90.212659H156.6142V89.602971H160.0579V90.212659ZM163.2853 90.194846C163.0746 90.194846 162.8818 90.230784 162.7206 90.293596C162.5499 90.365159 162.4109 90.459534 162.299 90.580471C162.1824 90.70141 162.0928 90.84953 162.0343 91.01985C161.9762 91.19016 161.9446 91.3786 161.9446 91.58485C161.9446 91.75985 161.9762 91.93016 162.039 92.0961C162.1062 92.25735 162.2003 92.40078 162.3168 92.52641C162.4424 92.64766 162.5859 92.7461 162.7609 92.82235C162.9356 92.89422 163.1284 92.93016 163.3437 92.93016C163.5456 92.93016 163.7293 92.8986 163.8953 92.83578C164.0612 92.77297 164.209 92.68328 164.3256 92.56235C164.4512 92.44578 164.5409 92.30235 164.6081 92.13203C164.6756 91.9661 164.7068 91.77766 164.7068 91.56703C164.7068 91.36953 164.6756 91.18578 164.6037 91.01985C164.5409 90.85391 164.4421 90.7061 164.3168 90.584846C164.1956 90.463909 164.0478 90.365159 163.8684 90.297971C163.6981 90.230784 163.5006 90.194846 163.2853 90.194846ZM162.819 93.62047L164.7246 96.02828H164.0162C163.9221 96.02828 163.8368 96.01047 163.7606 95.97016C163.689 95.93422 163.6306 95.88953 163.5903 95.83547L161.9581 93.64297C161.6846 93.27985 161.4874 92.93891 161.3662 92.62516C161.2409 92.30235 161.1781 92.00641 161.1781 91.72391C161.1781 91.38766 161.2271 91.08703 161.3303 90.8136C161.429 90.544534 161.5724 90.315784 161.7518 90.122971C161.9403 89.934846 162.1599 89.791409 162.4246 89.683596C162.689 89.585159 162.9806 89.531096 163.3034 89.531096C163.6306 89.531096 163.9265 89.585159 164.2003 89.692659C164.469 89.800159 164.7024 89.948284 164.8906 90.136409C165.0881 90.324846 165.2359 90.544534 165.3434 90.80016C165.4512 91.05578 165.5049 91.32922 165.5049 91.62516C165.5049 91.93016 165.4556 92.2036 165.3524 92.43672C165.2493 92.67891 165.1149 92.8761 164.9443 93.03766C164.7696 93.2036 164.5678 93.32453 164.339 93.41422C164.1106 93.49516 163.8637 93.53985 163.6037 93.53985C163.3884 93.53985 163.1912 93.51297 163.0074 93.45453C162.8237 93.39641 162.6578 93.31578 162.5053 93.21266C162.5546 93.27985 162.6037 93.34266 162.6578 93.41422C162.7071 93.47703 162.7609 93.54891 162.819 93.62047Z' fill='#808080'/>
+<path d='M151.84065 36.0866C151.84065 36.56629 151.7644 37.00567 151.6119 37.40035C151.4594 37.79473 151.24409 38.13129 150.96628 38.41817C150.68815 38.69598 150.35628 38.91598 149.9619 39.07286C149.57628 39.22535 149.14128 39.30129 148.67034 39.30129H146.271589V32.87598H148.67034C149.14128 32.87598 149.57628 32.95223 149.9619 33.109105C150.35628 33.261605 150.68815 33.476917 150.96628 33.759417C151.24409 34.04192 151.4594 34.37817 151.6119 34.77254C151.7644 35.16723 151.84065 35.6066 151.84065 36.0866ZM150.94815 36.0866C150.94815 35.69192 150.8944 35.33754 150.7869 35.02817C150.67909 34.71879 150.5269 34.45442 150.3294 34.2391C150.13221 34.02848 149.8944 33.862542 149.6119 33.750355C149.32971 33.638167 149.01565 33.580042 148.67034 33.580042H147.14128V38.59754H148.67034C149.01565 38.59754 149.32971 38.53911 149.6119 38.42723C149.8944 38.31504 150.13221 38.1491 150.3294 37.93379C150.5269 37.71848 150.67909 37.4541 150.7869 37.14473C150.8944 36.83535 150.94815 36.48098 150.94815 36.0866ZM157.0542 33.584417H153.96018V35.77723H156.4624V36.45848H153.96018V38.59286H157.0499V39.30129H153.0905V32.87598H157.0499L157.0542 33.584417ZM161.6807 35.26129H159.282L160.2907 37.87098C160.3579 38.03254 160.4207 38.23442 160.4835 38.47629C160.5148 38.35973 160.5464 38.24785 160.5776 38.1491C160.6092 38.04161 160.6404 37.95192 160.672 37.87567L161.6807 35.26129ZM163.4923 32.87598L160.9229 39.30129H160.0442L157.4748 32.87598H158.1473C158.2235 32.87598 158.2864 32.89848 158.3357 32.938792C158.3851 32.979105 158.421 33.02848 158.4389 33.08223L159.0398 34.63379H161.9229L162.5239 33.08223C162.546 33.024105 162.582 32.97473 162.6314 32.934417C162.6807 32.893792 162.7435 32.87598 162.8198 32.87598H163.4923ZM169.9078 36.0866C169.9078 36.56629 169.8316 37.00567 169.6791 37.40035C169.5266 37.79473 169.3113 38.13129 169.0335 38.41817C168.7553 38.69598 168.4235 38.91598 168.0291 39.07286C167.6435 39.22535 167.2085 39.30129 166.7375 39.30129H164.3388V32.87598H166.7375C167.2085 32.87598 167.6435 32.95223 168.0291 33.109105C168.4235 33.261605 168.7553 33.476917 169.0335 33.759417C169.3113 34.04192 169.5266 34.37817 169.6791 34.77254C169.8316 35.16723 169.9078 35.6066 169.9078 36.0866ZM169.0153 36.0866C169.0153 35.69192 168.9616 35.33754 168.8541 35.02817C168.7463 34.71879 168.5941 34.45442 168.3966 34.2391C168.1994 34.02848 167.9616 33.862542 167.6791 33.750355C167.3969 33.638167 167.0828 33.580042 166.7375 33.580042H165.2085V38.59754H166.7375C167.0828 38.59754 167.3969 38.53911 167.6791 38.42723C167.9616 38.31504 168.1994 38.1491 168.3966 37.93379C168.5941 37.71848 168.7463 37.4541 168.8541 37.14473C168.9616 36.83535 169.0153 36.48098 169.0153 36.0866Z' fill='#808080'/>
+<path d='M167.4375 115.9297L195.258 119.1328' stroke='#808080' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M198.82028 119.542758C197.742148 119.62088 195.956994 120.015409 194.691378 120.570107L195.03121 117.601343C196.140593 118.433382 197.789023 119.222441 198.82028 119.542758' fill='#808080'/>
+<path d='M171.746 104.6641L195.492 114.2031' stroke='#808080' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M198.82044 115.539373C197.761835 115.328436 195.933712 115.242507 194.566528 115.441715L195.679811 112.668286C196.531369 113.762045 197.910283 114.961267 198.82044 115.539373' fill='#808080'/>
+<path d='M169.4141 93.2852L195.805 110.2422' stroke='#808080' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M198.820711 112.179265C197.820713 111.773009 196.043372 111.343331 194.660558 111.28083L196.277748 108.769108C196.906643 109.999575 198.035555 111.437071 198.820711 112.179265' fill='#808080'/>
+<path d='M173.859 36.668L191.668 36.414' stroke='#808080' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M195.253819 36.363287C194.195213 36.578133 192.476464 37.199225 191.292869 37.914072L191.249914 34.925793C192.45304 35.605475 194.187405 36.179693 195.253819 36.363287' fill='#808080'/>
+<path d='M244.937 91.9375H180.66C178.457 91.9375 176.676 90.1523 176.676 87.9531V69.3125C176.676 67.1133 178.457 65.3281 180.66 65.3281H244.937C247.141 65.3281 248.922 67.1133 248.922 69.3125V87.9531C248.922 90.1523 247.141 91.9375 244.937 91.9375Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M186.41296 85.23037H184.43984V84.73724C184.43984 84.68787 184.45796 84.64755 184.48921 84.61599C184.52515 84.58474 184.56984 84.56693 184.62827 84.56693H185.62827V83.15443C185.40827 83.03318 185.17984 82.939117 184.94671 82.876305C184.71796 82.804742 184.45327 82.77318 184.15296 82.77318C183.77171 82.77318 183.43109 82.831617 183.12609 82.94818C182.82109 83.064742 182.56109 83.23505 182.34577 83.45912C182.13515 83.67912 181.96921 83.95255 181.85265 84.2663C181.74046 84.58912 181.68234 84.94787 181.68234 85.35162C181.68234 85.74162 181.73609 86.0913 181.84827 86.40068C181.96015 86.71474 182.11734 86.98349 182.32359 87.19881C182.52984 87.42318 182.78077 87.5888 183.07234 87.71006C183.36359 87.82662 183.69109 87.88505 184.05421 87.88505C184.30077 87.88505 184.51609 87.86693 184.69546 87.82662C184.87921 87.7863 185.03609 87.74131 185.17077 87.68318C185.30077 87.62943 185.41296 87.57099 185.50702 87.51287C185.60109 87.45443 185.68202 87.40068 185.75359 87.36037C185.82984 87.31537 185.89702 87.30193 185.95984 87.31537C186.01827 87.33349 186.06765 87.3738 186.10796 87.43193L186.35452 87.82662C186.21546 87.95224 186.06765 88.06412 185.91046 88.16724C185.75359 88.26599 185.5789 88.3513 185.39484 88.41849C185.21109 88.49037 185.00921 88.54412 184.78952 88.58005C184.56984 88.62037 184.33671 88.63818 184.08109 88.63818C183.5789 88.63818 183.12609 88.55755 182.71796 88.40068C182.31015 88.24349 181.96484 88.01943 181.68234 87.72787C181.39984 87.44099 181.180149 87.09568 181.027649 86.69224C180.870774 86.28849 180.794524 85.84037 180.794524 85.35162C180.794524 84.86724 180.875149 84.42318 181.032024 84.01974S181.41765 83.27099 181.70921 82.984117C182.00515 82.692555 182.35921 82.46818 182.7764 82.311305C183.19327 82.150055 183.65952 82.069117 184.17546 82.069117C184.61015 82.069117 185.0139 82.127555 185.37702 82.239742C185.74484 82.356305 186.08984 82.530992 186.41296 82.764117V85.23037Z'/>
+<path d='M190.5383 84.90755H188.05421C188.10827 85.30224 188.24702 85.61162 188.4714 85.83568C188.69109 86.05537 188.99609 86.16756 189.37702 86.16756C189.56077 86.16756 189.72234 86.1363 189.86577 86.07787C190.00921 86.01505 190.13046 85.92537 190.2289 85.81787C190.33202 85.7013 190.4083 85.5713 190.4623 85.41412C190.5114 85.26193 190.5383 85.0913 190.5383 84.90755ZM191.1842 82.777555L190.9598 83.069117C190.9239 83.118492 190.8748 83.14537 190.8073 83.14537C190.7583 83.14537 190.6955 83.122867 190.6236 83.073492C190.5564 83.028805 190.4667 82.97943 190.36359 82.92568C190.26046 82.87193 190.13484 82.822555 189.98702 82.777555C189.84327 82.728492 189.67296 82.705992 189.4714 82.705992C189.25609 82.705992 189.06327 82.74193 188.88827 82.813492C188.71359 82.880992 188.56546 82.988492 188.43984 83.127555C188.31452 83.27099 188.21577 83.45037 188.14859 83.66099C188.07671 83.87193 188.0364 84.12287 188.02734 84.40974H191.063C191.1392 84.40974 191.1886 84.43224 191.2155 84.47255C191.2423 84.51287 191.2558 84.59818 191.2558 84.7238C191.2558 85.04662 191.2064 85.33349 191.1123 85.58474C191.0183 85.84037 190.8836 86.05099 190.7133 86.22131C190.5473 86.3963 190.34546 86.5263 190.11234 86.61599C189.8839 86.71006 189.63265 86.75505 189.35921 86.75505C189.03171 86.75505 188.73577 86.69662 188.4714 86.58005C188.20671 86.46787 187.98702 86.31099 187.80327 86.10474C187.61952 85.90755 187.48046 85.66537 187.38609 85.39193C187.28765 85.11818 187.23827 84.82224 187.23827 84.50412C187.23827 84.1138 187.29202 83.76412 187.39952 83.4638C187.50734 83.16318 187.65515 82.907867 187.85265 82.705992C188.04077 82.499742 188.2739 82.342867 188.53421 82.239742C188.80327 82.13193 189.09015 82.07818 189.4039 82.07818C189.56984 82.07818 189.73577 82.091617 189.90171 82.12318C190.06765 82.150055 190.2289 82.190367 190.3905 82.248492C190.543 82.30693 190.6908 82.378492 190.8298 82.463805C190.9689 82.553492 191.0855 82.656617 191.1842 82.777555Z'/>
+<path d='M193.5876 82.069117C193.7938 82.069117 193.9954 82.105055 194.1882 82.17693C194.381 82.25318 194.5469 82.351617 194.686 82.481617L194.4529 82.862867C194.4213 82.912242 194.381 82.939117 194.3407 82.939117C194.3182 82.939117 194.2869 82.930055 194.2601 82.90318C194.2241 82.885367 194.1882 82.858492 194.1435 82.831617C194.0985 82.804742 194.0448 82.777555 193.9819 82.759742C193.9238 82.732867 193.8519 82.723805 193.7666 82.723805C193.6188 82.723805 193.5023 82.768805 193.4082 82.862867C193.3138 82.95693 193.2691 83.095992 193.2691 83.2888V86.01505H194.5829V86.59349H193.2691V88.15849H192.8654C192.8163 88.15849 192.7713 88.14506 192.7444 88.11349C192.7085 88.08662 192.6907 88.05068 192.6816 88.00599L192.4979 86.60256L191.7535 86.50818V86.19006C191.7535 86.13162 191.7713 86.08693 191.8029 86.06005C191.8341 86.02849 191.8744 86.01505 191.9238 86.01505H192.471V83.23505C192.471 82.858492 192.5651 82.571305 192.7623 82.369742C192.9507 82.167867 193.2288 82.069117 193.5876 82.069117ZM200.8014 88.5663H200.0392V84.01537C200.0392 83.94787 200.0392 83.88068 200.0483 83.80912C200.0483 83.73287 200.0573 83.65662 200.0617 83.58037L196.3445 88.41849C196.322 88.44974 196.2998 88.47224 196.2773 88.49037C196.2548 88.51255 196.237 88.52599 196.2145 88.53505C196.192 88.54849 196.1695 88.55287 196.1426 88.56193C196.1158 88.56193 196.0845 88.5663 196.0442 88.5663H195.5958V82.140992H196.358V86.71912C196.358 86.78193 196.358 86.84912 196.3536 86.92099C196.3489 86.99255 196.3445 87.06443 196.3401 87.14068L200.0573 82.297867C200.102 82.239742 200.147 82.19943 200.1917 82.17693C200.2411 82.15443 200.2992 82.140992 200.3667 82.140992H200.8014V88.5663Z'/>
+<path d='M204.0277 86.75505C203.6915 86.75505 203.3909 86.70099 203.1221 86.58912C202.8574 86.47693 202.6287 86.32005 202.4405 86.11818C202.2521 85.9163 202.1087 85.66974 202.0099 85.37849C201.9068 85.0913 201.8574 84.76849 201.8574 84.41443C201.8574 84.05568 201.9068 83.73287 202.0099 83.44568C202.1087 83.1588 202.2521 82.912242 202.4405 82.710367C202.6287 82.508805 202.8574 82.351617 203.1221 82.239742C203.3909 82.13193 203.6915 82.07818 204.0277 82.07818C204.3596 82.07818 204.6599 82.13193 204.9246 82.239742C205.189 82.351617 205.4177 82.508805 205.6062 82.710367C205.7943 82.912242 205.9377 83.1588 206.0365 83.44568C206.1396 83.73287 206.189 84.05568 206.189 84.41443C206.189 84.76849 206.1396 85.0913 206.0365 85.37849C205.9377 85.66974 205.7943 85.9163 205.6062 86.11818C205.4177 86.32005 205.189 86.47693 204.9246 86.58912C204.6599 86.70099 204.3596 86.75505 204.0277 86.75505ZM204.0277 82.701617C203.5749 82.701617 203.234 82.84943 203.0143 83.15443C202.7902 83.45037 202.678 83.87193 202.678 84.40974C202.678 84.6788 202.7049 84.92099 202.7634 85.1363C202.8171 85.34693 202.8977 85.5263 203.0143 85.67443C203.1221 85.82224 203.2655 85.93443 203.4359 86.01068C203.6018 86.08693 203.799 86.12724 204.0277 86.12724C204.4762 86.12724 204.8124 85.97474 205.0321 85.67443C205.2518 85.3738 205.364 84.95255 205.364 84.40974C205.364 83.87193 205.2518 83.45037 205.0321 83.15443C204.8124 82.84943 204.4762 82.701617 204.0277 82.701617ZM208.0401 86.68318H207.2419V82.140992H208.0401V86.68318ZM208.2104 88.10912C208.2104 88.18537 208.1969 88.26162 208.161 88.3288C208.1341 88.40068 208.0894 88.46318 208.0354 88.51724C207.986 88.5663 207.9235 88.60693 207.856 88.63818C207.7844 88.66943 207.7082 88.68318 207.6319 88.68318C207.5557 88.68318 207.4794 88.66943 207.4166 88.63818C207.3451 88.60693 207.2866 88.5663 207.2373 88.51724C207.1879 88.46318 207.1476 88.40068 207.1163 88.3288C207.0848 88.26162 207.0713 88.18537 207.0713 88.10912S207.0848 87.96099 207.1163 87.88943C207.1476 87.82662 207.1879 87.7638 207.2373 87.71006C207.2866 87.66068 207.3451 87.62037 207.4166 87.5888C207.4794 87.55755 207.5557 87.54412 207.6319 87.54412C207.7082 87.54412 207.7844 87.55755 207.856 87.5888C207.9235 87.62037 207.986 87.66068 208.0354 87.71006C208.0894 87.7638 208.1341 87.82662 208.161 87.88943C208.1969 87.96099 208.2104 88.03287 208.2104 88.10912ZM211.9944 85.93443L212.1738 86.22599C211.9988 86.39162 211.7926 86.51724 211.5594 86.61599C211.3173 86.70568 211.0529 86.75505 210.7523 86.75505C210.4966 86.75505 210.2682 86.71912 210.0663 86.64724C209.8644 86.57568 209.6985 86.4813 209.5598 86.35599C209.4207 86.23943 209.3176 86.09568 209.2457 85.93443C209.1741 85.77755 209.1382 85.61162 209.1382 85.43662C209.1382 85.2438 209.1741 85.07787 209.2366 84.9388C209.3085 84.80443 209.3938 84.69224 209.5057 84.59818C209.6179 84.50412 209.7435 84.42787 209.8826 84.36505C210.026 84.30662 210.1694 84.25287 210.3219 84.20349C210.4654 84.15443 210.6132 84.10943 210.7523 84.06912C210.8957 84.02412 211.0213 83.97037 211.1335 83.91662C211.2457 83.8538 211.3354 83.78662 211.3979 83.7013C211.4698 83.62068 211.501 83.51755 211.501 83.39193C211.501 83.2888 211.4832 83.19474 211.4429 83.105055C211.4069 83.015367 211.3488 82.934742 211.2726 82.867242C211.1963 82.800055 211.0976 82.74193 210.981 82.705992C210.8644 82.660992 210.7301 82.64318 210.5729 82.64318C210.3891 82.64318 210.2366 82.66568 210.1157 82.705992C209.9944 82.746305 209.8913 82.79568 209.8016 82.845055C209.721 82.89443 209.6448 82.943492 209.5866 82.984117C209.5282 83.02443 209.4701 83.046617 209.416 83.046617C209.3669 83.046617 209.3219 83.037867 209.2907 83.015367C209.2591 82.992867 209.2279 82.965992 209.2054 82.92568L209.0169 82.62068C209.1963 82.45943 209.416 82.32943 209.6716 82.221617C209.9273 82.12318 210.2141 82.069117 210.5326 82.069117C210.8107 82.069117 211.0573 82.105055 211.2679 82.181305C211.4788 82.257555 211.6582 82.356305 211.806 82.49068C211.9541 82.616305 212.0616 82.77318 212.1379 82.94818C212.2141 83.127555 212.2501 83.32037 212.2501 83.53099C212.2501 83.71474 212.2141 83.87193 212.1513 83.99724C212.0794 84.13193 211.9944 84.23943 211.8823 84.32912C211.7701 84.4188 211.6448 84.49505 211.5057 84.55349C211.3666 84.61162 211.2185 84.67005 211.0751 84.71474C210.9226 84.76849 210.7791 84.81349 210.6404 84.85818C210.5013 84.89849 210.3757 84.94787 210.2635 85.0063C210.1516 85.06443 210.0619 85.13162 209.9991 85.20787C209.9273 85.28412 209.896 85.38287 209.896 85.49943C209.896 85.59349 209.9182 85.6788 209.9541 85.75505C209.9991 85.83568 210.0529 85.90755 210.1335 85.96568C210.2054 86.02412 210.2994 86.07349 210.4069 86.10474C210.5148 86.14068 210.6357 86.15849 210.7704 86.15849C210.9273 86.15849 211.0616 86.14068 211.1738 86.10474C211.286 86.07349 211.3844 86.03318 211.4698 85.99724C211.5504 85.95224 211.6179 85.9163 211.676 85.88505C211.7344 85.8538 211.7835 85.83568 211.8285 85.83568C211.9048 85.83568 211.9585 85.86724 211.9944 85.93443ZM216.2712 84.90755H213.7872C213.8412 85.30224 213.98 85.61162 214.2044 85.83568C214.4241 86.05537 214.7291 86.16756 215.11 86.16756C215.2937 86.16756 215.4553 86.1363 215.5987 86.07787C215.7422 86.01505 215.8634 85.92537 215.9619 85.81787C216.065 85.7013 216.1412 85.5713 216.1953 85.41412C216.2444 85.26193 216.2712 85.0913 216.2712 84.90755ZM216.9172 82.777555L216.6928 83.069117C216.6569 83.118492 216.6078 83.14537 216.5403 83.14537C216.4912 83.14537 216.4284 83.122867 216.3566 83.073492C216.2894 83.028805 216.1997 82.97943 216.0966 82.92568C215.9934 82.87193 215.8678 82.822555 215.72 82.777555C215.5762 82.728492 215.4059 82.705992 215.2044 82.705992C214.9891 82.705992 214.7962 82.74193 214.6212 82.813492C214.4466 82.880992 214.2984 82.988492 214.1728 83.127555C214.0475 83.27099 213.9487 83.45037 213.8816 83.66099C213.8097 83.87193 213.7694 84.12287 213.7603 84.40974H216.7959C216.8722 84.40974 216.9216 84.43224 216.9484 84.47255C216.9753 84.51287 216.9887 84.59818 216.9887 84.7238C216.9887 85.04662 216.9394 85.33349 216.8453 85.58474C216.7512 85.84037 216.6166 86.05099 216.4462 86.22131C216.2803 86.3963 216.0784 86.5263 215.8453 86.61599C215.6169 86.71006 215.3656 86.75505 215.0922 86.75505C214.7647 86.75505 214.4687 86.69662 214.2044 86.58005C213.9397 86.46787 213.72 86.31099 213.5362 86.10474C213.3525 85.90755 213.2134 85.66537 213.1191 85.39193C213.0206 85.11818 212.9712 84.82224 212.9712 84.50412C212.9712 84.1138 213.025 83.76412 213.1325 83.4638C213.2403 83.16318 213.3881 82.907867 213.5856 82.705992C213.7737 82.499742 214.0069 82.342867 214.2672 82.239742C214.5362 82.13193 214.8231 82.07818 215.1369 82.07818C215.3028 82.07818 215.4687 82.091617 215.6347 82.12318C215.8006 82.150055 215.9619 82.190367 216.1234 82.248492C216.2759 82.30693 216.4237 82.378492 216.5628 82.463805C216.7019 82.553492 216.8184 82.656617 216.9172 82.777555Z'/>
+<path d='M222.7102 84.18568V83.24412C222.6205 83.14974 222.5308 83.064742 222.432 82.988492C222.3423 82.912242 222.2436 82.84943 222.1361 82.79568C222.0373 82.74193 221.9255 82.701617 221.8086 82.670055C221.692 82.64318 221.562 82.629742 221.423 82.629742C221.3198 82.629742 221.2214 82.64318 221.1317 82.670055C221.0373 82.692555 220.9614 82.732867 220.8895 82.786617C220.8267 82.845055 220.773 82.916617 220.7326 83.00193C220.6923 83.087242 220.6742 83.19037 220.6742 83.3113C220.6742 83.43693 220.7102 83.5488 220.782 83.65193C220.8583 83.75505 220.9748 83.84037 221.1408 83.91662C221.302 83.99287 221.5126 84.05099 221.7683 84.09599C222.0286 84.14537 222.3423 84.17224 222.7102 84.18568ZM220.1317 86.04193L220.2751 85.7863C220.302 85.74599 220.3336 85.71005 220.3739 85.68318C220.4142 85.65193 220.4592 85.63849 220.513 85.63849C220.5801 85.63849 220.652 85.66537 220.7192 85.71005C220.7908 85.76412 220.8761 85.81787 220.9701 85.88068C221.0689 85.9388 221.1855 85.99724 221.3198 86.04193C221.4501 86.09568 221.6158 86.11818 221.8133 86.11818C222.1045 86.11818 222.3289 86.02849 222.4814 85.84474C222.6339 85.66537 222.7102 85.40068 222.7102 85.04662V84.69224C222.1942 84.6788 221.7548 84.63412 221.4008 84.55349C221.0464 84.46818 220.7551 84.36505 220.5351 84.23505C220.3155 84.10505 220.1542 83.96162 220.0555 83.79099C219.9567 83.62974 219.9076 83.45474 219.9076 83.27537C219.9076 83.069117 219.9389 82.889742 220.0108 82.74193C220.0736 82.58943 220.1677 82.463805 220.2798 82.365055C220.3964 82.266617 220.5308 82.194742 220.6876 82.140992C220.8448 82.096305 221.0105 82.069117 221.1855 82.069117S221.5173 82.087242 221.6608 82.114117C221.7998 82.150055 221.9342 82.194742 222.0598 82.248492C222.1855 82.311305 222.3064 82.38318 222.4186 82.463805C222.5308 82.553492 222.6473 82.647555 222.7683 82.759742L222.858 82.32943C222.8805 82.25318 222.9164 82.203805 222.9567 82.17693C222.997 82.15443 223.0598 82.140992 223.1361 82.140992H223.4901V85.04662C223.4901 85.30224 223.4542 85.53537 223.387 85.74599C223.3198 85.95693 223.2167 86.14068 223.082 86.28849C222.9476 86.43662 222.7817 86.55318 222.5845 86.63849C222.387 86.72349 222.163 86.7638 221.9073 86.7638C221.5533 86.7638 221.2348 86.70568 220.9433 86.58443C220.652 86.46349 220.383 86.28412 220.1317 86.04193ZM227.8658 85.87599L228.0764 86.16318C227.8883 86.3513 227.673 86.49943 227.4264 86.59787C227.1842 86.70568 226.9017 86.75505 226.5833 86.75505C226.238 86.75505 225.9376 86.69662 225.6686 86.58005C225.4086 86.46349 225.1842 86.30193 225.0048 86.09568C224.8211 85.88505 224.682 85.63849 224.5923 85.35162C224.4939 85.06443 224.4489 84.75068 224.4489 84.41443C224.4489 84.04224 224.4983 83.71474 224.6014 83.42349C224.7045 83.13193 224.8436 82.889742 225.023 82.68818C225.2023 82.49068 225.413 82.33818 225.6595 82.235055C225.9017 82.13193 226.1664 82.07818 226.4489 82.07818C226.6148 82.07818 226.7761 82.091617 226.933 82.118492C227.0901 82.145367 227.2423 82.18568 227.3905 82.248492C227.5339 82.302555 227.6686 82.378492 227.7939 82.463805C227.9195 82.549117 228.0317 82.656617 228.1301 82.777555L227.9061 83.069117C227.8702 83.118492 227.8208 83.14537 227.7536 83.14537C227.6998 83.14537 227.6461 83.122867 227.5876 83.073492C227.5339 83.028805 227.4667 82.97943 227.3814 82.921305C227.3008 82.862867 227.1976 82.813492 227.072 82.768805C226.9464 82.71943 226.7851 82.69693 226.5923 82.69693C226.3905 82.69693 226.2067 82.732867 226.0451 82.813492C225.8792 82.885367 225.7405 82.997555 225.6239 83.14537C225.5117 83.2888 225.422 83.46818 225.3592 83.68349C225.2964 83.89412 225.2652 84.14068 225.2652 84.41443C225.2652 84.6788 225.292 84.91662 225.3548 85.12724C225.4086 85.33818 225.4983 85.52193 225.6148 85.66974C225.727 85.81787 225.8705 85.93443 226.0408 86.01505C226.2111 86.0913 226.4086 86.13162 226.6327 86.13162C226.7986 86.13162 226.942 86.1138 227.0586 86.07787C227.1708 86.03755 227.2695 85.99724 227.3455 85.95224C227.4264 85.90755 227.4936 85.86724 227.5473 85.82693C227.6011 85.79099 227.6505 85.77287 227.6955 85.77287C227.7358 85.77287 227.7717 85.78193 227.7939 85.79974C227.8164 85.81787 227.8433 85.84474 227.8658 85.87599ZM230.3806 82.069117C230.5869 82.069117 230.7884 82.105055 230.9812 82.17693C231.1741 82.25318 231.34 82.351617 231.4791 82.481617L231.2459 82.862867C231.2144 82.912242 231.1741 82.939117 231.1337 82.939117C231.1112 82.939117 231.08 82.930055 231.0531 82.90318C231.0172 82.885367 230.9812 82.858492 230.9366 82.831617C230.8916 82.804742 230.8378 82.777555 230.775 82.759742C230.7169 82.732867 230.645 82.723805 230.5597 82.723805C230.4119 82.723805 230.2953 82.768805 230.2012 82.862867C230.1069 82.95693 230.0622 83.095992 230.0622 83.2888V86.01505H231.3759V86.59349H230.0622V88.15849H229.6584C229.6094 88.15849 229.5644 88.14506 229.5375 88.11349C229.5016 88.08662 229.4837 88.05068 229.4747 88.00599L229.2909 86.60256L228.5466 86.50818V86.19006C228.5466 86.13162 228.5644 86.08693 228.5959 86.06005C228.6272 86.02849 228.6675 86.01505 228.7169 86.01505H229.2641V83.23505C229.2641 82.858492 229.3581 82.571305 229.5553 82.369742C229.7437 82.167867 230.0219 82.069117 230.3806 82.069117ZM233.0435 86.68318H232.2454V82.140992H233.0435V86.68318ZM233.2138 88.10912C233.2138 88.18537 233.2004 88.26162 233.1644 88.3288C233.1376 88.40068 233.0929 88.46318 233.0388 88.51724C232.9894 88.5663 232.9269 88.60693 232.8594 88.63818C232.7879 88.66943 232.7116 88.68318 232.6354 88.68318C232.5591 88.68318 232.4829 88.66943 232.4201 88.63818C232.3485 88.60693 232.2901 88.5663 232.2407 88.51724C232.1913 88.46318 232.151 88.40068 232.1198 88.3288C232.0882 88.26162 232.0748 88.18537 232.0748 88.10912S232.0882 87.96099 232.1198 87.88943C232.151 87.82662 232.1913 87.7638 232.2407 87.71006C232.2901 87.66068 232.3485 87.62037 232.4201 87.5888C232.4829 87.55755 232.5591 87.54412 232.6354 87.54412C232.7116 87.54412 232.7879 87.55755 232.8594 87.5888C232.9269 87.62037 232.9894 87.66068 233.0388 87.71006C233.0929 87.7638 233.1376 87.82662 233.1644 87.88943C233.2004 87.96099 233.2138 88.03287 233.2138 88.10912ZM238.2444 86.68318H237.621C237.5629 86.68318 237.5135 86.66974 237.4732 86.63381C237.4329 86.60693 237.4013 86.56662 237.3835 86.51724L236.2176 83.5938C236.1773 83.48162 236.146 83.37412 236.1188 83.27099C236.0919 83.16787 236.0651 83.060055 236.0429 82.95693C236.0204 83.060055 235.9935 83.16787 235.9666 83.27099C235.9398 83.37412 235.9082 83.48162 235.8723 83.5938L234.7201 86.51724C234.7066 86.56224 234.6751 86.60256 234.6348 86.63381C234.5944 86.66537 234.5407 86.68318 234.4735 86.68318H233.8232L235.6751 82.140992H236.3926L238.2444 86.68318Z'/>
+<path d='M241.8816 84.90755H239.3975C239.4516 85.30224 239.5903 85.61162 239.8147 85.83568C240.0344 86.05537 240.3394 86.16756 240.7203 86.16756C240.9041 86.16756 241.0656 86.1363 241.2091 86.07787C241.3525 86.01505 241.4737 85.92537 241.5722 85.81787C241.6753 85.7013 241.7516 85.5713 241.8056 85.41412C241.8547 85.26193 241.8816 85.0913 241.8816 84.90755ZM242.5275 82.777555L242.3031 83.069117C242.2672 83.118492 242.2181 83.14537 242.1506 83.14537C242.1016 83.14537 242.0387 83.122867 241.9669 83.073492C241.8997 83.028805 241.81 82.97943 241.7069 82.92568C241.6037 82.87193 241.4781 82.822555 241.3303 82.777555C241.1866 82.728492 241.0162 82.705992 240.8147 82.705992C240.5994 82.705992 240.4066 82.74193 240.2316 82.813492C240.0569 82.880992 239.9087 82.988492 239.7831 83.127555C239.6578 83.27099 239.5591 83.45037 239.4919 83.66099C239.42 83.87193 239.3797 84.12287 239.3706 84.40974H242.4062C242.4825 84.40974 242.5319 84.43224 242.5587 84.47255C242.5856 84.51287 242.5991 84.59818 242.5991 84.7238C242.5991 85.04662 242.5497 85.33349 242.4556 85.58474C242.3616 85.84037 242.2269 86.05099 242.0566 86.22131C241.8906 86.3963 241.6887 86.5263 241.4556 86.61599C241.2272 86.71006 240.9759 86.75505 240.7025 86.75505C240.375 86.75505 240.0791 86.69662 239.8147 86.58005C239.55 86.46787 239.3303 86.31099 239.1466 86.10474C238.9628 85.90755 238.8237 85.66537 238.7294 85.39193C238.6309 85.11818 238.5816 84.82224 238.5816 84.50412C238.5816 84.1138 238.6353 83.76412 238.7428 83.4638C238.8506 83.16318 238.9984 82.907867 239.1959 82.705992C239.3841 82.499742 239.6172 82.342867 239.8775 82.239742C240.1466 82.13193 240.4334 82.07818 240.7472 82.07818C240.9131 82.07818 241.0791 82.091617 241.245 82.12318C241.4109 82.150055 241.5722 82.190367 241.7337 82.248492C241.8862 82.30693 242.0341 82.378492 242.1731 82.463805C242.3122 82.553492 242.4287 82.656617 242.5275 82.777555ZM243.5042 82.634117C243.5042 82.553492 243.5176 82.481617 243.5445 82.410055C243.5758 82.347242 243.6161 82.28443 243.6611 82.235055C243.7148 82.18568 243.773 82.145367 243.8405 82.114117C243.9076 82.087242 243.9839 82.073805 244.0601 82.073805C244.1364 82.073805 244.2126 82.087242 244.2798 82.114117C244.347 82.145367 244.4098 82.18568 244.4592 82.235055S244.5489 82.347242 244.5801 82.410055C244.6117 82.481617 244.6252 82.553492 244.6252 82.634117C244.6252 82.710367 244.6117 82.786617 244.5801 82.853805C244.5489 82.921305 244.5086 82.984117 244.4592 83.03318C244.4098 83.082555 244.347 83.122867 244.2798 83.15443C244.2126 83.18568 244.1364 83.19912 244.0601 83.19912C243.9839 83.19912 243.9076 83.18568 243.8405 83.15443C243.773 83.122867 243.7148 83.082555 243.6611 83.03318C243.6161 82.984117 243.5758 82.921305 243.5445 82.853805C243.5176 82.786617 243.5042 82.710367 243.5042 82.634117ZM243.5042 85.99724C243.5042 85.9163 243.5176 85.84474 243.5445 85.77287C243.5758 85.71005 243.6161 85.64755 243.6611 85.59818C243.7148 85.5488 243.773 85.50849 243.8405 85.47693C243.9076 85.45005 243.9839 85.43662 244.0601 85.43662C244.1364 85.43662 244.2126 85.45005 244.2798 85.47693C244.347 85.50849 244.4098 85.5488 244.4592 85.59818C244.5086 85.64755 244.5489 85.71005 244.5801 85.77287C244.6117 85.84474 244.6252 85.9163 244.6252 85.99724C244.6252 86.07349 244.6117 86.14974 244.5801 86.21693C244.5489 86.28412 244.5086 86.34693 244.4592 86.3963C244.4098 86.44568 244.347 86.48599 244.2798 86.51724C244.2126 86.5488 244.1364 86.56224 244.0601 86.56224C243.9839 86.56224 243.9076 86.5488 243.8405 86.51724C243.773 86.48599 243.7148 86.44568 243.6611 86.3963C243.6161 86.34693 243.5758 86.28412 243.5445 86.21693C243.5176 86.14974 243.5042 86.07349 243.5042 85.99724Z'/>
+<path d='M186.18178 76.66978H185.11896V72.72853C185.11896 72.64322 185.12365 72.54915 185.12803 72.44603C185.1324 72.3429 185.14146 72.23978 185.15053 72.13665L181.75178 76.47697C181.72021 76.51728 181.68896 76.55322 181.66209 76.58009C181.63521 76.60259 181.60803 76.62509 181.58115 76.63384C181.5499 76.65197 181.51865 76.66072 181.48271 76.66072C181.4424 76.66978 181.3974 76.66978 181.34803 76.66978H180.715839V70.18603H181.77865V74.1679C181.77865 74.33353 181.76959 74.51759 181.75178 74.71478L185.13709 70.39228C185.19521 70.31603 185.25803 70.266655 185.32084 70.230717C185.38803 70.203842 185.46896 70.18603 185.56303 70.18603H186.18178V76.66978Z'/>
+<path d='M189.33959 74.85822C188.99428 74.85822 188.6849 74.80447 188.4024 74.69228C188.1199 74.5804 187.88209 74.42322 187.68053 74.22166C187.48303 74.01978 187.33084 73.76853 187.22303 73.47728C187.11115 73.18572 187.05709 72.85853 187.05709 72.4954C187.05709 72.13197 187.11115 71.80009 187.22303 71.50884C187.33084 71.21728 187.48303 70.966342 187.68053 70.760092C187.88209 70.553842 188.1199 70.396655 188.4024 70.28478C188.6849 70.172592 188.99428 70.118842 189.33959 70.118842C189.68021 70.118842 189.98959 70.172592 190.2721 70.28478C190.5502 70.396655 190.7877 70.553842 190.9896 70.760092C191.1868 70.966342 191.3393 71.21728 191.4471 71.50884C191.5546 71.80009 191.6083 72.13197 191.6083 72.4954C191.6083 72.85853 191.5546 73.18572 191.4471 73.47728C191.3393 73.76853 191.1868 74.01978 190.9896 74.22166C190.7877 74.42322 190.5502 74.5804 190.2721 74.69228C189.98959 74.80447 189.68021 74.85822 189.33959 74.85822ZM189.33959 70.970717C188.94928 70.970717 188.6624 71.100717 188.47865 71.36072C188.29021 71.61634 188.19615 71.9929 188.19615 72.48634C188.19615 72.97947 188.29021 73.35603 188.47865 73.62072C188.6624 73.88072 188.94928 74.01072 189.33959 74.01072C189.72053 74.01072 190.003 73.88072 190.1915 73.62072C190.3708 73.36072 190.4649 72.98384 190.4649 72.48634C190.4649 71.98853 190.3708 71.61197 190.1915 71.35634C190.003 71.100717 189.72053 70.970717 189.33959 70.970717Z'/>
+<path d='M198.99439 70.894467H195.90033V73.08728H198.40252V73.76853H195.90033V75.90291H198.99002V76.61134H195.030644V70.18603H198.99002L198.99439 70.894467ZM203.49525 75.60697L203.70619 76.01947C203.48182 76.23478 203.22182 76.40072 202.93025 76.5129C202.63432 76.62509 202.30713 76.68322 201.94838 76.68322C201.62994 76.68322 201.34307 76.63384 201.10088 76.5354C200.84994 76.43665 200.64369 76.30666 200.47307 76.14072C200.30713 75.97478 200.17713 75.78634 200.08744 75.57572C200.00244 75.36509 199.95744 75.1454 199.95744 74.91665C199.95744 74.63415 200.00244 74.39197 200.08744 74.20353C200.17713 74.00634 200.29369 73.84947 200.43744 73.71947C200.58088 73.58947 200.74682 73.48634 200.93057 73.4054C201.11432 73.32478 201.30275 73.25291 201.49557 73.19041C201.68838 73.13197 201.8765 73.07353 202.06057 73.01103C202.24432 72.95697 202.41025 72.8854 202.55369 72.80009C202.69713 72.71509 202.81369 72.61197 202.90338 72.49072C202.98869 72.36509 203.03338 72.20384 203.03338 72.01103C203.03338 71.83603 203.00213 71.67478 202.94369 71.53134C202.88557 71.38759 202.79588 71.26228 202.68838 71.16353C202.5715 71.05603 202.43713 70.97978 202.27557 70.921342C202.11432 70.863217 201.93057 70.836342 201.72432 70.836342C201.55838 70.836342 201.41025 70.84978 201.28025 70.885405C201.15025 70.91228 201.02932 70.952905 200.93057 71.001967C200.82307 71.051342 200.73338 71.100717 200.65244 71.159155C200.57182 71.21728 200.49994 71.26665 200.43744 71.31603C200.37463 71.3654 200.32057 71.40572 200.26682 71.43259C200.22213 71.46853 200.17713 71.48197 200.13682 71.48197C200.0965 71.48197 200.05619 71.46853 200.02463 71.4504C199.989 71.42353 199.95744 71.39665 199.93525 71.3654L199.684 70.952905C199.92619 70.69728 200.21744 70.49103 200.55838 70.33853C200.899 70.190405 201.28025 70.114155 201.69744 70.114155C202.03807 70.114155 202.34307 70.168217 202.60744 70.271342C202.8765 70.374467 203.10088 70.517905 203.289 70.701655C203.46838 70.885405 203.61182 71.100717 203.70619 71.3429C203.80025 71.59384 203.84963 71.85415 203.84963 72.13665C203.84963 72.40103 203.80463 72.6254 203.71963 72.80915C203.62994 72.9929 203.51338 73.1454 203.36994 73.27103C203.22182 73.39665 203.05588 73.49978 202.8765 73.58478C202.68838 73.6654 202.49994 73.73728 202.3115 73.80447C202.11432 73.87197 201.92588 73.93447 201.7465 73.99728C201.55838 74.05572 201.39682 74.12728 201.25338 74.21259C201.10525 74.29791 200.98869 74.39634 200.90369 74.51759C200.814 74.63415 200.769 74.78197 200.769 74.96134C200.769 75.1004 200.79588 75.23478 200.84525 75.35166C200.89463 75.47697 200.97088 75.58009 201.074 75.66978C201.17275 75.75947 201.29807 75.83134 201.44182 75.88072C201.594 75.93447 201.76463 75.96134 201.95744 75.96134C202.16369 75.96134 202.33838 75.93447 202.48213 75.88509C202.62994 75.83572 202.75088 75.77759 202.85869 75.71915C202.95713 75.65634 203.04682 75.59822 203.11432 75.54884C203.1815 75.49947 203.24432 75.47259 203.29369 75.47259C203.33838 75.47259 203.37869 75.48603 203.40557 75.50384C203.4415 75.53072 203.46838 75.56228 203.49525 75.60697ZM208.817 70.795717H207.5526V76.62509H206.9023L204.9876 74.9704L205.2388 74.62509C205.2523 74.60259 205.2745 74.58478 205.3017 74.56697C205.3329 74.54884 205.3642 74.5354 205.3957 74.53103C205.427 74.52634 205.4629 74.52634 205.5032 74.5354C205.5435 74.53978 205.5795 74.56228 205.6198 74.59384L206.7632 75.57572C206.7542 75.44134 206.7498 75.30666 206.7498 75.17665V70.795717H205.3732V70.18603H208.817V70.795717ZM212.0443 70.777905C211.8337 70.777905 211.6409 70.813842 211.4796 70.876655C211.309 70.948217 211.1699 71.042592 211.0581 71.16353C210.9415 71.28447 210.8518 71.43259 210.7934 71.6029C210.7353 71.77322 210.7037 71.96165 210.7037 72.1679C210.7037 72.3429 210.7353 72.51322 210.7981 72.67916C210.8653 72.8404 210.9593 72.98384 211.0759 73.10947C211.2015 73.23072 211.3449 73.32915 211.5199 73.4054C211.6946 73.47728 211.8874 73.51322 212.1028 73.51322C212.3046 73.51322 212.4884 73.48166 212.6543 73.41884C212.8203 73.35603 212.9681 73.26634 213.0846 73.1454C213.2103 73.02884 213.2999 72.8854 213.3671 72.71509C213.4346 72.54915 213.4659 72.36072 213.4659 72.15009C213.4659 71.95259 213.4346 71.76884 213.3628 71.6029C213.2999 71.43697 213.2012 71.28915 213.0759 71.167905C212.9546 71.046967 212.8068 70.948217 212.6274 70.88103C212.4571 70.813842 212.2596 70.777905 212.0443 70.777905ZM211.5781 74.20353L213.4837 76.61134H212.7753C212.6812 76.61134 212.5959 76.59353 212.5196 76.55322C212.4481 76.51728 212.3896 76.47259 212.3493 76.41853L210.7171 74.22603C210.4437 73.8629 210.2465 73.52197 210.1253 73.20822C209.9999 72.8854 209.9371 72.58947 209.9371 72.30697C209.9371 71.97072 209.9862 71.67009 210.0893 71.39665C210.1881 71.127592 210.3315 70.898842 210.5109 70.70603C210.6993 70.517905 210.919 70.374467 211.1837 70.266655C211.4481 70.168217 211.7396 70.114155 212.0624 70.114155C212.3896 70.114155 212.6856 70.168217 212.9593 70.275717C213.2281 70.383217 213.4615 70.531342 213.6496 70.719467C213.8471 70.907905 213.9949 71.127592 214.1024 71.38322C214.2103 71.63884 214.264 71.91228 214.264 72.20822C214.264 72.51322 214.2146 72.78665 214.1115 73.01978C214.0084 73.26197 213.874 73.45915 213.7034 73.62072C213.5287 73.78665 213.3268 73.90759 213.0981 73.99728C212.8696 74.07822 212.6228 74.1229 212.3628 74.1229C212.1474 74.1229 211.9503 74.09603 211.7665 74.03759C211.5828 73.97947 211.4168 73.89884 211.2643 73.79572C211.3137 73.8629 211.3628 73.92572 211.4168 73.99728C211.4662 74.06009 211.5199 74.13197 211.5781 74.20353Z'/>
+<path d='M219.4898 74.80009C219.1535 74.80009 218.8529 74.74603 218.5842 74.63415C218.3195 74.52197 218.0907 74.36509 217.9026 74.16322C217.7142 73.96134 217.5707 73.71478 217.472 73.42353C217.3688 73.13634 217.3195 72.81353 217.3195 72.45947C217.3195 72.10072 217.3688 71.7779 217.472 71.49072C217.5707 71.20384 217.7142 70.95728 217.9026 70.755405C218.0907 70.553842 218.3195 70.396655 218.5842 70.28478C218.8529 70.176967 219.1535 70.123217 219.4898 70.123217C219.8217 70.123217 220.122 70.176967 220.3867 70.28478C220.651 70.396655 220.8798 70.553842 221.0682 70.755405C221.2563 70.95728 221.3998 71.20384 221.4985 71.49072C221.6017 71.7779 221.651 72.10072 221.651 72.45947C221.651 72.81353 221.6017 73.13634 221.4985 73.42353C221.3998 73.71478 221.2563 73.96134 221.0682 74.16322C220.8798 74.36509 220.651 74.52197 220.3867 74.63415C220.122 74.74603 219.8217 74.80009 219.4898 74.80009ZM219.4898 70.746655C219.037 70.746655 218.696 70.894467 218.4763 71.19947C218.2523 71.4954 218.1401 71.91697 218.1401 72.45478C218.1401 72.72384 218.167 72.96603 218.2254 73.18134C218.2792 73.39197 218.3598 73.57134 218.4763 73.71947C218.5842 73.86728 218.7276 73.97947 218.8979 74.05572C219.0638 74.13197 219.261 74.17228 219.4898 74.17228C219.9382 74.17228 220.2745 74.01978 220.4942 73.71947C220.7138 73.41884 220.826 72.99759 220.826 72.45478C220.826 71.91697 220.7138 71.4954 220.4942 71.19947C220.2745 70.894467 219.9382 70.746655 219.4898 70.746655ZM226.394 74.72822H225.5959V71.38322C225.4212 71.18603 225.2328 71.029155 225.0312 70.921342C224.8246 70.80478 224.6049 70.75103 224.3674 70.75103C224.0446 70.75103 223.8024 70.845092 223.6499 71.03353C223.4887 71.22197 223.4124 71.48634 223.4124 71.83165V74.72822H222.6143V71.83165C222.6143 71.57603 222.6456 71.33853 222.7084 71.127592C222.7756 70.916967 222.8699 70.733217 222.9999 70.585092C223.1299 70.43728 223.2868 70.320405 223.4796 70.23978C223.6681 70.15478 223.8878 70.114155 224.1343 70.114155C224.4528 70.114155 224.7306 70.181655 224.9771 70.311655C225.224 70.44603 225.4437 70.62103 225.6409 70.840717L225.7037 70.351967C225.7349 70.23978 225.8068 70.18603 225.919 70.18603H226.394V74.72822ZM229.0524 70.114155C229.2587 70.114155 229.4603 70.150092 229.6531 70.221967C229.8459 70.298217 230.0118 70.396655 230.1509 70.526655L229.9178 70.907905C229.8862 70.95728 229.8459 70.984155 229.8056 70.984155C229.7831 70.984155 229.7518 70.975092 229.7249 70.948217C229.689 70.930405 229.6531 70.90353 229.6084 70.876655C229.5634 70.84978 229.5096 70.822592 229.4468 70.80478C229.3887 70.777905 229.3168 70.768842 229.2315 70.768842C229.0837 70.768842 228.9671 70.813842 228.8731 70.907905C228.7787 71.001967 228.734 71.14103 228.734 71.33384V74.06009H230.0478V74.63853H228.734V76.20353H228.3303C228.2812 76.20353 228.2362 76.19009 228.2093 76.15853C228.1734 76.13165 228.1556 76.09572 228.1465 76.05103L227.9628 74.64759L227.2184 74.55322V74.23509C227.2184 74.17665 227.2362 74.13197 227.2678 74.10509C227.299 74.07353 227.3393 74.06009 227.3887 74.06009H227.9359V71.28009C227.9359 70.90353 228.0299 70.616342 228.2271 70.41478C228.4156 70.212905 228.6937 70.114155 229.0524 70.114155ZM231.675 71.28009V73.47728C231.8406 73.69697 232.02 73.8629 232.2128 73.98384C232.4103 74.10509 232.6388 74.16322 232.8991 74.16322C233.0828 74.16322 233.2444 74.13197 233.3878 74.06915C233.5313 74.00634 233.6522 73.90759 233.751 73.77322C233.8497 73.63415 233.926 73.45915 233.9797 73.24853C234.0291 73.0379 234.056 72.78228 234.056 72.48634C234.056 71.92572 233.9438 71.4954 233.715 71.19478C233.4863 70.894467 233.1635 70.741967 232.7375 70.741967C232.5222 70.741967 232.3294 70.78228 232.1547 70.863217C231.9797 70.943842 231.8228 71.082905 231.675 71.28009ZM231.6344 74.02415L231.5628 74.56228C231.536 74.67447 231.4641 74.72822 231.3519 74.72822H230.8722V68.6479H231.675V70.656967C231.8272 70.49103 232.0022 70.356342 232.2041 70.266655C232.4013 70.168217 232.6388 70.123217 232.9169 70.123217C233.2219 70.123217 233.4953 70.18603 233.7375 70.302592C233.9841 70.428217 234.1903 70.589467 234.3563 70.80478C234.5266 71.01103 234.6566 71.26228 234.7463 71.54915C234.836 71.84072 234.881 72.15009 234.881 72.48634C234.881 72.8629 234.8406 73.19478 234.7597 73.48634C234.6791 73.77759 234.5625 74.01978 234.4147 74.21259C234.2666 74.40978 234.0828 74.5579 233.8719 74.66103C233.6613 74.75978 233.4235 74.80884 233.1591 74.80884C232.8363 74.80884 232.5494 74.73728 232.2981 74.59384C232.0469 74.45009 231.8272 74.26197 231.6344 74.02415ZM239.6328 74.72822H238.8347V71.38322C238.66 71.18603 238.4716 71.029155 238.27 70.921342C238.0635 70.80478 237.8438 70.75103 237.6063 70.75103C237.2835 70.75103 237.0413 70.845092 236.8888 71.03353C236.7275 71.22197 236.6513 71.48634 236.6513 71.83165V74.72822H235.8531V71.83165C235.8531 71.57603 235.8844 71.33853 235.9472 71.127592C236.0144 70.916967 236.1088 70.733217 236.2388 70.585092C236.3688 70.43728 236.5256 70.320405 236.7185 70.23978C236.9069 70.15478 237.1266 70.114155 237.3731 70.114155C237.6916 70.114155 237.9694 70.181655 238.216 70.311655C238.4628 70.44603 238.6825 70.62103 238.8797 70.840717L238.9425 70.351967C238.9738 70.23978 239.0456 70.18603 239.1578 70.18603H239.6328V74.72822ZM242.2913 70.114155C242.4975 70.114155 242.6991 70.150092 242.8919 70.221967C243.0847 70.298217 243.2506 70.396655 243.3897 70.526655L243.1566 70.907905C243.125 70.95728 243.0847 70.984155 243.0444 70.984155C243.0219 70.984155 242.9906 70.975092 242.9638 70.948217C242.9278 70.930405 242.8919 70.90353 242.8472 70.876655C242.8022 70.84978 242.7485 70.822592 242.6856 70.80478C242.6275 70.777905 242.5556 70.768842 242.4703 70.768842C242.3225 70.768842 242.206 70.813842 242.1119 70.907905C242.0175 71.001967 241.9728 71.14103 241.9728 71.33384V74.06009H243.2866V74.63853H241.9728V76.20353H241.5691C241.52 76.20353 241.475 76.19009 241.4481 76.15853C241.4122 76.13165 241.3944 76.09572 241.3853 76.05103L241.2016 74.64759L240.4572 74.55322V74.23509C240.4572 74.17665 240.475 74.13197 240.5066 74.10509C240.5378 74.07353 240.5781 74.06009 240.6275 74.06009H241.1747V71.28009C241.1747 70.90353 241.2688 70.616342 241.466 70.41478C241.6544 70.212905 241.9325 70.114155 242.2913 70.114155ZM243.9767 70.679155C243.9767 70.59853 243.9901 70.526655 244.017 70.455092C244.0482 70.39228 244.0885 70.329467 244.1335 70.280092C244.1873 70.230717 244.2457 70.190405 244.3129 70.159155C244.3801 70.13228 244.4563 70.118842 244.5326 70.118842C244.6088 70.118842 244.6851 70.13228 244.7523 70.159155C244.8195 70.190405 244.8823 70.230717 244.9317 70.280092C244.981 70.329467 245.0213 70.39228 245.0526 70.455092C245.0842 70.526655 245.0976 70.59853 245.0976 70.679155C245.0976 70.755405 245.0842 70.831655 245.0526 70.898842C245.0213 70.966342 244.981 71.029155 244.9317 71.078217C244.8823 71.127592 244.8195 71.167905 244.7523 71.19947C244.6851 71.23072 244.6088 71.24415 244.5326 71.24415C244.4563 71.24415 244.3801 71.23072 244.3129 71.19947C244.2457 71.167905 244.1873 71.127592 244.1335 71.078217C244.0885 71.029155 244.0482 70.966342 244.017 70.898842C243.9901 70.831655 243.9767 70.755405 243.9767 70.679155Z'/>
+</g>
+</g>
+</svg>
diff --git a/src/images/es_state.svg b/src/images/es_state.svg
new file mode 100644
index 0000000..d50e2fd
--- /dev/null
+++ b/src/images/es_state.svg
@@ -0,0 +1,71 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!-- This file was generated by dvisvgm 2.11.1 -->
+<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='173.298pt' height='199.468pt' viewBox='0 -199.468 173.298 199.468'>
+<g id='page1'>
+<g transform='matrix(1 0 0 -1 0 0)'>
+<path d='M70.21637 193.3456L70.15669 194.11278C70.14169 194.20247 70.11669 194.26716 70.082 194.30216C70.047 194.33685 69.97731 194.35685 69.88262 194.35685H69.374498V189.309972H70.26637V192.49841C70.33106 192.67278 70.40075 192.82747 70.47544 192.95685C70.55512 193.09653 70.64481 193.20591 70.7445 193.2956C70.83919 193.39028 70.95387 193.45997 71.07325 193.50497C71.20294 193.54966 71.34231 193.57466 71.502 193.57466C71.61637 193.57466 71.71606 193.56466 71.80575 193.54466C71.89544 193.52497 71.96512 193.51497 72.01012 193.51497C72.08981 193.51497 72.1395 193.55466 72.1595 193.63935L72.22419 194.30216C72.1495 194.35185 72.05981 194.38685 71.96012 194.41153C71.86543 194.43653 71.76106 194.44653 71.65637 194.44653C71.32262 194.44653 71.03856 194.35185 70.8045 194.15247C70.57012 193.96341 70.37575 193.68935 70.21637 193.3456Z'/>
+<path d='M76.17809 192.38403H73.41809C73.47778 192.82247 73.63215 193.16622 73.88153 193.41528C74.12559 193.65935 74.46434 193.78403 74.88778 193.78403C75.09215 193.78403 75.27153 193.74903 75.4309 193.68435C75.59028 193.61466 75.72465 193.51497 75.83434 193.39528C75.94903 193.26591 76.03372 193.12122 76.0934 192.94685C76.1484 192.77747 76.17809 192.5881 76.17809 192.38403ZM76.89559 190.017472L76.64653 190.34122C76.60653 190.39622 76.55184 190.42591 76.47715 190.42591C76.42215 190.42591 76.35247 190.40091 76.27278 190.34622C76.19809 190.296534 76.0984 190.241534 75.98372 190.181847C75.86934 190.122159 75.72965 190.067159 75.56528 190.017472C75.4059 189.962784 75.21653 189.937784 74.99247 189.937784C74.7534 189.937784 74.53903 189.977472 74.34465 190.057159C74.15028 190.132159 73.9859 190.251534 73.84653 190.40591C73.70715 190.5656 73.59747 190.76466 73.52278 190.99903C73.44309 191.2331 73.39809 191.51216 73.38809 191.83091H76.7609C76.8459 191.83091 76.90059 191.85591 76.93059 191.9006C76.96028 191.9456 76.97528 192.04028 76.97528 192.17966C76.97528 192.53841 76.92059 192.85716 76.8159 193.13622C76.71122 193.42028 76.56184 193.65435 76.37247 193.84372C76.18809 194.0381 75.96403 194.18247 75.70497 194.28216C75.4509 194.38685 75.17184 194.43653 74.86778 194.43653C74.50403 194.43653 74.17528 194.37185 73.88153 194.24216C73.58747 194.11778 73.3434 193.94341 73.13903 193.71403C72.93465 193.49497 72.78028 193.22591 72.67559 192.92216C72.56622 192.6181 72.51122 192.28935 72.51122 191.9356C72.51122 191.50216 72.57122 191.11341 72.69059 190.77966C72.81028 190.44591 72.97465 190.161847 73.19372 189.937784C73.40309 189.708409 73.66215 189.534034 73.95122 189.419659C74.24997 189.299972 74.56903 189.240284 74.91778 189.240284C75.10215 189.240284 75.28622 189.255284 75.47059 189.289972C75.65497 189.319972 75.83434 189.364659 76.01372 189.429659C76.18309 189.494347 76.34747 189.574034 76.50184 189.668722C76.65653 189.768409 76.7859 189.882784 76.89559 190.017472ZM80.9999 193.52497L81.1993 193.84872C81.0049 194.0331 80.7758 194.17247 80.5168 194.28216C80.2477 194.38185 79.9536 194.43653 79.6199 194.43653C79.3358 194.43653 79.0818 194.39685 78.8577 194.31716C78.63333 194.23716 78.44895 194.13278 78.29458 193.9931C78.1402 193.86372 78.02551 193.70435 77.94583 193.52497C77.86614 193.3506 77.82645 193.16622 77.82645 192.97185C77.82645 192.75747 77.86614 192.57341 77.93583 192.41872C78.01551 192.26935 78.1102 192.14466 78.23489 192.04028C78.35958 191.9356 78.49895 191.85091 78.65333 191.78122C78.8127 191.71622 78.9721 191.65653 79.1418 191.60185C79.3011 191.54685 79.4655 191.49716 79.6199 191.45216C79.7793 191.40247 79.919 191.34278 80.0433 191.28278C80.168 191.2131 80.2677 191.13841 80.3374 191.04372C80.4171 190.95403 80.4521 190.83935 80.4521 190.69997C80.4521 190.58528 80.4321 190.48091 80.3871 190.38122C80.3474 190.281534 80.2824 190.191847 80.1977 190.117159C80.113 190.042472 80.0036 189.977472 79.874 189.937784C79.7446 189.887784 79.5949 189.868097 79.4205 189.868097C79.2165 189.868097 79.0471 189.892784 78.9124 189.937784C78.778 189.982472 78.66333 190.037472 78.56364 190.092159C78.47395 190.146847 78.38926 190.201847 78.32458 190.246534C78.25989 190.291534 78.19489 190.31622 78.1352 190.31622C78.08051 190.31622 78.03051 190.306534 77.99583 190.281534C77.96083 190.256534 77.92583 190.226534 77.90114 190.181847L77.69176 189.843097C77.89114 189.663722 78.1352 189.519347 78.41926 189.399659C78.7033 189.289972 79.0221 189.230284 79.3758 189.230284C79.6846 189.230284 79.9586 189.269972 80.1927 189.354659C80.4271 189.439659 80.6265 189.549034 80.7908 189.698722C80.9552 189.838097 81.0746 190.012472 81.1593 190.206847C81.244 190.40591 81.284 190.62028 81.284 190.85435C81.284 191.05872 81.244 191.2331 81.1743 191.37247C81.0946 191.52216 80.9999 191.64153 80.8755 191.74122C80.7508 191.84091 80.6115 191.9256 80.4568 191.99028C80.3024 192.05528 80.138 192.11997 79.9786 192.16966C79.8093 192.22966 79.6499 192.27935 79.4952 192.32903C79.3408 192.37403 79.2015 192.42872 79.0768 192.49341C78.9524 192.55841 78.8527 192.6331 78.783 192.71778C78.7033 192.80247 78.66833 192.91216 78.66833 193.04153C78.66833 193.14622 78.6933 193.24091 78.733 193.3256C78.783 193.41528 78.8427 193.49497 78.9324 193.55966C79.0121 193.62435 79.1168 193.67935 79.2361 193.71403C79.3558 193.75403 79.4905 193.77403 79.6399 193.77403C79.8143 193.77403 79.9636 193.75403 80.0883 193.71403C80.2127 193.67935 80.3224 193.63435 80.4171 193.59466C80.5068 193.54466 80.5815 193.50497 80.6461 193.46997C80.7111 193.43528 80.7658 193.41528 80.8155 193.41528C80.9002 193.41528 80.9602 193.45028 80.9999 193.52497ZM85.7521 192.38403H82.9921C83.0518 192.82247 83.2061 193.16622 83.4555 193.41528C83.6996 193.65935 84.0383 193.78403 84.4618 193.78403C84.6661 193.78403 84.8455 193.74903 85.0049 193.68435C85.1643 193.61466 85.2986 193.51497 85.4083 193.39528C85.523 193.26591 85.6077 193.12122 85.6674 192.94685C85.7224 192.77747 85.7521 192.5881 85.7521 192.38403ZM86.4696 190.017472L86.2205 190.34122C86.1805 190.39622 86.1258 190.42591 86.0511 190.42591C85.9961 190.42591 85.9264 190.40091 85.8468 190.34622C85.7721 190.296534 85.6724 190.241534 85.5577 190.181847C85.4433 190.122159 85.3036 190.067159 85.1393 190.017472C84.9799 189.962784 84.7905 189.937784 84.5665 189.937784C84.3274 189.937784 84.113 189.977472 83.9186 190.057159C83.7243 190.132159 83.5599 190.251534 83.4205 190.40591C83.2811 190.5656 83.1715 190.76466 83.0968 190.99903C83.0171 191.2331 82.9721 191.51216 82.9621 191.83091H86.3349C86.4199 191.83091 86.4746 191.85591 86.5046 191.9006C86.5343 191.9456 86.5493 192.04028 86.5493 192.17966C86.5493 192.53841 86.4946 192.85716 86.3899 193.13622C86.2852 193.42028 86.1358 193.65435 85.9465 193.84372C85.7621 194.0381 85.538 194.18247 85.279 194.28216C85.0249 194.38685 84.7458 194.43653 84.4418 194.43653C84.078 194.43653 83.7493 194.37185 83.4555 194.24216C83.1615 194.11778 82.9174 193.94341 82.713 193.71403C82.5086 193.49497 82.3543 193.22591 82.2496 192.92216C82.1402 192.6181 82.0852 192.28935 82.0852 191.9356C82.0852 191.50216 82.1452 191.11341 82.2646 190.77966C82.3843 190.44591 82.5486 190.161847 82.7677 189.937784C82.9771 189.708409 83.2361 189.534034 83.5252 189.419659C83.824 189.299972 84.143 189.240284 84.4918 189.240284C84.6761 189.240284 84.8602 189.255284 85.0446 189.289972C85.229 189.319972 85.4083 189.364659 85.5877 189.429659C85.7571 189.494347 85.9215 189.574034 86.0758 189.668722C86.2305 189.768409 86.3599 189.882784 86.4696 190.017472Z'/>
+<path d='M89.1379 189.230284C89.3673 189.230284 89.5914 189.269972 89.8057 189.349972C90.0198 189.434659 90.2042 189.544034 90.3586 189.688722L90.0995 190.112159C90.0648 190.166847 90.0198 190.196847 89.9751 190.196847C89.9501 190.196847 89.9151 190.186847 89.8854 190.156847C89.8454 190.137159 89.8057 190.107159 89.7557 190.077159C89.7061 190.047472 89.6461 190.017472 89.5764 189.997472C89.5117 189.967472 89.432 189.957784 89.3373 189.957784C89.1729 189.957784 89.0432 190.007472 88.9386 190.112159C88.8342 190.216847 88.7842 190.37122 88.7842 190.58528V193.61466H90.2439V194.25716H88.7842V195.99591H88.3357C88.2811 195.99591 88.2314 195.98091 88.2014 195.94622C88.1614 195.91622 88.1417 195.87653 88.1317 195.82653L87.9273 194.26716L87.1004 194.16247V193.80872C87.1004 193.74403 87.1201 193.69435 87.1551 193.66435C87.1901 193.62935 87.2348 193.61466 87.2895 193.61466H87.8973V190.5256C87.8973 190.107159 88.002 189.788409 88.2214 189.564034C88.4304 189.339972 88.7395 189.230284 89.1379 189.230284Z'/>
+<path d='M89.16406 165.4609H69.97266C67.7734 165.4609 65.9883 163.6758 65.9883 161.4727V144.5391C65.9883 142.3359 67.7734 140.5508 69.97266 140.5508H89.16406C91.3633 140.5508 93.1484 142.3359 93.1484 144.5391V161.4727C93.1484 163.6758 91.3633 165.4609 89.16406 165.4609Z' fill='#e6ffff'/>
+<path d='M89.16406 165.4609H69.97266C67.7734 165.4609 65.9883 163.6758 65.9883 161.4727V144.5391C65.9883 142.3359 67.7734 140.5508 69.97266 140.5508H89.16406C91.3633 140.5508 93.1484 142.3359 93.1484 144.5391V161.4727C93.1484 163.6758 91.3633 165.4609 89.16406 165.4609Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M72.72778 150.213174H71.18341V152.69942H72.72778C73.25091 152.69942 73.64435 152.59474 73.90841 152.37536C74.17247 152.1663 74.30216 151.87224 74.30216 151.50349C74.30216 151.31442 74.27216 151.14005 74.21247 150.98036C74.15247 150.82599 74.0581 150.69161 73.93341 150.57192C73.80372 150.46224 73.63935 150.372549 73.44028 150.307861C73.24091 150.243174 73.00185 150.213174 72.72778 150.213174ZM71.18341 155.82317H72.49841C73.03153 155.82317 73.42028 155.72349 73.67435 155.53411C73.92841 155.33474 74.0531 155.03099 74.0531 154.60755C74.0531 154.42817 74.0231 154.2638 73.95841 154.10911C73.89341 153.95974 73.79872 153.83036 73.66435 153.72567C73.53497 153.62099 73.37028 153.5363 73.16622 153.47661C72.96685 153.41661 72.73278 153.38692 72.45872 153.38692H71.18341V155.82317ZM72.49841 156.58536H70.221847V149.445986H72.74278C73.14122 149.445986 73.49497 149.495674 73.80872 149.595361C74.12278 149.690049 74.38185 149.829736 74.60091 150.009111C74.81028 150.188174 74.97466 150.402549 75.08935 150.65161C75.19872 150.90067 75.25372 151.17474 75.25372 151.4788C75.25372 151.92224 75.11903 152.28567 74.85997 152.55474C74.59091 152.8338 74.19747 153.01817 73.67435 153.11786C73.89841 153.18755 74.09778 153.27724 74.26216 153.39192C74.43153 153.5013 74.57122 153.62599 74.6806 153.76536C74.79028 153.90505 74.86997 154.05442 74.92997 154.2188C74.97966 154.37817 75.00966 154.54755 75.00966 154.72192C75.00966 155.01099 74.95966 155.27005 74.86497 155.50411C74.77028 155.73349 74.62091 155.92786 74.41153 156.08724C74.21247 156.24661 73.94841 156.3713 73.63435 156.45599C73.3156 156.54067 72.93685 156.58536 72.49841 156.58536ZM77.62888 149.445986V156.58536H76.66263V149.445986H77.62888ZM83.104 155.46942L83.338 155.92786C83.089 156.16692 82.7999 156.3513 82.4761 156.47567C82.1474 156.60036 81.7836 156.66505 81.3849 156.66505C81.0311 156.66505 80.7124 156.61036 80.4433 156.50067C80.1643 156.39099 79.9352 156.24661 79.7458 156.06224C79.5615 155.87786 79.4171 155.6688 79.3174 155.43442C79.22271 155.20036 79.17302 154.9563 79.17302 154.70224C79.17302 154.38817 79.22271 154.11911 79.3174 153.91005C79.4171 153.69067 79.5465 153.5163 79.7061 153.37192C79.8655 153.22755 80.0499 153.11286 80.254 153.02317C80.4583 152.93349 80.6677 152.8538 80.8818 152.78411C81.0961 152.71911 81.3052 152.65442 81.5096 152.58474C81.714 152.52505 81.898 152.44536 82.0577 152.35067C82.2171 152.25599 82.3465 152.1413 82.4461 152.00692C82.5408 151.86724 82.5908 151.68786 82.5908 151.4738C82.5908 151.27942 82.5558 151.10005 82.4911 150.94067C82.4261 150.7813 82.3268 150.64161 82.2071 150.53224C82.0774 150.412549 81.928 150.327861 81.7486 150.263174C81.5693 150.198174 81.3652 150.168486 81.1358 150.168486C80.9515 150.168486 80.7871 150.183486 80.6427 150.223174C80.4983 150.253174 80.3636 150.297861 80.254 150.352861C80.1346 150.407549 80.0349 150.46224 79.9452 150.52724C79.8555 150.59192 79.7758 150.64661 79.7061 150.70161C79.6361 150.7563 79.5765 150.80099 79.5168 150.83099C79.4668 150.87099 79.4171 150.88567 79.3721 150.88567C79.3274 150.88567 79.28239 150.87099 79.24771 150.85099C79.20771 150.82099 79.17302 150.7913 79.14802 150.7563L78.86896 150.297861C79.13802 150.013799 79.4618 149.784736 79.8405 149.615361C80.2193 149.450986 80.6427 149.366299 81.1061 149.366299C81.4846 149.366299 81.8233 149.425986 82.1174 149.540674C82.4165 149.655361 82.6655 149.814736 82.8746 150.018799C83.074 150.223174 83.2333 150.46224 83.338 150.7313C83.4427 151.01036 83.4974 151.29942 83.4974 151.61317C83.4974 151.90724 83.4477 152.1563 83.353 152.36067C83.2533 152.56474 83.1236 152.73411 82.9643 152.8738C82.7999 153.01317 82.6155 153.12786 82.4165 153.22255C82.2071 153.31224 81.9977 153.39192 81.7886 153.46661C81.5693 153.5413 81.3602 153.61099 81.1608 153.68067C80.9515 153.74567 80.7721 153.82536 80.6127 153.92005C80.4483 154.01474 80.319 154.12411 80.2243 154.2588C80.1246 154.38817 80.0746 154.55255 80.0746 154.75192C80.0746 154.9063 80.1046 155.05599 80.1593 155.18536C80.2143 155.32505 80.299 155.43942 80.4136 155.53911C80.523 155.6388 80.6627 155.71849 80.8221 155.77317C80.9915 155.83317 81.1808 155.86286 81.3949 155.86286C81.6243 155.86286 81.8183 155.83317 81.978 155.77817C82.1424 155.72349 82.2768 155.6588 82.3965 155.5938C82.5061 155.52411 82.6055 155.45942 82.6805 155.40474C82.7552 155.34974 82.8249 155.32005 82.8796 155.32005C82.9296 155.32005 82.9743 155.33474 83.0043 155.35474C83.044 155.38474 83.074 155.41942 83.104 155.46942ZM89.6843 155.77317V156.58536H84.0943V155.77317H86.4111V149.445986H87.3727V155.77317H89.6843Z'/>
+<path d='M55.8398 105.93H31.8633C29.6641 105.93 27.8789 104.148 27.8789 101.945V85.008C27.8789 82.809 29.6641 81.023 31.8633 81.023H55.8398C58.043 81.023 59.8242 82.809 59.8242 85.008V101.945C59.8242 104.148 58.043 105.93 55.8398 105.93Z' fill='#ffc'/>
+<path d='M55.8398 105.93H31.8633C29.6641 105.93 27.8789 104.148 27.8789 101.945V85.008C27.8789 82.809 29.6641 81.023 31.8633 81.023H55.8398C58.043 81.023 59.8242 82.809 59.8242 85.008V101.945C59.8242 104.148 58.043 105.93 55.8398 105.93Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M41.3634 97.02139H40.61123C40.52655 97.02139 40.45686 96.99639 40.39686 96.9517C40.34217 96.9067 40.30248 96.85202 40.28748 96.79233L38.8078 91.83014C38.7828 91.74545 38.7628 91.65077 38.7428 91.55108C38.72311 91.45139 38.70311 91.3467 38.68811 91.23702C38.66311 91.3467 38.64342 91.45139 38.61342 91.55108C38.59342 91.65077 38.56373 91.74545 38.53373 91.83014L36.85967 96.79233C36.83467 96.85702 36.79498 96.9117 36.73998 96.9567C36.6853 97.00139 36.61561 97.02139 36.53092 97.02139H36.25186C36.16717 97.02139 36.09748 96.99639 36.04248 96.9467C35.9828 96.9017 35.94311 96.84702 35.92311 96.79233L34.24405 91.83014C34.21405 91.74545 34.18936 91.64577 34.15936 91.54608C34.13936 91.43639 34.11467 91.3267 34.08967 91.21233C34.06967 91.3267 34.04967 91.43639 34.02998 91.54108C34.00498 91.64577 33.98498 91.74045 33.95998 91.83014L32.4853 96.79233C32.4703 96.85702 32.43061 96.9117 32.37592 96.9567C32.31592 97.00139 32.24123 97.02139 32.156547 97.02139H31.354359L33.58155 89.882016H34.44842L36.26686 95.32764C36.28186 95.38233 36.30155 95.43702 36.31655 95.49702C36.33155 95.5567 36.35155 95.62139 36.36655 95.68608L36.41123 95.49702C36.43123 95.43702 36.44623 95.38233 36.46123 95.32764L38.26967 89.882016H39.13655L41.3634 97.02139Z'/>
+<path d='M45.7872 92.53264H43.1219L44.2429 95.43202C44.3176 95.61139 44.3873 95.83577 44.4569 96.10483C44.4919 95.97514 44.5269 95.85077 44.5616 95.74108C44.5966 95.62139 44.6313 95.5217 44.6663 95.43702L45.7872 92.53264ZM47.8001 89.882016L44.9454 97.02139H43.9688L41.11413 89.882016H41.8613C41.946 89.882016 42.0157 89.907016 42.0707 89.951704C42.1254 89.996704 42.1654 90.051391 42.1851 90.111079L42.8529 91.83514H46.0563L46.7238 90.111079C46.7488 90.046391 46.7888 89.991704 46.8435 89.946704C46.8982 89.902016 46.9679 89.882016 47.0529 89.882016H47.8001ZM49.7069 89.882016V97.02139H48.7406V89.882016H49.7069ZM56.3576 96.2092V97.02139H50.7676V96.2092H53.0844V89.882016H54.046V96.2092H56.3576Z'/>
+<path d='M46.8672 80.609C51.4883 60.984 37.7422 59.809 40.1562 77.074' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M40.824246 80.609378C40.437531 79.601571 39.535188 78.011725 38.636742 76.960937L41.574255 76.42188C41.105498 77.72266 40.828152 79.531257 40.824246 80.609378'/>
+<path d='M125.9805 105.93H104.5937C102.3906 105.93 100.6094 104.148 100.6094 101.945V85.008C100.6094 82.809 102.3906 81.023 104.5937 81.023H125.9805C128.1797 81.023 129.9648 82.809 129.9648 85.008V101.945C129.9648 104.148 128.1797 105.93 125.9805 105.93Z' fill='#cfc'/>
+<path d='M125.9805 105.93H104.5937C102.3906 105.93 100.6094 104.148 100.6094 101.945V85.008C100.6094 82.809 102.3906 81.023 104.5937 81.023H125.9805C128.1797 81.023 129.9648 82.809 129.9648 85.008V101.945C129.9648 104.148 128.1797 105.93 125.9805 105.93Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M109.24397 90.706167H105.80616V93.14242H108.58647V93.8996H105.80616V96.27117H109.23897V97.05835H104.839909V89.918979H109.23897L109.24397 90.706167ZM114.2451 95.94242L114.4792 96.40085C114.2301 96.63992 113.9411 96.82429 113.61733 96.94867C113.28858 97.07335 112.92483 97.13804 112.52608 97.13804C112.17233 97.13804 111.85358 97.08335 111.58452 96.97367C111.30546 96.86398 111.07639 96.7196 110.88702 96.53523C110.70264 96.35085 110.55827 96.14179 110.45858 95.90742C110.36389 95.67335 110.31421 95.42929 110.31421 95.17523C110.31421 94.86117 110.36389 94.5921 110.45858 94.38304C110.55827 94.16367 110.68764 93.98929 110.84733 93.84492C111.00671 93.70054 111.19108 93.58585 111.39514 93.49617C111.59952 93.40648 111.80889 93.32679 112.02296 93.2571C112.23733 93.1921 112.44639 93.12742 112.65077 93.05773C112.85514 92.99804 113.03921 92.91835 113.19889 92.82367C113.35827 92.72898 113.48764 92.61429 113.58733 92.47992C113.68202 92.34023 113.73202 92.16085 113.73202 91.94679C113.73202 91.75242 113.69702 91.57304 113.63233 91.41367C113.56733 91.25429 113.46796 91.1146 113.34827 91.00523C113.21858 90.885542 113.06921 90.800854 112.88983 90.736167C112.71046 90.671167 112.50639 90.641479 112.27702 90.641479C112.09264 90.641479 111.92827 90.656479 111.78389 90.696167C111.63952 90.726167 111.50483 90.770854 111.39514 90.825854C111.27577 90.880542 111.17608 90.93523 111.08639 91.00023C110.99671 91.06492 110.91702 91.1196 110.84733 91.1746C110.77733 91.22929 110.71764 91.27398 110.65796 91.30398C110.60796 91.34398 110.55827 91.35867 110.51327 91.35867C110.46858 91.35867 110.42358 91.34398 110.38889 91.32398C110.34889 91.29398 110.31421 91.26429 110.28921 91.22929L110.01014 90.770854C110.27921 90.486792 110.60296 90.257729 110.98171 90.088354C111.36046 89.923979 111.78389 89.839292 112.24733 89.839292C112.62577 89.839292 112.96452 89.898979 113.25858 90.013667C113.55764 90.128354 113.80671 90.287729 114.0158 90.491792C114.2151 90.696167 114.3745 90.93523 114.4792 91.20429C114.5839 91.48335 114.6386 91.77242 114.6386 92.08617C114.6386 92.38023 114.5889 92.62929 114.4942 92.83367C114.3945 93.03773 114.2648 93.2071 114.1055 93.34679C113.9411 93.48617 113.75671 93.60085 113.55764 93.69554C113.34827 93.78523 113.13889 93.86492 112.92983 93.9396C112.71046 94.01429 112.50139 94.08398 112.30202 94.15367C112.09264 94.21867 111.91327 94.29835 111.75389 94.39304C111.58952 94.48773 111.46014 94.5971 111.36546 94.73179C111.26577 94.86117 111.21577 95.02554 111.21577 95.22492C111.21577 95.37929 111.24577 95.52898 111.30046 95.65835C111.35546 95.79804 111.44014 95.91242 111.55483 96.0121C111.66421 96.11179 111.80389 96.19148 111.96327 96.24617C112.13264 96.30617 112.32202 96.33585 112.53608 96.33585C112.76546 96.33585 112.95952 96.30617 113.11921 96.25117C113.28358 96.19648 113.41796 96.13179 113.53764 96.06679C113.64733 95.9971 113.74671 95.93242 113.82171 95.87773C113.89639 95.82273 113.9661 95.79304 114.0208 95.79304C114.0708 95.79304 114.1155 95.80773 114.1455 95.82773C114.1851 95.85773 114.2151 95.89242 114.2451 95.94242ZM120.158 90.596479H118.753V97.07335H118.0305L115.9033 95.23492L116.182 94.85117C116.197 94.82648 116.222 94.80648 116.252 94.78648C116.2867 94.76648 116.3217 94.75179 116.3564 94.74679C116.3914 94.74179 116.4314 94.74179 116.4761 94.75179C116.5211 94.75648 116.5608 94.78148 116.6058 94.81648L117.8761 95.90742C117.8661 95.75804 117.8611 95.60867 117.8611 95.46398V90.596479H116.3317V89.918979H120.158V90.596479ZM123.744 90.576479C123.51 90.576479 123.2956 90.616479 123.1162 90.686167C122.9269 90.765854 122.7725 90.870542 122.6481 91.00523C122.5184 91.1396 122.4187 91.30398 122.3541 91.49335C122.2894 91.68273 122.2544 91.89179 122.2544 92.12117C122.2544 92.31554 122.2894 92.5046 122.359 92.68898C122.4337 92.86835 122.5384 93.02773 122.6678 93.16742C122.8075 93.30179 122.9669 93.41148 123.1612 93.49617C123.3553 93.57585 123.5697 93.61585 123.8087 93.61585C124.0331 93.61585 124.2372 93.58085 124.4215 93.51117C124.6059 93.44148 124.7703 93.34179 124.9 93.2071C125.0394 93.07773 125.1391 92.91835 125.2137 92.72898C125.2884 92.5446 125.3234 92.33523 125.3234 92.10117C125.3234 91.88179 125.2884 91.67773 125.2087 91.49335C125.1391 91.30898 125.0294 91.1446 124.89 91.00992C124.7553 90.875542 124.5909 90.765854 124.3919 90.691167C124.2025 90.616479 123.9831 90.576479 123.744 90.576479ZM123.2259 94.38304L125.3434 97.05835H124.5562C124.4516 97.05835 124.3569 97.03835 124.2722 96.99367C124.1925 96.95367 124.1278 96.90398 124.0828 96.84429L122.2694 94.40773C121.9653 94.00429 121.7462 93.62554 121.6115 93.27679C121.4722 92.91835 121.4025 92.58929 121.4025 92.27554C121.4025 91.90179 121.4572 91.56804 121.5719 91.26429C121.6815 90.96523 121.8409 90.711167 122.0403 90.496792C122.2494 90.287729 122.4934 90.128354 122.7875 90.008667C123.0815 89.898979 123.4053 89.839292 123.7641 89.839292C124.1278 89.839292 124.4565 89.898979 124.7603 90.018667C125.0594 90.138042 125.3184 90.302729 125.5275 90.511792C125.7469 90.721167 125.9112 90.96523 126.0309 91.24929C126.1503 91.53304 126.2103 91.8371 126.2103 92.16585C126.2103 92.5046 126.1553 92.80867 126.0409 93.06773C125.9262 93.33679 125.7769 93.55585 125.5875 93.73523C125.3931 93.9196 125.169 94.05429 124.915 94.15367C124.6606 94.24335 124.3869 94.29335 124.0978 94.29335C123.8587 94.29335 123.6394 94.26335 123.4353 94.19867C123.2309 94.13398 123.0465 94.04429 122.8772 93.9296C122.9319 94.00429 122.9869 94.07398 123.0465 94.15367C123.1012 94.22367 123.1612 94.30335 123.2259 94.38304Z'/>
+<path d='M118.3125 80.609C122.9297 60.984 109.1836 59.809 111.5977 77.074' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M112.269241 80.609369C111.882518 79.601556 110.980177 78.011706 110.077826 76.960924L113.019232 76.421861C112.54658 77.722645 112.273137 79.531239 112.269241 80.609369'/>
+<path d='M140.07533 99.15003H137.31533C137.37502 99.58846 137.5294 99.93221 137.77877 100.18128C138.02283 100.42534 138.36158 100.55003 138.78502 100.55003C138.9894 100.55003 139.16877 100.51503 139.32815 100.45034C139.48752 100.38065 139.6219 100.28096 139.73158 100.16128C139.84627 100.0319 139.93096 99.88721 139.99065 99.71284C140.04565 99.54346 140.07533 99.35409 140.07533 99.15003ZM140.79283 96.783464L140.54377 97.10721C140.50377 97.16221 140.44908 97.1919 140.3744 97.1919C140.3194 97.1919 140.24971 97.1669 140.17002 97.11221C140.09533 97.062527 139.99565 97.007527 139.88096 96.947839C139.76658 96.888152 139.6269 96.833152 139.46252 96.783464C139.30315 96.728777 139.11377 96.703777 138.88971 96.703777C138.65065 96.703777 138.43627 96.743464 138.2419 96.823152C138.04752 96.898152 137.88315 97.017527 137.74377 97.1719C137.6044 97.33159 137.49471 97.53065 137.42002 97.76503C137.34033 97.99909 137.29533 98.27815 137.28533 98.5969H140.65815C140.74315 98.5969 140.79783 98.6219 140.82783 98.66659C140.85752 98.71159 140.87252 98.80628 140.87252 98.94565C140.87252 99.3044 140.81783 99.62315 140.71315 99.90221C140.60846 100.18628 140.45908 100.42034 140.26971 100.60971C140.08533 100.80409 139.86127 100.94846 139.60221 101.04815C139.34815 101.15284 139.06908 101.20253 138.76502 101.20253C138.40127 101.20253 138.07252 101.13784 137.77877 101.00815C137.48471 100.88378 137.24065 100.7094 137.03627 100.48003C136.831897 100.26096 136.677522 99.9919 136.572834 99.68815C136.463459 99.38409 136.408459 99.05534 136.408459 98.70159C136.408459 98.26815 136.468459 97.8794 136.587834 97.54565C136.707522 97.2119 136.871897 96.927839 137.09096 96.703777C137.30033 96.474402 137.5594 96.300027 137.84846 96.185652C138.14721 96.065964 138.46627 96.006277 138.81502 96.006277C138.9994 96.006277 139.18346 96.021277 139.36783 96.055964C139.55221 96.085964 139.73158 96.130652 139.91096 96.195652C140.08033 96.260339 140.24471 96.340027 140.39908 96.434714C140.55377 96.534402 140.68315 96.648777 140.79283 96.783464ZM142.79463 100.39034L142.72494 100.93846C142.69494 101.06315 142.61526 101.12284 142.49088 101.12284H141.95776V96.075964H142.84963V99.79253C143.04369 100.0069 143.25307 100.18128 143.47744 100.30565C143.70651 100.43034 143.95057 100.49503 144.21463 100.49503C144.56838 100.49503 144.83244 100.39034 145.01182 100.18128C145.18119 99.9669 145.27088 99.67315 145.27088 99.2894V96.075964H146.1628V99.2894C146.1628 99.57346 146.1278 99.83753 146.0531 100.07159C145.97838 100.30565 145.87369 100.51003 145.72932 100.6794C145.58963 100.84378 145.41526 100.97346 145.20119 101.06815C144.99182 101.15784 144.74776 101.20253 144.47369 101.20253C144.29432 101.20253 144.12494 101.18253 143.97557 101.14784C143.81619 101.10784 143.67151 101.05315 143.53713 100.97846C143.39744 100.90878 143.26807 100.82409 143.14338 100.7244C143.01901 100.62471 142.90432 100.51503 142.79463 100.39034Z'/>
+<path d='M148.9935 95.996277C149.2229 95.996277 149.447 96.035964 149.6614 96.115964C149.8754 96.200652 150.0598 96.310027 150.2142 96.454714L149.9551 96.878152C149.9204 96.932839 149.8754 96.962839 149.8307 96.962839C149.8057 96.962839 149.7707 96.952839 149.741 96.922839C149.701 96.903152 149.6614 96.873152 149.6114 96.843152C149.5617 96.813464 149.5017 96.783464 149.432 96.763464C149.3673 96.733464 149.2876 96.723777 149.1929 96.723777C149.0285 96.723777 148.8989 96.773464 148.7942 96.878152C148.6898 96.982839 148.6398 97.13721 148.6398 97.35128V100.38065H150.0995V101.02315H148.6398V102.7619H148.1914C148.1367 102.7619 148.087 102.7469 148.057 102.71221C148.017 102.68221 147.9973 102.64253 147.9873 102.59253L147.7829 101.03315L146.956 100.92846V100.57471C146.956 100.51003 146.9757 100.46034 147.0107 100.43034C147.0457 100.39534 147.0904 100.38065 147.1451 100.38065H147.7529V97.29159C147.7529 96.873152 147.8576 96.554402 148.077 96.330027C148.286 96.105964 148.5951 95.996277 148.9935 95.996277ZM151.8576 100.11159L151.7979 100.87878C151.7829 100.96846 151.7579 101.03315 151.7232 101.06815C151.6882 101.10284 151.6185 101.12284 151.5239 101.12284H151.0157V96.075964H151.9076V99.2644C151.9723 99.43878 152.042 99.59346 152.1167 99.72284C152.1963 99.86253 152.286 99.9719 152.3857 100.06159C152.4804 100.15628 152.5951 100.22596 152.7145 100.27096C152.8442 100.31565 152.9835 100.34065 153.1432 100.34065C153.2576 100.34065 153.3573 100.33065 153.447 100.31065C153.5367 100.29096 153.6064 100.28096 153.6513 100.28096C153.731 100.28096 153.7807 100.32065 153.8007 100.40534L153.8654 101.06815C153.7907 101.11784 153.701 101.15284 153.6013 101.17753C153.5067 101.20253 153.4023 101.21253 153.2976 101.21253C152.9638 101.21253 152.6798 101.11784 152.4457 100.91846C152.2114 100.7294 152.017 100.45534 151.8576 100.11159Z'/>
+<path d='M156.5578 101.20253C156.184 101.20253 155.8503 101.14284 155.5512 101.01815C155.2571 100.89378 155.0031 100.7194 154.794 100.49503C154.5846 100.27096 154.4253 99.9969 154.3156 99.67315C154.2012 99.35409 154.1462 98.99565 154.1462 98.6019C154.1462 98.20346 154.2012 97.84471 154.3156 97.52565C154.4253 97.2069 154.5846 96.932839 154.794 96.708777C155.0031 96.484402 155.2571 96.310027 155.5512 96.185652C155.8503 96.065964 156.184 96.006277 156.5578 96.006277C156.9262 96.006277 157.2599 96.065964 157.554 96.185652C157.8481 96.310027 158.1021 96.484402 158.3112 96.708777C158.5206 96.932839 158.6799 97.2069 158.7896 97.52565C158.9043 97.84471 158.959 98.20346 158.959 98.6019C158.959 98.99565 158.9043 99.35409 158.7896 99.67315C158.6799 99.9969 158.5206 100.27096 158.3112 100.49503C158.1021 100.7194 157.8481 100.89378 157.554 101.01815C157.2599 101.14284 156.9262 101.20253 156.5578 101.20253ZM156.5578 96.698777C156.0543 96.698777 155.6759 96.863152 155.4315 97.2019C155.1824 97.53065 155.0581 97.99909 155.0581 98.5969C155.0581 98.89596 155.0878 99.16503 155.1528 99.40409C155.2124 99.63815 155.3021 99.83753 155.4315 100.0019C155.5512 100.16628 155.7106 100.29096 155.8999 100.37565C156.0843 100.46034 156.3034 100.50503 156.5578 100.50503C157.0559 100.50503 157.4296 100.33565 157.6737 100.0019S158.0421 99.19971 158.0421 98.5969C158.0421 97.99909 157.9178 97.53065 157.6737 97.2019C157.4296 96.863152 157.0559 96.698777 156.5578 96.698777ZM160.9709 97.29159V99.73284C161.1553 99.9769 161.3543 100.16128 161.5687 100.29596C161.7878 100.43034 162.0418 100.49503 162.3309 100.49503C162.5353 100.49503 162.7146 100.46034 162.874 100.39034C163.0334 100.32065 163.1681 100.21128 163.2774 100.06159C163.3871 99.90721 163.4718 99.71284 163.5315 99.47878C163.5865 99.24471 163.6162 98.96065 163.6162 98.6319C163.6162 98.00909 163.4918 97.53065 163.2378 97.1969C162.9837 96.863152 162.6249 96.693777 162.1515 96.693777C161.9124 96.693777 161.6981 96.738464 161.504 96.828152C161.3096 96.917839 161.1353 97.072527 160.9709 97.29159ZM160.9259 100.34065L160.8462 100.93846C160.8162 101.06315 160.7365 101.12284 160.6121 101.12284H160.079V94.36721H160.9709V96.599089C161.1403 96.414714 161.3346 96.265339 161.5587 96.165652C161.7778 96.055964 162.0418 96.006277 162.3509 96.006277C162.6896 96.006277 162.9937 96.075964 163.2624 96.205652C163.5365 96.345027 163.7659 96.524402 163.9503 96.763464C164.1393 96.992527 164.284 97.27159 164.3837 97.59065C164.4831 97.9144 164.5331 98.25815 164.5331 98.6319C164.5331 99.05034 164.4881 99.41909 164.3984 99.74284S164.1793 100.33565 164.0149 100.55003C163.8506 100.76909 163.6462 100.93346 163.4121 101.04815C163.1778 101.15784 162.9137 101.21253 162.6199 101.21253C162.2612 101.21253 161.9424 101.13284 161.6634 100.97346C161.3843 100.81409 161.1403 100.60471 160.9259 100.34065Z'/>
+<path d='M169.8856 101.12284H169.1831C169.1234 101.12284 169.0684 101.10784 169.0237 101.06815C168.9737 101.03815 168.939 100.99346 168.919 100.93846L167.6087 97.76503C167.554 97.62534 167.504 97.47596 167.4593 97.32159C167.4243 97.47596 167.3796 97.62034 167.3246 97.76003L165.9746 100.93846C165.9596 100.98346 165.9246 101.02815 165.8849 101.06815C165.8349 101.10284 165.7753 101.12284 165.7006 101.12284H164.9334L167.0159 96.370027L166.094 94.36721H166.7518C166.8465 94.36721 166.9112 94.3869 166.9612 94.4269C167.0009 94.46659 167.0409 94.52159 167.0706 94.58628L169.8856 101.12284Z'/>
+<path d='M141.0219 89.16788H140.3294C140.26471 89.16788 140.21002 89.15288 140.16502 89.11319C140.12033 89.08319 140.08533 89.0385 140.06533 88.9835L138.77002 85.73506C138.72533 85.61069 138.69033 85.491 138.66033 85.37663C138.63065 85.26194 138.60065 85.14225 138.57565 85.027877C138.55096 85.14225 138.52096 85.26194 138.49096 85.37663C138.46127 85.491 138.42627 85.61069 138.38658 85.73506L137.10596 88.9835C137.09096 89.0335 137.05627 89.07819 137.01127 89.11319C136.966584 89.14788 136.906897 89.16788 136.831897 89.16788H136.109709L138.16721 84.121002H138.9644L141.0219 89.16788Z'/>
+<path d='M144.46385 86.39288V85.34663C144.36416 85.24194 144.26447 85.14725 144.15479 85.062565C144.0551 84.977877 143.94573 84.908189 143.82604 84.848502C143.71635 84.788502 143.59198 84.743814 143.46229 84.708815C143.33291 84.679127 143.18822 84.664127 143.03385 84.664127C142.91916 84.664127 142.80979 84.679127 142.7101 84.708815C142.60541 84.733814 142.52072 84.778502 142.44104 84.838502C142.37135 84.903189 142.31135 84.982877 142.26666 85.077564C142.22166 85.17225 142.20197 85.28694 142.20197 85.42131C142.20197 85.56069 142.24166 85.68538 142.32135 85.80006C142.40604 85.91444 142.53573 86.00913 142.7201 86.09381C142.89948 86.1785 143.13354 86.2435 143.4176 86.29319C143.70635 86.34788 144.0551 86.37788 144.46385 86.39288ZM141.59885 88.45538L141.75854 88.17163C141.78823 88.12663 141.82323 88.08694 141.86791 88.05694C141.91291 88.02194 141.9626 88.00694 142.0226 88.00694C142.09729 88.00694 142.17697 88.03694 142.25166 88.08694C142.33135 88.14663 142.42604 88.20631 142.53073 88.276C142.6401 88.341 142.76979 88.40569 142.91916 88.45538C143.06385 88.51538 143.24823 88.54006 143.46729 88.54006C143.79104 88.54006 144.0401 88.44038 144.20947 88.23631C144.37916 88.03694 144.46385 87.74288 144.46385 87.34944V86.95569C143.89073 86.941 143.4026 86.891 143.00885 86.80131C142.61541 86.70663 142.29135 86.59225 142.04729 86.44756C141.80323 86.30319 141.62385 86.14381 141.51416 85.95444C141.40479 85.77506 141.34979 85.58069 141.34979 85.38163C141.34979 85.15225 141.38479 84.952877 141.46448 84.788502C141.53416 84.619127 141.63885 84.479752 141.76354 84.370064C141.89291 84.260377 142.04229 84.180689 142.21666 84.121002C142.39104 84.071314 142.57541 84.041314 142.76979 84.041314C142.96416 84.041314 143.13854 84.061314 143.29791 84.091002C143.45229 84.131002 143.60166 84.180689 143.74135 84.240689C143.88073 84.310377 144.01541 84.390064 144.13979 84.479752C144.26447 84.579439 144.39385 84.684127 144.52854 84.808502L144.62823 84.330377C144.65291 84.245689 144.69291 84.190689 144.7376 84.161002C144.7826 84.136002 144.85229 84.121002 144.93697 84.121002H145.33072V87.34944C145.33072 87.6335 145.29072 87.89256 145.21604 88.12663C145.14135 88.36069 145.02666 88.56506 144.87729 88.72944C144.72791 88.89381 144.54354 89.0235 144.32416 89.11819C144.1051 89.21288 143.85604 89.25756 143.57197 89.25756C143.17823 89.25756 142.82447 89.19288 142.50072 89.05819C142.17697 88.92381 141.87791 88.72444 141.59885 88.45538ZM147.5965 91.45975H146.7099V84.121002H147.5965V91.45975ZM149.9677 89.16788H149.0808V84.121002H149.9677V89.16788ZM150.1571 90.75225C150.1571 90.83694 150.1421 90.92163 150.1024 90.99631C150.0724 91.076 150.0227 91.14569 149.9627 91.20569C149.908 91.26038 149.8383 91.30538 149.7636 91.34006C149.6836 91.37506 149.5989 91.39006 149.5142 91.39006C149.4296 91.39006 149.3449 91.37506 149.2752 91.34006C149.1955 91.30538 149.1308 91.26038 149.0758 91.20569C149.0211 91.14569 148.9764 91.076 148.9414 90.99631C148.9064 90.92163 148.8917 90.83694 148.8917 90.75225S148.9064 90.58788 148.9414 90.50819C148.9764 90.4385 149.0211 90.3685 149.0758 90.30881C149.1308 90.25413 149.1955 90.20913 149.2752 90.17444C149.3449 90.13944 149.4296 90.12444 149.5142 90.12444C149.5989 90.12444 149.6836 90.13944 149.7636 90.17444C149.8383 90.20913 149.908 90.25413 149.9627 90.30881C150.0227 90.3685 150.0724 90.4385 150.1024 90.50819C150.1421 90.58788 150.1571 90.66756 150.1571 90.75225ZM154.7103 87.96725V85.531C154.5259 85.28694 154.3268 85.102564 154.1074 84.967877C153.8934 84.833502 153.6393 84.768815 153.3453 84.768815C153.1409 84.768815 152.9615 84.803502 152.8021 84.873189C152.6428 84.94319 152.5081 85.052565 152.3987 85.20725C152.289 85.35663 152.2043 85.546 152.1496 85.78506C152.0946 86.01413 152.0649 86.29819 152.0649 86.62694C152.0649 87.24975 152.1893 87.72819 152.4434 88.06194C152.6974 88.39569 153.0562 88.56506 153.5246 88.56506C153.7637 88.56506 153.9781 88.52038 154.1721 88.43538C154.3665 88.346 154.5459 88.19131 154.7103 87.96725ZM155.5971 91.45975H154.7103V88.66475C154.5359 88.84913 154.3415 88.9935 154.1174 89.10319C153.8984 89.20288 153.6343 89.25756 153.3253 89.25756C152.9865 89.25756 152.6824 89.19288 152.4137 89.05319C152.1396 88.92381 151.9103 88.73444 151.7259 88.50038C151.5418 88.266 151.3971 87.98725 151.2974 87.66819C151.1981 87.34444 151.1481 87.00069 151.1481 86.62694C151.1481 86.2085 151.1931 85.83975 151.2828 85.516C151.3724 85.19225 151.5018 84.923189 151.6662 84.708815C151.8306 84.494752 152.0349 84.330377 152.269 84.220689C152.5034 84.106002 152.7674 84.051314 153.0562 84.051314C153.4199 84.051314 153.7387 84.131002 154.0128 84.290377C154.2868 84.449752 154.5359 84.659127 154.7503 84.918189L154.8299 84.305377C154.8646 84.180689 154.9446 84.121002 155.069 84.121002H155.5971V91.45975ZM158.0674 91.26038H157.2202V88.41069C157.2202 88.26131 157.2252 88.11663 157.2302 87.97225C157.2352 87.82756 157.2452 87.68819 157.2552 87.53881C157.2652 87.39913 157.2752 87.24975 157.2952 87.10038C157.3049 86.946 157.3249 86.78631 157.3449 86.61194H157.9427C157.9627 86.78631 157.9827 86.946 157.9927 87.10038C158.0124 87.24975 158.0224 87.39913 158.0324 87.53881C158.0424 87.68819 158.0524 87.82756 158.0574 87.97225C158.0624 88.11663 158.0674 88.26131 158.0674 88.41069V91.26038ZM157.0061 84.669127C157.0061 84.579439 157.0211 84.499752 157.0558 84.420064C157.0858 84.350064 157.1305 84.280377 157.1855 84.225689C157.2402 84.170689 157.3049 84.126002 157.3849 84.091002C157.4546 84.061314 157.5392 84.046314 157.6289 84.046314C157.7136 84.046314 157.7933 84.061314 157.873 84.091002C157.9427 84.126002 158.0124 84.170689 158.0674 84.225689C158.1221 84.280377 158.1671 84.350064 158.2017 84.420064C158.2367 84.499752 158.2517 84.579439 158.2517 84.669127C158.2517 84.753814 158.2367 84.838502 158.2017 84.913189C158.1671 84.987877 158.1221 85.057565 158.0674 85.112565C158.0124 85.16725 157.9427 85.21194 157.873 85.24694C157.7933 85.28194 157.7136 85.29694 157.6289 85.29694C157.5392 85.29694 157.4546 85.28194 157.3849 85.24694C157.3049 85.21194 157.2402 85.16725 157.1855 85.112565C157.1305 85.057565 157.0858 84.987877 157.0558 84.913189C157.0211 84.838502 157.0061 84.753814 157.0061 84.669127Z'/>
+<path d='M92.7305 46.402H66.4062C64.207 46.402 62.4219 44.621 62.4219 42.418V25.48C62.4219 23.281 64.207 21.496 66.4062 21.496H92.7305C94.9297 21.496 96.7148 23.281 96.7148 25.48V42.418C96.7148 44.621 94.9297 46.402 92.7305 46.402Z' fill='#fcc'/>
+<path d='M92.7305 46.402H66.4062C64.207 46.402 62.4219 44.621 62.4219 42.418V25.48C62.4219 23.281 64.207 21.496 66.4062 21.496H92.7305C94.9297 21.496 96.7148 23.281 96.7148 25.48V42.418C96.7148 44.621 94.9297 46.402 92.7305 46.402Z' stroke='#000' fill='none' stroke-width='.79701' stroke-miterlimit='10'/>
+<path d='M72.84267 33.92122C72.84267 34.45434 72.75798 34.94247 72.5883 35.3809C72.41892 35.81934 72.17986 36.19309 71.87111 36.51184C71.56205 36.8209 71.1933 37.06497 70.75486 37.23934C70.32642 37.40872 69.8433 37.4934 69.32017 37.4934H66.654859V30.354029H69.32017C69.8433 30.354029 70.32642 30.438717 70.75486 30.613092C71.1933 30.782467 71.56205 31.021529 71.87111 31.335592C72.17986 31.64934 72.41892 32.02309 72.5883 32.46153C72.75798 32.89997 72.84267 33.38809 72.84267 33.92122ZM71.85111 33.92122C71.85111 33.48278 71.79142 33.08934 71.67173 32.74559C71.55205 32.40184 71.38267 32.10778 71.16361 31.86872C70.94423 31.63434 70.68017 31.44997 70.36642 31.325592C70.05267 31.200904 69.70392 31.136217 69.32017 31.136217H67.62111V36.71122H69.32017C69.70392 36.71122 70.05267 36.64653 70.36642 36.52184C70.68017 36.39747 70.94423 36.21309 71.16361 35.97403C71.38267 35.73465 71.55205 35.4409 71.67173 35.09715C71.79142 34.7534 71.85111 34.35965 71.85111 33.92122ZM78.6354 31.141217H75.19759V33.57747H77.9779V34.33465H75.19759V36.70622H78.6304V37.4934H74.23134V30.354029H78.6304L78.6354 31.141217ZM83.776 33.00465H81.1106L82.2316 35.90403C82.3063 36.0834 82.376 36.30778 82.4456 36.57684C82.4806 36.44715 82.5156 36.32278 82.5503 36.21309C82.5853 36.0934 82.62 35.99372 82.655 35.90903L83.776 33.00465ZM85.7888 30.354029L82.9341 37.4934H81.9575L79.1028 30.354029H79.85C79.9347 30.354029 80.0044 30.379029 80.0594 30.423717C80.1141 30.468717 80.1541 30.523404 80.1738 30.583092L80.8416 32.30715H84.045L84.7125 30.583092C84.7375 30.518404 84.7775 30.463717 84.8322 30.418717C84.8869 30.374029 84.9566 30.354029 85.0416 30.354029H85.7888ZM92.9171 33.92122C92.9171 34.45434 92.8324 34.94247 92.6628 35.3809C92.4934 35.81934 92.2543 36.19309 91.9456 36.51184C91.6365 36.8209 91.2677 37.06497 90.8293 37.23934C90.4009 37.40872 89.9177 37.4934 89.3946 37.4934H86.7293V30.354029H89.3946C89.9177 30.354029 90.4009 30.438717 90.8293 30.613092C91.2677 30.782467 91.6365 31.021529 91.9456 31.335592C92.2543 31.64934 92.4934 32.02309 92.6628 32.46153C92.8324 32.89997 92.9171 33.38809 92.9171 33.92122ZM91.9256 33.92122C91.9256 33.48278 91.8659 33.08934 91.7462 32.74559S91.4571 32.10778 91.2381 31.86872C91.0187 31.63434 90.7546 31.44997 90.4409 31.325592C90.1271 31.200904 89.7784 31.136217 89.3946 31.136217H87.6956V36.71122H89.3946C89.7784 36.71122 90.1271 36.64653 90.4409 36.52184C90.7546 36.39747 91.0187 36.21309 91.2381 35.97403C91.4571 35.73465 91.6265 35.4409 91.7462 35.09715S91.9256 34.35965 91.9256 33.92122Z'/>
+<path d='M94.88816 13.62667L95.11254 13.94573C94.94816 14.12011 94.74879 14.25448 94.51973 14.35917C94.28535 14.45886 94.02129 14.50855 93.71754 14.50855C93.43348 14.50855 93.17441 14.46386 92.94535 14.36917C92.72098 14.27948 92.5266 14.1598 92.36723 14.00542C92.207852 13.85105 92.088164 13.67667 91.998477 13.4823C91.918789 13.28292 91.874102 13.07886 91.874102 12.86448C91.874102 12.62042 91.923789 12.42605 92.028477 12.28167C92.133164 12.13698 92.262539 12.01761 92.41723 11.92792C92.5716 11.83323 92.74098 11.75855 92.92035 11.69855C93.09973 11.64386 93.2691 11.57917 93.42348 11.51448C93.57785 11.44948 93.70754 11.3648 93.81223 11.26511C93.9166 11.16573 93.9666 11.03105 93.9666 10.86167C93.9666 10.7373 93.9416 10.61761 93.89191 10.50292C93.84691 10.39323 93.77723 10.29886 93.68254 10.214172C93.59285 10.129172 93.48316 10.064485 93.35379 10.014797C93.2191 9.964797 93.07473 9.940109 92.91035 9.940109C92.72598 9.940109 92.5716 9.964797 92.44691 10.009797C92.327539 10.054485 92.227852 10.109484 92.148164 10.164172C92.068477 10.223859 92.003477 10.278859 91.948789 10.323547C91.894102 10.368547 91.844102 10.39323 91.789414 10.39323C91.734414 10.39323 91.689727 10.383547 91.649727 10.358547C91.620039 10.333547 91.585039 10.303547 91.555352 10.25886L91.335977 9.920109C91.490352 9.740735 91.694727 9.59636 91.938789 9.476672C92.187852 9.366985 92.47191 9.307297 92.79566 9.307297C93.09473 9.307297 93.36379 9.356985 93.60285 9.451672C93.84691 9.54636 94.05129 9.676047 94.22066 9.835422C94.39504 9.999797 94.52441 10.184172 94.6191 10.39823C94.70879 10.61261 94.75379 10.83167 94.75379 11.06605C94.75379 11.30511 94.70379 11.49948 94.59941 11.64886C94.49473 11.79823 94.36504 11.92292 94.21066 12.01761C94.05629 12.1123 93.88691 12.19198 93.70754 12.25667C93.52816 12.32136 93.35879 12.38636 93.20441 12.45605C93.04973 12.52073 92.92035 12.60042 92.81566 12.69511C92.71098 12.7898 92.66129 12.91448 92.66129 13.06886C92.66129 13.17855 92.68629 13.28292 92.73598 13.38261C92.78066 13.4773 92.85066 13.56198 92.93535 13.63667C93.02504 13.71136 93.12941 13.76636 93.2541 13.81105C93.37879 13.85105 93.51316 13.87105 93.66254 13.87105C93.82223 13.87105 93.9566 13.85105 94.07129 13.81105C94.18566 13.77636 94.28035 13.73136 94.36004 13.69167C94.43504 13.64167 94.49973 13.60198 94.55941 13.56698C94.60941 13.53198 94.6641 13.5123 94.70879 13.5123C94.74879 13.5123 94.78379 13.5223 94.80848 13.54198C94.83348 13.55698 94.86348 13.58698 94.88816 13.62667ZM96.01848 10.338547C96.02348 10.004797 96.12316 9.745735 96.30254 9.57136C96.49191 9.396985 96.74098 9.307297 97.06473 9.307297C97.2741 9.307297 97.48316 9.346985 97.68754 9.426985C97.89691 9.511672 98.08098 9.621047 98.24566 9.765735L98.05629 10.189172C98.04129 10.218859 98.02629 10.23886 98.01629 10.25386C97.99629 10.268859 97.9766 10.273859 97.9466 10.273859C97.9216 10.273859 97.89691 10.263859 97.86191 10.23386C97.82691 10.214172 97.78723 10.184172 97.73723 10.154172C97.68754 10.124485 97.62785 10.094484 97.56785 10.074485C97.49816 10.044484 97.42348 10.034797 97.33379 10.034797C97.19941 10.034797 97.09473 10.074485 97.01504 10.154172C96.93535 10.23886 96.89535 10.363547 96.89535 10.53292C96.89535 10.54292 96.89535 10.55792 96.90035 10.57761C96.90035 10.59761 96.90035 10.63261 96.91035 10.6823C96.91035 10.7323 96.92035 10.79698 96.93035 10.88167C96.94004 10.96636 96.95504 11.07605 96.97004 11.21042L97.2741 13.69167H98.6041L98.6791 14.33417H97.35379L97.56785 16.07292H97.10473C97.04973 16.07292 97.01004 16.05792 96.97004 16.02323C96.94004 15.99323 96.91035 15.95355 96.89535 15.90355L96.5166 14.34417L95.73941 14.23948L95.69973 13.88573C95.69473 13.82105 95.70473 13.77136 95.73441 13.74136C95.75941 13.70636 95.79941 13.69167 95.8441 13.69167H96.40723L96.09816 11.16573C96.07816 11.01105 96.06348 10.88167 96.05348 10.78698C96.03848 10.6923 96.03348 10.61261 96.02348 10.55292C96.02348 10.49292 96.01848 10.44823 96.01848 10.41323V10.338547Z' fill='#f00'/>
+<path d='M102.5186 13.81605L102.3042 12.0873C102.2098 11.79323 102.1051 11.51948 101.9854 11.27011C101.8657 11.02605 101.7364 10.81198 101.597 10.63261C101.4523 10.44823 101.30293 10.308547 101.14856 10.204172C100.99387 10.104484 100.83449 10.054485 100.67012 10.054485C100.15699 10.054485 99.90293 10.45323 99.90293 11.25542C99.90293 11.48448 99.92793 11.70855 99.98262 11.92792C100.03731 12.14198 100.11231 12.34636 100.20199 12.54073C100.30137 12.73511 100.41106 12.90948 100.54574 13.07386C100.68012 13.23323 100.82449 13.37261 100.98918 13.4873C101.15356 13.60198 101.32793 13.69167 101.5123 13.76136C101.6964 13.82105 101.8907 13.85605 102.0901 13.85605C102.1598 13.85605 102.2295 13.85105 102.3042 13.85105C102.3742 13.84105 102.4439 13.83105 102.5186 13.81605ZM102.1798 10.7173L102.0851 9.695735C102.0851 9.611047 102.1051 9.53636 102.1448 9.476672C102.1898 9.416985 102.2695 9.386985 102.3842 9.386985H102.8423L103.4451 14.26948C103.2461 14.35417 103.0417 14.41886 102.8423 14.44886C102.6332 14.48855 102.4239 14.50355 102.2098 14.50355C101.9107 14.50355 101.6267 14.45886 101.3526 14.37917C101.07855 14.28948 100.82449 14.1698 100.59043 14.02042C100.35137 13.86105 100.13699 13.68167 99.94293 13.4723C99.74855 13.25823 99.58418 13.02886 99.44449 12.7748C99.31012 12.52073 99.20543 12.25667 99.12574 11.96761C99.05605 11.68886 99.01606 11.3948 99.01606 11.09573C99.01606 10.81198 99.04605 10.55792 99.11074 10.333547C99.17543 10.114484 99.26512 9.930109 99.3748 9.775735C99.49449 9.626047 99.62887 9.511672 99.79324 9.436672C99.95762 9.356985 100.13699 9.317297 100.33637 9.317297C100.52074 9.317297 100.69512 9.351985 100.86949 9.416985C101.03887 9.481672 101.19824 9.576359 101.3576 9.695735C101.5073 9.820422 101.6567 9.964797 101.7961 10.139172C101.9307 10.313547 102.0601 10.50292 102.1798 10.7173ZM108.8 14.43386H108.0975C108.0479 14.43386 107.9982 14.41886 107.9532 14.38917C107.9035 14.35417 107.8635 14.31417 107.8385 14.25948L106.2444 11.07605C106.2094 11.00605 106.1794 10.93636 106.1497 10.86167C106.1197 10.79198 106.0897 10.7223 106.06 10.6523C106.055 10.7223 106.045 10.79198 106.035 10.86167S106.01 11.00105 105.995 11.07105L105.1832 14.24948C105.1682 14.30448 105.1432 14.34917 105.1085 14.37917C105.0735 14.41886 105.0238 14.43386 104.9488 14.43386H104.2166L105.5269 9.686047L104.4307 7.67823H105.0835C105.1582 7.67823 105.2179 7.69292 105.2629 7.72792C105.3125 7.76292 105.3575 7.81261 105.3922 7.8823L108.8 14.43386Z' fill='#f00'/>
+<path d='M112.0878 13.62667L112.3121 13.94573C112.1478 14.12011 111.9484 14.25448 111.7193 14.35917C111.485 14.45886 111.2209 14.50855 110.9171 14.50855C110.6331 14.50855 110.374 14.46386 110.145 14.36917C109.9206 14.27948 109.7262 14.1598 109.5668 14.00542C109.4075 13.85105 109.2878 13.67667 109.1981 13.4823C109.1184 13.28292 109.0737 13.07886 109.0737 12.86448C109.0737 12.62042 109.1234 12.42605 109.2281 12.28167C109.3328 12.13698 109.4621 12.01761 109.6168 11.92792C109.7712 11.83323 109.9406 11.75855 110.12 11.69855C110.2993 11.64386 110.4687 11.57917 110.6231 11.51448C110.7775 11.44948 110.9071 11.3648 111.0118 11.26511C111.1162 11.16573 111.1662 11.03105 111.1662 10.86167C111.1662 10.7373 111.1412 10.61761 111.0915 10.50292C111.0465 10.39323 110.9768 10.29886 110.8821 10.214172C110.7925 10.129172 110.6828 10.064485 110.5534 10.014797C110.4187 9.964797 110.2743 9.940109 110.11 9.940109C109.9256 9.940109 109.7712 9.964797 109.6465 10.009797C109.5271 10.054485 109.4275 10.109484 109.3478 10.164172C109.2681 10.223859 109.2031 10.278859 109.1484 10.323547C109.0937 10.368547 109.0437 10.39323 108.989 10.39323C108.934 10.39323 108.8893 10.383547 108.8493 10.358547C108.8196 10.333547 108.7846 10.303547 108.755 10.25886L108.5356 9.920109C108.69 9.740735 108.8943 9.59636 109.1384 9.476672C109.3875 9.366985 109.6715 9.307297 109.9953 9.307297C110.2943 9.307297 110.5634 9.356985 110.8025 9.451672C111.0465 9.54636 111.2509 9.676047 111.4203 9.835422C111.5946 9.999797 111.724 10.184172 111.8187 10.39823C111.9084 10.61261 111.9534 10.83167 111.9534 11.06605C111.9534 11.30511 111.9034 11.49948 111.799 11.64886C111.6943 11.79823 111.5646 11.92292 111.4103 12.01761C111.2559 12.1123 111.0865 12.19198 110.9071 12.25667C110.7278 12.32136 110.5584 12.38636 110.404 12.45605C110.2493 12.52073 110.12 12.60042 110.0153 12.69511S109.8609 12.91448 109.8609 13.06886C109.8609 13.17855 109.8859 13.28292 109.9356 13.38261C109.9803 13.4773 110.0503 13.56198 110.135 13.63667C110.2246 13.71136 110.329 13.76636 110.4537 13.81105C110.5784 13.85105 110.7128 13.87105 110.8621 13.87105C111.0218 13.87105 111.1562 13.85105 111.2709 13.81105C111.3853 13.77636 111.48 13.73136 111.5596 13.69167C111.6346 13.64167 111.6993 13.60198 111.759 13.56698C111.809 13.53198 111.8637 13.5123 111.9084 13.5123C111.9484 13.5123 111.9834 13.5223 112.0081 13.54198C112.0331 13.55698 112.0631 13.58698 112.0878 13.62667Z' fill='#f00'/>
+<path d='M118.7125 13.33292L118.5481 12.02261C118.4534 11.73355 118.3387 11.46948 118.2043 11.22542C118.0746 10.98136 117.9353 10.77198 117.7856 10.59261C117.6312 10.41823 117.4768 10.278859 117.3125 10.179172C117.1481 10.079485 116.9887 10.029797 116.829 10.029797C116.565 10.029797 116.3659 10.134172 116.2212 10.343547C116.0818 10.54792 116.0121 10.85167 116.0121 11.24542C116.0121 11.53917 116.0518 11.84323 116.1315 12.14698C116.2112 12.45105 116.3259 12.73011 116.4703 12.97417C116.62 13.22323 116.7993 13.42761 117.0084 13.58198C117.2178 13.73636 117.4518 13.81605 117.7159 13.81605C117.9003 13.81605 118.0796 13.78136 118.254 13.71136C118.4334 13.63667 118.5878 13.5123 118.7125 13.33292ZM119.9978 16.72573H119.1309L118.7871 13.94573C118.6428 14.12511 118.4734 14.26448 118.264 14.35917C118.0646 14.45886 117.8356 14.50855 117.5865 14.50855C117.3521 14.50855 117.1331 14.46386 116.9187 14.37417C116.7096 14.28448 116.5153 14.1598 116.3309 14.00542C116.1465 13.85105 115.9821 13.66167 115.8328 13.4523C115.6881 13.23323 115.5637 13.00417 115.454 12.7548C115.3543 12.50573 115.2696 12.24667 115.215 11.97261C115.1603 11.69855 115.1303 11.4298 115.1303 11.15573C115.1303 10.55792 115.2496 10.104484 115.489 9.785422C115.7281 9.476672 116.0618 9.317297 116.4953 9.317297C116.6796 9.317297 116.859 9.351985 117.0384 9.416985C117.2128 9.486672 117.3871 9.58636 117.5465 9.710735C117.7159 9.835422 117.8703 9.989797 118.02 10.164172C118.1693 10.338547 118.3087 10.53792 118.4334 10.75698L118.3387 9.695735C118.3387 9.611047 118.3587 9.53636 118.3984 9.476672C118.4384 9.416985 118.5181 9.386985 118.6328 9.386985H119.0959L119.9978 16.72573ZM122.9861 13.86605C123.1207 13.86605 123.2301 13.85105 123.3248 13.81105C123.4195 13.78136 123.4942 13.73636 123.5542 13.68167C123.6089 13.62667 123.6539 13.57198 123.6786 13.5023C123.7036 13.4423 123.7186 13.37761 123.7186 13.31792C123.7186 13.19823 123.6936 13.08386 123.6389 12.97417C123.5839 12.86448 123.4745 12.7648 123.3098 12.66511C123.1454 12.57542 122.9064 12.48573 122.5976 12.40605C122.2886 12.32136 121.8801 12.25167 121.367 12.18698C121.4217 12.42105 121.4964 12.64542 121.5911 12.84448C121.6857 13.05386 121.8054 13.22823 121.9398 13.38261C122.0745 13.53198 122.2339 13.65167 122.4082 13.73636C122.5826 13.82105 122.777 13.86605 122.9861 13.86605ZM124.3911 10.318547L124.172 10.59261C124.122 10.64761 124.0673 10.6773 124.0026 10.6773C123.9476 10.6773 123.8979 10.6623 123.8429 10.62761C123.7882 10.59261 123.7336 10.55292 123.6736 10.50292C123.6089 10.45823 123.5442 10.40323 123.4645 10.343547C123.3948 10.28886 123.3051 10.23386 123.2054 10.184172C123.1107 10.139172 122.9961 10.099484 122.8764 10.064485C122.747 10.029797 122.6076 10.014797 122.4479 10.014797C122.0545 10.014797 121.7604 10.134172 121.5711 10.363547C121.372 10.60261 121.2773 10.94136 121.2773 11.3848C121.2773 11.4198 121.2773 11.45948 121.2823 11.48948C121.2823 11.52917 121.2823 11.56417 121.2823 11.59917C121.9398 11.66386 122.4779 11.75355 122.8964 11.86323C123.3148 11.97261 123.6439 12.1023 123.8829 12.24667C124.122 12.39605 124.2864 12.56573 124.3761 12.7448C124.4657 12.93417 124.5107 13.13355 124.5107 13.35292C124.5107 13.4773 124.4807 13.60698 124.4211 13.74136C124.3661 13.87573 124.2764 14.00042 124.157 14.11511C124.0373 14.22948 123.8829 14.31917 123.6986 14.39417C123.5142 14.46886 123.2901 14.50355 123.0361 14.50355C122.767 14.50355 122.5179 14.46386 122.2786 14.37917C122.0495 14.29448 121.8301 14.1798 121.6411 14.04042C121.4417 13.89073 121.2723 13.72136 121.1229 13.5223C120.9682 13.32292 120.8439 13.10855 120.7342 12.87448C120.6345 12.64042 120.5548 12.39605 120.4951 12.13698C120.4451 11.88292 120.4154 11.62386 120.4154 11.3648C120.4154 11.05105 120.4601 10.77198 120.5448 10.51792C120.6295 10.263859 120.7542 10.049484 120.9136 9.87511C121.0729 9.695735 121.2673 9.55636 121.4964 9.461672C121.7257 9.366985 121.9848 9.317297 122.2736 9.317297C122.4879 9.317297 122.6873 9.337297 122.8667 9.376985C123.0557 9.411985 123.2301 9.471672 123.3948 9.55636C123.5642 9.641047 123.7286 9.745735 123.8929 9.865422C124.0573 9.994797 124.2217 10.144172 124.3911 10.318547ZM128.645 13.81605L128.4306 12.0873C128.3362 11.79323 128.2315 11.51948 128.1118 11.27011C127.9921 11.02605 127.8628 10.81198 127.7234 10.63261C127.5787 10.44823 127.4293 10.308547 127.275 10.204172C127.1203 10.104484 126.9609 10.054485 126.7965 10.054485C126.2834 10.054485 126.0293 10.45323 126.0293 11.25542C126.0293 11.48448 126.0543 11.70855 126.109 11.92792C126.1637 12.14198 126.2387 12.34636 126.3284 12.54073C126.4278 12.73511 126.5375 12.90948 126.6722 13.07386C126.8065 13.23323 126.9509 13.37261 127.1156 13.4873C127.28 13.60198 127.4543 13.69167 127.6387 13.76136C127.8228 13.82105 128.0171 13.85605 128.2165 13.85605C128.2862 13.85605 128.3559 13.85105 128.4306 13.85105C128.5006 13.84105 128.5703 13.83105 128.645 13.81605ZM128.3062 10.7173L128.2115 9.695735C128.2115 9.611047 128.2315 9.53636 128.2712 9.476672C128.3162 9.416985 128.3959 9.386985 128.5106 9.386985H128.9687L129.5715 14.26948C129.3725 14.35417 129.1681 14.41886 128.9687 14.44886C128.7596 14.48855 128.5503 14.50355 128.3362 14.50355C128.0371 14.50355 127.7531 14.45886 127.479 14.37917C127.205 14.28948 126.9509 14.1698 126.7168 14.02042C126.4778 13.86105 126.2634 13.68167 126.0693 13.4723C125.875 13.25823 125.7106 13.02886 125.5709 12.7748C125.4365 12.52073 125.3318 12.25667 125.2521 11.96761C125.1825 11.68886 125.1425 11.3948 125.1425 11.09573C125.1425 10.81198 125.1725 10.55792 125.2371 10.333547C125.3018 10.114484 125.3915 9.930109 125.5012 9.775735C125.6209 9.626047 125.7553 9.511672 125.9196 9.436672C126.084 9.356985 126.2634 9.317297 126.4628 9.317297C126.6471 9.317297 126.8215 9.351985 126.9959 9.416985C127.1653 9.481672 127.3247 9.576359 127.484 9.695735C127.6337 9.820422 127.7831 9.964797 127.9225 10.139172C128.0571 10.313547 128.1865 10.50292 128.3062 10.7173ZM133.8405 13.33292L133.6761 12.02261C133.5814 11.73355 133.4668 11.46948 133.3324 11.22542C133.2027 10.98136 133.0633 10.77198 132.9136 10.59261C132.7593 10.41823 132.6049 10.278859 132.4405 10.179172S132.1168 10.029797 131.9571 10.029797C131.693 10.029797 131.4939 10.134172 131.3493 10.343547C131.2099 10.54792 131.1402 10.85167 131.1402 11.24542C131.1402 11.53917 131.1799 11.84323 131.2596 12.14698C131.3393 12.45105 131.4539 12.73011 131.5983 12.97417C131.748 13.22323 131.9274 13.42761 132.1364 13.58198C132.3458 13.73636 132.5799 13.81605 132.8439 13.81605C133.0283 13.81605 133.2077 13.78136 133.3821 13.71136C133.5614 13.63667 133.7158 13.5123 133.8405 13.33292ZM135.1258 16.72573H134.2589L133.9152 13.94573C133.7708 14.12511 133.6014 14.26448 133.3921 14.35917C133.1927 14.45886 132.9636 14.50855 132.7146 14.50855C132.4802 14.50855 132.2611 14.46386 132.0468 14.37417C131.8377 14.28448 131.6433 14.1598 131.4589 14.00542C131.2746 13.85105 131.1102 13.66167 130.9608 13.4523C130.8161 13.23323 130.6918 13.00417 130.5821 12.7548C130.4824 12.50573 130.3977 12.24667 130.343 11.97261S130.2583 11.4298 130.2583 11.15573C130.2583 10.55792 130.3777 10.104484 130.6171 9.785422C130.8561 9.476672 131.1899 9.317297 131.6233 9.317297C131.8077 9.317297 131.9871 9.351985 132.1664 9.416985C132.3408 9.486672 132.5152 9.58636 132.6746 9.710735C132.8439 9.835422 132.9983 9.989797 133.148 10.164172C133.2974 10.338547 133.4368 10.53792 133.5614 10.75698L133.4668 9.695735C133.4668 9.611047 133.4868 9.53636 133.5264 9.476672C133.5664 9.416985 133.6461 9.386985 133.7608 9.386985H134.2239L135.1258 16.72573Z' fill='#f00'/>
+<path d='M111.7154 139.35756L111.79009 140.33881C111.79009 140.53819 111.6904 140.63787 111.49134 140.63787H111.052902L110.445089 135.585999H111.33165L111.62071 138.14694C111.7154 138.42069 111.82509 138.67506 111.95446 138.89412C112.08915 139.12319 112.22853 139.31256 112.3829 139.47194C112.53759 139.63162 112.69196 139.756 112.86134 139.84069C113.02071 139.92537 113.18509 139.97037 113.34446 139.97037C113.60353 139.97037 113.7829 139.87569 113.87759 139.68131C113.97228 139.49194 113.99728 139.19819 113.95228 138.79944L113.57384 135.585999H114.45571L114.83415 138.79944C114.86915 139.1035 114.86915 139.37256 114.83415 139.61162C114.79946 139.84569 114.72946 140.04506 114.62509 140.20944C114.5254 140.37381 114.39571 140.4985 114.23634 140.57819C114.07196 140.66787 113.88759 140.70756 113.67353 140.70756C113.31478 140.70756 112.96603 140.59319 112.62728 140.36881C112.28821 140.13975 111.98446 139.801 111.7154 139.35756ZM117.68806 136.208811C117.33931 136.208811 117.07525 136.328186 116.89087 136.562561C116.7065 136.80162 116.61681 137.15537 116.61681 137.61881C116.61681 137.93256 116.65681 138.23662 116.7315 138.52537C116.80618 138.81444 116.91587 139.0685 117.05525 139.28787C117.19493 139.50694 117.36431 139.68131 117.56368 139.811C117.75775 139.94537 117.98212 140.01006 118.22618 140.01006C118.56993 140.01006 118.839 139.89069 119.01837 139.66131C119.20775 139.42225 119.29743 139.0735 119.29743 138.61006C119.29743 138.29631 119.25743 137.99225 119.18275 137.7035C119.10806 137.41444 118.99837 137.16037 118.859 136.941C118.71431 136.71694 118.54493 136.542561 118.35087 136.408186C118.1515 136.273499 117.93212 136.208811 117.68806 136.208811ZM117.60337 135.516311C117.96712 135.516311 118.30587 135.595999 118.61962 135.765374C118.93368 135.924749 119.20775 136.149124 119.43681 136.432874C119.67087 136.71694 119.85025 137.04569 119.98493 137.41944C120.11931 137.79319 120.184 138.19162 120.184 138.61506C120.184 138.94381 120.13931 139.23787 120.04462 139.49694C119.94993 139.756 119.82056 139.97537 119.65618 140.15475C119.4915 140.33412 119.29243 140.4685 119.06306 140.56819C118.834 140.65787 118.57993 140.70756 118.30587 140.70756C117.94212 140.70756 117.60337 140.62787 117.29462 140.4635C116.97556 140.29912 116.7065 140.07975 116.47243 139.801C116.23837 139.51694 116.059 139.18819 115.92431 138.81444C115.78993 138.44069 115.72525 138.03725 115.72525 137.61381C115.72525 137.28006 115.76993 136.986 115.86462 136.72694C115.95931 136.467874 116.08868 136.248499 116.25337 136.069124C116.41775 135.890061 116.61681 135.755374 116.84618 135.655686C117.07525 135.565999 117.32931 135.516311 117.60337 135.516311ZM122.1661 139.35756L122.2408 140.33881C122.2408 140.53819 122.1411 140.63787 121.942 140.63787H121.5036L120.8958 135.585999H121.7824L122.0714 138.14694C122.1661 138.42069 122.2758 138.67506 122.4052 138.89412C122.5399 139.12319 122.6792 139.31256 122.8336 139.47194C122.9883 139.63162 123.1427 139.756 123.312 139.84069C123.4714 139.92537 123.6358 139.97037 123.7952 139.97037C124.0542 139.97037 124.2336 139.87569 124.3283 139.68131C124.423 139.49194 124.448 139.19819 124.403 138.79944L124.0245 135.585999H124.9064L125.2849 138.79944C125.3199 139.1035 125.3199 139.37256 125.2849 139.61162C125.2502 139.84569 125.1802 140.04506 125.0758 140.20944C124.9761 140.37381 124.8464 140.4985 124.687 140.57819C124.5227 140.66787 124.3383 140.70756 124.1242 140.70756C123.7655 140.70756 123.4167 140.59319 123.078 140.36881C122.7389 140.13975 122.4352 139.801 122.1661 139.35756ZM126.5297 138.93412L126.44 138.20662H128.7166L128.8063 138.93412H126.5297ZM131.3465 139.89569H132.5721L132.6568 140.53319H131.3965L131.4512 140.99662C131.4762 141.21069 131.5209 141.39506 131.5909 141.54475C131.6506 141.69412 131.7302 141.81381 131.8249 141.90819C131.9196 142.00287 132.0243 142.06787 132.1487 142.11256C132.2684 142.15256 132.3977 142.17225 132.5424 142.17225H132.8312C132.9062 142.17225 132.9509 142.20725 132.9659 142.27194L133.0506 142.73037C132.8762 142.79506 132.6918 142.83006 132.4874 142.83006C132.2434 142.83006 132.0143 142.79006 131.7999 142.71037C131.5909 142.63069 131.4015 142.51131 131.2421 142.36162C131.0727 142.20225 130.9381 142.01287 130.8334 141.79381C130.724 141.56444 130.649 141.31037 130.6143 141.02162L130.5546 140.53319H129.8371L129.7921 140.17444C129.7871 140.10475 129.7971 140.05506 129.8371 140.02006C129.8668 139.98537 129.9168 139.96037 129.9765 139.94537L130.4746 139.88069L129.8071 134.34537H130.1509C130.2756 134.34537 130.3752 134.38037 130.4449 134.44006C130.5196 134.50975 130.5743 134.599436 130.6093 134.719124L130.8434 135.750374L131.3465 139.89569Z' fill='#00f'/>
+<path d='M136.0836 140.01506L135.8692 138.28631C135.7749 137.99225 135.6702 137.7185 135.5505 137.46912C135.4308 137.22506 135.3014 137.011 135.162 136.83162C135.0174 136.64725 134.868 136.507561 134.7136 136.403186C134.5589 136.303499 134.3995 136.253499 134.2352 136.253499C133.722 136.253499 133.468 136.65225 133.468 137.45444C133.468 137.6835 133.493 137.90756 133.5477 138.12694C133.6024 138.341 133.6774 138.54537 133.767 138.73975C133.8664 138.93412 133.9761 139.1085 134.1108 139.27287C134.2452 139.43225 134.3895 139.57162 134.5542 139.68631C134.7186 139.801 134.893 139.89069 135.0774 139.96037C135.2614 140.02006 135.4558 140.05506 135.6552 140.05506C135.7249 140.05506 135.7945 140.05006 135.8692 140.05006C135.9392 140.04006 136.0089 140.03006 136.0836 140.01506ZM135.7449 136.91631L135.6502 135.894749C135.6502 135.810061 135.6702 135.735374 135.7099 135.675686C135.7549 135.615999 135.8345 135.585999 135.9492 135.585999H136.4074L137.0102 140.4685C136.8111 140.55319 136.6067 140.61787 136.4074 140.64787C136.1983 140.68756 135.9889 140.70256 135.7749 140.70256C135.4758 140.70256 135.1917 140.65787 134.9177 140.57819C134.6436 140.4885 134.3895 140.36881 134.1555 140.21944C133.9164 140.06006 133.702 139.88069 133.508 139.67131C133.3136 139.45725 133.1492 139.22787 133.0095 138.97381C132.8752 138.71975 132.7705 138.45569 132.6908 138.16662C132.6211 137.88787 132.5811 137.59381 132.5811 137.29475C132.5811 137.011 132.6111 136.75694 132.6758 136.532561C132.7405 136.313499 132.8302 136.129124 132.9399 135.974749C133.0595 135.825061 133.1939 135.710686 133.3583 135.635686C133.5227 135.555999 133.702 135.516311 133.9014 135.516311C134.0858 135.516311 134.2602 135.550999 134.4345 135.615999C134.6039 135.680686 134.7633 135.775374 134.9227 135.894749C135.0724 136.019436 135.2217 136.163811 135.3611 136.338186C135.4958 136.512561 135.6252 136.70194 135.7449 136.91631ZM138.1154 136.537561C138.1204 136.203811 138.2201 135.944749 138.3995 135.770374C138.5888 135.595999 138.8379 135.506311 139.1617 135.506311C139.371 135.506311 139.5801 135.545999 139.7845 135.625999C139.9938 135.710686 140.1779 135.820061 140.3426 135.964749L140.1532 136.388186C140.1382 136.417874 140.1232 136.437874 140.1132 136.452874C140.0932 136.467874 140.0735 136.472874 140.0435 136.472874C140.0185 136.472874 139.9938 136.462874 139.9588 136.432874C139.9238 136.413186 139.8842 136.383186 139.8342 136.353186C139.7845 136.323499 139.7248 136.293499 139.6648 136.273499C139.5951 136.243499 139.5204 136.233811 139.4307 136.233811C139.2963 136.233811 139.1917 136.273499 139.112 136.353186C139.0323 136.437874 138.9923 136.562561 138.9923 136.73194C138.9923 136.74194 138.9923 136.75694 138.9973 136.77662C138.9973 136.79662 138.9973 136.83162 139.0073 136.88131C139.0073 136.93131 139.0173 136.996 139.0273 137.08069C139.037 137.16537 139.052 137.27506 139.067 137.40944L139.371 139.89069H140.701L140.776 140.53319H139.4507L139.6648 142.27194H139.2017C139.1467 142.27194 139.107 142.25694 139.067 142.22225C139.037 142.19225 139.0073 142.15256 138.9923 142.10256L138.6135 140.54319L137.8363 140.4385L137.7967 140.08475C137.7917 140.02006 137.8017 139.97037 137.8313 139.94037C137.8563 139.90537 137.8963 139.89069 137.941 139.89069H138.5042L138.1951 137.36475C138.1751 137.21006 138.1604 137.08069 138.1504 136.986C138.1354 136.89131 138.1304 136.81162 138.1204 136.75194C138.1204 136.69194 138.1154 136.64725 138.1154 136.61225V136.537561Z' fill='#00f'/>
+<path d='M144.605 140.01506L144.3906 138.28631C144.2963 137.99225 144.1916 137.7185 144.0719 137.46912C143.9522 137.22506 143.8228 137.011 143.6834 136.83162C143.5388 136.64725 143.3894 136.507561 143.235 136.403186C143.0803 136.303499 142.9209 136.253499 142.7566 136.253499C142.2434 136.253499 141.9894 136.65225 141.9894 137.45444C141.9894 137.6835 142.0144 137.90756 142.0691 138.12694C142.1238 138.341 142.1988 138.54537 142.2884 138.73975C142.3878 138.93412 142.4975 139.1085 142.6322 139.27287C142.7666 139.43225 142.9109 139.57162 143.0756 139.68631C143.24 139.801 143.4144 139.89069 143.5988 139.96037C143.7828 140.02006 143.9772 140.05506 144.1766 140.05506C144.2463 140.05506 144.3159 140.05006 144.3906 140.05006C144.4606 140.04006 144.5303 140.03006 144.605 140.01506ZM144.2663 136.91631L144.1716 135.894749C144.1716 135.810061 144.1916 135.735374 144.2313 135.675686C144.2763 135.615999 144.3559 135.585999 144.4706 135.585999H144.9288L145.5316 140.4685C145.3325 140.55319 145.1281 140.61787 144.9288 140.64787C144.7197 140.68756 144.5103 140.70256 144.2963 140.70256C143.9972 140.70256 143.7131 140.65787 143.4391 140.57819C143.165 140.4885 142.9109 140.36881 142.6769 140.21944C142.4378 140.06006 142.2234 139.88069 142.0294 139.67131C141.835 139.45725 141.6706 139.22787 141.5309 138.97381C141.3966 138.71975 141.2919 138.45569 141.2122 138.16662C141.1425 137.88787 141.1025 137.59381 141.1025 137.29475C141.1025 137.011 141.1325 136.75694 141.1972 136.532561C141.2619 136.313499 141.3516 136.129124 141.4613 135.974749C141.5809 135.825061 141.7153 135.710686 141.8797 135.635686C142.0441 135.555999 142.2234 135.516311 142.4228 135.516311C142.6072 135.516311 142.7816 135.550999 142.9559 135.615999C143.1253 135.680686 143.2847 135.775374 143.4441 135.894749C143.5938 136.019436 143.7431 136.163811 143.8825 136.338186C144.0172 136.512561 144.1466 136.70194 144.2663 136.91631ZM146.2631 135.585999H147.1349L148.0268 142.92475H147.1549L146.2631 135.585999Z' fill='#00f'/>
+<path d='M121.09058 128.0601L120.8762 126.33135C120.78183 126.03729 120.67714 125.76354 120.55745 125.51416C120.43777 125.2701 120.30839 125.05604 120.16902 124.87666C120.02433 124.69229 119.87495 124.552599 119.72058 124.448224C119.56589 124.348536 119.40652 124.298536 119.24214 124.298536C118.72902 124.298536 118.47495 124.69729 118.47495 125.49947C118.47495 125.72854 118.49995 125.9526 118.55464 126.17197C118.60933 126.38604 118.68433 126.59041 118.77402 126.78479C118.87339 126.97916 118.98308 127.15354 119.11777 127.31791C119.25214 127.47729 119.39652 127.61666 119.5612 127.73135C119.72558 127.84604 119.89995 127.93572 120.08433 128.00541C120.26839 128.0651 120.46277 128.1001 120.66214 128.1001C120.73183 128.1001 120.80152 128.0951 120.8762 128.0951C120.9462 128.0851 121.01589 128.0751 121.09058 128.0601ZM120.75183 124.96135L120.65714 123.939786C120.65714 123.855099 120.67714 123.780411 120.71683 123.720724C120.76183 123.661036 120.84152 123.631036 120.9562 123.631036H121.41433L122.01714 128.51354C121.81808 128.59822 121.6137 128.66291 121.41433 128.69291C121.20527 128.7326 120.99589 128.7476 120.78183 128.7476C120.48277 128.7476 120.1987 128.70291 119.92464 128.62322C119.65058 128.53354 119.39652 128.41385 119.16245 128.26447C118.92339 128.1051 118.70902 127.92572 118.51495 127.71635C118.320579 127.50229 118.156204 127.27291 118.016517 127.01885C117.882142 126.76479 117.777454 126.50072 117.697767 126.21166C117.628079 125.93291 117.588079 125.63885 117.588079 125.33979C117.588079 125.05604 117.618079 124.80197 117.682767 124.577599C117.747454 124.358536 117.837142 124.174161 117.946829 124.019786C118.066517 123.870099 118.200892 123.755724 118.36527 123.680724C118.52964 123.601036 118.70902 123.561349 118.90839 123.561349C119.09277 123.561349 119.26714 123.596036 119.44152 123.661036C119.61089 123.725724 119.77027 123.820411 119.92964 123.939786C120.07933 124.064474 120.2287 124.208849 120.36808 124.383224C120.50277 124.557599 120.63214 124.74697 120.75183 124.96135ZM122.74863 123.631036H123.6205L124.51238 130.96979H123.6405L122.74863 123.631036ZM128.423 128.0601L128.2086 126.33135C128.1143 126.03729 128.0096 125.76354 127.8899 125.51416C127.7702 125.2701 127.6408 125.05604 127.5014 124.87666C127.3568 124.69229 127.20738 124.552599 127.053 124.448224C126.89831 124.348536 126.73894 124.298536 126.57456 124.298536C126.06144 124.298536 125.80738 124.69729 125.80738 125.49947C125.80738 125.72854 125.83238 125.9526 125.88706 126.17197C125.94175 126.38604 126.01675 126.59041 126.10644 126.78479C126.20581 126.97916 126.3155 127.15354 126.45019 127.31791C126.58456 127.47729 126.72894 127.61666 126.89363 127.73135C127.058 127.84604 127.23238 127.93572 127.4168 128.00541C127.6008 128.0651 127.7952 128.1001 127.9946 128.1001C128.0643 128.1001 128.1339 128.0951 128.2086 128.0951C128.2786 128.0851 128.3483 128.0751 128.423 128.0601ZM128.0843 124.96135L127.9896 123.939786C127.9896 123.855099 128.0096 123.780411 128.0493 123.720724C128.0943 123.661036 128.1739 123.631036 128.2886 123.631036H128.7468L129.3496 128.51354C129.1505 128.59822 128.9461 128.66291 128.7468 128.69291C128.5377 128.7326 128.3283 128.7476 128.1143 128.7476C127.8152 128.7476 127.5311 128.70291 127.25706 128.62322C126.983 128.53354 126.72894 128.41385 126.49488 128.26447C126.25581 128.1051 126.04144 127.92572 125.84738 127.71635C125.653 127.50229 125.48863 127.27291 125.34894 127.01885C125.21456 126.76479 125.10988 126.50072 125.03019 126.21166C124.9605 125.93291 124.9205 125.63885 124.9205 125.33979C124.9205 125.05604 124.9505 124.80197 125.01519 124.577599C125.07988 124.358536 125.16956 124.174161 125.27925 124.019786C125.39894 123.870099 125.53331 123.755724 125.69769 123.680724C125.86206 123.601036 126.04144 123.561349 126.24081 123.561349C126.42519 123.561349 126.59956 123.596036 126.77394 123.661036C126.94331 123.725724 127.10269 123.820411 127.26206 123.939786C127.4118 124.064474 127.5611 124.208849 127.7005 124.383224C127.8352 124.557599 127.9646 124.74697 128.0843 124.96135ZM131.3217 127.27291L131.4064 128.38385C131.4064 128.58322 131.3067 128.68291 131.1026 128.68291H130.6642L130.0564 123.631036H130.9232L131.202 125.9676C131.4064 126.74979 131.6754 127.28791 132.0042 127.58697C132.3379 127.88572 132.7167 127.95041 133.1501 127.77604L133.3095 128.62822C133.1251 128.70791 132.941 128.7326 132.7617 128.71291C132.5823 128.68291 132.4079 128.61322 132.2385 128.49354C132.0692 128.37916 131.9045 128.21447 131.7551 128.00541C131.5957 127.80104 131.4564 127.55697 131.3217 127.27291ZM133.4635 123.631036H134.3304L134.6442 126.26166C134.7389 126.53572 134.8385 126.77979 134.9532 126.99885C135.0676 127.21322 135.1873 127.3976 135.3217 127.54697C135.4514 127.70135 135.5907 127.81604 135.7404 127.89572C135.8848 127.97541 136.0392 128.01541 136.1985 128.01541C136.4476 128.01541 136.6023 127.92072 136.667 127.72635C136.7317 127.53197 136.7367 127.23822 136.687 126.84447L136.3082 123.631036H137.1851L137.5089 126.37135V126.37635C137.5985 126.6401 137.7032 126.87947 137.8129 127.07854C137.9323 127.28791 138.052 127.45729 138.1864 127.59697C138.321 127.73135 138.4554 127.83604 138.6001 127.90572C138.7395 127.98041 138.8789 128.01541 139.0235 128.01541C139.2726 128.01541 139.432 127.92072 139.5067 127.72635C139.5764 127.53197 139.5864 127.23822 139.5417 126.84447L139.1579 123.631036H140.0348L140.4135 126.84447C140.4882 127.45229 140.4335 127.92072 140.2542 128.25447C140.0748 128.58822 139.7707 128.7526 139.3373 128.7526C138.9885 128.7526 138.6598 128.64291 138.341 128.42385C138.032 128.19979 137.7479 127.86072 137.4989 127.3976C137.4989 127.83104 137.4192 128.16479 137.2548 128.40385C137.0904 128.63322 136.8414 128.7526 136.4976 128.7526C136.1739 128.7526 135.8598 128.64291 135.561 128.43385C135.267 128.21447 134.9929 127.90072 134.7439 127.48729L134.8135 128.38385C134.8135 128.58322 134.7139 128.68291 134.5098 128.68291H134.0714L133.4635 123.631036Z' fill='#00f'/>
+<path d='M79.570312 185.7109V169.4375' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M79.570312 165.85141C79.769531 166.91391 80.367187 168.640477 81.0625 169.83579H78.07422C78.773437 168.640477 79.371094 166.91391 79.570312 165.85141'/>
+<path d='M71.85937 140.1445L53.3984 109.395' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M51.554706 106.316658C52.273455 107.12525 53.671896 108.301029 54.886735 108.965098L52.324236 110.504162C52.308612 109.121349 51.929701 107.332272 51.554706 106.316658'/>
+<path d='M87.27734 140.1445L105.7383 109.395' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M107.582215 106.31666C107.207209 107.332279 106.832206 109.121346 106.812674 110.504153L104.250171 108.965096C105.46502 108.301032 106.867365 107.125249 107.582215 106.31666'/>
+<path d='M60.2227 102.91C72.85156 109.891 84.78516 110.234 97.0781 103.914' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M100.210894 102.164541C99.378864 102.85204 98.156208 104.211412 97.44918 105.402818L95.999956 102.78563C97.386675 102.816882 99.183546 102.504382 100.210894 102.164541'/>
+<path d='M100.2109 84.758C87.85156 77.309 75.9375 76.523 63.418 82.379' stroke='#000' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M60.222658 84.011672C61.082028 83.351516 62.351563 82.03902 63.105476 80.878865L64.453129 83.546828C63.070316 83.460895 61.261719 83.706988 60.222658 84.011672'/>
+<path d='M65.5898 146.0156C1.3437 113.8945 .2187 75.023 58.832 44.328' stroke='#f00' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M62.023424 42.695297C61.167964 43.359356 59.902335 44.679667 59.160147 45.843732L57.792962 43.187485C59.175771 43.261702 60.98436 43.00389 62.023424 42.695297' fill='#f00'/>
+<path d='M51.5547 80.609L70.00781 49.859' stroke='#f00' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M71.855507 46.781288C71.480508 47.796914 71.101607 49.585976 71.085973 50.968785L68.523478 49.429724C69.73832 48.765665 71.136761 47.589887 71.855507 46.781288' fill='#f00'/>
+<path d='M107.582 80.609L89.12891 49.859' stroke='#f00' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='2.98883,2.98883'/>
+<path d='M87.281205 46.781292C87.999961 47.589885 89.402302 48.765666 90.613248 49.429719L88.050736 50.968791C88.035108 49.585977 87.660117 47.796913 87.281205 46.781292' fill='#f00'/>
+<path d='M82.58984 21.074C87.21094 1.449 73.46484 .273 75.87891 17.539' stroke='#f00' fill='none' stroke-width='.3985' stroke-miterlimit='10'/>
+<path d='M76.546918 21.074224C76.160195 20.06641 75.257852 18.476564 74.355509 17.425782L77.296908 16.886722C76.828162 18.187503 76.550812 19.996092 76.546918 21.074224' fill='#f00'/>
+<path d='M33.01979 40.68371H34.24541L34.3301 41.32121H33.06979L33.12448 41.78465C33.14948 41.99871 33.19416 42.18308 33.26416 42.33277C33.32385 42.48215 33.40354 42.60183 33.49823 42.69621C33.59291 42.79089 33.6976 42.85589 33.82198 42.90058C33.94166 42.94058 34.07104 42.96027 34.21573 42.96027H34.50448C34.57948 42.96027 34.62416 42.99527 34.63916 43.05996L34.72385 43.5184C34.54948 43.58308 34.3651 43.61808 34.16073 43.61808C33.91666 43.61808 33.6876 43.57808 33.47323 43.4984C33.26416 43.41871 33.07479 43.29933 32.91541 43.14965C32.74604 42.99027 32.61135 42.8009 32.50666 42.58183C32.39729 42.35246 32.32229 42.0984 32.2876 41.80965L32.22791 41.32121H31.510413L31.465413 40.96246C31.460413 40.89277 31.470413 40.84308 31.510413 40.80808C31.540101 40.77339 31.590101 40.7484 31.649788 40.7334L32.14791 40.66871L31.480413 35.1334H31.824163C31.948851 35.1334 32.048538 35.1684 32.11823 35.22808C32.19291 35.29777 32.2476 35.387458 32.2826 35.507145L32.51666 36.538395L33.01979 40.68371Z' fill='#f00'/>
+<path d='M37.7658 40.80308L37.55143 39.07433C37.45705 38.78027 37.35237 38.50652 37.23268 38.25715C37.11299 38.01308 36.98362 37.79902 36.84424 37.61965C36.69955 37.43527 36.55018 37.295583 36.3958 37.191208C36.24112 37.09152 36.08174 37.04152 35.91737 37.04152C35.40424 37.04152 35.15018 37.44027 35.15018 38.24246C35.15018 38.47152 35.17518 38.69558 35.22987 38.91496C35.28455 39.12902 35.35955 39.3334 35.44924 39.52777C35.54862 39.72215 35.6583 39.89652 35.79299 40.0609C35.92737 40.22027 36.07174 40.35965 36.23643 40.47433C36.4008 40.58902 36.57518 40.67871 36.75955 40.7484C36.94362 40.80808 37.13799 40.84308 37.33737 40.84308C37.40705 40.84308 37.47674 40.83808 37.55143 40.83808C37.62143 40.82808 37.69112 40.81808 37.7658 40.80308ZM37.42705 37.70433L37.33237 36.68277C37.33237 36.598083 37.35237 36.523395 37.39205 36.463708C37.43705 36.40402 37.51674 36.37402 37.63143 36.37402H38.08955L38.69237 41.25652C38.4933 41.34121 38.28893 41.4059 38.08955 41.4359C37.88049 41.47558 37.67112 41.49058 37.45705 41.49058C37.15799 41.49058 36.87393 41.4459 36.59987 41.36621C36.3258 41.27652 36.07174 41.15683 35.83768 41.00746C35.59862 40.84808 35.38424 40.66871 35.19018 40.45933C34.9958 40.24527 34.83143 40.0159 34.69174 39.76183C34.55737 39.50777 34.45268 39.24371 34.37299 38.95465C34.3033 38.6759 34.2633 38.38183 34.2633 38.08277C34.2633 37.79902 34.2933 37.54496 34.35799 37.320583C34.42268 37.10152 34.51237 36.917145 34.62205 36.76277C34.74174 36.613083 34.87612 36.498708 35.04049 36.423708C35.20487 36.34402 35.38424 36.304333 35.58362 36.304333C35.76799 36.304333 35.94237 36.33902 36.11674 36.40402C36.28612 36.468708 36.44549 36.563395 36.60487 36.68277C36.75455 36.807458 36.90393 36.951833 37.0433 37.126208C37.17799 37.300583 37.30737 37.48996 37.42705 37.70433ZM39.7976 37.325583C39.8026 36.991833 39.90229 36.73277 40.08166 36.558395C40.27104 36.38402 40.5201 36.294333 40.84385 36.294333C41.0532 36.294333 41.2623 36.33402 41.4667 36.41402C41.676 36.498708 41.8601 36.608083 42.0248 36.75277L41.8354 37.176208C41.8204 37.205895 41.8054 37.225895 41.7954 37.240895C41.7754 37.255895 41.7557 37.260895 41.7257 37.260895C41.7007 37.260895 41.676 37.250895 41.641 37.220895C41.606 37.201208 41.5664 37.171208 41.5164 37.141208C41.4667 37.11152 41.407 37.08152 41.347 37.06152C41.2773 37.03152 41.2026 37.021833 41.1129 37.021833C40.97854 37.021833 40.87385 37.06152 40.79416 37.141208C40.71448 37.225895 40.67448 37.350583 40.67448 37.51996C40.67448 37.52996 40.67448 37.54496 40.67948 37.56465C40.67948 37.58465 40.67948 37.61965 40.68948 37.66933C40.68948 37.71933 40.69948 37.78402 40.70948 37.86871C40.71916 37.9534 40.73416 38.06308 40.74916 38.19746L41.0532 40.67871H42.3832L42.4582 41.32121H41.1329L41.347 43.05996H40.88385C40.82885 43.05996 40.78916 43.04496 40.74916 43.01027C40.71916 42.98027 40.68948 42.94058 40.67448 42.89058L40.29573 41.33121L39.51854 41.22652L39.47885 40.87277C39.47385 40.80808 39.48385 40.7584 39.51354 40.72839C39.53854 40.6934 39.57854 40.67871 39.62323 40.67871H40.18635L39.87729 38.15277C39.85729 37.99808 39.8426 37.86871 39.8326 37.77402C39.8176 37.67933 39.8126 37.59965 39.8026 37.53996C39.8026 37.47996 39.7976 37.43527 39.7976 37.40027V37.325583Z' fill='#f00'/>
+<path d='M46.2873 40.80308L46.0729 39.07433C45.9785 38.78027 45.8739 38.50652 45.7542 38.25715C45.6345 38.01308 45.5051 37.79902 45.3657 37.61965C45.221 37.43527 45.0717 37.295583 44.9173 37.191208C44.7626 37.09152 44.6032 37.04152 44.4389 37.04152C43.9257 37.04152 43.6717 37.44027 43.6717 38.24246C43.6717 38.47152 43.6967 38.69558 43.7514 38.91496C43.806 39.12902 43.881 39.3334 43.9707 39.52777C44.0701 39.72215 44.1798 39.89652 44.3145 40.0609C44.4489 40.22027 44.5932 40.35965 44.7579 40.47433C44.9223 40.58902 45.0967 40.67871 45.281 40.7484C45.4651 40.80808 45.6595 40.84308 45.8589 40.84308C45.9285 40.84308 45.9982 40.83808 46.0729 40.83808C46.1429 40.82808 46.2126 40.81808 46.2873 40.80308ZM45.9485 37.70433L45.8539 36.68277C45.8539 36.598083 45.8739 36.523395 45.9135 36.463708C45.9585 36.40402 46.0382 36.37402 46.1529 36.37402H46.611L47.2138 41.25652C47.0148 41.34121 46.8104 41.4059 46.611 41.4359C46.402 41.47558 46.1926 41.49058 45.9785 41.49058C45.6795 41.49058 45.3954 41.4459 45.1214 41.36621C44.8473 41.27652 44.5932 41.15683 44.3592 41.00746C44.1201 40.84808 43.9057 40.66871 43.7117 40.45933C43.5173 40.24527 43.3529 40.0159 43.2132 39.76183C43.0789 39.50777 42.9742 39.24371 42.8945 38.95465C42.8248 38.6759 42.7848 38.38183 42.7848 38.08277C42.7848 37.79902 42.8148 37.54496 42.8795 37.320583C42.9442 37.10152 43.0339 36.917145 43.1435 36.76277C43.2632 36.613083 43.3976 36.498708 43.562 36.423708C43.7264 36.34402 43.9057 36.304333 44.1051 36.304333C44.2895 36.304333 44.4639 36.33902 44.6382 36.40402C44.8076 36.468708 44.967 36.563395 45.1264 36.68277C45.276 36.807458 45.4254 36.951833 45.5648 37.126208C45.6995 37.300583 45.8289 37.48996 45.9485 37.70433ZM47.9453 36.37402H48.8172L49.7091 43.71277H48.8372L47.9453 36.37402Z' fill='#f00'/>
+<path d='M32.75672 28.89804C32.8914 28.89804 33.00078 28.88304 33.09547 28.84304C33.19015 28.81335 33.26484 28.76835 33.32484 28.71367C33.37953 28.65867 33.42453 28.60398 33.44922 28.53429C33.47422 28.47429 33.48922 28.4096 33.48922 28.34992C33.48922 28.23023 33.46422 28.11585 33.40953 28.00617C33.35453 27.89648 33.24515 27.79679 33.08047 27.6971C32.91609 27.60742 32.67703 27.51773 32.36828 27.43804C32.05922 27.35335 31.65078 27.28367 31.13765 27.21898C31.19234 27.45304 31.26703 27.67742 31.36172 27.87648C31.4564 28.08585 31.57609 28.26023 31.71047 28.4146C31.84515 28.56398 32.00453 28.68367 32.1789 28.76835C32.35328 28.85304 32.54765 28.89804 32.75672 28.89804ZM34.16172 25.350542L33.94265 25.6246C33.89265 25.6796 33.83797 25.70929 33.77328 25.70929C33.71828 25.70929 33.66859 25.69429 33.61359 25.6596C33.5589 25.6246 33.50422 25.58492 33.44422 25.53492C33.37953 25.49023 33.31484 25.43523 33.23515 25.375542C33.16547 25.320855 33.07578 25.265855 32.97609 25.216167C32.8814 25.171167 32.76672 25.13148 32.64703 25.09648C32.51765 25.061792 32.37828 25.046792 32.21859 25.046792C31.82515 25.046792 31.53109 25.166167 31.34172 25.395542C31.14265 25.6346 31.04797 25.97335 31.04797 26.41679C31.04797 26.45179 31.04797 26.49148 31.05297 26.52148C31.05297 26.56117 31.05297 26.59617 31.05297 26.63117C31.71047 26.69585 32.24859 26.78554 32.66703 26.89523C33.08547 27.0046 33.41453 27.13429 33.65359 27.27867C33.89265 27.42804 34.05703 27.59773 34.14672 27.77679C34.2364 27.96617 34.2814 28.16554 34.2814 28.38492C34.2814 28.50929 34.2514 28.63898 34.19172 28.77335C34.13672 28.90773 34.04703 29.03242 33.92765 29.1471C33.80797 29.26148 33.65359 29.35117 33.46922 29.42617C33.28484 29.50085 33.06078 29.53554 32.80672 29.53554C32.53765 29.53554 32.28859 29.49585 32.04922 29.41117C31.82015 29.32648 31.60078 29.21179 31.41172 29.07242C31.21234 28.92273 31.04297 28.75335 30.893591 28.55429C30.738904 28.35492 30.614529 28.14054 30.504841 27.90648C30.405154 27.67242 30.325466 27.42804 30.265779 27.16898C30.215779 26.91492 30.186091 26.65585 30.186091 26.39679C30.186091 26.08304 30.230779 25.80398 30.315466 25.54992C30.400154 25.295855 30.524841 25.08148 30.684216 24.907105C30.843591 24.72773 31.03797 24.588355 31.26703 24.493667C31.4964 24.39898 31.75547 24.349292 32.04422 24.349292C32.25859 24.349292 32.45797 24.369292 32.63734 24.40898C32.8264 24.44398 33.00078 24.503667 33.16547 24.588355C33.33484 24.673042 33.49922 24.77773 33.66359 24.897417C33.82797 25.026792 33.99234 25.176167 34.16172 25.350542ZM36.22344 28.06085L36.30812 29.17179C36.30812 29.37117 36.20844 29.47085 36.00437 29.47085H35.56593L34.95812 24.41898H35.825L36.10375 26.75554C36.30812 27.53773 36.57718 28.07585 36.90593 28.37492C37.23969 28.67367 37.61844 28.73835 38.05187 28.56398L38.21125 29.41617C38.02687 29.49585 37.84281 29.52054 37.66344 29.50085C37.48406 29.47085 37.30968 29.40117 37.14031 29.28148C36.97094 29.1671 36.80625 29.00242 36.65687 28.79335C36.4975 28.58898 36.35812 28.34492 36.22344 28.06085ZM39.63062 28.06085L39.71531 29.17179C39.71531 29.37117 39.61562 29.47085 39.41156 29.47085H38.97312L38.36531 24.41898H39.23219L39.51094 26.75554C39.71531 27.53773 39.9844 28.07585 40.3131 28.37492C40.6469 28.67367 41.0256 28.73835 41.4591 28.56398L41.6184 29.41617C41.4341 29.49585 41.25 29.52054 41.0706 29.50085C40.8912 29.47085 40.7169 29.40117 40.5475 29.28148C40.3781 29.1671 40.2134 29.00242 40.0641 28.79335C39.9047 28.58898 39.76531 28.34492 39.63062 28.06085Z' fill='#f00'/>
+<path d='M43.5427 25.041792C43.194 25.041792 42.9299 25.161167 42.7455 25.395542C42.5612 25.6346 42.4715 25.98835 42.4715 26.45179C42.4715 26.76554 42.5115 27.0696 42.5862 27.35835C42.6609 27.64742 42.7705 27.90148 42.9099 28.12085C43.0496 28.33992 43.219 28.51429 43.4184 28.64398C43.6124 28.77835 43.8368 28.84304 44.0809 28.84304C44.4246 28.84304 44.6937 28.72367 44.873 28.49429C45.0624 28.25523 45.1521 27.90648 45.1521 27.44304C45.1521 27.12929 45.1121 26.82523 45.0374 26.53648C44.9627 26.24742 44.853 25.99335 44.7137 25.77398C44.569 25.54992 44.3996 25.375542 44.2055 25.241167C44.0062 25.10648 43.7868 25.041792 43.5427 25.041792ZM43.458 24.349292C43.8218 24.349292 44.1605 24.42898 44.4743 24.598355C44.7884 24.75773 45.0624 24.982105 45.2915 25.265855C45.5255 25.54992 45.7049 25.87867 45.8396 26.25242C45.974 26.62617 46.0387 27.0246 46.0387 27.44804C46.0387 27.77679 45.994 28.07085 45.8993 28.32992C45.8046 28.58898 45.6752 28.80835 45.5109 28.98773C45.3462 29.1671 45.1471 29.30148 44.9177 29.40117C44.6887 29.49085 44.4346 29.54054 44.1605 29.54054C43.7968 29.54054 43.458 29.46085 43.1493 29.29648C42.8302 29.1321 42.5612 28.91273 42.3271 28.63398C42.093 28.34992 41.9137 28.02117 41.779 27.64742C41.6446 27.27367 41.5799 26.87023 41.5799 26.44679C41.5799 26.11304 41.6246 25.81898 41.7193 25.55992C41.814 25.300855 41.9434 25.08148 42.108 24.902105C42.2724 24.723042 42.4715 24.588355 42.7009 24.488667C42.9299 24.39898 43.184 24.349292 43.458 24.349292ZM48.0158 28.06085L48.1005 29.17179C48.1005 29.37117 48.0008 29.47085 47.7967 29.47085H47.3583L46.7505 24.41898H47.6173L47.8961 26.75554C48.1005 27.53773 48.3695 28.07585 48.6983 28.37492C49.032 28.67367 49.4108 28.73835 49.8442 28.56398L50.0036 29.41617C49.8192 29.49585 49.6352 29.52054 49.4558 29.50085C49.2764 29.47085 49.102 29.40117 48.9327 29.28148C48.7633 29.1671 48.5986 29.00242 48.4492 28.79335C48.2898 28.58898 48.1505 28.34492 48.0158 28.06085Z' fill='#f00'/>
+<path d='M39.5625 106.316C39.8711 105.422 39.8828 123.707 62.6914 141.0977' stroke='#00f' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='.3985,.99628'/>
+<path d='M65.589862 143.21497C64.613298 142.746217 62.86721 142.20716 61.492207 142.06263L63.261736 139.652467C63.812518 140.922001 64.851585 142.425912 65.589862 143.21497' fill='#00f'/>
+<path d='M119.5742 106.316C119.2656 105.422 119.2539 123.707 96.4453 141.0977' stroke='#00f' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='.3985,.99628'/>
+<path d='M93.546865 143.214977C94.289057 142.425913 95.324209 140.922007 95.878896 139.652482L97.644525 142.062631C96.269525 142.207166 94.523432 142.746227 93.546865 143.214977' fill='#00f'/>
+<path d='M65.5898 149.707C47.0977 145.3594 45.918 158.9961 62.0508 156.9336' stroke='#00f' fill='none' stroke-width='.3985' stroke-miterlimit='10' stroke-dasharray='.3985,.99628'/>
+<path d='M65.589851 156.285522C64.578129 156.668345 62.980472 157.558956 61.925786 158.453489L61.406255 155.512087C62.703132 155.988646 64.507821 156.273806 65.589851 156.285522' fill='#00f'/>
+</g>
+</g>
+</svg>
diff --git a/src/images/graphviz/litmus_addrpo.png b/src/images/graphviz/litmus_addrpo.png
new file mode 100644
index 0000000..38209e3
--- /dev/null
+++ b/src/images/graphviz/litmus_addrpo.png
Binary files differ
diff --git a/src/graphviz/litmus_addrpo.dot b/src/images/graphviz/litmus_addrpo.txt
index d61fd5e..3bd231b 100644
--- a/src/graphviz/litmus_addrpo.dot
+++ b/src/images/graphviz/litmus_addrpo.txt
@@ -8,7 +8,7 @@ pad="0.000000";
eiid0 [label="a: Ry=1", shape="none", fontsize=8, pos="1.000000,1.125000!", fixedsize="false", height="0.111111", width="0.555556"];
eiid1 [label="c: Wx=t", shape="none", fontsize=8, pos="1.000000,0.562500!", fixedsize="false", height="0.111111", width="0.555556"];
eiid2 [label="d: Rx=t", shape="none", fontsize=8, pos="2.500000,1.125000!", fixedsize="false", height="0.111111", width="0.555556"];
-eiid3 [label="e: Rt=$v$", shape="none", fontsize=8, pos="2.500000,0.562500!", fixedsize="false", height="0.111111", width="0.555556"];
+eiid3 [label="e: Rt=v", shape="none", fontsize=8, pos="2.500000,0.562500!", fixedsize="false", height="0.111111", width="0.555556"];
eiid4 [label="f: Wy=1", shape="none", fontsize=8, pos="2.500000,0.000000!", fixedsize="false", height="0.111111", width="0.555556"];
/* the intra_causality_data edges */
diff --git a/src/images/graphviz/litmus_datacoirfi.png b/src/images/graphviz/litmus_datacoirfi.png
new file mode 100644
index 0000000..4315b90
--- /dev/null
+++ b/src/images/graphviz/litmus_datacoirfi.png
Binary files differ
diff --git a/src/graphviz/litmus_datacoirfi.dot b/src/images/graphviz/litmus_datacoirfi.txt
index df8ea72..df8ea72 100644
--- a/src/graphviz/litmus_datacoirfi.dot
+++ b/src/images/graphviz/litmus_datacoirfi.txt
diff --git a/src/images/graphviz/litmus_datarfi.png b/src/images/graphviz/litmus_datarfi.png
new file mode 100644
index 0000000..06f4042
--- /dev/null
+++ b/src/images/graphviz/litmus_datarfi.png
Binary files differ
diff --git a/src/graphviz/litmus_datarfi.dot b/src/images/graphviz/litmus_datarfi.txt
index 88106e3..88106e3 100644
--- a/src/graphviz/litmus_datarfi.dot
+++ b/src/images/graphviz/litmus_datarfi.txt
diff --git a/src/images/graphviz/litmus_lb_lrsc.png b/src/images/graphviz/litmus_lb_lrsc.png
new file mode 100644
index 0000000..b47eb35
--- /dev/null
+++ b/src/images/graphviz/litmus_lb_lrsc.png
Binary files differ
diff --git a/src/graphviz/litmus_lb_lrsc.dot b/src/images/graphviz/litmus_lb_lrsc.txt
index 0a6c4ca..ae74dcd 100644
--- a/src/graphviz/litmus_lb_lrsc.dot
+++ b/src/images/graphviz/litmus_lb_lrsc.txt
@@ -2,7 +2,7 @@ digraph G {
splines=spline;
pad="0.000000";
-
+label="A sample litmus test and one forbidden execution (a0-1)."
/* the unlocked events */
eiid0 [label="a: Rx=0", shape="none", fontsize=8, pos="1.000000,1.687500!", fixedsize="false", height="0.111111", width="0.555556"];
diff --git a/src/images/graphviz/litmus_mp_fenceww_fri_rfi_addr.png b/src/images/graphviz/litmus_mp_fenceww_fri_rfi_addr.png
new file mode 100644
index 0000000..c999de9
--- /dev/null
+++ b/src/images/graphviz/litmus_mp_fenceww_fri_rfi_addr.png
Binary files differ
diff --git a/src/graphviz/litmus_mp_fenceww_fri_rfi_addr.dot b/src/images/graphviz/litmus_mp_fenceww_fri_rfi_addr.txt
index e56599b..e2cd98b 100644
--- a/src/graphviz/litmus_mp_fenceww_fri_rfi_addr.dot
+++ b/src/images/graphviz/litmus_mp_fenceww_fri_rfi_addr.txt
@@ -2,7 +2,7 @@ digraph G {
splines=spline;
pad="0.000000";
-
+label="Litmus test MP+fence.w.w+fri-rfi-addr (outcome permitted)"
/* the unlocked events */
eiid0 [label="a: Wx=1", shape="none", fontsize=8, pos="1.000000,1.575000!", fixedsize="false", height="0.111111", width="0.555556"];
diff --git a/src/images/graphviz/litmus_ppoca.png b/src/images/graphviz/litmus_ppoca.png
new file mode 100644
index 0000000..032629b
--- /dev/null
+++ b/src/images/graphviz/litmus_ppoca.png
Binary files differ
diff --git a/src/graphviz/litmus_ppoca.dot b/src/images/graphviz/litmus_ppoca.txt
index d512d5f..fbf6d00 100644
--- a/src/graphviz/litmus_ppoca.dot
+++ b/src/images/graphviz/litmus_ppoca.txt
@@ -1,8 +1,9 @@
+
digraph G {
splines=spline;
pad="0.000000";
-
+label="The PPOCA store buffer forwarding litmus test (outcome permitted)."
/* the unlocked events */
eiid0 [label="a: Wx=1", shape="none", fontsize=8, pos="1.000000,1.687500!", fixedsize="false", height="0.111111", width="0.555556"];
diff --git a/src/images/graphviz/litmus_rsw.png b/src/images/graphviz/litmus_rsw.png
new file mode 100644
index 0000000..68f6c92
--- /dev/null
+++ b/src/images/graphviz/litmus_rsw.png
Binary files differ
diff --git a/src/graphviz/litmus_rsw.dot b/src/images/graphviz/litmus_rsw.txt
index 9142351..15a6cee 100644
--- a/src/graphviz/litmus_rsw.dot
+++ b/src/images/graphviz/litmus_rsw.txt
@@ -2,7 +2,7 @@ digraph G {
splines=spline;
pad="0.000000";
-
+label="Litmus test RSW (outcome permitted)."
/* the unlocked events */
eiid0 [label="a: Wx=1", shape="none", fontsize=8, pos="1.000000,2.025000!", fixedsize="false", height="0.111111", width="0.555556"];
diff --git a/src/graphviz/litmus_sample.dot b/src/images/graphviz/litmus_sample.adoc
index 072c8ca..1ffb096 100644
--- a/src/graphviz/litmus_sample.dot
+++ b/src/images/graphviz/litmus_sample.adoc
@@ -1,3 +1,7 @@
+//a-1
+
+["graphviz", ,"png"]
+....
digraph G {
splines=spline;
@@ -33,3 +37,4 @@ eiid2 -> eiid3 [label=<<font color="#ffa040">fr</font>>, color="#ffa040", fontsi
eiiid6 [label="", shape=none, width=0.05, height=0.1, pos="1.0,1.85!";]
eiid4 -> eiid5 [label=<<font color="blue">co</font>>, color="blue", fontsize=11, penwidth="3.000000", arrowsize="0.666700"];
}
+....
diff --git a/src/images/graphviz/litmus_sample.png b/src/images/graphviz/litmus_sample.png
new file mode 100644
index 0000000..7d081f4
--- /dev/null
+++ b/src/images/graphviz/litmus_sample.png
Binary files differ
diff --git a/src/images/graphviz/litmus_sample.txt b/src/images/graphviz/litmus_sample.txt
new file mode 100644
index 0000000..bb772a0
--- /dev/null
+++ b/src/images/graphviz/litmus_sample.txt
@@ -0,0 +1,37 @@
+
+digraph G {
+
+splines=spline;
+pad="0.000000";
+label="A sample litmus test and one forbidden execution (a0=1).";
+
+
+/* the unlocked events */
+eiid0 [label="a: Wx=1", shape="none", fontsize=8, pos="1.000000,2.109375!", fixedsize="false", height="0.111111", width="0.555556"];
+eiid1 [label="b: Wx=2", shape="none", fontsize=8, pos="1.000000,1.546875!", fixedsize="false", height="0.111111", width="0.555556"];
+eiid2 [label="c: Rx=1", shape="none", fontsize=8, pos="1.000000,0.984375!", fixedsize="false", height="0.111111", width="0.555556"];
+eiid3 [label="d: Wx=3", shape="none", fontsize=8, pos="1.000000,0.421875!", fixedsize="false", height="0.111111", width="0.555556"];
+eiid4 [label="e: Wx=4", shape="none", fontsize=8, pos="1.850000,1.687500!", fixedsize="false", height="0.111111", width="0.555556"];
+eiiid6 [label="", shape=none, width=0.05, height=0.1, pos="1.0,1.85!";]
+eiid5 [label="f: Wx=5", shape="none", fontsize=8, pos="1.850000,1.125000!", fixedsize="false", height="0.111111", width="0.555556"];
+
+/* the intra_causality_data edges */
+
+
+/* the intra_causality_control edges */
+
+/* the poi edges */
+/* the rfmap edges */
+
+
+/* The viewed-before edges */
+eiid0 -> eiid1 [label=<<font color="blue">co</font>>, color="blue", fontsize=11, penwidth="3.000000", arrowsize="0.666700"];
+eiid0 -> eiid2 [label=<<font color="red">rf</font>>, color="red", fontsize=11, penwidth="3.000000", arrowsize="0.666700"];
+eiid1 -> eiid0 [label=<<font color="blue">co</font>>, color="blue", fontsize=11, penwidth="3.000000", arrowsize="0.666700"];
+eiid1 -> eiid3 [label=<<font color="blue">co</font>>, color="blue", fontsize=11, penwidth="3.000000", arrowsize="0.666700"];
+eiid2 -> eiid0 [label=<<font color="#ffa040">fr</font>>, color="#ffa040", fontsize=11, penwidth="3.000000", arrowsize="0.666700"];
+eiid2 -> eiid1 [label=<<font color="#ffa040">fr</font>>, color="#ffa040", fontsize=11, penwidth="3.000000", arrowsize="0.666700"];
+eiid2 -> eiid3 [label=<<font color="#ffa040">fr</font>>, color="#ffa040", fontsize=11, penwidth="3.000000", arrowsize="0.666700"];
+eiiid6 [label="", shape=none, width=0.05, height=0.1, pos="1.0,1.85!";]
+eiid4 -> eiid5 [label=<<font color="blue">co</font>>, color="blue", fontsize=11, penwidth="3.000000", arrowsize="0.666700"];
+}
diff --git a/src/images/graphviz/litmus_sb_fwd.png b/src/images/graphviz/litmus_sb_fwd.png
new file mode 100644
index 0000000..71513b6
--- /dev/null
+++ b/src/images/graphviz/litmus_sb_fwd.png
Binary files differ
diff --git a/src/graphviz/litmus_sb_fwd.dot b/src/images/graphviz/litmus_sb_fwd.txt
index 5434951..1bcd5ff 100644
--- a/src/graphviz/litmus_sb_fwd.dot
+++ b/src/images/graphviz/litmus_sb_fwd.txt
@@ -1,8 +1,9 @@
+
digraph G {
splines=spline;
pad="0.000000";
-
+label="A store buffer forwarding litmus test (outcome permitted).";
/* the unlocked events */
eiid0 [label="a: Wx=1", shape="none", fontsize=8, pos="1.000000,1.125000!", fixedsize="false", height="0.111111", width="0.555556"];
diff --git a/src/images/graphviz/litmus_subsumption.png b/src/images/graphviz/litmus_subsumption.png
new file mode 100644
index 0000000..bb7f1f2
--- /dev/null
+++ b/src/images/graphviz/litmus_subsumption.png
Binary files differ
diff --git a/src/graphviz/litmus_subsumption.dot b/src/images/graphviz/litmus_subsumption.txt
index 75e0a70..75e0a70 100644
--- a/src/graphviz/litmus_subsumption.dot
+++ b/src/images/graphviz/litmus_subsumption.txt
diff --git a/src/images/image_placeholder.png b/src/images/image_placeholder.png
new file mode 100644
index 0000000..dc3ea33
--- /dev/null
+++ b/src/images/image_placeholder.png
Binary files differ
diff --git a/src/images/png/misareg.png b/src/images/png/misareg.png
new file mode 100644
index 0000000..5b6e96d
--- /dev/null
+++ b/src/images/png/misareg.png
Binary files differ
diff --git a/src/images/png/mvendorid.png b/src/images/png/mvendorid.png
new file mode 100644
index 0000000..f941147
--- /dev/null
+++ b/src/images/png/mvendorid.png
Binary files differ
diff --git a/src/images/png/privimps.png b/src/images/png/privimps.png
new file mode 100644
index 0000000..f2a78ae
--- /dev/null
+++ b/src/images/png/privimps.png
Binary files differ
diff --git a/src/images/risc-v_logo.png b/src/images/risc-v_logo.png
new file mode 100644
index 0000000..d754746
--- /dev/null
+++ b/src/images/risc-v_logo.png
Binary files differ
diff --git a/src/images/riscv-horizontal-color.svg b/src/images/riscv-horizontal-color.svg
new file mode 100644
index 0000000..8b6e13b
--- /dev/null
+++ b/src/images/riscv-horizontal-color.svg
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Generator: Adobe Illustrator 26.4.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
+<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
+ viewBox="0 0 1000 175.4" style="enable-background:new 0 0 1000 175.4;" xml:space="preserve">
+<style type="text/css">
+ .st0{fill:#E6AC2C;}
+ .st1{fill:#2C356D;}
+</style>
+<g>
+ <g>
+ <path class="st0" d="M91.6,58.2c0,22.9-13.9,43.7-40.9,48.6l38.1,45.1l3.4-4.8L161,49.9V9H49.3C77.7,11.7,91.6,35.3,91.6,58.2z"/>
+ <path class="st1" d="M13.2,85.9h26.4C59,85.9,68.7,72,68.7,58.2c0-13.9-9.7-27.1-29.1-27.1H3.5v135.3h67.3L13.2,97.1V85.9z
+ M111,159.5l50.6-70.8v77.7H106L111,159.5z"/>
+ <rect x="392.7" y="35.3" class="st1" width="22.9" height="107.5"/>
+ <path class="st1" d="M552,119.3l-119.1-0.1v23.6h120c9,0,16.7-3.5,22.9-9.7s9.7-13.9,9.7-22.9s-3.5-16.6-9.7-22.9
+ c-6.2-6.2-13.9-9.7-22.9-9.7L465.6,77c-5.1,0-9.3-4.2-9.4-9.3l0,0l0,0c0-5.2,4.2-9.3,9.4-9.3l119.9-0.1v-23h-120
+ c-9,0-16.7,3.5-22.9,9.7c-6.2,6.2-9.7,13.9-9.7,22.9s3.5,16.6,9.7,22.9c6.2,6.2,13.9,9,22.9,9h87.2c5.2,0,9.4,4.2,9.3,9.4l0,0l0,0
+ C562.1,114.8,557.6,119.3,552,119.3z"/>
+ <path class="st1" d="M650,35.3h99.2v22.9H650c-8.3,0-15.2,2.7-21.5,9c-6.2,6.2-9,13.2-9,21.5s2.8,15.2,9,21.5
+ c6.3,6.2,13.2,9,21.5,9h99.2v23.6H650c-14.6,0-27.1-5.6-37.5-16s-15.2-22.9-15.2-37.5s4.8-27.1,15.2-37.5
+ C623,40.9,635.4,35.3,650,35.3z"/>
+ <path class="st1" d="M342,78.5l-95.7-0.2V58.9l96.7-0.2c5.2,0,9.5,4.2,9.5,9.4l0,0l0,0C352.4,73.9,347.8,78.5,342,78.5z
+ M376,142.8l-30.5-42.3c8.3-0.7,15.2-3.5,20.8-9.7c6.2-6.3,9.7-13.9,9.7-22.9s-3.5-16.7-9.7-22.9s-13.9-9.7-22.9-9.7h-120v107.5
+ h22.9v-42.3h70.8l30.5,42.3H376z"/>
+ <polyline class="st0" points="863.7,142.8 800.8,35.3 827.7,35.3 876.8,120.6 926,35.3 952.5,35.3 890,142.8 "/>
+ <rect x="763.1" y="79" class="st0" width="45.1" height="20.8"/>
+ </g>
+ <g>
+ <path class="st1" d="M996.5,52.5c0,9.4-7.3,16.7-16.9,16.7c-9.5,0-17-7.3-17-16.7c0-9.2,7.5-16.5,17-16.5
+ C989.1,36,996.5,43.3,996.5,52.5z M966.8,52.5c0,7.3,5.4,13.2,12.9,13.2c7.2,0,12.6-5.8,12.6-13.1s-5.3-13.3-12.7-13.3
+ S966.8,45.2,966.8,52.5z M977,61.1h-3.8V44.6c1.5-0.3,3.6-0.5,6.3-0.5c3.1,0,4.5,0.5,5.7,1.2c0.9,0.7,1.6,2,1.6,3.6
+ c0,1.8-1.4,3.2-3.4,3.8V53c1.6,0.6,2.5,1.8,3,4c0.5,2.5,0.8,3.5,1.2,4.1h-4.1c-0.5-0.6-0.8-2.1-1.3-4c-0.3-1.8-1.3-2.6-3.4-2.6
+ H977V61.1L977,61.1z M977,51.8h1.8c2.1,0,3.8-0.7,3.8-2.4c0-1.5-1.1-2.5-3.5-2.5c-1,0-1.7,0.1-2.1,0.2V51.8z"/>
+ </g>
+</g>
+</svg>
diff --git a/src/images/smepmp-visual-representation.png b/src/images/smepmp-visual-representation.png
new file mode 100644
index 0000000..9502271
--- /dev/null
+++ b/src/images/smepmp-visual-representation.png
Binary files differ
diff --git a/src/images/wavedrom/atomic-mem.edn b/src/images/wavedrom/atomic-mem.edn
new file mode 100644
index 0000000..1e95eb4
--- /dev/null
+++ b/src/images/wavedrom/atomic-mem.edn
@@ -0,0 +1,15 @@
+//## 9.4 Atomic Memory Operations
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','AMO','AMO','AMO','AMO','AMO','AMO','AMO']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest','dest','dest','dest','dest','dest']},
+ {bits: 3, name: 'funct3', attr: ['3','width','width','width','width','width','width','width']},
+ {bits: 5, name: 'rs1', attr: ['5','addr','addr','addr','addr','addr','addr','addr']},
+ {bits: 5, name: 'rs2', attr: ['5','src','src','src','src','src','src','src']},
+ {bits: 1, name: 'rl', attr: ['1']},
+ {bits: 1, name: 'aq', attr: ['1']},
+ {bits: 6, name: 'funct5', attr: ['5','AMOSWAP.W/D', 'AMOADD.W/D', 'AMOAND.W/D', 'AMOOR.W/D', 'AMOXOR.W/D', 'AMOMAX[U].W/D','AMOMIN[U].W/D']},
+], config: {bits: 32}}
+....
diff --git a/src/images/wavedrom/b-immediate.edn b/src/images/wavedrom/b-immediate.edn
new file mode 100644
index 0000000..138b0aa
--- /dev/null
+++ b/src/images/wavedrom/b-immediate.edn
@@ -0,0 +1,12 @@
+//#### B-immediate
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: '0'},
+ {bits: 4, name: 'inst[11:8]'},
+ {bits: 6, name: 'inst[30:25]'},
+ {bits: 1, name: '[7]'},
+ {bits: 20, name: '— inst[31] —'},
+], config:{fontsize: 12, label:{right: 'B-immediate'}}}
+....
diff --git a/src/images/wavedrom/c-andi.edn b/src/images/wavedrom/c-andi.edn
new file mode 100644
index 0000000..e0ab053
--- /dev/null
+++ b/src/images/wavedrom/c-andi.edn
@@ -0,0 +1,13 @@
+//c-andi.adoc
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C1'],},
+ {bits: 5, name: 'imm[4:0]', attr: ['5','imm[4:0]']},
+ {bits: 3, name: 'rd′/rs1′', attr: ['3','dest'],},
+ {bits: 2, name: 'funct2', attr: ['2','C.ANDI'],},
+ {bits: 1, name: 'imm[5]', attr: ['1','imm[5]'],},
+ {bits: 3, name: 'funct3', attr: ['3','C.ANDI'],},
+]}
+....
diff --git a/src/images/wavedrom/c-breakpoint-instr.edn b/src/images/wavedrom/c-breakpoint-instr.edn
new file mode 100644
index 0000000..25e245e
--- /dev/null
+++ b/src/images/wavedrom/c-breakpoint-instr.edn
@@ -0,0 +1,11 @@
+//
+
+[wavedrom, ,svg]
+
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C2'],},
+ {bits: 10, name: '0', attr: ['10','0'],},
+ {bits: 4, name: 'funct4', attr: ['4','C.EBREAK'],},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-cb-format-ls.edn b/src/images/wavedrom/c-cb-format-ls.edn
new file mode 100644
index 0000000..3ffd7a0
--- /dev/null
+++ b/src/images/wavedrom/c-cb-format-ls.edn
@@ -0,0 +1,12 @@
+//c-cb-format-ls
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C1', 'C1']},
+ {bits: 5, name: 'imm', attr: ['5','offset[7:6|2:1|5]', 'offset[7:6|2:1|5]']},
+ {bits: 3, name: 'rs1′', attr: ['3','src', 'src']},
+ {bits: 3, name: 'imm', attr: ['3','offset[8|4:3]', 'offset[8|4:3]'],},
+ {bits: 3, name: 'funct3', attr: ['3','C.BEQZ', 'C.BNEZ'],},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-ci.edn b/src/images/wavedrom/c-ci.edn
new file mode 100644
index 0000000..4f36a63
--- /dev/null
+++ b/src/images/wavedrom/c-ci.edn
@@ -0,0 +1,12 @@
+//
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2', 'C2']},
+ {bits: 5, name: 'shamt[4:0]', attr: ['5', 'shamt[4:0]']},
+ {bits: 5, name: 'rd/rs1', attr: ['5', 'dest != 0']},
+ {bits: 1, name: 'shamt[5]', attr: ['1', 'shamt[5]']},
+ {bits: 3, name: 'funct3', attr: ['3', 'C.SLLI']},
+]}
+....
diff --git a/src/images/wavedrom/c-ciw.edn b/src/images/wavedrom/c-ciw.edn
new file mode 100644
index 0000000..5486c78
--- /dev/null
+++ b/src/images/wavedrom/c-ciw.edn
@@ -0,0 +1,11 @@
+//c-ciw.adoc
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C0'],},
+ {bits: 3, name: 'rd′', attr: ['3','dest'],},
+ {bits: 8, name: 'imm', attr: ['8','nzuimm[5:4|9:6|2|3]']},
+ {bits: 3, name: 'funct3', attr: ['3','C.ADDI4SPN']},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-cj-format-ls.edn b/src/images/wavedrom/c-cj-format-ls.edn
new file mode 100644
index 0000000..b6e3a98
--- /dev/null
+++ b/src/images/wavedrom/c-cj-format-ls.edn
@@ -0,0 +1,20 @@
+//c-cj-format-ls
+
+//[wavedrom, ,svg]
+//....
+//{reg: [
+// {bits: 2, name: 'op', attr: ['2','CI','CI']},
+// {bits: 10, name: 'imm'},
+// {bits: 4, name: 'funct3' attr:['3','CJ','CJAL']},
+//] config: {bits: 16}}
+//....
+
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C1','C1']},
+ {bits: 11, name: 'imm', attr: ['11','offset[11|4|9:8|10|6|7|3:1|5]','offset[11|4|9:8|10|6|7|3:1|5]']},
+ {bits: 3, name: 'funct3', attr: ['3','C.J','C.JAL']},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-cr-format-ls.edn b/src/images/wavedrom/c-cr-format-ls.edn
new file mode 100644
index 0000000..a584426
--- /dev/null
+++ b/src/images/wavedrom/c-cr-format-ls.edn
@@ -0,0 +1,11 @@
+//These instructions use the CR format.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C2', 'C2']},
+ {bits: 5, name: 'rs2', attr: ['5','0', '0']},
+ {bits: 5, name: 'rs1', attr: ['5','src≠0', 'src≠0']},
+ {bits: 4, name: 'funct4', attr: ['4','C.JR', 'C.JALR']},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-cs-format-ls.edn b/src/images/wavedrom/c-cs-format-ls.edn
new file mode 100644
index 0000000..a72e991
--- /dev/null
+++ b/src/images/wavedrom/c-cs-format-ls.edn
@@ -0,0 +1,14 @@
+//## 16.X Load and Store Instructions
+//### c-cs-format-ls
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2', 'C0','C0','C0','C0']},
+ {bits: 3, name: 'rs2ʹ', attr: ['3', 'src','src','src','src']},
+ {bits: 2, name: 'imm', attr: ['2', 'offset[2|6]','offset[7:6]','offset[2|6]','offset[7:6]']},
+ {bits: 3, name: 'rs1ʹ', attr: ['3', 'base','base','base','base']},
+ {bits: 3, name: 'imm', attr: ['3', 'offset[5:3]','offset[5:3]','offset[5:3]','offset[5:3]']},
+ {bits: 3, name: 'funct3', attr: ['3', 'C.SW','C.SD','C.FSW','C.FSD']},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-def-illegal-inst.edn b/src/images/wavedrom/c-def-illegal-inst.edn
new file mode 100644
index 0000000..5d05eb7
--- /dev/null
+++ b/src/images/wavedrom/c-def-illegal-inst.edn
@@ -0,0 +1,13 @@
+//
+
+[wavedrom, ,svg]
+
+....
+{reg: [
+ {bits: 2, name: '0', attr: ['2','0'],},
+ {bits: 5, name: '0', attr: ['5','0'],},
+ {bits: 5, name: '0', attr: ['5','0'],},
+ {bits: 1, name: '0', attr: ['1','0'],},
+ {bits: 3, name: '0', attr: ['3','0'],},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-int-reg-immed.edn b/src/images/wavedrom/c-int-reg-immed.edn
new file mode 100644
index 0000000..0bd4cb4
--- /dev/null
+++ b/src/images/wavedrom/c-int-reg-immed.edn
@@ -0,0 +1,12 @@
+//c-int-reg-immed.adoc
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C1', 'C1', 'C1']},
+ {bits: 5, name: 'imm[4:0]', attr: ['5','nzimm[4:0]', 'imm[4:0]', 'nzimm[4|6|8:7|5]']},
+ {bits: 5, name: 'rd/rs1', attr: ['5','dest != 0', 'dest != 0', '2']},
+ {bits: 1, name: 'imm[5]', attr: ['1','nzimm[5]', 'imm[5]', 'nzimm[9]']},
+ {bits: 3, name: 'funct3', attr: ['3','C.ADDI', 'C.ADDIW', 'C.ADDI16SP']},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-int-reg-to-reg-ca-format.edn b/src/images/wavedrom/c-int-reg-to-reg-ca-format.edn
new file mode 100644
index 0000000..33749e6
--- /dev/null
+++ b/src/images/wavedrom/c-int-reg-to-reg-ca-format.edn
@@ -0,0 +1,13 @@
+//
+
+[wavedrom, ,svg]
+
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2', 'C1', 'C1', 'C1', 'C1', 'C1', 'C1'],},
+ {bits: 3, name: 'rs2′', attr: ['3', 'src', 'src', 'src', 'src', 'src', 'src'],},
+ {bits: 2, name: 'funct2', attr: ['2', 'C.AND', 'C.OR', 'C.XOR', 'C.SUB', 'C.ADDW', 'C.SUBW'],},
+ {bits: 3, name: 'rd′/rs1′', attr: ['3', 'dest', 'dest', 'dest', 'dest', 'dest', 'dest'],},
+ {bits: 6, name: 'funct6', attr: ['6', 'C.AND', 'C.OR', 'C.XOR', 'C.SUB', 'C.ADDW', 'C.SUBW'],},
+]}
+....
diff --git a/src/images/wavedrom/c-int-reg-to-reg-cr-format.edn b/src/images/wavedrom/c-int-reg-to-reg-cr-format.edn
new file mode 100644
index 0000000..3cb28c7
--- /dev/null
+++ b/src/images/wavedrom/c-int-reg-to-reg-cr-format.edn
@@ -0,0 +1,12 @@
+//
+
+[wavedrom, ,svg]
+
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2', 'C2', 'C2'],},
+ {bits: 5, name: 'rs2', attr: ['5', 'src≠0', 'src≠0'],},
+ {bits: 5, name: 'rd/rs1', attr: ['5', 'dest≠0', 'dest≠0'],},
+ {bits: 4, name: 'funct4', attr: ['4', 'C.MV', 'C.ADD'],},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-integer-const-gen.edn b/src/images/wavedrom/c-integer-const-gen.edn
new file mode 100644
index 0000000..159e462
--- /dev/null
+++ b/src/images/wavedrom/c-integer-const-gen.edn
@@ -0,0 +1,12 @@
+//c-integer-const-gen
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C1', 'C1']},
+ {bits: 5, name: 'imm[4:0]', attr: ['5','imm[4:0]','nzimm[16:12]']},
+ {bits: 5, name: 'rd', attr: ['5','dest != 0', 'dest != {0, 2}']},
+ {bits: 1, name: 'imm[5]', attr: ['1','imm[5]', 'nzimm[17]'],},
+ {bits: 3, name: 'funct3', attr: ['3','C.LI', 'C.LUI'],},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-mop.edn b/src/images/wavedrom/c-mop.edn
new file mode 100644
index 0000000..9b850a5
--- /dev/null
+++ b/src/images/wavedrom/c-mop.edn
@@ -0,0 +1,12 @@
+[wavedrom, ,svg]
+....
+{reg:[
+ { bits: 2, name: 0x1 },
+ { bits: 5, name: 0x0 },
+ { bits: 1, name: 0x1 },
+ { bits: 3, name: 'n[3:1]' },
+ { bits: 1, name: 0x0 },
+ { bits: 1, name: 0x0 },
+ { bits: 3, name: 0x3 },
+]}
+....
diff --git a/src/images/wavedrom/c-nop-instr.edn b/src/images/wavedrom/c-nop-instr.edn
new file mode 100644
index 0000000..d6770dc
--- /dev/null
+++ b/src/images/wavedrom/c-nop-instr.edn
@@ -0,0 +1,13 @@
+//
+
+[wavedrom, ,svg]
+
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C1'],},
+ {bits: 5, name: 'imm[4:0]', attr: ['5','0'],},
+ {bits: 5, name: 'rd/rs1', attr: ['5','0'],},
+ {bits: 1, name: 'imm[5]', attr: ['1','0'],},
+ {bits: 3, name: 'funct3', attr: ['3','C.NOP'],},
+]}
+....
diff --git a/src/images/wavedrom/c-sp-load-store-css.edn b/src/images/wavedrom/c-sp-load-store-css.edn
new file mode 100644
index 0000000..bb5114d
--- /dev/null
+++ b/src/images/wavedrom/c-sp-load-store-css.edn
@@ -0,0 +1,11 @@
+//c-sp load and store, css format--is this correct?
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C2','C2','C2','C2']},
+ {bits: 5, name: 'rs2', attr: ['5', 'src', 'src', 'src', 'src']},
+ {bits: 6, name: 'imm', attr: ['6','offset[5:2|7:6]', 'offset[5:3|8:6]', 'offset[5:2|7:6]','offset[5:3|8:6]']},
+ {bits: 3, name: 'funct3', attr: ['3','C.SWSP', 'C.SDSP', 'C.FSWSP', 'C.FSDSP']},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-sp-load-store.edn b/src/images/wavedrom/c-sp-load-store.edn
new file mode 100644
index 0000000..9959f65
--- /dev/null
+++ b/src/images/wavedrom/c-sp-load-store.edn
@@ -0,0 +1,13 @@
+//## 16.3 Load and Store Instructions
+//### Stack-Pointer-Based Loads and Stores
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C2','C2','C2','C2']},
+ {bits: 5, name: 'imm', attr: ['5','offset[4:2|7:6]', 'offset[4:3|8:6]', 'offset[4:2|7:6]', 'offset[4:3|8:6]']},
+ {bits: 5, name: 'rd', attr: ['5','dest≠0', 'dest≠0', 'dest', 'dest']},
+ {bits: 1, name: 'imm', attr: ['1','offset[5]','offset[5]','offset[5]','offset[5]']},
+ {bits: 3, name: 'funct3', attr: ['3','C.LWSP', 'C.LDSP', 'C.FLWSP', 'C.FLDSP']},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/c-srli-srai.edn b/src/images/wavedrom/c-srli-srai.edn
new file mode 100644
index 0000000..fc31dfe
--- /dev/null
+++ b/src/images/wavedrom/c-srli-srai.edn
@@ -0,0 +1,13 @@
+//c-srli-srai.adoc
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2','C1', 'C1'],},
+ {bits: 5, name: 'shamt[4:0]', attr: ['5','shamt[4:0]', 'shamt[4:0]'],},
+ {bits: 3, name: 'rd′/rs1′', attr: ['3','dest', 'dest'],},
+ {bits: 2, name: 'funct2', attr: ['2','C.SRLI', 'C.SRAI'],},
+ {bits: 1, name: 'shamt[5]', attr: ['1','shamt[5]', 'shamt[5]'],},
+ {bits: 3, name: 'funct3', attr: ['3','C.SRLI', 'C.SRAI'],},
+]}
+....
diff --git a/src/images/wavedrom/counters-diag.edn b/src/images/wavedrom/counters-diag.edn
new file mode 100644
index 0000000..5c99cb3
--- /dev/null
+++ b/src/images/wavedrom/counters-diag.edn
@@ -0,0 +1,13 @@
+//# 11 Counters
+//## 11.1 Base Counters and Timers
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','SYSTEM','SYSTEM','SYSTEM']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest','dest']},
+ {bits: 3, name: 'funct3', attr: ['3','CSRRS','CSRRS','CSRRS']},
+ {bits: 5, name: 'rs1', attr: ['5','0','0','0']},
+ {bits: 12, name: 'csr', attr: ['12','RDCYCLE[H]', 'RDTIME[H]','RDINSTRET[H]']},
+]}
+....
diff --git a/src/images/wavedrom/cr-register.edn b/src/images/wavedrom/cr-register.edn
new file mode 100644
index 0000000..2eee07f
--- /dev/null
+++ b/src/images/wavedrom/cr-register.edn
@@ -0,0 +1,109 @@
+//# 16 "C" Standard Extension for Compressed Instructions, Version 2.0
+//## 16.2 Compressed Instruction Formats
+//Table 16.1: Compressed 16-bit RVC instruction formats.
+//### CR : Register
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op' },
+ {bits: 5, name: 'rs2' },
+ {bits: 5, name: 'rd/rs1' },
+ {bits: 4, name: 'funct4' },
+ ]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op' },
+ {bits: 5, name: 'imm' },
+ {bits: 5, name: 'rd/rs1' },
+ {bits: 1, name: 'imm' },
+ {bits: 3, name: 'funct3' },
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op' },
+ {bits: 5, name: 'rs2' },
+ {bits: 6, name: 'imm' },
+ {bits: 3, name: 'funct3' },
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op' },
+ {bits: 3, name: 'rdʹ' },
+ {bits: 8, name: 'imm' },
+ {bits: 3, name: 'funct3' },
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op' },
+ {bits: 3, name: 'rdʹ' },
+ {bits: 2, name: 'imm' },
+ {bits: 3, name: 'rs1ʹ' },
+ {bits: 3, name: 'imm' },
+ {bits: 3, name: 'funct3' },
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op' },
+ {bits: 3, name: 'rs2ʹ' },
+ {bits: 2, name: 'imm' },
+ {bits: 3, name: 'rs1ʹ' },
+ {bits: 3, name: 'imm' },
+ {bits: 3, name: 'funct3' },
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op' },
+ {bits: 3, name: 'rs2ʹ' },
+ {bits: 2, name: 'funct2' },
+ {bits: 3, name: 'rdʹ/rs1ʹ' },
+ {bits: 6, name: 'funct6' },
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op' },
+ {bits: 5, name: 'offset' },
+ {bits: 3, name: 'rdʹ/rs1ʹ' },
+ {bits: 3, name: 'offset' },
+ {bits: 3, name: 'funct3' },
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op' },
+ {bits: 11, name: 'jmp trgt' },
+ {bits: 3, name: 'funct3' },
+]}
+....
+
+//the following configuration broke the build.
+//config: {
+// hflip: true,
+// compact: true,
+// bits: 16 * 9, lanes: 9,
+// margin: {right: width / 4},
+// label: {right: ['CR : Register', 'CI : Immediate', 'CSS : Stack-relative Store', 'CIW : Wide Immediate', 'CL : Load', 'CS //: Store', 'CA : //Arithmetic', 'CB : Branch/Arithmetic', 'CJ : Jump']}
+//}
diff --git a/src/images/wavedrom/csr-instr.edn b/src/images/wavedrom/csr-instr.edn
new file mode 100644
index 0000000..dc50b27
--- /dev/null
+++ b/src/images/wavedrom/csr-instr.edn
@@ -0,0 +1,24 @@
+//# 10 "Zicsr", Control and Status Register (CSR) Instructions, Version 2.0
+//## 10.1 CSR Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM', 'SYSTEM', 'SYSTEM', 'SYSTEM', 'SYSTEM', 'SYSTEM'] },
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest', 'dest', 'dest', 'dest', 'dest'] },
+ {bits: 3, name: 'funct3', attr: ['3', 'CSRRW', 'CSRRS', 'CSRRC', 'CSRRWI', 'CSRRSI', 'CSRRCI'] },
+ {bits: 5, name: 'rs1', attr: ['5', 'source', 'source', 'source', 'uimm[4:0]', 'uimm[4:0]', 'uimm[4:0]'] },
+ {bits: 12, name: 'csr', attr: ['12', 'source/dest', 'source/dest', 'source/dest', 'source/dest', 'source/dest', 'source/dest'], },
+]}
+....
+
+//[wavedrom, ,]
+//....
+//{reg: [
+// {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM','SYSTEM','SYSTEM'] },
+// {bits: 5, name: 'rd', attr: ['3', 'dest','dest', 'dest' ] },
+// {bits: 3, name: 'funct3', attr: ['3', 'CSRRWI', 'CSRRSI', 'CSRRCI'] },
+// {bits: 5, name: 'rs1', attr: ['5', 'uimm[4:0]','uimm[4:0]', 'uimm[4:0]'] },
+// {bits: 12, name: 'csr', attr: ['12', 'source/dest','source/dest','source/dest'] },
+//]}
+//....
diff --git a/src/images/wavedrom/ct-conditional.edn b/src/images/wavedrom/ct-conditional.edn
new file mode 100644
index 0000000..e021907
--- /dev/null
+++ b/src/images/wavedrom/ct-conditional.edn
@@ -0,0 +1,13 @@
+//### Conditional Branches
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'BRANCH', 'BRANCH', 'BRANCH'] },
+ {bits: 5, name: 'imm[4:1|11]', attr: ['5', 'offset[4:1|11]', 'offset[4:1|11]', 'offset[4:1|11]'] },
+ {bits: 3, name: 'funct3', attr: ['3', 'BEQ/BNE', 'BLT[U]', 'BGE[U]'] },
+ {bits: 5, name: 'rs1', attr: ['5', 'src1', 'src1', 'src1'] },
+ {bits: 5, name: 'rs2', attr: ['5', 'src2','src2', 'src2'] },
+ {bits: 7, name: 'imm[12|10:5]', attr: ['7', 'offset[12|10:5]', 'offset[12|10:5]', 'offset[12|10:5]'] },
+], config:{fontsize: 10}}
+....
diff --git a/src/images/wavedrom/ct-unconditional-2.edn b/src/images/wavedrom/ct-unconditional-2.edn
new file mode 100644
index 0000000..95f103e
--- /dev/null
+++ b/src/images/wavedrom/ct-unconditional-2.edn
@@ -0,0 +1,12 @@
+//ct-unconditional-2
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'JALR'] },
+ {bits: 5, name: 'rd', attr: ['5', 'dest'] },
+ {bits: 3, name: 'funct3', attr: ['3', '0'] },
+ {bits: 5, name: 'rs1', attr: ['5', 'base'] },
+ {bits: 12, name: 'imm[11:0]', attr: ['12', 'offset[11:0]'] },
+]}
+....
diff --git a/src/images/wavedrom/ct-unconditional.edn b/src/images/wavedrom/ct-unconditional.edn
new file mode 100644
index 0000000..bc2213b
--- /dev/null
+++ b/src/images/wavedrom/ct-unconditional.edn
@@ -0,0 +1,14 @@
+//## 2.5 Control Transfer Instructions
+//### Unconditional Jumps
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'JAL']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest']},
+ {bits: 8, name: 'imm[19:12]', attr: ['8']},
+ {bits: 1, name: '[11]', attr: ['1']},
+ {bits: 10, name: 'imm[10:1]', attr: ['10', 'offset[20:1]']},
+ {bits: 1, name: '[20]', attr: ['1']},
+], config:{fontsize: 12}}
+....
diff --git a/src/images/wavedrom/d-xwwx.edn b/src/images/wavedrom/d-xwwx.edn
new file mode 100644
index 0000000..cc28715
--- /dev/null
+++ b/src/images/wavedrom/d-xwwx.edn
@@ -0,0 +1,14 @@
+//xw-wx
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','000','000']},
+ {bits: 5, name: 'rs1', attr: ['5','src','src']},
+ {bits: 5, name: 'rs2', attr: ['5','0','0']},
+ {bits: 2, name: 'fmt', attr: ['2','D','D']},
+ {bits: 5, name: 'funct5', attr: ['5','FMV.X.D','FMV.D.X']},
+]}
+....
diff --git a/src/images/wavedrom/division-op.edn b/src/images/wavedrom/division-op.edn
new file mode 100644
index 0000000..0dff0e3
--- /dev/null
+++ b/src/images/wavedrom/division-op.edn
@@ -0,0 +1,25 @@
+//## 8.2 Division Operations
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP', 'OP-32']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest']},
+ {bits: 3, name: 'funct3', attr: ['3','DIV[U]/REM[U]', 'DIV[U]W/REM[U]W']},
+ {bits: 5, name: 'rs1', attr: ['5', 'dividend', 'dividend']},
+ {bits: 5, name: 'rs2', attr: ['5', 'divisor', 'divisor']},
+ {bits: 7, name: 'funct7', attr: ['7', 'MULDIV', 'MULDIV']},
+]}
+....
+
+//[wavedrom, ,svg]
+//....
+//{reg: [
+// {bits: 7, name: 'opcode', attr: 'OP-32'},
+// {bits: 5, name: 'rd', attr: 'dest'},
+// {bits: 3, name: 'funct3', attr: ['DIVW', 'DIVUW', 'REMW', 'REMUW']},
+// {bits: 5, name: 'rs1', attr: 'dividend'},
+// {bits: 5, name: 'rs2', attr: 'divisor'},
+// {bits: 7, name: 'funct7', attr: 'MULDIV'},
+//]}
+//....
diff --git a/src/images/wavedrom/double-fl-class.edn b/src/images/wavedrom/double-fl-class.edn
new file mode 100644
index 0000000..664ff9d
--- /dev/null
+++ b/src/images/wavedrom/double-fl-class.edn
@@ -0,0 +1,14 @@
+//## 13.7 Double-Precision Floating-Point Classify Instruction
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','1']},
+ {bits: 5, name: 'rs1', attr: ['5','src']},
+ {bits: 5, name: 'rs2', attr: ['5','0']},
+ {bits: 2, name: 'fmt', attr: ['2','D']},
+ {bits: 5, name: 'funct5', attr: ['5','FCLASS']},
+]}
+....
diff --git a/src/images/wavedrom/double-fl-compare.edn b/src/images/wavedrom/double-fl-compare.edn
new file mode 100644
index 0000000..bd381c8
--- /dev/null
+++ b/src/images/wavedrom/double-fl-compare.edn
@@ -0,0 +1,14 @@
+//## 13.6 Double-Precision Floating-Point Compare Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','EQ/LT/LE']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','D']},
+ {bits: 5, name: 'funct5', attr: ['5','FCMP']},
+]}
+....
diff --git a/src/images/wavedrom/double-fl-compute.edn b/src/images/wavedrom/double-fl-compute.edn
new file mode 100644
index 0000000..d074fea
--- /dev/null
+++ b/src/images/wavedrom/double-fl-compute.edn
@@ -0,0 +1,53 @@
+//## 13.4 Double-Precision Floating-Point Computational Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM','RM','MIN/MAX','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src1','src1','src1','src']},
+ {bits: 5, name: 'rs2', attr: ['5','src2','src2','src2','0']},
+ {bits: 2, name: 'fmt', attr: ['2','D','D','D','D']},
+ {bits: 5, name: 'funct5', attr: ['5','FADD/FSUB', 'FMUL/FDIV', 'FMIN-MAX', 'FSQRT']},
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','F[N]MADD/F[N]MSUB']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','D']},
+ {bits: 5, name: 'rs3', attr: ['5','src3']},
+]}
+....
+
+//[wavedrom, ,]
+//....
+//{reg: [
+// {bits: 7, name: 'opcode', attr: 'OP-FP'},
+// {bits: 5, name: 'rd', attr: 'dest'},
+// {bits: 3, name: 'funct3', attr: ['MIN', 'MAX']},
+// {bits: 5, name: 'rs1', attr: 'src1'},
+// {bits: 5, name: 'rs2', attr: 'src2'},
+// {bits: 2, name: 'fmt', attr: 'D'},
+// {bits: 5, name: 'funct5', attr: 'FMIN-MAX'},
+//]}
+//....
+
+//[wavedrom, ,]
+//....
+//{reg: [
+// {bits: 7, name: 'opcode', attr: ['FMADD', 'FNMADD', 'FMSUB', 'FNMSUB']},
+// {bits: 5, name: 'rd', attr: 'dest'},
+// {bits: 3, name: 'funct3', attr: 'RM'},
+// {bits: 5, name: 'rs1', attr: 'src1'},
+// {bits: 5, name: 'rs2', attr: 'src2'},
+// {bits: 2, name: 'fmt', attr: 'D'},
+// {bits: 5, name: 'rs3', attr: 'src3'},
+//]}
+//....
diff --git a/src/images/wavedrom/double-fl-convert-mv.edn b/src/images/wavedrom/double-fl-convert-mv.edn
new file mode 100644
index 0000000..711ce0c
--- /dev/null
+++ b/src/images/wavedrom/double-fl-convert-mv.edn
@@ -0,0 +1,15 @@
+//## 13.5 Double-Precision Floating-Point Conversion and Move Instructions
+
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src','src']},
+ {bits: 5, name: 'rs2', attr: ['5','W[U]/L[U]','W[U]/L[U]']},
+ {bits: 2, name: 'fmt', attr: ['2','D','D']},
+ {bits: 5, name: 'funct5', attr: ['5','FCVT.int.D','FCVT.D.int']},
+]}
+....
diff --git a/src/images/wavedrom/double-ls.edn b/src/images/wavedrom/double-ls.edn
new file mode 100644
index 0000000..97306a9
--- /dev/null
+++ b/src/images/wavedrom/double-ls.edn
@@ -0,0 +1,25 @@
+//# "D" Standard Extension for Double-Precision Floating-Point, Version 2.2
+//## 13.3 Double-Precision Load and Store Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','LOAD-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'width', attr: ['3','D']},
+ {bits: 5, name: 'rs1', attr: ['5','base']},
+ {bits: 12, name: 'imm[11:0]', attr: ['12','offset[11:0]']},
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','STORE-FP']},
+ {bits: 5, name: 'imm[4:0]', attr: ['5','offset[4:0]']},
+ {bits: 3, name: 'width', attr: ['3','D']},
+ {bits: 5, name: 'rs1', attr: ['5','base']},
+ {bits: 5, name: 'rs2', attr: ['5','src']},
+ {bits: 7, name: 'imm[11:5]', attr: ['7','offset[11:5]']},
+]}
+....
diff --git a/src/images/wavedrom/env-call-breakpoint.edn b/src/images/wavedrom/env-call-breakpoint.edn
new file mode 100644
index 0000000..5814faf
--- /dev/null
+++ b/src/images/wavedrom/env-call-breakpoint.edn
@@ -0,0 +1,12 @@
+//## 2.8 Environment Call and Breakpoints
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM', 'SYSTEM']},
+ {bits: 5, name: 'rd', attr: ['5', '0', '0']},
+ {bits: 3, name: 'funct3', attr: ['3', 'PRIV', 'PRIV']},
+ {bits: 5, name: 'rs1', attr: ['5', '0', '0']},
+ {bits: 12, name: 'func12', attr: ['12', 'ECALL', 'EBREAK']},
+]}
+....
diff --git a/src/images/wavedrom/fcvt-sd-ds.edn b/src/images/wavedrom/fcvt-sd-ds.edn
new file mode 100644
index 0000000..dda6234
--- /dev/null
+++ b/src/images/wavedrom/fcvt-sd-ds.edn
@@ -0,0 +1,14 @@
+//FCVT.S.D and FCVT.D.S
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src','src']},
+ {bits: 5, name: 'rs2', attr: ['5','D', 'S']},
+ {bits: 2, name: 'fmt', attr: ['2','S','D']},
+ {bits: 5, name: 'funct5', attr: ['5','FCVT.S.D', 'FCVT.D.S']},
+]}
+....
diff --git a/src/images/wavedrom/float-csr.edn b/src/images/wavedrom/float-csr.edn
new file mode 100644
index 0000000..ed51932
--- /dev/null
+++ b/src/images/wavedrom/float-csr.edn
@@ -0,0 +1,16 @@
+//# "F" Standard Extension for Single-Precision Floating-Point, Version 2.2
+//## 12.2 Floating-Point Control and Status Register
+//### Figure 12.2: Floating-point control and status register.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'NX', attr: ['1']},
+ {bits: 1, name: 'UF', attr: ['1']},
+ {bits: 1, name: 'OF', attr: ['1']},
+ {bits: 1, name: 'DZ', attr: ['1']},
+ {bits: 1, name: 'NV', attr: ['1']},
+ {bits: 3, name: 'Rounding Mode', attr:['3']},
+ {bits: 24, name: 'Reserved', attr:['24']},
+], config: {fontsize: 10}}
+....
diff --git a/src/images/wavedrom/flt-pt-to-int-move.edn b/src/images/wavedrom/flt-pt-to-int-move.edn
new file mode 100644
index 0000000..ed33285
--- /dev/null
+++ b/src/images/wavedrom/flt-pt-to-int-move.edn
@@ -0,0 +1,14 @@
+// 16.3 Instructions for moving bit patterns between floating-point and integer registers.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','000','000']},
+ {bits: 5, name: 'rs1', attr: ['5','src','src']},
+ {bits: 5, name: 'rs2', attr: ['5','0','0']},
+ {bits: 2, name: 'fmt', attr: ['2','H','H']},
+ {bits: 5, name: 'funct5', attr: ['5','FMV.X.H','FMV.H.X']},
+]}
+....
diff --git a/src/images/wavedrom/flt-to-flt-sgn-inj-instr.edn b/src/images/wavedrom/flt-to-flt-sgn-inj-instr.edn
new file mode 100644
index 0000000..60480cf
--- /dev/null
+++ b/src/images/wavedrom/flt-to-flt-sgn-inj-instr.edn
@@ -0,0 +1,14 @@
+// 16.3 Floating point to floating point sign injection instructions.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'funct3', attr: ['3','J[N]/JX']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','H']},
+ {bits: 5, name: 'funct5', attr: ['5','FSGNJ']},
+]}
+....
diff --git a/src/images/wavedrom/fsjgnjnx-d.edn b/src/images/wavedrom/fsjgnjnx-d.edn
new file mode 100644
index 0000000..02ab6a7
--- /dev/null
+++ b/src/images/wavedrom/fsjgnjnx-d.edn
@@ -0,0 +1,14 @@
+//FSGNJ.D, FSGNJN.D, and FSGNJX.D
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','J[N]/JX']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','D']},
+ {bits: 5, name: 'funct5', attr: ['5','FSGNJ']},
+]}
+....
diff --git a/src/images/wavedrom/half-ls.edn b/src/images/wavedrom/half-ls.edn
new file mode 100644
index 0000000..be24c0d
--- /dev/null
+++ b/src/images/wavedrom/half-ls.edn
@@ -0,0 +1,13 @@
+//## 15.1 Half-Precision Load and Store Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: 'LOAD-FP'},
+ {bits: 5, name: 'rd', attr: 'dest'},
+ {bits: 3, name: 'width', attr: 'H'},
+ {bits: 5, name: 'rs1', attr: 'base'},
+ {bits: 12, name: 'imm[11:0]', attr: 'offset'},
+]}
+
+....
diff --git a/src/images/wavedrom/half-pr-flt-pt-class.edn b/src/images/wavedrom/half-pr-flt-pt-class.edn
new file mode 100644
index 0000000..e12608c
--- /dev/null
+++ b/src/images/wavedrom/half-pr-flt-pt-class.edn
@@ -0,0 +1,14 @@
+//## 15.5 Half-Precision Floating-Point Classify Instruction
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','001']},
+ {bits: 5, name: 'rs1', attr: ['5', 'src']},
+ {bits: 5, name: 'rs2', attr: ['5','0']},
+ {bits: 2, name: 'fmt', attr: ['2','H']},
+ {bits: 5, name: 'funct5', attr: ['5','FCLASS']},
+]}
+....
diff --git a/src/images/wavedrom/half-pr-flt-pt-compare.edn b/src/images/wavedrom/half-pr-flt-pt-compare.edn
new file mode 100644
index 0000000..b05b77f
--- /dev/null
+++ b/src/images/wavedrom/half-pr-flt-pt-compare.edn
@@ -0,0 +1,14 @@
+// 16.4 Half-Precision Floating-Point Compare Instructions.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','EQ/LT/LE']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','H']},
+ {bits: 5, name: 'funct5', attr: ['5','FCMP']},
+]}
+....
diff --git a/src/images/wavedrom/half-prec-conv-and-mv.edn b/src/images/wavedrom/half-prec-conv-and-mv.edn
new file mode 100644
index 0000000..443afd3
--- /dev/null
+++ b/src/images/wavedrom/half-prec-conv-and-mv.edn
@@ -0,0 +1,15 @@
+//## 16.3 Half-Precision Conversion and Move Instructions
+
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src','src']},
+ {bits: 5, name: 'rs2', attr: ['5','W[U]/L[U]','W[U]/L[U]']},
+ {bits: 2, name: 'fmt', attr: ['2','H', 'H']},
+ {bits: 5, name: 'funct5', attr: ['5','FCVT.int.H','FCVT.H.int']},
+]}
+....
diff --git a/src/images/wavedrom/half-prec-flpt-to-flpt-conv.edn b/src/images/wavedrom/half-prec-flpt-to-flpt-conv.edn
new file mode 100644
index 0000000..bfd1f8b
--- /dev/null
+++ b/src/images/wavedrom/half-prec-flpt-to-flpt-conv.edn
@@ -0,0 +1,14 @@
+//## 16.3 Half-Precision Floating Point to Floating Point Conversion Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP','OP-FP','OP-FP','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest','dest','dest','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM','RM','RM','RM','RM','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src','src','src','src','src','SRC']},
+ {bits: 5, name: 'rs2', attr: ['5','H','S','H','D','H','Q']},
+ {bits: 2, name: 'fmt', attr: ['2','S','H','D','H','Q','H']},
+ {bits: 5, name: 'funct5', attr: ['5','FCVT.S.H','FCVT.H.S','FCVT.D.H','FCVT.H.D','FCVT.Q.H','FCVT.H.Q']},
+]}
+....
diff --git a/src/images/wavedrom/hinvalgvma.edn b/src/images/wavedrom/hinvalgvma.edn
new file mode 100644
index 0000000..6d1b134
--- /dev/null
+++ b/src/images/wavedrom/hinvalgvma.edn
@@ -0,0 +1,11 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM']},
+ {bits: 5, name: 'rd', attr: ['5', '0']},
+ {bits: 3, name: 'funct3', attr: ['3', 'PRIV']},
+ {bits: 5, name: 'rs1', attr: ['5', 'gaddr']},
+ {bits: 5, name: 'rs2', attr: ['5', 'vmid']},
+ {bits: 7, name: 'funct7', attr: ['7', 'HINVAL.GVMA']},
+]}
+....
diff --git a/src/images/wavedrom/hinvalvvma.edn b/src/images/wavedrom/hinvalvvma.edn
new file mode 100644
index 0000000..c339d86
--- /dev/null
+++ b/src/images/wavedrom/hinvalvvma.edn
@@ -0,0 +1,11 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM']},
+ {bits: 5, name: 'rd', attr: ['5', '0']},
+ {bits: 3, name: 'funct3', attr: ['3', 'PRIV']},
+ {bits: 5, name: 'rs1', attr: ['5', 'vaddr']},
+ {bits: 5, name: 'rs2', attr: ['5', 'asid']},
+ {bits: 7, name: 'funct7', attr: ['7', 'HINVAL.VVMA']},
+]}
+....
diff --git a/src/images/wavedrom/hypv-mm-fence.edn b/src/images/wavedrom/hypv-mm-fence.edn
new file mode 100644
index 0000000..1109c1b
--- /dev/null
+++ b/src/images/wavedrom/hypv-mm-fence.edn
@@ -0,0 +1,13 @@
+//hypv-mm-fence.edn
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM', 'SYSTEM']},
+ {bits: 5, name: 'rd', attr: ['5','0', '0']},
+ {bits: 3, name: 'funct3', attr: ['3','PRIV', 'PRIV']},
+ {bits: 5, name: 'rs1', attr: ['5','vaddr', 'gaddr']},
+ {bits: 5, name: 'rs2', attr: ['5','asid', 'vmid']},
+ {bits: 7, name: 'funct7', attr: ['7','HFENCE.VVMA', 'HFENCE.GVMA']},
+], config: {bits: 32}}
+....
diff --git a/src/images/wavedrom/hypv-virt-load-and-store.edn b/src/images/wavedrom/hypv-virt-load-and-store.edn
new file mode 100644
index 0000000..0f8b802
--- /dev/null
+++ b/src/images/wavedrom/hypv-virt-load-and-store.edn
@@ -0,0 +1,13 @@
+//hypv-virt-load-and-store.edn
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','SYSTEM', 'SYSTEM', 'SYSTEM']},
+ {bits: 5, name: 'rd', attr: ['5','dest', 'dest', '0']},
+ {bits: 3, name: 'funct3', attr: ['3','PRIVM', 'PRIVM', 'PRIVM']},
+ {bits: 5, name: 'rs1', attr: ['5','addr', 'addr', 'addr']},
+ {bits: 5, name: 'rs2', attr: ['5','[U]', 'HLVX', 'src']},
+ {bits: 7, name: 'funct7', attr: ['7','HLV.width', 'HLVX.HU/WU', 'HSV.width']},
+], config: {bits: 32}}
+....
diff --git a/src/images/wavedrom/i-immediate.edn b/src/images/wavedrom/i-immediate.edn
new file mode 100644
index 0000000..adb5622
--- /dev/null
+++ b/src/images/wavedrom/i-immediate.edn
@@ -0,0 +1,13 @@
+//### Figure 2.4
+//Types of immediate produced by RISC-V instructions. The fields are labeled with the instruction bits used to construct their value. Sign extension always uses inst[31].
+//#### I-immediate
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: '[20]'},
+ {bits: 4, name: 'inst[24:21]'},
+ {bits: 6, name: 'inst[30:25]'},
+ {bits: 21, name: '— inst[31] —'},
+], config:{fontsize: 12, label:{right: 'I-immediate'}}}
+....
diff --git a/src/images/wavedrom/immediate-variants.edn b/src/images/wavedrom/immediate-variants.edn
new file mode 100644
index 0000000..5fc3a73
--- /dev/null
+++ b/src/images/wavedrom/immediate-variants.edn
@@ -0,0 +1,73 @@
+//## 2.3 Immediate Encoding Variants
+//### Figure 2.3
+//RISC-V base instruction formats showing immediate variants.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode'},
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 'funct3'},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'rs2'},
+ {bits: 7, name: 'funct7'}
+], config: {label: {right: 'R-Type'}}}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode'},
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 'funct3'},
+ {bits: 5, name: 'rs1'},
+ {bits: 12, name: 'imm[11:0]'},
+], config: {label: {right: 'I-Type'}}}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode'},
+ {bits: 5, name: 'imm[4:0]'},
+ {bits: 3, name: 'funct3'},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'rs2'},
+ {bits: 7, name: 'imm[11:5]'}
+], config: {label: {right: 'S-Type'}}}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode'},
+ {bits: 1, name: '[11]'},
+ {bits: 4, name: 'imm[4:1]'},
+ {bits: 3, name: 'funct3'},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'rs2'},
+ {bits: 6, name: 'imm[10:5]'},
+ {bits: 1, name: '[12]'}
+], config: {fontsize: 12, label: {right: 'B-Type'}}}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode'},
+ {bits: 5, name: 'rd'},
+ {bits: 20, name: 'imm[31:12]'}
+], config: {label: {right: 'U-Type'}}}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode'},
+ {bits: 5, name: 'rd'},
+ {bits: 8, name: 'imm[19:12]'},
+ {bits: 1, name: '[11]'},
+ {bits: 10, name: 'imm[10:1]'},
+ {bits: 1, name: '[20]'}
+], config: {fontsize: 12, label: {right: 'J-Type'}}}
+....
diff --git a/src/images/wavedrom/immediate.edn b/src/images/wavedrom/immediate.edn
new file mode 100644
index 0000000..adb5622
--- /dev/null
+++ b/src/images/wavedrom/immediate.edn
@@ -0,0 +1,13 @@
+//### Figure 2.4
+//Types of immediate produced by RISC-V instructions. The fields are labeled with the instruction bits used to construct their value. Sign extension always uses inst[31].
+//#### I-immediate
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: '[20]'},
+ {bits: 4, name: 'inst[24:21]'},
+ {bits: 6, name: 'inst[30:25]'},
+ {bits: 21, name: '— inst[31] —'},
+], config:{fontsize: 12, label:{right: 'I-immediate'}}}
+....
diff --git a/src/images/wavedrom/instruction-formats.edn b/src/images/wavedrom/instruction-formats.edn
new file mode 100644
index 0000000..5cd5f8c
--- /dev/null
+++ b/src/images/wavedrom/instruction-formats.edn
@@ -0,0 +1,47 @@
+//### Figure 2.2
+
+//RISC-V base instruction formats. Each immediate subfield is labeled with the bit position (imm[x]) in the immediate value being produced, rather than the bit position within the instruction’s immediate field as is usually done.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode'},
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 'funct3'},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'rs2'},
+ {bits: 7, name: 'funct7'}
+], config: {label: {right: 'R-Type'}}}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode'},
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 'funct3'},
+ {bits: 5, name: 'rs1'},
+ {bits: 12, name: 'imm[11:0]'},
+], config: {label: {right: 'I-Type'}}}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode'},
+ {bits: 5, name: 'imm[4:0]'},
+ {bits: 3, name: 'funct3'},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'rs2'},
+ {bits: 7, name: 'imm[11:5]'}
+], config: {label: {right: 'S-Type'}}}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode'},
+ {bits: 5, name: 'rd'},
+ {bits: 20, name: 'imm[31:12]'}
+], config: {label: {right: 'U-Type'}}}
+....
diff --git a/src/images/wavedrom/int-comp-lui-aiupc.edn b/src/images/wavedrom/int-comp-lui-aiupc.edn
new file mode 100644
index 0000000..dfb77d1
--- /dev/null
+++ b/src/images/wavedrom/int-comp-lui-aiupc.edn
@@ -0,0 +1,12 @@
+//FROM ## 2.4 Integer Computational Instructions
+//### Integer Register-Immediate Instructions
+//lui-aiupc-u-immed
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'LUI', 'AUIPC']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest']},
+ {bits: 20, name: 'imm[31:12]', attr: ['20', 'U-immediate[31:12]', 'U-immediate[31:12]']}
+]}
+....
diff --git a/src/images/wavedrom/int-comp-slli-srli-srai.edn b/src/images/wavedrom/int-comp-slli-srli-srai.edn
new file mode 100644
index 0000000..3d23dfb
--- /dev/null
+++ b/src/images/wavedrom/int-comp-slli-srli-srai.edn
@@ -0,0 +1,15 @@
+//FROM ## 2.4 Integer Computational Instructions
+//### Integer Register-Immediate Instructions
+//
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP-IMM', 'OP-IMM', 'OP-IMM']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest', 'dest']},
+ {bits: 3, name: 'funct3', attr: ['3', 'SLLI', 'SRLI', 'SRAI']},
+ {bits: 5, name: 'rs1', attr: ['5', 'src', 'src', 'src']},
+ {bits: 5, name: 'imm[4:0]', attr: ['5', 'shamt[4:0]', 'shamt[4:0]', 'shamt[4:0]']},
+ {bits: 7, name: 'imm[11:5]', attr: ['7', 0, 0, 32]}
+]}
+....
diff --git a/src/images/wavedrom/int-reg-reg.edn b/src/images/wavedrom/int-reg-reg.edn
new file mode 100644
index 0000000..3fd19f7
--- /dev/null
+++ b/src/images/wavedrom/int-reg-reg.edn
@@ -0,0 +1,13 @@
+//### Integer Register-Register Operations
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP', 'OP', 'OP', 'OP']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest', 'dest','dest']},
+ {bits: 3, name: 'funct3', attr: ['3', 'ADD/SLT[U]', 'AND/OR/XOR', 'SLL/SRL', 'SUB/SRA']},
+ {bits: 5, name: 'rs1', attr: ['5', 'src1', 'src1', 'src1', 'src1']},
+ {bits: 5, name: 'rs2', attr: ['5', 'src2', 'src2', 'src2', 'src2']},
+ {bits: 7, name: 'funct7', attr: ['7', 0, 0, 0, 32]}
+]}
+....
diff --git a/src/images/wavedrom/integer-computational.edn b/src/images/wavedrom/integer-computational.edn
new file mode 100644
index 0000000..707f06f
--- /dev/null
+++ b/src/images/wavedrom/integer-computational.edn
@@ -0,0 +1,15 @@
+//## 2.4 Integer Computational Instructions
+//### Integer Register-Immediate Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP-IMM', 'OP-IMM']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest']},
+ {bits: 3, name: 'funct3', attr: ['3', 'ADDI/SLTI[U]', 'ANDI/ORI/XORI']},
+ {bits: 5, name: 'rs1', attr: ['5', 'src', 'src']},
+ {bits: 12, name: 'imm[11:0]', attr: ['12', 'I-immediate[11:0]', 'I-immediate[11:0]']}
+]}
+....
+
+//<snio>
diff --git a/src/images/wavedrom/j-immediate.edn b/src/images/wavedrom/j-immediate.edn
new file mode 100644
index 0000000..6bebec3
--- /dev/null
+++ b/src/images/wavedrom/j-immediate.edn
@@ -0,0 +1,13 @@
+//#### J-immediate
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: '0'},
+ {bits: 4, name: 'inst[24:21]'},
+ {bits: 6, name: 'inst[30:25]'},
+ {bits: 1, name: '[20]'},
+ {bits: 8, name: 'inst[19:12]'},
+ {bits: 12, name: '— inst[31] —'},
+], config:{fontsize: 12, label:{right: 'J-immediate'}}}
+....
diff --git a/src/images/wavedrom/load-reserve-st-conditional.edn b/src/images/wavedrom/load-reserve-st-conditional.edn
new file mode 100644
index 0000000..1bd3814
--- /dev/null
+++ b/src/images/wavedrom/load-reserve-st-conditional.edn
@@ -0,0 +1,17 @@
+//# 9 "A" Standard Extension for Atomic Instructions, Version 2.1
+//## 9.2 Load-Reserved/Store-Conditional Instructions
+
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'AMO', 'AMO']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest']},
+ {bits: 3, name: 'funct3', attr: ['3', 'width', 'width']},
+ {bits: 5, name: 'rs1', attr: ['5', 'addr', 'addr']},
+ {bits: 5, name: 'rs2', attr: ['5', '0', 'src']},
+ {bits: 1, name: 'rl', attr: ['1', 'ring', 'ring']},
+ {bits: 1, name: 'aq', attr: ['1', 'orde', 'orde']},
+ {bits: 5, name: 'funct5', attr: ['5', 'LR.W/D', 'SC.W/D']},
+]}
+....
diff --git a/src/images/wavedrom/load-store.edn b/src/images/wavedrom/load-store.edn
new file mode 100644
index 0000000..ac23d35
--- /dev/null
+++ b/src/images/wavedrom/load-store.edn
@@ -0,0 +1,24 @@
+//## 2.6 Load and Store Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'LOAD']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest']},
+ {bits: 3, name: 'funct3', attr: ['3', 'width']},
+ {bits: 5, name: 'rs1', attr: ['5', 'base']},
+ {bits: 12, name: 'imm[11:0]', attr: ['12', 'offset[11:0]']},
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'STORE']},
+ {bits: 5, name: 'imm[4:0]', attr: ['5', 'offset[4:0]']},
+ {bits: 3, name: 'funct3', attr: ['3', 'width']},
+ {bits: 5, name: 'rs1', attr: ['5', 'base']},
+ {bits: 5, name: 'rs2', attr: ['5', 'src']},
+ {bits: 7, name: 'imm[11:5]', attr: ['7', 'offset[11:5]']},
+]}
+....
diff --git a/src/images/wavedrom/m-st-ext-for-int-mult.edn b/src/images/wavedrom/m-st-ext-for-int-mult.edn
new file mode 100644
index 0000000..4adcda4
--- /dev/null
+++ b/src/images/wavedrom/m-st-ext-for-int-mult.edn
@@ -0,0 +1,26 @@
+//# 8 "M" Standard Extension for Integer Multiplication and Division, Version 2.0
+//## 8.1 Multiplication Operations
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP', 'OP-32']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest']},
+ {bits: 3, name: 'funct3', attr: ['3', 'MUL/MULH[[S]U]', 'MULW']},
+ {bits: 5, name: 'rs1', attr: ['5', 'multiplicand', 'multiplicand']},
+ {bits: 5, name: 'rs2', attr: ['5', 'multiplier', 'multiplier']},
+ {bits: 7, name: 'funct7', attr: ['7', 'MULDIV', 'MULDIV']},
+]}
+....
+
+//[wavedrom, ,]
+//....
+//{reg: [
+// {bits: 7, name: 'opcode', attr: 'OP-32'},
+// {bits: 5, name: 'rd', attr: 'dest'},
+// {bits: 3, name: 'funct3', attr: 'MULW'},
+// {bits: 5, name: 'rs1', attr: 'multiplicand'},
+// {bits: 5, name: 'rs2', attr: 'multiplier'},
+// {bits: 7, name: 'funct7', attr: 'MULDIV'},
+//]}
+//....
diff --git a/src/images/wavedrom/mem-order.edn b/src/images/wavedrom/mem-order.edn
new file mode 100644
index 0000000..c7e0ba4
--- /dev/null
+++ b/src/images/wavedrom/mem-order.edn
@@ -0,0 +1,20 @@
+//## 2.7 Memory Ordering Instructions
+
+[wavedrom,mem-order ,]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'MISC-MEM']},
+ {bits: 5, name: 'rd', attr: ['5', '0']},
+ {bits: 3, name: 'funct3', attr: ['3', 'FENCE']},
+ {bits: 5, name: 'rs1', attr: ['5', '0']},
+ {bits: 1, name: 'SW', attr: 1},
+ {bits: 1, name: 'SR', attr: 1},
+ {bits: 1, name: 'SO', attr: 1},
+ {bits: 1, name: 'SI', attr: 1},
+ {bits: 1, name: 'PW', attr: 1},
+ {bits: 1, name: 'PR', attr: 1},
+ {bits: 1, name: 'PO', attr: 1},
+ {bits: 1, name: 'PI', attr: 1},
+ {bits: 4, name: 'fm', attr: ['4', 'FM']},
+]}
+....
diff --git a/src/images/wavedrom/menvcfgreg.edn b/src/images/wavedrom/menvcfgreg.edn
new file mode 100644
index 0000000..5ed6fb6
--- /dev/null
+++ b/src/images/wavedrom/menvcfgreg.edn
@@ -0,0 +1,21 @@
+//.Machine environment configuration (`menvcfg`) register.
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'FIOM'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'LPE'},
+ {bits: 1, name: 'SSE'},
+ {bits: 2, name: 'CBIE'},
+ {bits: 1, name: 'CBCFE'},
+ {bits: 1, name: 'CBZE'},
+ {bits: 24, name: 'WPRI'},
+ {bits: 2, name: 'PMM'},
+ {bits: 25, name: 'WPRI'},
+ {bits: 1, name: 'DTE'},
+ {bits: 1, name: 'CDE'},
+ {bits: 1, name: 'ADUE'},
+ {bits: 1, name: 'PBMTE'},
+ {bits: 1, name: 'STCE'},
+], config:{lanes: 4, hspace:1024}}
+....
diff --git a/src/images/wavedrom/mm-env-call.edn b/src/images/wavedrom/mm-env-call.edn
new file mode 100644
index 0000000..0b8a378
--- /dev/null
+++ b/src/images/wavedrom/mm-env-call.edn
@@ -0,0 +1,13 @@
+//
+
+[wavedrom, ,svg]
+
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','SYSTEM','SYSTEM'],},
+ {bits: 5, name: 'rd', attr: ['5','0','0'],},
+ {bits: 3, name: 'funct3', attr: ['3','PRIV','PRIV'],},
+ {bits: 5, name: 'rs1', attr: ['5','0','0'],},
+ {bits: 12, name: 'funct12', attr: ['12','ECALL','EBREAK',]},
+], config: {bits: 32}}
+....
diff --git a/src/images/wavedrom/mop-r.edn b/src/images/wavedrom/mop-r.edn
new file mode 100644
index 0000000..55347e0
--- /dev/null
+++ b/src/images/wavedrom/mop-r.edn
@@ -0,0 +1,15 @@
+[wavedrom, ,svg]
+....
+{reg:[
+ { bits: 7, name: 0x73, attr: ['SYSTEM']},
+ { bits: 5, name: 'rd'},
+ { bits: 3, name: 0x4 },
+ { bits: 5, name: 'rs1'},
+ { bits: 2, name: 'n[1:0]' },
+ { bits: 4, name: 0x7 },
+ { bits: 2, name: 'n[3:2]' },
+ { bits: 2, name: 0x0 },
+ { bits: 1, name: 'n[4]' },
+ { bits: 1, name: 0x1 },
+], config: {fontsize: 11}}
+....
diff --git a/src/images/wavedrom/mop-rr.edn b/src/images/wavedrom/mop-rr.edn
new file mode 100644
index 0000000..879e372
--- /dev/null
+++ b/src/images/wavedrom/mop-rr.edn
@@ -0,0 +1,15 @@
+[wavedrom, ,svg]
+....
+{reg:[
+ { bits: 7, name: 0x73, attr: ['SYSTEM']},
+ { bits: 5, name: 'rd'},
+ { bits: 3, name: 0x4 },
+ { bits: 5, name: 'rs1'},
+ { bits: 5, name: 'rs2'},
+ { bits: 1, name: 0x1 },
+ { bits: 2, name: 'n[1:0]' },
+ { bits: 2, name: 0x0 },
+ { bits: 1, name: 'n[2]' },
+ { bits: 1, name: 0x1 },
+], config: {fontsize: 11}}
+....
diff --git a/src/images/wavedrom/mseccfg.edn b/src/images/wavedrom/mseccfg.edn
new file mode 100644
index 0000000..7343fb3
--- /dev/null
+++ b/src/images/wavedrom/mseccfg.edn
@@ -0,0 +1,16 @@
+//.Machine security configuration (`mseccfg`) register.
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'MML'},
+ {bits: 1, name: 'MMWP'},
+ {bits: 1, name: 'RLB'},
+ {bits: 5, name: 'WPRI'},
+ {bits: 1, name: 'USEED'},
+ {bits: 1, name: 'SSEED'},
+ {bits: 1, name: 'MLPE'},
+ {bits: 21, name: 'WPRI'},
+ {bits: 2, name: 'PMM'},
+ {bits: 30, name: 'WPRI'},
+], config:{lanes: 4, hspace:1024}}
+....
diff --git a/src/images/wavedrom/mstatushreg.edn b/src/images/wavedrom/mstatushreg.edn
new file mode 100644
index 0000000..702ea11
--- /dev/null
+++ b/src/images/wavedrom/mstatushreg.edn
@@ -0,0 +1,15 @@
+//.Additional machine-mode status (`mstatush`) register for RV32.
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 4, name: 'WPRI'},
+ {bits: 1, name: 'SBE'},
+ {bits: 1, name: 'MBE'},
+ {bits: 1, name: 'GVA'},
+ {bits: 1, name: 'MPV'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'MPELP'},
+ {bits: 1, name: 'MDT'},
+ {bits: 21, name: 'WPRI'},
+], config:{lanes: 2, hspace:1024}}
+....
diff --git a/src/images/wavedrom/mstatusreg-rv321.edn b/src/images/wavedrom/mstatusreg-rv321.edn
new file mode 100644
index 0000000..cc77fc2
--- /dev/null
+++ b/src/images/wavedrom/mstatusreg-rv321.edn
@@ -0,0 +1,29 @@
+//.Machine-mode status (`mstatus`) register for RV32
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SIE'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'MIE'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SPIE'},
+ {bits: 1, name: 'UBE'},
+ {bits: 1, name: 'MPIE'},
+ {bits: 1, name: 'SPP'},
+ {bits: 2, name: 'VS[1:0]'},
+ {bits: 2, name: 'MPP[1:0]'},
+ {bits: 2, name: 'FS[1:0]'},
+ {bits: 2, name: 'XS[1:0]'},
+ {bits: 1, name: 'MPRV'},
+ {bits: 1, name: 'SUM'},
+ {bits: 1, name: 'MXR'},
+ {bits: 1, name: 'TVM'},
+ {bits: 1, name: 'TW'},
+ {bits: 1, name: 'TSR'},
+ {bits: 1, name: 'SPELP'},
+ {bits: 1, name: 'SDT'},
+ {bits: 6, name: 'WPRI'},
+ {bits: 1, name: 'SD'},
+], config:{lanes: 2, hspace:1024}}
+....
diff --git a/src/images/wavedrom/mstatusreg.edn b/src/images/wavedrom/mstatusreg.edn
new file mode 100644
index 0000000..db24626
--- /dev/null
+++ b/src/images/wavedrom/mstatusreg.edn
@@ -0,0 +1,39 @@
+//.Machine-mode status (`mstatus`) register for RV64
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SIE'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'MIE'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SPIE'},
+ {bits: 1, name: 'UBE'},
+ {bits: 1, name: 'MPIE'},
+ {bits: 1, name: 'SPP'},
+ {bits: 2, name: 'VS[1:0]'},
+ {bits: 2, name: 'MPP[1:0]'},
+ {bits: 2, name: 'FS[1:0]'},
+ {bits: 2, name: 'XS[1:0]'},
+ {bits: 1, name: 'MPRV'},
+ {bits: 1, name: 'SUM'},
+ {bits: 1, name: 'MXR'},
+ {bits: 1, name: 'TVM'},
+ {bits: 1, name: 'TW'},
+ {bits: 1, name: 'TSR'},
+ {bits: 1, name: 'SPELP'},
+ {bits: 1, name: 'SDT'},
+ {bits: 7, name: 'WPRI'},
+ {bits: 2, name: 'UXL[1:0]'},
+ {bits: 2, name: 'SXL[1:0]'},
+ {bits: 1, name: 'SBE'},
+ {bits: 1, name: 'MBE'},
+ {bits: 1, name: 'GVA'},
+ {bits: 1, name: 'MPV'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'MPELP'},
+ {bits: 1, name: 'MDT'},
+ {bits: 20, name: 'WPRI'},
+ {bits: 1, name: 'SD'},
+], config:{lanes: 4, hspace:1024}}
+....
diff --git a/src/images/wavedrom/nop.edn b/src/images/wavedrom/nop.edn
new file mode 100644
index 0000000..b566909
--- /dev/null
+++ b/src/images/wavedrom/nop.edn
@@ -0,0 +1,11 @@
+//### NOP Instruction
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP-IMM']},
+ {bits: 5, name: 'rd', attr: ['5', '0']},
+ {bits: 3, name: 'funct3', attr: ['3', 'ADDI']},
+ {bits: 5, name: 'rs1', attr: ['5', '0']},
+ {bits: 12, name: 'imm[11:0]', attr: ['12', '0']}
+]}
+....
diff --git a/src/images/wavedrom/quad-cnvrt-intch-xqqx.edn b/src/images/wavedrom/quad-cnvrt-intch-xqqx.edn
new file mode 100644
index 0000000..097c839
--- /dev/null
+++ b/src/images/wavedrom/quad-cnvrt-intch-xqqx.edn
@@ -0,0 +1,14 @@
+//quad-cnvrt-intch-xqqx
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3', 'J[N]/JX']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','Q']},
+ {bits: 5, name: 'funct5', attr: ['5','FSGNJ']},
+]}
+....
diff --git a/src/images/wavedrom/quad-cnvrt-mv.edn b/src/images/wavedrom/quad-cnvrt-mv.edn
new file mode 100644
index 0000000..769257e
--- /dev/null
+++ b/src/images/wavedrom/quad-cnvrt-mv.edn
@@ -0,0 +1,27 @@
+//## 14.3 Quad-Precision Convert and Move Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src','src']},
+ {bits: 5, name: 'rs2', attr: ['5','W[U]/L[U]', 'W[U]/L[U]']},
+ {bits: 2, name: 'fmt', attr: ['2','Q','Q']},
+ {bits: 5, name: 'funct5', attr: ['5','FCVT.int.Q','FCVT.Q.int']},
+]}
+....
+
+//[wavedrom, ,]
+//....
+//{reg: [
+// {bits: 7, name: 'opcode', attr: 'OP-FP'},
+// {bits: 5, name: 'rd', attr: 'dest'},
+// {bits: 3, name: 'rm', attr: 'RM'},
+// {bits: 5, name: 'rs1', attr: 'src'},
+// {bits: 5, name: 'rs2', attr: ['W', 'WU', 'L', 'LU']},
+// {bits: 2, name: 'fmt', attr: 'Q'},
+// {bits: 5, name: 'funct5', attr: 'FCVT.Q.int'},
+//]}
+//....
diff --git a/src/images/wavedrom/quad-cnvt-interchange.edn b/src/images/wavedrom/quad-cnvt-interchange.edn
new file mode 100644
index 0000000..a1871fa
--- /dev/null
+++ b/src/images/wavedrom/quad-cnvt-interchange.edn
@@ -0,0 +1,14 @@
+//14 conv-mv
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP-FP', 'OP-FP','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM','RM','RM','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src','src','src','src']},
+ {bits: 5, name: 'rs2', attr: ['5','Q', 'S', 'Q', 'D']},
+ {bits: 2, name: 'fmt', attr: ['2','S','Q', 'D', 'Q']},
+ {bits: 5, name: 'funct5', attr: ['5','FCVT.S.Q', 'FCVT.Q.S', 'FCVT.D.Q', 'FCVT.Q.D']},
+]}
+....
diff --git a/src/images/wavedrom/quad-compute.edn b/src/images/wavedrom/quad-compute.edn
new file mode 100644
index 0000000..eb5095e
--- /dev/null
+++ b/src/images/wavedrom/quad-compute.edn
@@ -0,0 +1,54 @@
+//## 14.2 Quad-Precision Computational Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM','RM','MIN/MAX','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src1','src1','src1','src']},
+ {bits: 5, name: 'rs2', attr: ['5','src2','src2','src2','0']},
+ {bits: 2, name: 'fmt', attr: ['2','Q','Q','Q','Q']},
+ {bits: 5, name: 'funct5', attr: ['5','FADD/FSUB', 'FMUL/FDIV', 'FMIN-MAX', 'FSQRT']},
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','F[N]MADD/F[N]MSUB']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','Q']},
+ {bits: 5, name: 'rs3', attr: ['5','src3']},
+]}
+....
+
+//[wavedrom, ,]
+//....
+//{reg: [
+// {bits: 7, name: 'opcode', attr: 'OP-FP'},
+// {bits: 5, name: 'rd', attr: 'dest'},
+// {bits: 3, name: 'funct3', attr: ['MIN', 'MAX']},
+// {bits: 5, name: 'rs1', attr: 'src1'},
+// {bits: 5, name: 'rs2', attr: 'src2'},
+// {bits: 2, name: 'fmt', attr: 'Q'},
+// {bits: 5, name: 'funct5', attr: 'FMIN-MAX'},
+//]}
+//....
+
+
+//[wavedrom, ,]
+//....
+//{reg: [
+// {bits: 7, name: 'opcode', attr: ['FMADD', 'FNMADD', 'FMSUB', 'FNMSUB']},
+// {bits: 5, name: 'rd', attr: 'dest'}
+// {bits: 3, name: 'funct3', attr: 'RM'},
+// {bits: 5, name: 'rs1', attr: 'src1'},
+// {bits: 5, name: 'rs2', attr: 'src2'},
+// {bits: 2, name: 'fmt', attr: 'Q'},
+// {bits: 5, name: 'rs3', attr: 'src3'},
+//]}
+//....
diff --git a/src/images/wavedrom/quad-float-clssfy.edn b/src/images/wavedrom/quad-float-clssfy.edn
new file mode 100644
index 0000000..245209f
--- /dev/null
+++ b/src/images/wavedrom/quad-float-clssfy.edn
@@ -0,0 +1,14 @@
+//## 14.5 Quad-Precision Floating-Point Classify Instruction
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','001']},
+ {bits: 5, name: 'rs1', attr: ['5','src']},
+ {bits: 5, name: 'rs2', attr: ['5','0']},
+ {bits: 2, name: 'fmt', attr: ['2','Q']},
+ {bits: 5, name: 'funct5', attr: ['5','FCLASS']},
+]}
+....
diff --git a/src/images/wavedrom/quad-float-compare.edn b/src/images/wavedrom/quad-float-compare.edn
new file mode 100644
index 0000000..7fd45ea
--- /dev/null
+++ b/src/images/wavedrom/quad-float-compare.edn
@@ -0,0 +1,14 @@
+//## 14.4 Quad-Precision Floating-Point Compare Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','EQ/LT/LE']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','Q']},
+ {bits: 5, name: 'funct5', attr: ['5','FCMP']},
+]}
+....
diff --git a/src/images/wavedrom/quad-ls.edn b/src/images/wavedrom/quad-ls.edn
new file mode 100644
index 0000000..077a79c
--- /dev/null
+++ b/src/images/wavedrom/quad-ls.edn
@@ -0,0 +1,24 @@
+//## 14.1 Quad-Precision Load and Store Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','LOAD-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'width', attr: ['3','Q']},
+ {bits: 5, name: 'rs1', attr: ['5','base']},
+ {bits: 12, name: 'imm[11:0]', attr: ['12','offset[11:0]']},
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','STORE-FP']},
+ {bits: 5, name: 'imm[4:0]', attr: ['5','offset[4:0]']},
+ {bits: 3, name: 'width', attr: ['3','Q']},
+ {bits: 5, name: 'rs1', attr: ['5','base']},
+ {bits: 5, name: 'rs2', attr: ['5','src']},
+ {bits: 7, name: 'imm[11:5]', attr: ['7','offset[11:5]']},
+]}
+....
diff --git a/src/images/wavedrom/reg-based-ldnstr.edn b/src/images/wavedrom/reg-based-ldnstr.edn
new file mode 100644
index 0000000..9b0abb4
--- /dev/null
+++ b/src/images/wavedrom/reg-based-ldnstr.edn
@@ -0,0 +1,14 @@
+//Register-Based loads and Stores
+
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr: ['2', 'C0', 'C0', 'C0', 'C0']},
+ {bits: 3, name: 'rdʹ', attr: ['3', 'dest','dest','dest','dest']},
+ {bits: 2, name: 'imm', attr:['2', 'offset[2|6]', 'offset[7:6]', 'offset[2|6]', 'offset[7:6]']},
+ {bits: 3, name: 'rs1ʹ', attr: ['3', 'base', 'base', 'base', 'base']},
+ {bits: 3, name: 'imm', attr: ['3', 'offset[5:3]', 'offset[5:3]', 'offset[5:3]', 'offset[5:3]']},
+ {bits: 3, name: 'funct3', attr: ['3', 'C.LW', 'C.LD', 'C.FLW', 'C.FLD']},
+], config: {bits: 16}}
+....
diff --git a/src/images/wavedrom/rv64-lui-auipc.edn b/src/images/wavedrom/rv64-lui-auipc.edn
new file mode 100644
index 0000000..5850133
--- /dev/null
+++ b/src/images/wavedrom/rv64-lui-auipc.edn
@@ -0,0 +1,10 @@
+//lui-auipc
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'LUI', 'AUIPC']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest']},
+ {bits: 20, name: 'imm[31:12]', attr: ['20', 'U-immediate[31:12]', 'U-immediate[31:12]']}
+]}
+....
diff --git a/src/images/wavedrom/rv64i-base-int.edn b/src/images/wavedrom/rv64i-base-int.edn
new file mode 100644
index 0000000..e5df7ee
--- /dev/null
+++ b/src/images/wavedrom/rv64i-base-int.edn
@@ -0,0 +1,14 @@
+//# 6 RV64I Base Integer Instruction Set, Version 2.1
+//## 6.2 Integer Computational Instructions
+//### Integer Register-Immediate Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP-IMM-32']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest']},
+ {bits: 3, name: 'funct3', attr: ['3', 'ADDIW']},
+ {bits: 5, name: 'rs1', attr: ['5', 'src']},
+ {bits: 12, name: 'imm[11:0]', attr: ['12', 'I-immediate[11:0]']}
+]}
+....
diff --git a/src/images/wavedrom/rv64i-int-reg-reg.edn b/src/images/wavedrom/rv64i-int-reg-reg.edn
new file mode 100644
index 0000000..6d29ec7
--- /dev/null
+++ b/src/images/wavedrom/rv64i-int-reg-reg.edn
@@ -0,0 +1,27 @@
+
+//rv64i int-reg-reg
+//### Integer Register-Register Operations
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP', 'OP', 'OP-32', 'OP-32', 'OP-32']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest', 'dest', 'dest', 'dest']},
+ {bits: 3, name: 'funct3', attr: ['3', 'SLL/SRL', 'SRA', 'ADDW', 'SLLW/SRLW', 'SUBW/SRAW']},
+ {bits: 5, name: 'rs1', attr: ['5', 'src1', 'src1', 'src1', 'src1', 'src1']},
+ {bits: 5, name: 'rs2', attr: ['5', 'src2', 'src2', 'src2', 'src2', 'src2']},
+ {bits: 7, name: 'funct7', attr: ['7', '0000000', '0100000', '0000000', '0000000', '0100000']}
+]}
+....
+
+//[wavedrom, ,svg]
+//....
+//{reg: [
+// {bits: 7, name: 'opcode', attr: 'OP-32'},
+// {bits: 5, name: 'rd', attr: 'dest'},
+// {bits: 3, name: 'funct3', attr: ['ADDW', 'SLLW', 'SRLW', 'SUBW', 'SRAW']},
+// {bits: 5, name: 'rs1', attr: 'src1'},
+// {bits: 5, name: 'rs2', attr: 'src2'},
+// {bits: 7, name: 'funct7', attr: [0, 0, 0, 32, 32]}
+//]}
+//....
diff --git a/src/images/wavedrom/rv64i-slli.edn b/src/images/wavedrom/rv64i-slli.edn
new file mode 100644
index 0000000..b261564
--- /dev/null
+++ b/src/images/wavedrom/rv64i-slli.edn
@@ -0,0 +1,11 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP-IMM', 'OP-IMM', 'OP-IMM']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest', 'dest']},
+ {bits: 3, name: 'funct3', attr: ['3', 'SLLI', 'SRLI', 'SRAI']},
+ {bits: 5, name: 'rs1', attr: ['5', 'src', 'src', 'src']},
+ {bits: 6, name: 'imm[5:0]', attr: ['6', 'shamt[5:0]', 'shamt[5:0]', 'shamt[5:0]']},
+ {bits: 6, name: 'imm[11:6]', attr: ['6', '000000', '000000', '010000']}
+]}
+....
diff --git a/src/images/wavedrom/rv64i-slliw.edn b/src/images/wavedrom/rv64i-slliw.edn
new file mode 100644
index 0000000..0ca01ba
--- /dev/null
+++ b/src/images/wavedrom/rv64i-slliw.edn
@@ -0,0 +1,12 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'OP-IMM-32', 'OP-IMM-32', 'OP-IMM-32']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest', 'dest', 'dest']},
+ {bits: 3, name: 'funct3', attr: ['3', 'SLLIW', 'SRLIW', 'SRAIW']},
+ {bits: 5, name: 'rs1', attr: ['5', 'src', 'src', 'src']},
+ {bits: 5, name: 'imm[4:0]', attr: ['5', 'shamt[4:0]', 'shamt[4:0]', 'shamt[4:0]']},
+ {bits: 1, name: '[5]', attr: ['1', '0', '0', '0']},
+ {bits: 6, name: 'imm[11:6]', attr: ['6', '000000', '000000', '010000']}
+]}
+....
diff --git a/src/images/wavedrom/s-immediate.edn b/src/images/wavedrom/s-immediate.edn
new file mode 100644
index 0000000..14abede
--- /dev/null
+++ b/src/images/wavedrom/s-immediate.edn
@@ -0,0 +1,11 @@
+//#### S-immediate
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: '[7]'},
+ {bits: 4, name: 'inst[11:8]'},
+ {bits: 6, name: 'inst[30:25]'},
+ {bits: 21, name: '— inst[31] —'},
+], config:{fontsize: 12, label:{right: 'S-immediate'}}}
+....
diff --git a/src/images/wavedrom/sfenceinvalir.edn b/src/images/wavedrom/sfenceinvalir.edn
new file mode 100644
index 0000000..ca237fc
--- /dev/null
+++ b/src/images/wavedrom/sfenceinvalir.edn
@@ -0,0 +1,11 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM']},
+ {bits: 5, name: 'rd', attr: ['5', '0']},
+ {bits: 3, name: 'funct3', attr: ['3', 'PRIV']},
+ {bits: 5, name: 'rs1', attr: ['5', '0']},
+ {bits: 5, name: 'rs2', attr: ['5', '1']},
+ {bits: 7, name: 'funct7', attr: ['7', 'SFENCE.INVAL.IR']},
+]}
+....
diff --git a/src/images/wavedrom/sfencevma.edn b/src/images/wavedrom/sfencevma.edn
new file mode 100644
index 0000000..bba975e
--- /dev/null
+++ b/src/images/wavedrom/sfencevma.edn
@@ -0,0 +1,11 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM']},
+ {bits: 5, name: 'rd', attr: ['5', '0']},
+ {bits: 3, name: 'funct3', attr: ['3', 'PRIV']},
+ {bits: 5, name: 'rs1', attr: ['5', 'vaddr']},
+ {bits: 5, name: 'rs2', attr: ['5', 'asid']},
+ {bits: 7, name: 'funct7', attr: ['7', 'SFENCE.VMA']},
+]}
+....
diff --git a/src/images/wavedrom/sfencewinval.edn b/src/images/wavedrom/sfencewinval.edn
new file mode 100644
index 0000000..81e6667
--- /dev/null
+++ b/src/images/wavedrom/sfencewinval.edn
@@ -0,0 +1,11 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM']},
+ {bits: 5, name: 'rd', attr: ['5', '0']},
+ {bits: 3, name: 'funct3', attr: ['3', 'PRIV']},
+ {bits: 5, name: 'rs1', attr: ['5', '0']},
+ {bits: 5, name: 'rs2', attr: ['5', '0']},
+ {bits: 7, name: 'funct7', attr: ['7', 'SFENCE.W.INVAL']},
+]}
+....
diff --git a/src/images/wavedrom/sinvalvma.edn b/src/images/wavedrom/sinvalvma.edn
new file mode 100644
index 0000000..d29d14c
--- /dev/null
+++ b/src/images/wavedrom/sinvalvma.edn
@@ -0,0 +1,11 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM']},
+ {bits: 5, name: 'rd', attr: ['5', '0']},
+ {bits: 3, name: 'funct3', attr: ['3', 'PRIV']},
+ {bits: 5, name: 'rs1', attr: ['5', 'vaddr']},
+ {bits: 5, name: 'rs2', attr: ['5', 'asid']},
+ {bits: 7, name: 'funct7', attr: ['7', 'SINVAL.VMA']},
+]}
+....
diff --git a/src/images/wavedrom/sp-load-store-2.edn b/src/images/wavedrom/sp-load-store-2.edn
new file mode 100644
index 0000000..fffc263
--- /dev/null
+++ b/src/images/wavedrom/sp-load-store-2.edn
@@ -0,0 +1,24 @@
+//## 12.5 Single-Precision Load and Store Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'LOAD-FP']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest']},
+ {bits: 3, name: 'width', attr: ['3', 'W']},
+ {bits: 5, name: 'rs1', attr: ['5', 'base']},
+ {bits: 12, name: 'imm[11:0]', attr: ['12', 'offset[11:0]']},
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'STORE-FP']},
+ {bits: 5, name: 'imm[4:0]', attr: ['5', 'offset[4:0]']},
+ {bits: 3, name: 'width', attr: ['3', 'W']},
+ {bits: 5, name: 'rs1', attr: ['5', 'base']},
+ {bits: 5, name: 'rs2', attr: ['5', 'src']},
+ {bits: 7, name: 'imm[11:5]', attr: ['7', 'offset[11:5]']},
+]}
+....
diff --git a/src/images/wavedrom/sp-load-store.edn b/src/images/wavedrom/sp-load-store.edn
new file mode 100644
index 0000000..e12818a
--- /dev/null
+++ b/src/images/wavedrom/sp-load-store.edn
@@ -0,0 +1,24 @@
+//## 12.5 Single-Precision Load and Store Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'LOAD-FP']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest']},
+ {bits: 3, name: 'width', attr: ['3', 'H']},
+ {bits: 5, name: 'rs1', attr: ['5', 'base']},
+ {bits: 12, name: 'imm[11:0]', attr: ['12', 'offset[11:0]']},
+]}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'STORE-FP']},
+ {bits: 5, name: 'imm[4:0]', attr: ['5', 'offset[4:0]']},
+ {bits: 3, name: 'width', attr: ['3', 'H']},
+ {bits: 5, name: 'rs1', attr: ['5', 'base']},
+ {bits: 5, name: 'rs2', attr: ['5', 'src']},
+ {bits: 7, name: 'imm[11:5]', attr: ['7', 'offset[11:5]']},
+]}
+....
diff --git a/src/images/wavedrom/spfloat-classify.edn b/src/images/wavedrom/spfloat-classify.edn
new file mode 100644
index 0000000..52ec8bc
--- /dev/null
+++ b/src/images/wavedrom/spfloat-classify.edn
@@ -0,0 +1,14 @@
+//## 12.9 Single-Precision Floating-Point Classify Instruction
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','001']},
+ {bits: 5, name: 'rs1', attr: ['5','src']},
+ {bits: 5, name: 'rs2', attr: ['5','0']},
+ {bits: 2, name: 'fmt', attr: ['2','S']},
+ {bits: 5, name: 'funct5', attr: ['5','FCLASS']},
+]}
+....
diff --git a/src/images/wavedrom/spfloat-cn-cmp.edn b/src/images/wavedrom/spfloat-cn-cmp.edn
new file mode 100644
index 0000000..fa6af7d
--- /dev/null
+++ b/src/images/wavedrom/spfloat-cn-cmp.edn
@@ -0,0 +1,14 @@
+//sp float convert and compare
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP', 'OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest', 'dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src', 'src']},
+ {bits: 5, name: 'rs2', attr: ['5','W[U]/L[U]D', 'W[U]/L[U]']},
+ {bits: 2, name: 'fmt', attr: ['2','S','S']},
+ {bits: 5, name: 'funct5', attr: ['5','FCVT.int.fmt', 'FCVT.fmt.int']},
+]}
+....
diff --git a/src/images/wavedrom/spfloat-comp.edn b/src/images/wavedrom/spfloat-comp.edn
new file mode 100644
index 0000000..b1d200d
--- /dev/null
+++ b/src/images/wavedrom/spfloat-comp.edn
@@ -0,0 +1,14 @@
+//## 12.8 Single-Precision Floating-Point Compare Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','EQ', 'LT', 'LE']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','S']},
+ {bits: 5, name: 'funct5', attr: ['5','FCMP']},
+]}
+....
diff --git a/src/images/wavedrom/spfloat-mv.edn b/src/images/wavedrom/spfloat-mv.edn
new file mode 100644
index 0000000..3db26bb
--- /dev/null
+++ b/src/images/wavedrom/spfloat-mv.edn
@@ -0,0 +1,14 @@
+//SP floating point move
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','000', '000']},
+ {bits: 5, name: 'rs1', attr: ['5','src','src']},
+ {bits: 5, name: 'rs2', attr: ['5','0','0']},
+ {bits: 2, name: 'fmt', attr: ['2','S','S']},
+ {bits: 5, name: 'funct5', attr: ['5','FMV.X.W','FMV.W.X']},
+]}
+....
diff --git a/src/images/wavedrom/spfloat-sign-inj.edn b/src/images/wavedrom/spfloat-sign-inj.edn
new file mode 100644
index 0000000..1511e22
--- /dev/null
+++ b/src/images/wavedrom/spfloat-sign-inj.edn
@@ -0,0 +1,14 @@
+//sp float sign injection
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5', 'dest']},
+ {bits: 3, name: 'rm', attr: ['3','J[N]/JX']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','S']},
+ {bits: 5, name: 'funct5', attr: ['5','FSGNJ']},
+]}
+....
diff --git a/src/images/wavedrom/spfloat-zfh.edn b/src/images/wavedrom/spfloat-zfh.edn
new file mode 100644
index 0000000..123b2ed
--- /dev/null
+++ b/src/images/wavedrom/spfloat-zfh.edn
@@ -0,0 +1,14 @@
+//## 12.6 Single-Precision Floating-Point Computational Instructions for ZFH Chapter
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM', 'RM', 'MIN/MAX', 'RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src1', 'src1', 'src1', 'src']},
+ {bits: 5, name: 'rs2', attr: ['5','src2', 'src2', 'src2', '0']},
+ {bits: 2, name: 'fmt', attr: ['2','H', 'H', 'H', 'H']},
+ {bits: 5, name: 'funct5', attr: ['5', 'FADD/FSUB', 'FMUL/FDIV', 'FMIN-MAX', 'FSQRT']},
+]}
+....
diff --git a/src/images/wavedrom/spfloat.edn b/src/images/wavedrom/spfloat.edn
new file mode 100644
index 0000000..27b141f
--- /dev/null
+++ b/src/images/wavedrom/spfloat.edn
@@ -0,0 +1,14 @@
+//## 12.6 Single-Precision Floating-Point Computational Instructions
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','OP-FP','OP-FP','OP-FP','OP-FP']},
+ {bits: 5, name: 'rd', attr: ['5','dest','dest','dest','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM', 'RM', 'RM','MIN/MAX']},
+ {bits: 5, name: 'rs1', attr: ['5','src1', 'src1', 'src', 'src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2', 'src2', '0', 'src2']},
+ {bits: 2, name: 'fmt', attr: ['2','S', 'S', 'S', 'S']},
+ {bits: 5, name: 'funct5', attr: ['5', 'FADD/FSUB', 'FMUL/FDIV', 'FSQRT','FMIN-MAX']},
+]}
+....
diff --git a/src/images/wavedrom/spfloat2-zfh.edn b/src/images/wavedrom/spfloat2-zfh.edn
new file mode 100644
index 0000000..89fc6bd
--- /dev/null
+++ b/src/images/wavedrom/spfloat2-zfh.edn
@@ -0,0 +1,12 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','F[N]MADD/F[N]MSUB']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','H']},
+ {bits: 5, name: 'rs3', attr: ['5','src3']},
+]}
+....
diff --git a/src/images/wavedrom/spfloat2.edn b/src/images/wavedrom/spfloat2.edn
new file mode 100644
index 0000000..13d152f
--- /dev/null
+++ b/src/images/wavedrom/spfloat2.edn
@@ -0,0 +1,12 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','F[N]MADD/F[N]MSUB']},
+ {bits: 5, name: 'rd', attr: ['5','dest']},
+ {bits: 3, name: 'rm', attr: ['3','RM']},
+ {bits: 5, name: 'rs1', attr: ['5','src1']},
+ {bits: 5, name: 'rs2', attr: ['5','src2']},
+ {bits: 2, name: 'fmt', attr: ['2','S']},
+ {bits: 5, name: 'rs3', attr: ['5','src3']},
+]}
+....
diff --git a/src/images/wavedrom/transformedatomicinst.edn b/src/images/wavedrom/transformedatomicinst.edn
new file mode 100644
index 0000000..4d9af20
--- /dev/null
+++ b/src/images/wavedrom/transformedatomicinst.edn
@@ -0,0 +1,13 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7']},
+ {bits: 5, name: 'rd', attr: ['5']},
+ {bits: 3, name: 'funct3', attr: ['3']},
+ {bits: 5, name: 'Addr. Offset', attr: ['5']},
+ {bits: 5, name: 'rs2', attr: ['5']},
+ {bits: 1, name: 'rl', attr: ['1']},
+ {bits: 1, name: 'aq', attr: ['1']},
+ {bits: 5, name: 'funct5', attr: ['5']},
+], config: {bits: 32}}
+....
diff --git a/src/images/wavedrom/transformedloadinst.edn b/src/images/wavedrom/transformedloadinst.edn
new file mode 100644
index 0000000..1db0f0f
--- /dev/null
+++ b/src/images/wavedrom/transformedloadinst.edn
@@ -0,0 +1,11 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7']},
+ {bits: 5, name: 'rd', attr: ['5']},
+ {bits: 3, name: 'funct3', attr: ['3']},
+ {bits: 5, name: 'Addr. Offset', attr: ['5']},
+ {bits: 5, name: '0', attr: ['5']},
+ {bits: 7, name: '0', attr: ['7']},
+], config: {bits: 32}}
+....
diff --git a/src/images/wavedrom/transformedstoreinst.edn b/src/images/wavedrom/transformedstoreinst.edn
new file mode 100644
index 0000000..4a7c09d
--- /dev/null
+++ b/src/images/wavedrom/transformedstoreinst.edn
@@ -0,0 +1,11 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7']},
+ {bits: 5, name: '0', attr: ['5']},
+ {bits: 3, name: 'funct3', attr: ['3']},
+ {bits: 5, name: 'Addr. Offset', attr: ['5']},
+ {bits: 5, name: 'rs2', attr: ['5']},
+ {bits: 7, name: '0', attr: ['7']},
+], config: {bits: 32}}
+....
diff --git a/src/images/wavedrom/transformedvmaccessinst.edn b/src/images/wavedrom/transformedvmaccessinst.edn
new file mode 100644
index 0000000..0eb2739
--- /dev/null
+++ b/src/images/wavedrom/transformedvmaccessinst.edn
@@ -0,0 +1,11 @@
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7']},
+ {bits: 5, name: 'rd', attr: ['5']},
+ {bits: 3, name: 'funct3', attr: ['3']},
+ {bits: 5, name: 'Addr. Offset', attr: ['5']},
+ {bits: 5, name: 'rs2', attr: ['5']},
+ {bits: 7, name: 'funct7', attr: ['7']},
+], config: {bits: 32}}
+....
diff --git a/src/images/wavedrom/trap-return.edn b/src/images/wavedrom/trap-return.edn
new file mode 100644
index 0000000..b0f356a
--- /dev/null
+++ b/src/images/wavedrom/trap-return.edn
@@ -0,0 +1,13 @@
+//
+
+[wavedrom, ,svg]
+
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','SYSTEM'],},
+ {bits: 5, name: 'rd', attr: ['5','0'],},
+ {bits: 3, name: 'funct3', attr: ['3','PRIV'],},
+ {bits: 5, name: 'rs1', attr: ['5','0'],},
+ {bits: 12, name: 'funct12', attr: ['12','MRET/SRET',]},
+], config: {bits: 32}}
+....
diff --git a/src/images/wavedrom/u-immediate.edn b/src/images/wavedrom/u-immediate.edn
new file mode 100644
index 0000000..08f1813
--- /dev/null
+++ b/src/images/wavedrom/u-immediate.edn
@@ -0,0 +1,11 @@
+//#### U-immediate
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 12, name: '0'},
+ {bits: 8, name: 'inst[19:12]'},
+ {bits: 11, name: 'inst[30:20]'},
+ {bits: 1, name: '[31]'},
+], config:{fontsize: 12, label:{right: 'U-immediate'}}}
+....
diff --git a/src/images/wavedrom/v-inst-table.edn b/src/images/wavedrom/v-inst-table.edn
new file mode 100644
index 0000000..144510d
--- /dev/null
+++ b/src/images/wavedrom/v-inst-table.edn
@@ -0,0 +1,208 @@
+
+// [cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+[cols="<,<,<,<,<,<,<,<,<,<,<,<,<",options="headers"]
+|===
+5+| Integer 4+| Integer 4+| FP
+
+| funct3 | | | | | funct3 | | | | funct3 | | |
+| OPIVV |V| | | | OPMVV{nbsp} |V| | | OPFVV |V| |
+| OPIVX | |X| | | OPMVX{nbsp} | |X| | OPFVF | |F|
+| OPIVI | | |I| | | | | | | | |
+|===
+
+[cols="<,<,<,<,<,<,<,<,<,<,<,<,<",options="headers"]
+|===
+5+| funct6 4+| funct6 4+| funct6
+
+| 000000 |V|X|I| vadd | 000000 |V| | vredsum | 000000 |V|F| vfadd
+| 000001 | | | | | 000001 |V| | vredand | 000001 |V| | vfredusum
+| 000010 |V|X| | vsub | 000010 |V| | vredor | 000010 |V|F| vfsub
+| 000011 | |X|I| vrsub | 000011 |V| | vredxor | 000011 |V| | vfredosum
+| 000100 |V|X| | vminu | 000100 |V| | vredminu | 000100 |V|F| vfmin
+| 000101 |V|X| | vmin | 000101 |V| | vredmin | 000101 |V| | vfredmin
+| 000110 |V|X| | vmaxu | 000110 |V| | vredmaxu | 000110 |V|F| vfmax
+| 000111 |V|X| | vmax | 000111 |V| | vredmax | 000111 |V| | vfredmax
+| 001000 | | | | | 001000 |V|X| vaaddu | 001000 |V|F| vfsgnj
+| 001001 |V|X|I| vand | 001001 |V|X| vaadd | 001001 |V|F| vfsgnjn
+| 001010 |V|X|I| vor | 001010 |V|X| vasubu | 001010 |V|F| vfsgnjx
+| 001011 |V|X|I| vxor | 001011 |V|X| vasub | 001011 | | |
+| 001100 |V|X|I| vrgather | 001100 | | | | 001100 | | |
+| 001101 | | | | | 001101 | | | | 001101 | | |
+| 001110 | |X|I| vslideup | 001110 | |X| vslide1up | 001110 | |F| vfslide1up
+| 001110 |V| | |vrgatherei16| | | | | | | |
+| 001111 | |X|I| vslidedown | 001111 | |X| vslide1down | 001111 | |F| vfslide1down
+|===
+
+// [cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+|===
+5+| funct6 4+| funct6 4+| funct6
+
+| 010000 |V|X|I| vadc | 010000 |V| | VWXUNARY0 | 010000 |V| | VWFUNARY0
+| | | | | | 010000 | |X| VRXUNARY0 | 010000 | |F| VRFUNARY0
+| 010001 |V|X|I| vmadc | 010001 | | | | 010001 | | |
+| 010010 |V|X| | vsbc | 010010 |V| | VXUNARY0 | 010010 |V| | VFUNARY0
+| 010011 |V|X| | vmsbc | 010011 | | | | 010011 |V| | VFUNARY1
+| 010100 | | | | | 010100 |V| | VMUNARY0 | 010100 | | |
+| 010101 | | | | | 010101 | | | | 010101 | | |
+| 010110 | | | | | 010110 | | | | 010110 | | |
+| 010111 |V|X|I| vmerge/vmv | 010111 |V| | vcompress | 010111 | |F| vfmerge/vfmv
+| 011000 |V|X|I| vmseq | 011000 |V| | vmandn | 011000 |V|F| vmfeq
+| 011001 |V|X|I| vmsne | 011001 |V| | vmand | 011001 |V|F| vmfle
+| 011010 |V|X| | vmsltu | 011010 |V| | vmor | 011010 | | |
+| 011011 |V|X| | vmslt | 011011 |V| | vmxor | 011011 |V|F| vmflt
+| 011100 |V|X|I| vmsleu | 011100 |V| | vmorn | 011100 |V|F| vmfne
+| 011101 |V|X|I| vmsle | 011101 |V| | vmnand | 011101 | |F| vmfgt
+| 011110 | |X|I| vmsgtu | 011110 |V| | vmnor | 011110 | | |
+| 011111 | |X|I| vmsgt | 011111 |V| | vmxnor | 011111 | |F| vmfge
+|===
+
+// [cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+|===
+5+| funct6 4+| funct6 4+| funct6
+
+| 100000 |V|X|I| vsaddu | 100000 |V|X| vdivu | 100000 |V|F| vfdiv
+| 100001 |V|X|I| vsadd | 100001 |V|X| vdiv | 100001 | |F| vfrdiv
+| 100010 |V|X| | vssubu | 100010 |V|X| vremu | 100010 | | |
+| 100011 |V|X| | vssub | 100011 |V|X| vrem | 100011 | | |
+| 100100 | | | | | 100100 |V|X| vmulhu | 100100 |V|F| vfmul
+| 100101 |V|X|I| vsll | 100101 |V|X| vmul | 100101 | | |
+| 100110 | | | | | 100110 |V|X| vmulhsu | 100110 | | |
+| 100111 |V|X| | vsmul | 100111 |V|X| vmulh | 100111 | |F| vfrsub
+| 100111 | | |I| vmv<nr>r | | | | | | | |
+| 101000 |V|X|I| vsrl | 101000 | | | | 101000 |V|F| vfmadd
+| 101001 |V|X|I| vsra | 101001 |V|X| vmadd | 101001 |V|F| vfnmadd
+| 101010 |V|X|I| vssrl | 101010 | | | | 101010 |V|F| vfmsub
+| 101011 |V|X|I| vssra | 101011 |V|X| vnmsub | 101011 |V|F| vfnmsub
+| 101100 |V|X|I| vnsrl | 101100 | | | | 101100 |V|F| vfmacc
+| 101101 |V|X|I| vnsra | 101101 |V|X| vmacc | 101101 |V|F| vfnmacc
+| 101110 |V|X|I| vnclipu | 101110 | | | | 101110 |V|F| vfmsac
+| 101111 |V|X|I| vnclip | 101111 |V|X| vnmsac | 101111 |V|F| vfnmsac
+|===
+
+// [cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+|===
+5+| funct6 4+| funct6 4+| funct6
+
+| 110000 |V| | | vwredsumu | 110000 |V|X| vwaddu | 110000 |V|F| vfwadd
+| 110001 |V| | | vwredsum | 110001 |V|X| vwadd | 110001 |V| | vfwredusum
+| 110010 | | | | | 110010 |V|X| vwsubu | 110010 |V|F| vfwsub
+| 110011 | | | | | 110011 |V|X| vwsub | 110011 |V| | vfwredosum
+| 110100 | | | | | 110100 |V|X| vwaddu.w | 110100 |V|F| vfwadd.w
+| 110101 | | | | | 110101 |V|X| vwadd.w | 110101 | | |
+| 110110 | | | | | 110110 |V|X| vwsubu.w | 110110 |V|F| vfwsub.w
+| 110111 | | | | | 110111 |V|X| vwsub.w | 110111 | | |
+| 111000 | | | | | 111000 |V|X| vwmulu | 111000 |V|F| vfwmul
+| 111001 | | | | | 111001 | | | | 111001 | | |
+| 111010 | | | | | 111010 |V|X| vwmulsu | 111010 | | |
+| 111011 | | | | | 111011 |V|X| vwmul | 111011 | | |
+| 111100 | | | | | 111100 |V|X| vwmaccu | 111100 |V|F| vfwmacc
+| 111101 | | | | | 111101 |V|X| vwmacc | 111101 |V|F| vfwnmacc
+| 111110 | | | | | 111110 | |X| vwmaccus | 111110 |V|F| vfwmsac
+| 111111 | | | | | 111111 |V|X| vwmaccsu | 111111 |V|F| vfwnmsac
+|===
+
+<<<
+
+.VRXUNARY0 encoding space
+[cols="2,14"]
+|===
+| vs2 |
+
+| 00000 | vmv.s.x
+|===
+
+.VWXUNARY0 encoding space
+[cols="2,14"]
+|===
+| vs1 |
+
+| 00000 | vmv.x.s
+| 10000 | vcpop
+| 10001 | vfirst
+|===
+
+.VXUNARY0 encoding space
+[cols="2,14"]
+|===
+| vs1 |
+
+| 00010 | vzext.vf8
+| 00011 | vsext.vf8
+| 00100 | vzext.vf4
+| 00101 | vsext.vf4
+| 00110 | vzext.vf2
+| 00111 | vsext.vf2
+|===
+
+.VRFUNARY0 encoding space
+[cols="2,14"]
+|===
+| vs2 |
+
+| 00000 | vfmv.s.f
+|===
+
+.VWFUNARY0 encoding space
+[cols="2,14"]
+|===
+| vs1 |
+
+| 00000 | vfmv.f.s
+|===
+
+.VFUNARY0 encoding space
+[cols="2,14"]
+|===
+| vs1 | name
+
+2+| single-width converts
+| 00000 | vfcvt.xu.f.v
+| 00001 | vfcvt.x.f.v
+| 00010 | vfcvt.f.xu.v
+| 00011 | vfcvt.f.x.v
+| 00110 | vfcvt.rtz.xu.f.v
+| 00111 | vfcvt.rtz.x.f.v
+| |
+2+| widening converts
+| 01000 | vfwcvt.xu.f.v
+| 01001 | vfwcvt.x.f.v
+| 01010 | vfwcvt.f.xu.v
+| 01011 | vfwcvt.f.x.v
+| 01100 | vfwcvt.f.f.v
+| 01110 | vfwcvt.rtz.xu.f.v
+| 01111 | vfwcvt.rtz.x.f.v
+| |
+2+| narrowing converts
+| 10000 | vfncvt.xu.f.w
+| 10001 | vfncvt.x.f.w
+| 10010 | vfncvt.f.xu.w
+| 10011 | vfncvt.f.x.w
+| 10100 | vfncvt.f.f.w
+| 10101 | vfncvt.rod.f.f.w
+| 10110 | vfncvt.rtz.xu.f.w
+| 10111 | vfncvt.rtz.x.f.w
+|===
+
+.VFUNARY1 encoding space
+[cols="2,14"]
+|===
+| vs1 | name
+
+| 00000 | vfsqrt.v
+| 00100 | vfrsqrt7.v
+| 00101 | vfrec7.v
+| 10000 | vfclass.v
+|===
+
+
+.VMUNARY0 encoding space
+[cols="2,14"]
+|===
+| vs1 |
+
+| 00001 | vmsbf
+| 00010 | vmsof
+| 00011 | vmsif
+| 10000 | viota
+| 10001 | vid
+|===
diff --git a/src/images/wavedrom/valu-format.edn b/src/images/wavedrom/valu-format.edn
new file mode 100644
index 0000000..95732e7
--- /dev/null
+++ b/src/images/wavedrom/valu-format.edn
@@ -0,0 +1,104 @@
+Formats for Vector Arithmetic Instructions under OP-V major opcode
+
+////
+31 26 25 24 20 19 15 14 12 11 7 6 0
+ funct6 | vm | vs2 | vs1 | 0 0 0 | vd |1010111| OP-V (OPIVV)
+ funct6 | vm | vs2 | vs1 | 0 0 1 | vd/rd |1010111| OP-V (OPFVV)
+ funct6 | vm | vs2 | vs1 | 0 1 0 | vd/rd |1010111| OP-V (OPMVV)
+ funct6 | vm | vs2 | imm[4:0] | 0 1 1 | vd |1010111| OP-V (OPIVI)
+ funct6 | vm | vs2 | rs1 | 1 0 0 | vd |1010111| OP-V (OPIVX)
+ funct6 | vm | vs2 | rs1 | 1 0 1 | vd |1010111| OP-V (OPFVF)
+ funct6 | vm | vs2 | rs1 | 1 1 0 | vd/rd |1010111| OP-V (OPMVX)
+ 6 1 5 5 3 5 7
+////
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x57, attr: 'OPIVV'},
+ {bits: 5, name: 'vd'},
+ {bits: 3, name: 0},
+ {bits: 5, name: 'vs1'},
+ {bits: 5, name: 'vs2'},
+ {bits: 1, name: 'vm'},
+ {bits: 6, name: 'funct6'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x57, attr: 'OPFVV'},
+ {bits: 5, name: 'vd / rd'},
+ {bits: 3, name: 1},
+ {bits: 5, name: 'vs1'},
+ {bits: 5, name: 'vs2'},
+ {bits: 1, name: 'vm'},
+ {bits: 6, name: 'funct6'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x57, attr: 'OPMVV'},
+ {bits: 5, name: 'vd / rd'},
+ {bits: 3, name: 2},
+ {bits: 5, name: 'vs1'},
+ {bits: 5, name: 'vs2'},
+ {bits: 1, name: 'vm'},
+ {bits: 6, name: 'funct6'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x57, attr: ['OPIVI']},
+ {bits: 5, name: 'vd'},
+ {bits: 3, name: 3},
+ {bits: 5, name: 'imm[4:0]'},
+ {bits: 5, name: 'vs2'},
+ {bits: 1, name: 'vm'},
+ {bits: 6, name: 'funct6'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x57, attr: 'OPIVX'},
+ {bits: 5, name: 'vd'},
+ {bits: 3, name: 4},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'vs2'},
+ {bits: 1, name: 'vm'},
+ {bits: 6, name: 'funct6'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x57, attr: 'OPFVF'},
+ {bits: 5, name: 'vd'},
+ {bits: 3, name: 5},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'vs2'},
+ {bits: 1, name: 'vm'},
+ {bits: 6, name: 'funct6'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x57, attr: 'OPMVX'},
+ {bits: 5, name: 'vd / rd'},
+ {bits: 3, name: 6},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'vs2'},
+ {bits: 1, name: 'vm'},
+ {bits: 6, name: 'funct6'},
+]}
+....
diff --git a/src/images/wavedrom/vcfg-format.edn b/src/images/wavedrom/vcfg-format.edn
new file mode 100644
index 0000000..0219e6b
--- /dev/null
+++ b/src/images/wavedrom/vcfg-format.edn
@@ -0,0 +1,47 @@
+Formats for Vector Configuration Instructions under OP-V major opcode
+
+////
+ 31 30 25 24 20 19 15 14 12 11 7 6 0
+ 0 | zimm[10:0] | rs1 | 1 1 1 | rd |1010111| vsetvli
+ 1 | 1| zimm[ 9:0] | uimm[4:0]| 1 1 1 | rd |1010111| vsetivli
+ 1 | 000000 | rs2 | rs1 | 1 1 1 | rd |1010111| vsetvl
+ 1 6 5 5 3 5 7
+////
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x57, attr: 'vsetvli'},
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 7},
+ {bits: 5, name: 'rs1'},
+ {bits: 11, name: 'vtypei[10:0]'},
+ {bits: 1, name: '0'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x57, attr: 'vsetivli'},
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 7},
+ {bits: 5, name: 'uimm[4:0]'},
+ {bits: 10, name: 'vtypei[9:0]'},
+ {bits: 1, name: '1'},
+ {bits: 1, name: '1'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x57, attr: 'vsetvl'},
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 7},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'rs2'},
+ {bits: 6, name: 0x00},
+ {bits: 1, name: 1},
+]}
+....
diff --git a/src/images/wavedrom/vfrec7.edn b/src/images/wavedrom/vfrec7.edn
new file mode 100644
index 0000000..d33f44e
--- /dev/null
+++ b/src/images/wavedrom/vfrec7.edn
@@ -0,0 +1,136 @@
+.vfrec7.v common-case lookup table contents
+[%autowidth,float="center",align="center",options="header"]
+|===
+
+| sig[MSB -: 7] | sig_out[MSB -: 7]
+
+| 0 | 127
+| 1 | 125
+| 2 | 123
+| 3 | 121
+| 4 | 119
+| 5 | 117
+| 6 | 116
+| 7 | 114
+| 8 | 112
+| 9 | 110
+| 10 | 109
+| 11 | 107
+| 12 | 105
+| 13 | 104
+| 14 | 102
+| 15 | 100
+| 16 | 99
+| 17 | 97
+| 18 | 96
+| 19 | 94
+| 20 | 93
+| 21 | 91
+| 22 | 90
+| 23 | 88
+| 24 | 87
+| 25 | 85
+| 26 | 84
+| 27 | 83
+| 28 | 81
+| 29 | 80
+| 30 | 79
+| 31 | 77
+| 32 | 76
+| 33 | 75
+| 34 | 74
+| 35 | 72
+| 36 | 71
+| 37 | 70
+| 38 | 69
+| 39 | 68
+| 40 | 66
+| 41 | 65
+| 42 | 64
+| 43 | 63
+| 44 | 62
+| 45 | 61
+| 46 | 60
+| 47 | 59
+| 48 | 58
+| 49 | 57
+| 50 | 56
+| 51 | 55
+| 52 | 54
+| 53 | 53
+| 54 | 52
+| 55 | 51
+| 56 | 50
+| 57 | 49
+| 58 | 48
+| 59 | 47
+| 60 | 46
+| 61 | 45
+| 62 | 44
+| 63 | 43
+| 64 | 42
+| 65 | 41
+| 66 | 40
+| 67 | 40
+| 68 | 39
+| 69 | 38
+| 70 | 37
+| 71 | 36
+| 72 | 35
+| 73 | 35
+| 74 | 34
+| 75 | 33
+| 76 | 32
+| 77 | 31
+| 78 | 31
+| 79 | 30
+| 80 | 29
+| 81 | 28
+| 82 | 28
+| 83 | 27
+| 84 | 26
+| 85 | 25
+| 86 | 25
+| 87 | 24
+| 88 | 23
+| 89 | 23
+| 90 | 22
+| 91 | 21
+| 92 | 21
+| 93 | 20
+| 94 | 19
+| 95 | 19
+| 96 | 18
+| 97 | 17
+| 98 | 17
+| 99 | 16
+| 100 | 15
+| 101 | 15
+| 102 | 14
+| 103 | 14
+| 104 | 13
+| 105 | 12
+| 106 | 12
+| 107 | 11
+| 108 | 11
+| 109 | 10
+| 110 | 9
+| 111 | 9
+| 112 | 8
+| 113 | 8
+| 114 | 7
+| 115 | 7
+| 116 | 6
+| 117 | 5
+| 118 | 5
+| 119 | 4
+| 120 | 4
+| 121 | 3
+| 122 | 3
+| 123 | 2
+| 124 | 2
+| 125 | 1
+| 126 | 1
+| 127 | 0
+
+|===
diff --git a/src/images/wavedrom/vfrsqrt7.edn b/src/images/wavedrom/vfrsqrt7.edn
new file mode 100644
index 0000000..ffb7a96
--- /dev/null
+++ b/src/images/wavedrom/vfrsqrt7.edn
@@ -0,0 +1,137 @@
+.vfrsqrt7.v common-case lookup table contents
+[%autowidth,float=center,align=center,options="header"]
+|===
+
+|exp[0] | sig[MSB -: 6] | sig_out[MSB -: 7]
+
+| 0| 0 | 52
+| 0| 1 | 51
+| 0| 2 | 50
+| 0| 3 | 48
+| 0| 4 | 47
+| 0| 5 | 46
+| 0| 6 | 44
+| 0| 7 | 43
+| 0| 8 | 42
+| 0| 9 | 41
+| 0| 10 | 40
+| 0| 11 | 39
+| 0| 12 | 38
+| 0| 13 | 36
+| 0| 14 | 35
+| 0| 15 | 34
+| 0| 16 | 33
+| 0| 17 | 32
+| 0| 18 | 31
+| 0| 19 | 30
+| 0| 20 | 30
+| 0| 21 | 29
+| 0| 22 | 28
+| 0| 23 | 27
+| 0| 24 | 26
+| 0| 25 | 25
+| 0| 26 | 24
+| 0| 27 | 23
+| 0| 28 | 23
+| 0| 29 | 22
+| 0| 30 | 21
+| 0| 31 | 20
+| 0| 32 | 19
+| 0| 33 | 19
+| 0| 34 | 18
+| 0| 35 | 17
+| 0| 36 | 16
+| 0| 37 | 16
+| 0| 38 | 15
+| 0| 39 | 14
+| 0| 40 | 14
+| 0| 41 | 13
+| 0| 42 | 12
+| 0| 43 | 12
+| 0| 44 | 11
+| 0| 45 | 10
+| 0| 46 | 10
+| 0| 47 | 9
+| 0| 48 | 9
+| 0| 49 | 8
+| 0| 50 | 7
+| 0| 51 | 7
+| 0| 52 | 6
+| 0| 53 | 6
+| 0| 54 | 5
+| 0| 55 | 4
+| 0| 56 | 4
+| 0| 57 | 3
+| 0| 58 | 3
+| 0| 59 | 2
+| 0| 60 | 2
+| 0| 61 | 1
+| 0| 62 | 1
+| 0| 63 | 0
+
+| 1| 0 | 127
+| 1| 1 | 125
+| 1| 2 | 123
+| 1| 3 | 121
+| 1| 4 | 119
+| 1| 5 | 118
+| 1| 6 | 116
+| 1| 7 | 114
+| 1| 8 | 113
+| 1| 9 | 111
+| 1| 10 | 109
+| 1| 11 | 108
+| 1| 12 | 106
+| 1| 13 | 105
+| 1| 14 | 103
+| 1| 15 | 102
+| 1| 16 | 100
+| 1| 17 | 99
+| 1| 18 | 97
+| 1| 19 | 96
+| 1| 20 | 95
+| 1| 21 | 93
+| 1| 22 | 92
+| 1| 23 | 91
+| 1| 24 | 90
+| 1| 25 | 88
+| 1| 26 | 87
+| 1| 27 | 86
+| 1| 28 | 85
+| 1| 29 | 84
+| 1| 30 | 83
+| 1| 31 | 82
+| 1| 32 | 80
+| 1| 33 | 79
+| 1| 34 | 78
+| 1| 35 | 77
+| 1| 36 | 76
+| 1| 37 | 75
+| 1| 38 | 74
+| 1| 39 | 73
+| 1| 40 | 72
+| 1| 41 | 71
+| 1| 42 | 70
+| 1| 43 | 70
+| 1| 44 | 69
+| 1| 45 | 68
+| 1| 46 | 67
+| 1| 47 | 66
+| 1| 48 | 65
+| 1| 49 | 64
+| 1| 50 | 63
+| 1| 51 | 63
+| 1| 52 | 62
+| 1| 53 | 61
+| 1| 54 | 60
+| 1| 55 | 59
+| 1| 56 | 59
+| 1| 57 | 58
+| 1| 58 | 57
+| 1| 59 | 56
+| 1| 60 | 56
+| 1| 61 | 55
+| 1| 62 | 54
+| 1| 63 | 53
+
+|===
diff --git a/src/images/wavedrom/vmem-format.edn b/src/images/wavedrom/vmem-format.edn
new file mode 100644
index 0000000..58cc6bf
--- /dev/null
+++ b/src/images/wavedrom/vmem-format.edn
@@ -0,0 +1,108 @@
+Format for Vector Load Instructions under LOAD-FP major opcode
+
+////
+31 29 28 27 26 25 24 20 19 15 14 12 11 7 6 0
+ nf | mew| mop | vm | lumop | rs1 | width | vd |0000111| VL* unit-stride
+ nf | mew| mop | vm | rs2 | rs1 | width | vd |0000111| VLS* strided
+ nf | mew| mop | vm | vs2 | rs1 | width | vd |0000111| VLX* indexed
+ 3 1 2 1 5 5 3 5 7
+////
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x7, attr: 'VL* unit-stride'},
+ {bits: 5, name: 'vd', attr: 'destination of load'},
+ {bits: 3, name: 'width'},
+ {bits: 5, name: 'rs1', attr: 'base address'},
+ {bits: 5, name: 'lumop'},
+ {bits: 1, name: 'vm'},
+ {bits: 2, name: 'mop'},
+ {bits: 1, name: 'mew'},
+ {bits: 3, name: 'nf'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x7, attr: 'VLS* strided'},
+ {bits: 5, name: 'vd', attr: 'destination of load'},
+ {bits: 3, name: 'width'},
+ {bits: 5, name: 'rs1', attr: 'base address'},
+ {bits: 5, name: 'rs2', attr: 'stride'},
+ {bits: 1, name: 'vm'},
+ {bits: 2, name: 'mop'},
+ {bits: 1, name: 'mew'},
+ {bits: 3, name: 'nf'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x7, attr: 'VLX* indexed'},
+ {bits: 5, name: 'vd', attr: 'destination of load'},
+ {bits: 3, name: 'width'},
+ {bits: 5, name: 'rs1', attr: 'base address'},
+ {bits: 5, name: 'vs2', attr: 'address offsets'},
+ {bits: 1, name: 'vm'},
+ {bits: 2, name: 'mop'},
+ {bits: 1, name: 'mew'},
+ {bits: 3, name: 'nf'},
+]}
+....
+Format for Vector Store Instructions under STORE-FP major opcode
+
+////
+31 29 28 27 26 25 24 20 19 15 14 12 11 7 6 0
+ nf | mew| mop | vm | sumop | rs1 | width | vs3 |0100111| VS* unit-stride
+ nf | mew| mop | vm | rs2 | rs1 | width | vs3 |0100111| VSS* strided
+ nf | mew| mop | vm | vs2 | rs1 | width | vs3 |0100111| VSX* indexed
+ 3 1 2 1 5 5 3 5 7
+////
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x27, attr: 'VS* unit-stride'},
+ {bits: 5, name: 'vs3', attr: 'store data'},
+ {bits: 3, name: 'width'},
+ {bits: 5, name: 'rs1', attr: 'base address'},
+ {bits: 5, name: 'sumop'},
+ {bits: 1, name: 'vm'},
+ {bits: 2, name: 'mop'},
+ {bits: 1, name: 'mew'},
+ {bits: 3, name: 'nf'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x27, attr: 'VSS* strided'},
+ {bits: 5, name: 'vs3', attr: 'store data'},
+ {bits: 3, name: 'width'},
+ {bits: 5, name: 'rs1', attr: 'base address'},
+ {bits: 5, name: 'rs2', attr: 'stride'},
+ {bits: 1, name: 'vm'},
+ {bits: 2, name: 'mop'},
+ {bits: 1, name: 'mew'},
+ {bits: 3, name: 'nf'},
+]}
+....
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x27, attr: 'VSX* indexed'},
+ {bits: 5, name: 'vs3', attr: 'store data'},
+ {bits: 3, name: 'width'},
+ {bits: 5, name: 'rs1', attr: 'base address'},
+ {bits: 5, name: 'vs2', attr: 'address offsets'},
+ {bits: 1, name: 'vm'},
+ {bits: 2, name: 'mop'},
+ {bits: 1, name: 'mew'},
+ {bits: 3, name: 'nf'},
+]}
+....
diff --git a/src/images/wavedrom/vtype-format.edn b/src/images/wavedrom/vtype-format.edn
new file mode 100644
index 0000000..9e6ab34
--- /dev/null
+++ b/src/images/wavedrom/vtype-format.edn
@@ -0,0 +1,28 @@
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 3, name: 'vlmul[2:0]'},
+ {bits: 3, name: 'vsew[2:0]'},
+ {bits: 1, name: 'vta'},
+ {bits: 1, name: 'vma'},
+ {bits: 23, name: 'reserved'},
+ {bits: 1, name: 'vill'},
+]}
+....
+
+NOTE: This diagram shows the layout for RV32 systems, whereas in
+general `vill` should be at bit XLEN-1.
+
+.`vtype` register layout
+[cols=">2,4,10"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+| Bits | Name | Description
+
+| XLEN-1 | vill | Illegal value if set
+| XLEN-2:8 | 0 | Reserved if non-zero
+| 7 | vma | Vector mask agnostic
+| 6 | vta | Vector tail agnostic
+| 5:3 | vsew[2:0] | Selected element width (SEW) setting
+| 2:0 | vlmul[2:0] | Vector register group multiplier (LMUL) setting
+|===
diff --git a/src/images/wavedrom/wfi.edn b/src/images/wavedrom/wfi.edn
new file mode 100644
index 0000000..01e3c74
--- /dev/null
+++ b/src/images/wavedrom/wfi.edn
@@ -0,0 +1,13 @@
+//
+
+[wavedrom, ,svg]
+
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7','SYSTEM'],},
+ {bits: 5, name: 'rd', attr: ['5','0'],},
+ {bits: 3, name: 'funct3', attr: ['3','PRIV'],},
+ {bits: 5, name: 'rs1', attr: ['5','0'],},
+ {bits: 12, name: 'funct12', attr: ['12','WFI',]},
+], config: {bits: 32}}
+....
diff --git a/src/images/wavedrom/zifencei-ff.edn b/src/images/wavedrom/zifencei-ff.edn
new file mode 100644
index 0000000..24cf87b
--- /dev/null
+++ b/src/images/wavedrom/zifencei-ff.edn
@@ -0,0 +1,12 @@
+//# 3 "Zifencei" Instruction-Fetch Fence, Version 2.0
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'MISC-MEM']},
+ {bits: 5, name: 'rd', attr: ['5', '0']},
+ {bits: 3, name: 'funct3', attr: ['3', 'FENCE.I']},
+ {bits: 5, name: 'rs1', attr: ['5', '0']},
+ {bits: 12, name: 'funct12', attr: ['12', '0']},
+]}
+....
diff --git a/src/images/wavedrom/zihintpause-hint.edn b/src/images/wavedrom/zihintpause-hint.edn
new file mode 100644
index 0000000..b1812ce
--- /dev/null
+++ b/src/images/wavedrom/zihintpause-hint.edn
@@ -0,0 +1,20 @@
+//# 4 "Zihintpause" Pause Hint, Version 1.0
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: 'MISC-MEM'},
+ {bits: 5, name: 'rd', attr: 0},
+ {bits: 3, name: 'funct3', attr: 'PAUSE'},
+ {bits: 5, name: 'rs1', attr: 0},
+ {bits: 1, name: 'SW', attr: 0},
+ {bits: 1, name: 'SR', attr: 0},
+ {bits: 1, name: 'SO', attr: 0},
+ {bits: 1, name: 'SI', attr: 0},
+ {bits: 1, name: 'PW', attr: 1},
+ {bits: 1, name: 'PR', attr: 0},
+ {bits: 1, name: 'PO', attr: 0},
+ {bits: 1, name: 'PI', attr: 0},
+ {bits: 4, name: 'fm', attr: 0},
+]}
+....
diff --git a/src/index.adoc b/src/index.adoc
new file mode 100644
index 0000000..4abaca2
--- /dev/null
+++ b/src/index.adoc
@@ -0,0 +1,2 @@
+[index]
+== Index
diff --git a/src/indirect-csr.adoc b/src/indirect-csr.adoc
new file mode 100644
index 0000000..adaccbb
--- /dev/null
+++ b/src/indirect-csr.adoc
@@ -0,0 +1,333 @@
+[[indirect-csr]]
+== "Smcsrind/Sscsrind" Indirect CSR Access, Version 1.0
+
+=== Introduction
+
+Smcsrind/Sscsrind is an ISA extension that extends the indirect CSR
+access mechanism originally defined as part of the
+https://github.com/riscv/riscv-aia[[.underline]#Smaia/Ssaia
+extensions#], in order to make it available for use by other extensions
+without creating an unnecessary dependence on Smaia/Ssaia.
+
+This extension confers two benefits:
+
+. It provides a means to access an array of registers via CSRs without
+requiring allocation of large chunks of the limited CSR address space.
+
+. It enables software to access each of an array of registers by index,
+without requiring a switch statement with a case for each register.
+
+[%unbreakable]
+[NOTE]
+====
+CSRs are accessed indirectly via this extension using select values, in
+contrast to being accessed directly using standard CSR numbers. A CSR
+accessible via one method may or may not be accessible via the other
+method. Select values are a separate address space from CSR numbers, and
+from tselect values in the Sdtrig extension. If a CSR is both directly
+and indirectly accessible, the CSR's select value is unrelated to its
+CSR number.
+
+Further, Machine-level and Supervisor-level select values are separate
+address spaces from each other; however, Machine-level and
+Supervisor-level CSRs with the same select value may be defined by an
+extension as partial or full aliases with respect to each other. This
+typically would be done for CSRs that can be delegated from
+Machine-level to Supervisor-level.
+====
+
+The machine-level extension *Smcsrind* encompasses all added CSRs and
+all behavior modifications for a hart, over all privilege levels. For a
+supervisor-level environment, extension *Sscsrind* is essentially the
+same as Smcsrind except excluding the machine-level CSRs and behavior
+not directly visible to supervisor level.
+
+[[body]]
+=== Machine-level CSRs
+
+[width="100%",cols="15%,12%,12%,15%,46%",options="header",]
+|===
+|*Number* |*Privilege* |*Width* |*Name* |*Description*
+|0x350 |MRW |XLEN |`miselect` |Machine indirect register select
+|0x351 |MRW |XLEN |`mireg` |Machine indirect register alias
+|0x352 |MRW |XLEN |`mireg2` |Machine indirect register alias 2
+|0x353 |MRW |XLEN |`mireg3` |Machine indirect register alias 3
+|0x355 |MRW |XLEN |`mireg4` |Machine indirect register alias 4
+|0x356 |MRW |XLEN |`mireg5` |Machine indirect register alias 5
+|0x357 |MRW |XLEN |`mireg6` |Machine indirect register alias 6
+|===
+
+[%unbreakable]
+[NOTE]
+====
+The `mireg*` CSR numbers are not consecutive because miph is CSR number
+0x354.
+====
+
+The CSRs listed in the table above provide a window for accessing
+register state indirectly. The value of `miselect` determines which
+register is accessed upon read or write of each of the machine indirect alias
+CSRs (`mireg*`). `miselect` value ranges are allocated to dependent
+extensions, which specify the register state accessible via each
+`mireg__i__` register, for each `miselect` value. `miselect` is a WARL
+register.
+
+The `miselect` register implements at least enough bits to support all
+implemented `miselect` values (corresponding to the implemented extensions
+that utilize `miselect`/`mireg*` to indirectly access register state). The
+`miselect` register may be read-only zero if there are no extensions
+implemented that utilize it.
+
+Values of `miselect` with the most-significant bit set (bit XLEN - 1 = 1)
+are designated only for custom use, presumably for accessing custom
+registers through the alias CSRs. Values of `miselect` with the
+most-significant bit clear are designated only for standard use and are
+reserved until allocated to a standard architecture extension. If XLEN
+is changed, the most-significant bit of `miselect` moves to the new
+position, retaining its value from before.
+
+[%unbreakable]
+[NOTE]
+====
+An implementation is not required to support any custom values for
+`miselect`.
+====
+
+The behavior upon accessing `mireg*` from M-mode, while `miselect` holds a
+value that is not implemented, is UNSPECIFIED.
+
+[%unbreakable]
+[NOTE]
+====
+It is expected that implementations will typically raise an illegal-instruction
+exception for such accesses, so that, for example, they can
+be identified as software bugs. Platform specs, profile specs, and/or
+the Privileged ISA spec may place more restrictions on behavior for such
+accesses.
+====
+
+Attempts to access `mireg*` while `miselect` holds a number in an allocated
+and implemented range results in a specific behavior that, for each
+combination of `miselect` and `mireg__i__`, is defined by the extension to
+which the `miselect` value is allocated.
+
+[%unbreakable]
+[NOTE]
+====
+Ordinarily, each `mireg`*_i_* will access register state, access
+read-only 0 state, or raise an illegal-instruction exception.
+
+For RV32, if an extension defines an indirectly accessed register as 64 bits wide, it is recommended that the lower 32 bits of the register are accessed through one of `mireg`, `mireg2`, or `mireg3`, while the upper 32 bits are accessed through `mireg4`, `mireg5`, or `mireg6`, respectively.
+====
+
+[%unbreakable]
+[NOTE]
+====
+Six `\*ireg*` registers are defined in order to ensure that the needs of extensions in development are covered, with some room for growth. For example, for an `siselect` value associated with counter X, `sireg`/`sireg2` could be used to access `mhpmcounterX`/`mhpmeventX`, while `sireg4`/`sireg5` could access `mhpmcounterXh`/`mhpmeventXh`. Six `\*ireg*` registers allows for accessing up to 3 CSR arrays per index (`*iselect`) with RV32-only CSRs, or up to 6 CSR arrays per index value without RV32-only CSRs.
+====
+
+=== Supervisor-level CSRs
+
+[width="100%",cols="15%,12%,12%,15%,46%",options="header",]
+|===
+|*Number* |*Privilege* |*Width* |*Name* |*Description*
+|0x150 |SRW |XLEN |`siselect` |Supervisor indirect register select
+|0x151 |SRW |XLEN |`sireg` |Supervisor indirect register alias
+|0x152 |SRW |XLEN |`sireg2` |Supervisor indirect register alias 2
+|0x153 |SRW |XLEN |`sireg3` |Supervisor indirect register alias 3
+|0x155 |SRW |XLEN |`sireg4` |Supervisor indirect register alias 4
+|0x156 |SRW |XLEN |`sireg5` |Supervisor indirect register alias 5
+|0x157 |SRW |XLEN |`sireg6` |Supervisor indirect register alias 6
+|===
+
+The CSRs in the table above are required if S-mode is implemented.
+
+The `siselect` register will support the value range 0..0xFFF at a
+minimum. A future extension may define a value range outside of this
+minimum range. Only if such an extension is implemented will `siselect` be
+required to support larger values.
+
+[%unbreakable]
+[NOTE]
+====
+Requiring a range of 0–0xFFF for `siselect`, even though most or
+all of the space may be reserved or inaccessible, permits M-mode to
+emulate indirectly accessed registers in this implemented range,
+including registers that may be standardized in the future.
+====
+
+Values of `siselect` with the most-significant bit set (bit XLEN - 1 = 1)
+are designated only for custom use, presumably for accessing custom registers through the alias
+CSRs. Values of `siselect` with the most-significant bit clear are
+designated only for standard use and are reserved until allocated to a
+standard architecture extension. If XLEN is changed, the
+most-significant bit of `siselect` moves to the new position, retaining
+its value from before.
+
+The behavior upon accessing `sireg*` from M-mode or S-mode, while `siselect`
+holds a value that is not implemented at supervisor level, is UNSPECIFIED.
+
+[%unbreakable]
+[NOTE]
+====
+It is recommended that implementations raise an illegal-instruction
+exception for such accesses, to facilitate possible emulation (by
+M-mode) of these accesses.
+====
+
+[%unbreakable]
+[NOTE]
+====
+An extension is considered not to be implemented at supervisor level if
+machine level has disabled the extension for S-mode, such as by the
+settings of certain fields in CSR `menvcfg`, for example.
+====
+
+Otherwise, attempts to access `sireg*` from M-mode or S-mode while
+`siselect` holds a number in a standard-defined and implemented range
+result in specific behavior that, for each combination of `siselect` and
+`sireg__i__`, is defined by the extension to which the `siselect` value is
+allocated.
+
+[%unbreakable]
+[NOTE]
+====
+Ordinarily, each `sireg`*_i_* will access register state, access
+read-only 0 state, or, unless executing in a virtual machine (covered in
+the next section), raise an illegal-instruction exception.
+====
+
+Note that the widths of `siselect` and `sireg*` are always the
+current XLEN rather than SXLEN. Hence, for example, if MXLEN = 64 and
+SXLEN = 32, then these registers are 64 bits when the current privilege
+mode is M (running RV64 code) but 32 bits when the privilege mode is S
+(RV32 code).
+
+=== Virtual Supervisor-level CSRs
+
+[width="100%",cols="15%,12%,12%,15%,46%",options="header",]
+|===
+|*Number* |*Privilege* |*Width* |*Name* |*Description*
+|0x250 |HRW |XLEN |`vsiselect` |Virtual supervisor indirect register
+select
+
+|0x251 |HRW |XLEN |`vsireg` |Virtual supervisor indirect register alias
+
+|0x252 |HRW |XLEN |`vsireg2` |Virtual supervisor indirect register alias 2
+
+|0x253 |HRW |XLEN |`vsireg3` |Virtual supervisor indirect register alias 3
+
+|0x255 |HRW |XLEN |`vsireg4` |Virtual supervisor indirect register alias 4
+
+|0x256 |HRW |XLEN |`vsireg5` |Virtual supervisor indirect register alias 5
+
+|0x257 |HRW |XLEN |`vsireg6` |Virtual supervisor indirect register alias 6
+|===
+
+The CSRs in the table above are required if the hypervisor extension is
+implemented. These VS CSRs all match supervisor CSRs, and substitute for
+those supervisor CSRs when executing in a virtual machine (in VS-mode or
+VU-mode).
+
+The `vsiselect` register will support the value range 0..0xFFF at a
+minimum. A future extension may define a value range outside of this
+minimum range. Only if such an extension is implemented will `vsiselect`
+be required to support larger values.
+
+[%unbreakable]
+[NOTE]
+====
+Requiring a range of 0–0xFFF for `vsiselect`, even though most or all of
+the space may be reserved or inaccessible, permits a hypervisor to
+emulate indirectly accessed registers in this implemented range,
+including registers that may be standardized in the future.
+
+More generally it is recommended that `vsiselect` and `siselect` be
+implemented with the same number of bits. This also avoids creation of a
+virtualization hole due to observable differences between `vsiselect` and
+`siselect` widths.
+====
+
+Values of `vsiselect` with the most-significant bit set (bit XLEN - 1 = 1)
+are designated only for custom use, presumably for accessing custom registers through the alias
+CSRs. Values of `vsiselect` with the most-significant bit clear are
+designated only for standard use and are reserved until allocated to a
+standard architecture extension. If XLEN is changed, the
+most-significant bit of `vsiselect` moves to the new position, retaining
+its value from before.
+
+For alias CSRs `sireg*` and `vsireg*`, the hypervisor extension’s usual
+rules for when to raise a virtual-instruction exception (based on
+whether an instruction is HS-qualified) are not applicable. The
+rules given in this section for `sireg` and `vsireg` apply instead, unless
+overridden by the requirements specified in the section below, which
+take precedence over this section when extension Smstateen is also
+implemented.
+
+A virtual-instruction exception is raised for attempts from VS-mode or VU-mode to directly access `vsiselect` or `vsireg*`, or attempts from VU-mode to access `siselect` or `sireg*`.
+
+The behavior upon accessing `vsireg*` from M-mode or HS-mode, or accessing `sireg*` (really `vsireg*`) from VS-mode, while `vsiselect` holds a value that is not implemented at HS level, is UNSPECIFIED.
+
+[%unbreakable]
+[NOTE]
+====
+It is recommended that implementations raise an illegal-instruction exception for such accesses, to facilitate possible emulation (by M-mode) of these accesses.
+====
+
+Otherwise, while `vsiselect` holds a number in a standard-defined and
+implemented range, attempts to access `vsireg*` from a sufficiently
+privileged mode, or to access `sireg*` (really `vsireg*`) from VS-mode,
+result in specific behavior that, for each combination of `vsiselect` and
+`vsireg__i__`, is defined by the extension to which the `vsiselect` value is
+allocated.
+
+[%unbreakable]
+[NOTE]
+====
+Ordinarily, each `vsireg`*_i_* will access register state, access read-only 0 state, or raise an exception (either an illegal-instruction exception or, for select accesses from VS-mode, a virtual-instruction exception). When `vsiselect` holds a value that is implemented at HS level but not at VS level, attempts to access `sireg*` (really `vsireg*`) from VS-mode will typically raise a virtual-instruction exception. But there may be cases specific to an extension where different behavior is more appropriate.
+====
+
+Like `siselect` and `sireg*`, the widths of `vsiselect` and `vsireg*` are always
+the current XLEN rather than VSXLEN. Hence, for example, if HSXLEN = 64
+and VSXLEN = 32, then these registers are 64 bits when accessed by a
+hypervisor in HS-mode (running RV64 code) but 32 bits for a guest OS in
+VS-mode (RV32 code).
+
+=== Access control by the state-enable CSRs
+
+If extension Smstateen is implemented together with Smcsrind, bit 60 of
+state-enable register `mstateen0` controls access to `siselect`, `sireg*`,
+`vsiselect`, and `vsireg*`. When `mstateen0`[60]=0, an attempt to access one
+of these CSRs from a privilege mode less privileged than M-mode results
+in an illegal-instruction exception. As always, the state-enable CSRs do
+not affect the accessibility of any state when in M-mode, only in less
+privileged modes. For more explanation, see the documentation for
+extension
+https://github.com/riscv/riscv-state-enable/releases/download/v1.0.0/Smstateen.pdf[[.underline]#Smstateen#].
+
+Other extensions may specify that certain mstateen bits control access
+to registers accessed indirectly through `siselect` + `sireg*`, and/or
+`vsiselect` + `vsireg*`. However, regardless of any other mstateen bits, if
+`mstateen0`[60] = 1, a virtual-instruction exception is raised as
+described in the previous section for all attempts from VS-mode or
+VU-mode to directly access `vsiselect` or `vsireg*`, and for all attempts
+from VU-mode to access `siselect` or `sireg*`.
+
+If the hypervisor extension is implemented, the same bit is defined also
+in hypervisor CSR `hstateen0`, but controls access to only `siselect` and `sireg*`
+(really `vsiselect` and `vsireg*`), which is the state potentially
+accessible to a virtual machine executing in VS or VU-mode. When
+`hstateen0`[60]=0 and `mstateen0`[60]=1, all attempts from VS or VU-mode to
+access `siselect` or `sireg*` raise a virtual-instruction exception, not an
+illegal-instruction exception, regardless of the value of `vsiselect` or
+any other mstateen bit.
+
+Extension Ssstateen is defined as the supervisor-level view of
+Smstateen. Therefore, the combination of Sscsrind and Ssstateen
+incorporates the bit defined above for `hstateen0` but not that for
+`mstateen0`, since machine-level CSRs are not visible to supervisor level.
+
+[NOTE]
+====
+CSR address space is reserved for a possible future "Sucsrind" extension that extends indirect CSR access to user mode.
+====
diff --git a/src/inkscape/PLIC-block-diagram.svg b/src/inkscape/PLIC-block-diagram.svg
deleted file mode 100644
index 0b84e8f..0000000
--- a/src/inkscape/PLIC-block-diagram.svg
+++ /dev/null
@@ -1,3309 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- version="1.1"
- viewBox="83.59451 42.51969 602.3898 428.53154"
- width="602.3898"
- height="428.53154"
- id="svg879"
- sodipodi:docname="PLIC-block-diagram.svg"
- inkscape:version="0.92.2 5c3e80d, 2017-08-06">
- <metadata
- id="metadata883">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <sodipodi:namedview
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1"
- objecttolerance="10"
- gridtolerance="10"
- guidetolerance="10"
- inkscape:pageopacity="0"
- inkscape:pageshadow="2"
- inkscape:window-width="1116"
- inkscape:window-height="988"
- id="namedview881"
- showgrid="false"
- inkscape:zoom="1.2207894"
- inkscape:cx="261.37251"
- inkscape:cy="376.57502"
- inkscape:window-x="0"
- inkscape:window-y="0"
- inkscape:window-maximized="0"
- inkscape:current-layer="Group_94" />
- <defs
- id="defs17">
- <font-face
- font-family="Helvetica Neue"
- font-size="12"
- panose-1="2 0 5 3 0 0 0 2 0 4"
- units-per-em="1000"
- underline-position="-100"
- underline-thickness="50"
- slope="0"
- x-height="517"
- cap-height="714"
- ascent="951.9958"
- descent="-212.99744"
- font-weight="400"
- id="font-face2">
- <font-face-src>
- <font-face-name
- name="HelveticaNeue" />
- </font-face-src>
- </font-face>
- <marker
- orient="auto"
- overflow="visible"
- markerUnits="strokeWidth"
- id="FilledArrow_Marker"
- stroke-linejoin="miter"
- stroke-miterlimit="10"
- viewBox="-1 -4 10 8"
- markerWidth="10"
- markerHeight="8"
- color="black">
- <g
- id="g6">
- <path
- d="M 8 0 L 0 -3 L 0 3 Z"
- fill="currentColor"
- stroke="currentColor"
- stroke-width="1"
- id="path4" />
- </g>
- </marker>
- <font-face
- font-family="Helvetica Neue"
- font-size="16"
- panose-1="2 0 5 3 0 0 0 2 0 4"
- units-per-em="1000"
- underline-position="-100"
- underline-thickness="50"
- slope="0"
- x-height="517"
- cap-height="714"
- ascent="951.9958"
- descent="-212.99744"
- font-weight="400"
- id="font-face9">
- <font-face-src>
- <font-face-name
- name="HelveticaNeue" />
- </font-face-src>
- </font-face>
- <font-face
- font-family="Helvetica Neue"
- font-size="14"
- panose-1="2 0 5 3 0 0 0 2 0 4"
- units-per-em="1000"
- underline-position="-100"
- underline-thickness="50"
- slope="0"
- x-height="517"
- cap-height="714"
- ascent="951.9958"
- descent="-212.99744"
- font-weight="400"
- id="font-face11">
- <font-face-src>
- <font-face-name
- name="HelveticaNeue" />
- </font-face-src>
- </font-face>
- <font-face
- font-family="Helvetica Neue"
- font-size="96"
- panose-1="2 0 2 6 0 0 0 2 0 4"
- units-per-em="1000"
- underline-position="-100"
- underline-thickness="50"
- slope="0"
- x-height="520"
- cap-height="722"
- ascent="930.9998"
- descent="-212.99744"
- font-weight="200"
- id="font-face13">
- <font-face-src>
- <font-face-name
- name="HelveticaNeue-UltraLight" />
- </font-face-src>
- </font-face>
- <font-face
- font-family="Helvetica Neue"
- font-size="10"
- panose-1="2 0 5 3 0 0 0 2 0 4"
- units-per-em="1000"
- underline-position="-100"
- underline-thickness="50"
- slope="0"
- x-height="517"
- cap-height="714"
- ascent="951.9958"
- descent="-212.99744"
- font-weight="400"
- id="font-face15">
- <font-face-src>
- <font-face-name
- name="HelveticaNeue" />
- </font-face-src>
- </font-face>
- </defs>
- <g
- id="Canvas_1"
- fill-opacity="1"
- stroke-dasharray="none"
- stroke="none"
- stroke-opacity="1"
- fill="none">
- <title
- id="title19">Canvas 1</title>
- <g
- id="Canvas_1: Layer 2">
- <title
- id="title21">Layer 2</title>
- <g
- id="Group_201">
- <g
- id="Group_203">
- <g
- id="Graphic_216">
- <rect
- x="254.44885"
- y="71.69292"
- width="51.02362"
- height="19.842522"
- fill="white"
- id="rect23" />
- <rect
- x="254.44885"
- y="71.69292"
- width="51.02362"
- height="19.842522"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect25" />
- <text
- transform="translate(255.44885 74.44618)"
- fill="black"
- id="text29">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".8538086"
- y="11"
- id="tspan27">Gateway</tspan>
- </text>
- </g>
- <g
- id="Graphic_215">
- <rect
- x="279.96066"
- y="122.71655"
- width="42.51969"
- height="19.842522"
- fill="white"
- id="rect32" />
- <rect
- x="279.96066"
- y="122.71655"
- width="42.51969"
- height="19.842522"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect34" />
- <text
- transform="translate(280.96066 125.46981)"
- fill="black"
- id="text38">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="1.3778449"
- y="11"
- id="tspan36">Priority</tspan>
- </text>
- </g>
- <g
- id="Line_214">
- <line
- x1="277.126"
- y1="182.4016"
- x2="277.126"
- y2="431.69296"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line41" />
- </g>
- <g
- id="Graphic_213">
- <rect
- x="254.44885"
- y="122.71655"
- width="17.007871"
- height="19.842522"
- fill="white"
- id="rect44" />
- <rect
- x="254.44885"
- y="122.71655"
- width="17.007871"
- height="19.842522"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect46" />
- <text
- transform="translate(255.44885 125.46981)"
- fill="black"
- id="text50">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="2.0619356"
- y="11"
- id="tspan48">IP</tspan>
- </text>
- </g>
- <g
- id="Graphic_212">
- <path
- d="M 262.21498 159.40947 L 262.21498 170.90553 C 262.21498 176.65356 266.20484 182.4016 278.17443 182.4016 C 290.14403 182.4016 294.1339 176.65356 294.1339 170.90553 L 294.1339 159.40947 Z"
- fill="white"
- id="path53" />
- <path
- d="M 262.21498 159.40947 L 262.21498 170.90553 C 262.21498 176.65356 266.20484 182.4016 278.17443 182.4016 C 290.14403 182.4016 294.1339 176.65356 294.1339 170.90553 L 294.1339 159.40947 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path55" />
- </g>
- <g
- id="Line_211">
- <line
- x1="288.4646"
- y1="142.55905"
- x2="288.4646"
- y2="159.56692"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line58" />
- </g>
- <g
- id="Line_210">
- <line
- x1="265.78743"
- y1="142.55907"
- x2="265.78743"
- y2="159.56695"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line61" />
- </g>
- <g
- id="Line_209">
- <line
- x1="285.62995"
- y1="153.89765"
- x2="291.29924"
- y2="148.22836"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line64" />
- </g>
- <g
- id="Line_208">
- <line
- x1="274.29137"
- y1="193.5827"
- x2="279.96066"
- y2="187.9134"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line67" />
- </g>
- <g
- id="Line_207">
- <line
- x1="262.9528"
- y1="91.53544"
- x2="262.9528"
- y2="112.31655"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line70" />
- </g>
- <g
- id="Graphic_206">
- <text
- transform="translate(264.20427 91.86744)"
- fill="black"
- id="text75">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".212"
- y="11"
- id="tspan73">Interrupt Request</tspan>
- </text>
- </g>
- <g
- id="Graphic_205">
- <text
- transform="translate(249.44885 42.85169)"
- fill="black"
- id="text80">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".492"
- y="11"
- id="tspan78">Interrupt 2 Signals</tspan>
- </text>
- </g>
- <g
- id="Line_204">
- <line
- x1="279.96066"
- y1="57.51969"
- x2="279.96066"
- y2="61.29292"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line83" />
- </g>
- </g>
- <g
- id="Line_202">
- <line
- x1="277.126"
- y1="431.69296"
- x2="277.126"
- y2="462.0473"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line87" />
- </g>
- </g>
- <g
- id="Group_185">
- <g
- id="Group_187">
- <g
- id="Graphic_200">
- <rect
- x="112.71655"
- y="71.69292"
- width="51.02362"
- height="19.842522"
- fill="white"
- id="rect91" />
- <rect
- x="112.71655"
- y="71.69292"
- width="51.02362"
- height="19.842522"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect93" />
- <text
- transform="translate(113.71655 74.44618)"
- fill="black"
- id="text97">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".8538086"
- y="11"
- id="tspan95">Gateway</tspan>
- </text>
- </g>
- <g
- id="Graphic_199">
- <rect
- x="138.22836"
- y="122.71655"
- width="42.51969"
- height="19.842522"
- fill="white"
- id="rect100" />
- <rect
- x="138.22836"
- y="122.71655"
- width="42.51969"
- height="19.842522"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect102" />
- <text
- transform="translate(139.22836 125.46981)"
- fill="black"
- id="text106">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="1.3778449"
- y="11"
- id="tspan104">Priority</tspan>
- </text>
- </g>
- <g
- id="Line_198">
- <line
- x1="135.39372"
- y1="182.4016"
- x2="135.39372"
- y2="431.69296"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line109" />
- </g>
- <g
- id="Graphic_197">
- <rect
- x="112.71655"
- y="122.71655"
- width="17.007871"
- height="19.842522"
- fill="white"
- id="rect112" />
- <rect
- x="112.71655"
- y="122.71655"
- width="17.007871"
- height="19.842522"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect114" />
- <text
- transform="translate(113.71655 125.46981)"
- fill="black"
- id="text118">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="2.0619356"
- y="11"
- id="tspan116">IP</tspan>
- </text>
- </g>
- <g
- id="Graphic_196">
- <path
- d="M 120.48268 159.40947 L 120.48268 170.90553 C 120.48268 176.65356 124.47254 182.4016 136.44213 182.4016 C 148.41173 182.4016 152.4016 176.65356 152.4016 170.90553 L 152.4016 159.40947 Z"
- fill="white"
- id="path121" />
- <path
- d="M 120.48268 159.40947 L 120.48268 170.90553 C 120.48268 176.65356 124.47254 182.4016 136.44213 182.4016 C 148.41173 182.4016 152.4016 176.65356 152.4016 170.90553 L 152.4016 159.40947 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path123" />
- </g>
- <g
- id="Line_195">
- <line
- x1="146.7323"
- y1="142.55905"
- x2="146.7323"
- y2="159.56692"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line126" />
- </g>
- <g
- id="Line_194">
- <line
- x1="124.05513"
- y1="142.55907"
- x2="124.05513"
- y2="159.56695"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line129" />
- </g>
- <g
- id="Line_193">
- <line
- x1="143.89765"
- y1="153.89765"
- x2="149.56695"
- y2="148.22836"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line132" />
- </g>
- <g
- id="Line_192">
- <line
- x1="132.55907"
- y1="193.5827"
- x2="138.22836"
- y2="187.9134"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line135" />
- </g>
- <g
- id="Line_191">
- <line
- x1="121.22049"
- y1="91.53544"
- x2="121.22049"
- y2="112.31655"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line138" />
- </g>
- <g
- id="Graphic_190">
- <text
- transform="translate(122.47197 91.86744)"
- fill="black"
- id="text143">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".212"
- y="11"
- id="tspan141">Interrupt Request</tspan>
- </text>
- </g>
- <g
- id="Graphic_189">
- <text
- transform="translate(107.71655 42.85169)"
- fill="black"
- id="text148">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".492"
- y="11"
- id="tspan146">Interrupt 1 Signals</tspan>
- </text>
- </g>
- <g
- id="Line_188">
- <line
- x1="138.22836"
- y1="57.51969"
- x2="138.22836"
- y2="61.29292"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line151" />
- </g>
- </g>
- <g
- id="Line_186">
- <line
- x1="135.39372"
- y1="431.69296"
- x2="135.39372"
- y2="462.0473"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line155" />
- </g>
- </g>
- <g
- id="Graphic_184">
- <path
- d="M 84.09451 107.71655 L 561.2599 107.71655 L 561.2599 470.55123 L 84.09451 470.55123 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="20.0,5.0,4.0,5.0"
- stroke-width="1"
- id="path159" />
- <text
- transform="translate(89.09451 447.60324)"
- fill="black"
- id="text163">
- <tspan
- font-family="Helvetica Neue"
- font-size="16"
- font-weight="400"
- fill="black"
- x="393.3894"
- y="15"
- id="tspan161">PLIC Core</tspan>
- </text>
- </g>
- <g
- id="Graphic_183">
- <path
- d="M 84.09451 65.19686 L 561.2599 65.19686 L 561.2599 107.71655 L 84.09451 107.71655 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="20.0,5.0,4.0,5.0"
- stroke-width="1"
- id="path166" />
- <text
- transform="translate(89.09451 84.76855)"
- fill="black"
- id="text170">
- <tspan
- font-family="Helvetica Neue"
- font-size="16"
- font-weight="400"
- fill="black"
- x="356.6694"
- y="15"
- id="tspan168">PLIC Gateways</tspan>
- </text>
- </g>
- <g
- id="Group_93">
- <g
- id="Graphic_182">
- <path
- d="M 90.70867 198.42522 L 555.5906 198.42522 L 555.5906 308.9764 L 90.70867 308.9764 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="1.0,4.0"
- stroke-width="1"
- id="path173" />
- </g>
- <g
- id="Group_94">
- <g
- id="Graphic_181">
- <text
- transform="translate(96.20867 243.41426)"
- fill="black"
- id="text178">
- <tspan
- font-family="Helvetica Neue"
- font-size="14"
- font-weight="400"
- fill="black"
- x=".108"
- y="13"
- id="tspan176">0</tspan>
- </text>
- </g>
- <g
- id="Graphic_180">
- <text
- transform="translate(95.70867 271.76072)"
- fill="black"
- id="text183">
- <tspan
- font-family="Helvetica Neue"
- font-size="14"
- font-weight="400"
- fill="black"
- x="1.029261"
- y="13"
- id="tspan181">0</tspan>
- </text>
- </g>
- <g
- id="Line_179">
- <line
- x1="390.2622"
- y1="249.44885"
- x2="405.3544"
- y2="249.44885"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line186" />
- </g>
- <g
- id="Line_178">
- <line
- x1="248.44885"
- y1="255.11814"
- x2="365.66933"
- y2="255.11814"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line189" />
- </g>
- <g
- id="Line_177">
- <line
- x1="248.44885"
- y1="283.4646"
- x2="377.0079"
- y2="283.4646"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line192" />
- </g>
- <g
- id="Group_159">
- <g
- id="Graphic_176">
- <rect
- x="422.36225"
- y="280.62996"
- width="56.69292"
- height="17.007873"
- fill="white"
- id="rect195" />
- <rect
- x="422.36225"
- y="280.62996"
- width="56.69292"
- height="17.007873"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect197" />
- <text
- transform="translate(423.36225 281.9659)"
- fill="black"
- id="text201">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="8.34446"
- y="11"
- id="tspan199">Max ID</tspan>
- </text>
- </g>
- <g
- id="Graphic_175">
- <rect
- x="422.36225"
- y="260.78743"
- width="56.69292"
- height="17.007873"
- fill="white"
- id="rect204" />
- <rect
- x="422.36225"
- y="260.78743"
- width="56.69292"
- height="17.007873"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect206" />
- <text
- transform="translate(423.36225 262.12337)"
- fill="black"
- id="text210">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".7844599"
- y="11"
- id="tspan208">Threshold</tspan>
- </text>
- </g>
- <g
- id="Graphic_174">
- <rect
- x="422.36225"
- y="240.9449"
- width="56.69292"
- height="17.007873"
- fill="white"
- id="rect213" />
- <rect
- x="422.36225"
- y="240.9449"
- width="56.69292"
- height="17.007873"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect215" />
- <text
- transform="translate(423.36225 242.28085)"
- fill="black"
- id="text219">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="5.23646"
- y="11"
- id="tspan217">Max Pri.</tspan>
- </text>
- </g>
- <g
- id="Graphic_173">
- <rect
- x="527.24415"
- y="249.44885"
- width="22.677168"
- height="19.842522"
- fill="white"
- id="rect222" />
- <rect
- x="527.24415"
- y="249.44885"
- width="22.677168"
- height="19.842522"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect224" />
- <text
- transform="translate(528.24415 252.2021)"
- fill="black"
- id="text228">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="1.230584"
- y="11"
- id="tspan226">EIP</tspan>
- </text>
- </g>
- <g
- id="Graphic_172">
- <path
- d="M 493.2284 241.3701 L 493.2284 277.3701 L 515.9056 270.1701 L 515.9056 248.5701 Z"
- fill="white"
- id="path231" />
- <path
- d="M 493.2284 241.3701 L 493.2284 277.3701 L 515.9056 270.1701 L 515.9056 248.5701 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path233" />
- <text
- transform="translate(494.087 250.59965)"
- fill="black"
- id="text237">
- <tspan
- font-family="Helvetica Neue"
- font-size="16"
- font-weight="400"
- fill="black"
- x="1.952"
- y="15"
- id="tspan235">&gt;?</tspan>
- </text>
- </g>
- <g
- id="Line_171">
- <line
- x1="484.72446"
- y1="253.53622"
- x2="490.39376"
- y2="246.6142"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line240" />
- </g>
- <g
- id="Line_170">
- <line
- x1="479.0552"
- y1="249.44885"
- x2="493.2284"
- y2="249.44885"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line243" />
- </g>
- <g
- id="Line_169">
- <line
- x1="484.72446"
- y1="273.37874"
- x2="490.39376"
- y2="266.45672"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line246" />
- </g>
- <g
- id="Line_168">
- <line
- x1="479.0552"
- y1="269.29137"
- x2="493.2284"
- y2="269.29137"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line249" />
- </g>
- <g
- id="Line_167">
- <line
- x1="515.9056"
- y1="259.3701"
- x2="526.74415"
- y2="259.3701"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line252" />
- </g>
- <g
- id="Graphic_166">
- <rect
- x="527.24415"
- y="249.44885"
- width="22.677168"
- height="19.842522"
- fill="white"
- id="rect255" />
- <rect
- x="527.24415"
- y="249.44885"
- width="22.677168"
- height="19.842522"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect257" />
- <text
- transform="translate(528.24415 252.2021)"
- fill="black"
- id="text261">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="1.230584"
- y="11"
- id="tspan259">EIP</tspan>
- </text>
- </g>
- <g
- id="Line_165">
- <line
- x1="550.4213"
- y1="259.3701"
- x2="568.3678"
- y2="259.3701"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line264" />
- </g>
- <g
- id="Line_164">
- <line
- x1="405.3544"
- y1="249.44885"
- x2="422.36225"
- y2="249.44885"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line267" />
- </g>
- <g
- id="Line_163">
- <path
- d="M 392.18115 289.1339 L 414.959 289.056 L 422.36225 289.1339"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="path270" />
- </g>
- <g
- id="Line_162">
- <line
- x1="479.0552"
- y1="289.1339"
- x2="565.53344"
- y2="289.8145"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line273" />
- </g>
- <g
- id="Graphic_161">
- <text
- transform="translate(572.5985 246.7782)"
- fill="black"
- id="text280">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="11.231783"
- y="11"
- id="tspan276">Interrupt </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="3.461783"
- y="25.336"
- id="tspan278">Notification</tspan>
- </text>
- </g>
- <g
- id="Graphic_160">
- <text
- transform="translate(575.43314 282.96983)"
- fill="black"
- id="text285">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".9531059"
- y="11"
- id="tspan283">Interrupt ID</tspan>
- </text>
- </g>
- </g>
- <g
- id="Graphic_158">
- <text
- transform="translate(626.4568 204.5036)"
- fill="black"
- id="text291">
- <tspan
- font-family="Helvetica Neue"
- font-size="96"
- font-weight="200"
- fill="black"
- x=".016"
- y="89"
- id="tspan289">}</tspan>
- </text>
- </g>
- <g
- id="Graphic_157">
- <text
- transform="translate(643.46464,235.77162)"
- id="text300"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="15.037845"
- y="11"
- id="tspan294"
- style="font-weight:400;font-size:12px;font-family:'Helvetica Neue';fill:#000000">To</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="4.8738451"
- y="25.336"
- id="tspan296"
- style="font-weight:400;font-size:12px;font-family:'Helvetica Neue';fill:#000000">Target</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="17.923845"
- y="39.671997"
- id="tspan298"
- style="font-weight:400;font-size:12px;font-family:'Helvetica Neue';fill:#000000">0</tspan>
- </text>
- </g>
- <g
- id="Group_124">
- <g
- id="Group_154">
- <g
- id="Line_156">
- <line
- x1="248.44885"
- y1="261.04016"
- x2="237.11026"
- y2="261.04016"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line303" />
- </g>
- <g
- id="Line_155">
- <line
- x1="248.44885"
- y1="261.04016"
- x2="248.44885"
- y2="255.11814"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line306" />
- </g>
- </g>
- <g
- id="Group_151">
- <g
- id="Line_153">
- <line
- x1="248.44885"
- y1="289.3866"
- x2="237.11026"
- y2="289.3866"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line310" />
- </g>
- <g
- id="Line_152">
- <line
- x1="248.44885"
- y1="289.3866"
- x2="248.44885"
- y2="283.4646"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line313" />
- </g>
- </g>
- <g
- id="Graphic_150">
- <rect
- x="140.7323"
- y="215.4331"
- width="17.007876"
- height="17.007873"
- fill="white"
- id="rect317" />
- <rect
- x="140.7323"
- y="215.4331"
- width="17.007876"
- height="17.007873"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect319" />
- <text
- transform="translate(141.7323 216.76904)"
- fill="black"
- id="text323">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="2.283938"
- y="11"
- id="tspan321">IE</tspan>
- </text>
- </g>
- <g
- id="Group_146">
- <g
- id="Graphic_149">
- <path
- d="M 163.40947 232.44097 L 174.90553 232.44097 C 180.65356 232.44097 186.4016 228.54333 186.4016 216.85042 C 186.4016 205.1575 180.65356 201.25987 174.90553 201.25987 L 163.40947 201.25987 Z"
- fill="white"
- id="path326" />
- <path
- d="M 163.40947 232.44097 L 174.90553 232.44097 C 180.65356 232.44097 186.4016 228.54333 186.4016 216.85042 C 186.4016 205.1575 180.65356 201.25987 174.90553 201.25987 L 163.40947 201.25987 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path328" />
- </g>
- <g
- id="Line_148">
- <line
- x1="135.063"
- y1="209.7638"
- x2="163.40947"
- y2="209.7638"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line331" />
- </g>
- <g
- id="Line_147">
- <line
- x1="158.24018"
- y1="223.93703"
- x2="163.40947"
- y2="223.93703"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line334" />
- </g>
- </g>
- <g
- id="Graphic_145">
- <path
- d="M 200.25987 210.6142 L 200.25987 246.6142 L 222.93703 239.4142 L 222.93703 217.8142 Z"
- fill="white"
- id="path338" />
- <path
- d="M 200.25987 210.6142 L 200.25987 246.6142 L 222.93703 239.4142 L 222.93703 217.8142 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path340" />
- <text
- transform="translate(201.11845 219.84375)"
- fill="black"
- id="text344">
- <tspan
- font-family="Helvetica Neue"
- font-size="16"
- font-weight="400"
- fill="black"
- x="1.952"
- y="15"
- id="tspan342">&gt;?</tspan>
- </text>
- </g>
- <g
- id="Line_144">
- <line
- x1="106.71655"
- y1="255.11814"
- x2="222.93703"
- y2="255.11814"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line347" />
- </g>
- <g
- id="Line_143">
- <line
- x1="106.71655"
- y1="283.4646"
- x2="234.27562"
- y2="283.4646"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line350" />
- </g>
- <g
- id="Line_142">
- <line
- x1="135.063"
- y1="266.45672"
- x2="222.93703"
- y2="266.45672"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line353" />
- </g>
- <g
- id="Line_141">
- <line
- x1="211.59845"
- y1="297.63783"
- x2="222.93703"
- y2="297.63783"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line356" />
- </g>
- <g
- id="Line_140">
- <line
- x1="188.92128"
- y1="240.9449"
- x2="200.25987"
- y2="240.9449"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line359" />
- </g>
- <g
- id="Line_139">
- <line
- x1="188.92128"
- y1="240.9449"
- x2="188.92128"
- y2="254.20082"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line362" />
- </g>
- <g
- id="Graphic_138">
- <text
- transform="translate(199.9331 288.7966)"
- fill="black"
- id="text367">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".164"
- y="11"
- id="tspan365">1</tspan>
- </text>
- </g>
- <g
- id="Line_137">
- <path
- d="M 222.93703 228.6142 L 228.60632 228.6142 L 228.60632 283.4646"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path370" />
- </g>
- <g
- id="Group_133">
- <g
- id="Graphic_136">
- <path
- d="M 222.93703 277.7953 L 222.93703 303.30712 L 237.11026 298.20476 L 237.11026 282.89767 Z"
- fill="white"
- id="path373" />
- <path
- d="M 222.93703 277.7953 L 222.93703 303.30712 L 237.11026 298.20476 L 237.11026 282.89767 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path375" />
- </g>
- <g
- id="Graphic_135">
- <text
- transform="translate(224.07082 277.8246)"
- fill="black"
- id="text380">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan378">0</tspan>
- </text>
- </g>
- <g
- id="Graphic_134">
- <text
- transform="translate(224.07082 289.8246)"
- fill="black"
- id="text385">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan383">1</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_129">
- <g
- id="Graphic_132">
- <path
- d="M 222.93703 246.94488 L 222.93703 272.4567 L 237.11026 267.35433 L 237.11026 252.04724 Z"
- fill="white"
- id="path389" />
- <path
- d="M 222.93703 246.94488 L 222.93703 272.4567 L 237.11026 267.35433 L 237.11026 252.04724 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path391" />
- </g>
- <g
- id="Graphic_131">
- <text
- transform="translate(224.07082 246.97417)"
- fill="black"
- id="text396">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan394">0</tspan>
- </text>
- </g>
- <g
- id="Graphic_130">
- <text
- transform="translate(224.07082 258.97417)"
- fill="black"
- id="text401">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan399">1</tspan>
- </text>
- </g>
- </g>
- <g
- id="Line_128">
- <line
- x1="188.92128"
- y1="221.1024"
- x2="194.59057"
- y2="214.18037"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line405" />
- </g>
- <g
- id="Line_127">
- <line
- x1="239.9449"
- y1="264.8748"
- x2="245.6142"
- y2="257.9528"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line408" />
- </g>
- <g
- id="Line_126">
- <line
- x1="239.9449"
- y1="291.96854"
- x2="245.6142"
- y2="285.04652"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line411" />
- </g>
- <g
- id="Line_125">
- <line
- x1="186.4016"
- y1="218.26774"
- x2="200.25987"
- y2="218.26774"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line414" />
- </g>
- </g>
- <g
- id="Group_95">
- <g
- id="Group_121">
- <g
- id="Line_123">
- <line
- x1="390.2622"
- y1="260.22113"
- x2="379.84256"
- y2="260.22113"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line418" />
- </g>
- <g
- id="Line_122">
- <line
- x1="390.2622"
- y1="260.22113"
- x2="390.2622"
- y2="249.44885"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line421" />
- </g>
- </g>
- <g
- id="Graphic_120">
- <rect
- x="283.4646"
- y="215.4331"
- width="17.007876"
- height="17.007873"
- fill="white"
- id="rect425" />
- <rect
- x="283.4646"
- y="215.4331"
- width="17.007876"
- height="17.007873"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect427" />
- <text
- transform="translate(284.4646 216.76904)"
- fill="black"
- id="text431">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="2.283938"
- y="11"
- id="tspan429">IE</tspan>
- </text>
- </g>
- <g
- id="Group_116">
- <g
- id="Graphic_119">
- <path
- d="M 306.14177 232.44097 L 317.63783 232.44097 C 323.38586 232.44097 329.1339 228.54333 329.1339 216.85042 C 329.1339 205.1575 323.38586 201.25987 317.63783 201.25987 L 306.14177 201.25987 Z"
- fill="white"
- id="path434" />
- <path
- d="M 306.14177 232.44097 L 317.63783 232.44097 C 323.38586 232.44097 329.1339 228.54333 329.1339 216.85042 C 329.1339 205.1575 323.38586 201.25987 317.63783 201.25987 L 306.14177 201.25987 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path436" />
- </g>
- <g
- id="Line_118">
- <line
- x1="277.7953"
- y1="209.7638"
- x2="306.14177"
- y2="209.7638"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line439" />
- </g>
- <g
- id="Line_117">
- <line
- x1="300.97247"
- y1="223.93703"
- x2="306.14177"
- y2="223.93703"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line442" />
- </g>
- </g>
- <g
- id="Graphic_115">
- <path
- d="M 342.99216 210.6142 L 342.99216 246.6142 L 365.66933 239.4142 L 365.66933 217.8142 Z"
- fill="white"
- id="path446" />
- <path
- d="M 342.99216 210.6142 L 342.99216 246.6142 L 365.66933 239.4142 L 365.66933 217.8142 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path448" />
- <text
- transform="translate(343.85075 219.84375)"
- fill="black"
- id="text452">
- <tspan
- font-family="Helvetica Neue"
- font-size="16"
- font-weight="400"
- fill="black"
- x="1.952"
- y="15"
- id="tspan450">&gt;?</tspan>
- </text>
- </g>
- <g
- id="Line_114">
- <line
- x1="277.7953"
- y1="266.45672"
- x2="365.66933"
- y2="266.45672"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line455" />
- </g>
- <g
- id="Line_113">
- <line
- x1="354.33075"
- y1="297.63783"
- x2="365.66933"
- y2="297.63783"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line458" />
- </g>
- <g
- id="Line_112">
- <line
- x1="331.6536"
- y1="240.9449"
- x2="342.99216"
- y2="240.9449"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line461" />
- </g>
- <g
- id="Line_111">
- <line
- x1="331.6536"
- y1="240.9449"
- x2="331.6536"
- y2="254.20082"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line464" />
- </g>
- <g
- id="Graphic_110">
- <text
- transform="translate(342.6654 288.7966)"
- fill="black"
- id="text469">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".164"
- y="11"
- id="tspan467">2</tspan>
- </text>
- </g>
- <g
- id="Line_109">
- <path
- d="M 365.66933 228.6142 L 371.33862 228.6142 L 371.33862 283.4646"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path472" />
- </g>
- <g
- id="Group_105">
- <g
- id="Graphic_108">
- <path
- d="M 365.66933 277.7953 L 365.66933 303.30712 L 379.84256 298.20476 L 379.84256 282.89767 Z"
- fill="white"
- id="path475" />
- <path
- d="M 365.66933 277.7953 L 365.66933 303.30712 L 379.84256 298.20476 L 379.84256 282.89767 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path477" />
- </g>
- <g
- id="Graphic_107">
- <text
- transform="translate(366.8031 277.8246)"
- fill="black"
- id="text482">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan480">0</tspan>
- </text>
- </g>
- <g
- id="Graphic_106">
- <text
- transform="translate(366.8031 289.8246)"
- fill="black"
- id="text487">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan485">1</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_101">
- <g
- id="Graphic_104">
- <path
- d="M 365.66933 246.94488 L 365.66933 272.4567 L 379.84256 267.35433 L 379.84256 252.04724 Z"
- fill="white"
- id="path491" />
- <path
- d="M 365.66933 246.94488 L 365.66933 272.4567 L 379.84256 267.35433 L 379.84256 252.04724 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path493" />
- </g>
- <g
- id="Graphic_103">
- <text
- transform="translate(366.8031 246.97417)"
- fill="black"
- id="text498">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan496">0</tspan>
- </text>
- </g>
- <g
- id="Graphic_102">
- <text
- transform="translate(366.8031 258.97417)"
- fill="black"
- id="text503">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan501">1</tspan>
- </text>
- </g>
- </g>
- <g
- id="Line_100">
- <line
- x1="331.6536"
- y1="221.1024"
- x2="337.32287"
- y2="214.18037"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line507" />
- </g>
- <g
- id="Line_99">
- <line
- x1="382.6772"
- y1="264.8748"
- x2="388.3465"
- y2="257.9528"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line510" />
- </g>
- <g
- id="Line_98">
- <line
- x1="382.6772"
- y1="291.96854"
- x2="388.3465"
- y2="285.04652"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line513" />
- </g>
- <g
- id="Line_97">
- <line
- x1="329.1339"
- y1="218.26774"
- x2="342.99216"
- y2="218.26774"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line516" />
- </g>
- <g
- id="Line_96">
- <line
- x1="379.84256"
- y1="289.1339"
- x2="392.18115"
- y2="289.1339"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line519" />
- </g>
- </g>
- </g>
- </g>
- <g
- id="Group_3">
- <g
- id="Graphic_92">
- <path
- d="M 90.70867 308.9764 L 555.5906 308.9764 L 555.5906 419.5276 L 90.70867 419.5276 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="1.0,4.0"
- stroke-width="1"
- id="path525" />
- </g>
- <g
- id="Group_4">
- <g
- id="Graphic_91">
- <text
- transform="translate(96.20867 353.96546)"
- fill="black"
- id="text530">
- <tspan
- font-family="Helvetica Neue"
- font-size="14"
- font-weight="400"
- fill="black"
- x=".108"
- y="13"
- id="tspan528">0</tspan>
- </text>
- </g>
- <g
- id="Graphic_90">
- <text
- transform="translate(95.70867 382.3119)"
- fill="black"
- id="text535">
- <tspan
- font-family="Helvetica Neue"
- font-size="14"
- font-weight="400"
- fill="black"
- x="1.029261"
- y="13"
- id="tspan533">0</tspan>
- </text>
- </g>
- <g
- id="Line_89">
- <line
- x1="390.2622"
- y1="360.00004"
- x2="405.3544"
- y2="360.00004"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line538" />
- </g>
- <g
- id="Line_88">
- <line
- x1="248.44885"
- y1="365.66933"
- x2="365.66933"
- y2="365.66933"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line541" />
- </g>
- <g
- id="Line_87">
- <line
- x1="248.44885"
- y1="394.0158"
- x2="377.0079"
- y2="394.0158"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line544" />
- </g>
- <g
- id="Group_69">
- <g
- id="Graphic_86">
- <rect
- x="422.36225"
- y="391.18115"
- width="56.69292"
- height="17.007873"
- fill="white"
- id="rect547" />
- <rect
- x="422.36225"
- y="391.18115"
- width="56.69292"
- height="17.007873"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect549" />
- <text
- transform="translate(423.36225 392.5171)"
- fill="black"
- id="text553">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="8.34446"
- y="11"
- id="tspan551">Max ID</tspan>
- </text>
- </g>
- <g
- id="Graphic_85">
- <rect
- x="422.36225"
- y="371.33863"
- width="56.69292"
- height="17.007873"
- fill="white"
- id="rect556" />
- <rect
- x="422.36225"
- y="371.33863"
- width="56.69292"
- height="17.007873"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect558" />
- <text
- transform="translate(423.36225 372.67456)"
- fill="black"
- id="text562">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".7844599"
- y="11"
- id="tspan560">Threshold</tspan>
- </text>
- </g>
- <g
- id="Graphic_84">
- <rect
- x="422.36225"
- y="351.4961"
- width="56.69292"
- height="17.007873"
- fill="white"
- id="rect565" />
- <rect
- x="422.36225"
- y="351.4961"
- width="56.69292"
- height="17.007873"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect567" />
- <text
- transform="translate(423.36225 352.83204)"
- fill="black"
- id="text571">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="5.23646"
- y="11"
- id="tspan569">Max Pri.</tspan>
- </text>
- </g>
- <g
- id="Graphic_83">
- <rect
- x="527.24415"
- y="360.00004"
- width="22.677168"
- height="19.842522"
- fill="white"
- id="rect574" />
- <rect
- x="527.24415"
- y="360.00004"
- width="22.677168"
- height="19.842522"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect576" />
- <text
- transform="translate(528.24415 362.7533)"
- fill="black"
- id="text580">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="1.230584"
- y="11"
- id="tspan578">EIP</tspan>
- </text>
- </g>
- <g
- id="Graphic_82">
- <path
- d="M 493.2284 351.9213 L 493.2284 387.9213 L 515.9056 380.7213 L 515.9056 359.1213 Z"
- fill="white"
- id="path583" />
- <path
- d="M 493.2284 351.9213 L 493.2284 387.9213 L 515.9056 380.7213 L 515.9056 359.1213 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path585" />
- <text
- transform="translate(494.087 361.15085)"
- fill="black"
- id="text589">
- <tspan
- font-family="Helvetica Neue"
- font-size="16"
- font-weight="400"
- fill="black"
- x="1.952"
- y="15"
- id="tspan587">&gt;?</tspan>
- </text>
- </g>
- <g
- id="Line_81">
- <line
- x1="484.72446"
- y1="364.0874"
- x2="490.39376"
- y2="357.1654"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line592" />
- </g>
- <g
- id="Line_80">
- <line
- x1="479.0552"
- y1="360.00004"
- x2="493.2284"
- y2="360.00004"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line595" />
- </g>
- <g
- id="Line_79">
- <line
- x1="484.72446"
- y1="383.92993"
- x2="490.39376"
- y2="377.0079"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line598" />
- </g>
- <g
- id="Line_78">
- <line
- x1="479.0552"
- y1="379.84256"
- x2="493.2284"
- y2="379.84256"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line601" />
- </g>
- <g
- id="Line_77">
- <line
- x1="515.9056"
- y1="369.9213"
- x2="526.74415"
- y2="369.9213"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line604" />
- </g>
- <g
- id="Graphic_76">
- <rect
- x="527.24415"
- y="360.00004"
- width="22.677168"
- height="19.842522"
- fill="white"
- id="rect607" />
- <rect
- x="527.24415"
- y="360.00004"
- width="22.677168"
- height="19.842522"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect609" />
- <text
- transform="translate(528.24415 362.7533)"
- fill="black"
- id="text613">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="1.230584"
- y="11"
- id="tspan611">EIP</tspan>
- </text>
- </g>
- <g
- id="Line_75">
- <line
- x1="550.4213"
- y1="369.9213"
- x2="568.3678"
- y2="369.9213"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line616" />
- </g>
- <g
- id="Line_74">
- <line
- x1="405.3544"
- y1="360.00004"
- x2="422.36225"
- y2="360.00004"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line619" />
- </g>
- <g
- id="Line_73">
- <path
- d="M 392.18115 399.6851 L 414.959 399.6072 L 422.36225 399.6851"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="path622" />
- </g>
- <g
- id="Line_72">
- <line
- x1="479.0552"
- y1="399.6851"
- x2="565.53344"
- y2="400.3657"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line625" />
- </g>
- <g
- id="Graphic_71">
- <text
- transform="translate(572.5985 357.3294)"
- fill="black"
- id="text632">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="11.231783"
- y="11"
- id="tspan628">Interrupt </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="3.461783"
- y="25.336"
- id="tspan630">Notification</tspan>
- </text>
- </g>
- <g
- id="Graphic_70">
- <text
- transform="translate(575.43314 393.521)"
- fill="black"
- id="text637">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".9531059"
- y="11"
- id="tspan635">Interrupt ID</tspan>
- </text>
- </g>
- </g>
- <g
- id="Graphic_68">
- <text
- transform="translate(626.4568 315.0548)"
- fill="black"
- id="text643">
- <tspan
- font-family="Helvetica Neue"
- font-size="96"
- font-weight="200"
- fill="black"
- x=".016"
- y="89"
- id="tspan641">}</tspan>
- </text>
- </g>
- <g
- id="Graphic_67">
- <text
- transform="translate(643.46464 346.3228)"
- fill="black"
- id="text652">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="15.037845"
- y="11"
- id="tspan646">To </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="4.873845"
- y="25.336"
- id="tspan648">Target </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="17.923845"
- y="39.671997"
- id="tspan650">1</tspan>
- </text>
- </g>
- <g
- id="Group_34">
- <g
- id="Group_64">
- <g
- id="Line_66">
- <line
- x1="248.44885"
- y1="371.59135"
- x2="237.11026"
- y2="371.59135"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line655" />
- </g>
- <g
- id="Line_65">
- <line
- x1="248.44885"
- y1="371.59135"
- x2="248.44885"
- y2="365.66933"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line658" />
- </g>
- </g>
- <g
- id="Group_61">
- <g
- id="Line_63">
- <line
- x1="248.44885"
- y1="399.9378"
- x2="237.11026"
- y2="399.9378"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line662" />
- </g>
- <g
- id="Line_62">
- <line
- x1="248.44885"
- y1="399.9378"
- x2="248.44885"
- y2="394.0158"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line665" />
- </g>
- </g>
- <g
- id="Graphic_60">
- <rect
- x="140.7323"
- y="325.9843"
- width="17.007876"
- height="17.007873"
- fill="white"
- id="rect669" />
- <rect
- x="140.7323"
- y="325.9843"
- width="17.007876"
- height="17.007873"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect671" />
- <text
- transform="translate(141.7323 327.32023)"
- fill="black"
- id="text675">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="2.283938"
- y="11"
- id="tspan673">IE</tspan>
- </text>
- </g>
- <g
- id="Group_56">
- <g
- id="Graphic_59">
- <path
- d="M 163.40947 342.99216 L 174.90553 342.99216 C 180.65356 342.99216 186.4016 339.09453 186.4016 327.4016 C 186.4016 315.7087 180.65356 311.81106 174.90553 311.81106 L 163.40947 311.81106 Z"
- fill="white"
- id="path678" />
- <path
- d="M 163.40947 342.99216 L 174.90553 342.99216 C 180.65356 342.99216 186.4016 339.09453 186.4016 327.4016 C 186.4016 315.7087 180.65356 311.81106 174.90553 311.81106 L 163.40947 311.81106 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path680" />
- </g>
- <g
- id="Line_58">
- <line
- x1="135.063"
- y1="320.315"
- x2="163.40947"
- y2="320.315"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line683" />
- </g>
- <g
- id="Line_57">
- <line
- x1="158.24018"
- y1="334.48823"
- x2="163.40947"
- y2="334.48823"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line686" />
- </g>
- </g>
- <g
- id="Graphic_55">
- <path
- d="M 200.25987 321.1654 L 200.25987 357.1654 L 222.93703 349.9654 L 222.93703 328.3654 Z"
- fill="white"
- id="path690" />
- <path
- d="M 200.25987 321.1654 L 200.25987 357.1654 L 222.93703 349.9654 L 222.93703 328.3654 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path692" />
- <text
- transform="translate(201.11845 330.39494)"
- fill="black"
- id="text696">
- <tspan
- font-family="Helvetica Neue"
- font-size="16"
- font-weight="400"
- fill="black"
- x="1.952"
- y="15"
- id="tspan694">&gt;?</tspan>
- </text>
- </g>
- <g
- id="Line_54">
- <line
- x1="106.71655"
- y1="365.66933"
- x2="222.93703"
- y2="365.66933"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line699" />
- </g>
- <g
- id="Line_53">
- <line
- x1="106.71655"
- y1="394.0158"
- x2="234.27562"
- y2="394.0158"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line702" />
- </g>
- <g
- id="Line_52">
- <line
- x1="135.063"
- y1="377.0079"
- x2="222.93703"
- y2="377.0079"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line705" />
- </g>
- <g
- id="Line_51">
- <line
- x1="211.59845"
- y1="408.189"
- x2="222.93703"
- y2="408.189"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line708" />
- </g>
- <g
- id="Line_50">
- <line
- x1="188.92128"
- y1="351.4961"
- x2="200.25987"
- y2="351.4961"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line711" />
- </g>
- <g
- id="Line_49">
- <line
- x1="188.92128"
- y1="351.4961"
- x2="188.92128"
- y2="364.752"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line714" />
- </g>
- <g
- id="Graphic_48">
- <text
- transform="translate(199.9331 399.3478)"
- fill="black"
- id="text719">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".164"
- y="11"
- id="tspan717">1</tspan>
- </text>
- </g>
- <g
- id="Line_47">
- <path
- d="M 222.93703 339.1654 L 228.60632 339.1654 L 228.60632 394.0158"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path722" />
- </g>
- <g
- id="Group_43">
- <g
- id="Graphic_46">
- <path
- d="M 222.93703 388.3465 L 222.93703 413.8583 L 237.11026 408.75595 L 237.11026 393.44886 Z"
- fill="white"
- id="path725" />
- <path
- d="M 222.93703 388.3465 L 222.93703 413.8583 L 237.11026 408.75595 L 237.11026 393.44886 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path727" />
- </g>
- <g
- id="Graphic_45">
- <text
- transform="translate(224.07082 388.3758)"
- fill="black"
- id="text732">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan730">0</tspan>
- </text>
- </g>
- <g
- id="Graphic_44">
- <text
- transform="translate(224.07082 400.3758)"
- fill="black"
- id="text737">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan735">1</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_39">
- <g
- id="Graphic_42">
- <path
- d="M 222.93703 357.49607 L 222.93703 383.0079 L 237.11026 377.9055 L 237.11026 362.59843 Z"
- fill="white"
- id="path741" />
- <path
- d="M 222.93703 357.49607 L 222.93703 383.0079 L 237.11026 377.9055 L 237.11026 362.59843 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path743" />
- </g>
- <g
- id="Graphic_41">
- <text
- transform="translate(224.07082 357.52536)"
- fill="black"
- id="text748">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan746">0</tspan>
- </text>
- </g>
- <g
- id="Graphic_40">
- <text
- transform="translate(224.07082 369.52536)"
- fill="black"
- id="text753">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan751">1</tspan>
- </text>
- </g>
- </g>
- <g
- id="Line_38">
- <line
- x1="188.92128"
- y1="331.6536"
- x2="194.59057"
- y2="324.73156"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line757" />
- </g>
- <g
- id="Line_37">
- <line
- x1="239.9449"
- y1="375.426"
- x2="245.6142"
- y2="368.504"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line760" />
- </g>
- <g
- id="Line_36">
- <line
- x1="239.9449"
- y1="402.51973"
- x2="245.6142"
- y2="395.5977"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line763" />
- </g>
- <g
- id="Line_35">
- <line
- x1="186.4016"
- y1="328.81893"
- x2="200.25987"
- y2="328.81893"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line766" />
- </g>
- </g>
- <g
- id="Group_5">
- <g
- id="Group_31">
- <g
- id="Line_33">
- <line
- x1="390.2622"
- y1="370.77233"
- x2="379.84256"
- y2="370.77233"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line770" />
- </g>
- <g
- id="Line_32">
- <line
- x1="390.2622"
- y1="370.77233"
- x2="390.2622"
- y2="360.00004"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line773" />
- </g>
- </g>
- <g
- id="Graphic_30">
- <rect
- x="283.4646"
- y="325.9843"
- width="17.007876"
- height="17.007873"
- fill="white"
- id="rect777" />
- <rect
- x="283.4646"
- y="325.9843"
- width="17.007876"
- height="17.007873"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="rect779" />
- <text
- transform="translate(284.4646 327.32023)"
- fill="black"
- id="text783">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="2.283938"
- y="11"
- id="tspan781">IE</tspan>
- </text>
- </g>
- <g
- id="Group_26">
- <g
- id="Graphic_29">
- <path
- d="M 306.14177 342.99216 L 317.63783 342.99216 C 323.38586 342.99216 329.1339 339.09453 329.1339 327.4016 C 329.1339 315.7087 323.38586 311.81106 317.63783 311.81106 L 306.14177 311.81106 Z"
- fill="white"
- id="path786" />
- <path
- d="M 306.14177 342.99216 L 317.63783 342.99216 C 323.38586 342.99216 329.1339 339.09453 329.1339 327.4016 C 329.1339 315.7087 323.38586 311.81106 317.63783 311.81106 L 306.14177 311.81106 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path788" />
- </g>
- <g
- id="Line_28">
- <line
- x1="277.7953"
- y1="320.315"
- x2="306.14177"
- y2="320.315"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line791" />
- </g>
- <g
- id="Line_27">
- <line
- x1="300.97247"
- y1="334.48823"
- x2="306.14177"
- y2="334.48823"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line794" />
- </g>
- </g>
- <g
- id="Graphic_25">
- <path
- d="M 342.99216 321.1654 L 342.99216 357.1654 L 365.66933 349.9654 L 365.66933 328.3654 Z"
- fill="white"
- id="path798" />
- <path
- d="M 342.99216 321.1654 L 342.99216 357.1654 L 365.66933 349.9654 L 365.66933 328.3654 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path800" />
- <text
- transform="translate(343.85075 330.39494)"
- fill="black"
- id="text804">
- <tspan
- font-family="Helvetica Neue"
- font-size="16"
- font-weight="400"
- fill="black"
- x="1.952"
- y="15"
- id="tspan802">&gt;?</tspan>
- </text>
- </g>
- <g
- id="Line_24">
- <line
- x1="277.7953"
- y1="377.0079"
- x2="365.66933"
- y2="377.0079"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line807" />
- </g>
- <g
- id="Line_23">
- <line
- x1="354.33075"
- y1="408.189"
- x2="365.66933"
- y2="408.189"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line810" />
- </g>
- <g
- id="Line_22">
- <line
- x1="331.6536"
- y1="351.4961"
- x2="342.99216"
- y2="351.4961"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line813" />
- </g>
- <g
- id="Line_21">
- <line
- x1="331.6536"
- y1="351.4961"
- x2="331.6536"
- y2="364.752"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line816" />
- </g>
- <g
- id="Graphic_20">
- <text
- transform="translate(342.6654 399.3478)"
- fill="black"
- id="text821">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x=".164"
- y="11"
- id="tspan819">2</tspan>
- </text>
- </g>
- <g
- id="Line_19">
- <path
- d="M 365.66933 339.1654 L 371.33862 339.1654 L 371.33862 394.0158"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path824" />
- </g>
- <g
- id="Group_15">
- <g
- id="Graphic_18">
- <path
- d="M 365.66933 388.3465 L 365.66933 413.8583 L 379.84256 408.75595 L 379.84256 393.44886 Z"
- fill="white"
- id="path827" />
- <path
- d="M 365.66933 388.3465 L 365.66933 413.8583 L 379.84256 408.75595 L 379.84256 393.44886 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path829" />
- </g>
- <g
- id="Graphic_17">
- <text
- transform="translate(366.8031 388.3758)"
- fill="black"
- id="text834">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan832">0</tspan>
- </text>
- </g>
- <g
- id="Graphic_16">
- <text
- transform="translate(366.8031 400.3758)"
- fill="black"
- id="text839">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan837">1</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_11">
- <g
- id="Graphic_14">
- <path
- d="M 365.66933 357.49607 L 365.66933 383.0079 L 379.84256 377.9055 L 379.84256 362.59843 Z"
- fill="white"
- id="path843" />
- <path
- d="M 365.66933 357.49607 L 365.66933 383.0079 L 379.84256 377.9055 L 379.84256 362.59843 Z"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="path845" />
- </g>
- <g
- id="Graphic_13">
- <text
- transform="translate(366.8031 357.52536)"
- fill="black"
- id="text850">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan848">0</tspan>
- </text>
- </g>
- <g
- id="Graphic_12">
- <text
- transform="translate(366.8031 369.52536)"
- fill="black"
- id="text855">
- <tspan
- font-family="Helvetica Neue"
- font-size="10"
- font-weight="400"
- fill="black"
- x=".22"
- y="10"
- id="tspan853">1</tspan>
- </text>
- </g>
- </g>
- <g
- id="Line_10">
- <line
- x1="331.6536"
- y1="331.6536"
- x2="337.32287"
- y2="324.73156"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line859" />
- </g>
- <g
- id="Line_9">
- <line
- x1="382.6772"
- y1="375.426"
- x2="388.3465"
- y2="368.504"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line862" />
- </g>
- <g
- id="Line_8">
- <line
- x1="382.6772"
- y1="402.51973"
- x2="388.3465"
- y2="395.5977"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line865" />
- </g>
- <g
- id="Line_7">
- <line
- x1="329.1339"
- y1="328.81893"
- x2="342.99216"
- y2="328.81893"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line868" />
- </g>
- <g
- id="Line_6">
- <line
- x1="379.84256"
- y1="399.6851"
- x2="392.18115"
- y2="399.6851"
- stroke="black"
- stroke-linecap="butt"
- stroke-linejoin="miter"
- stroke-width="1"
- id="line871" />
- </g>
- </g>
- </g>
- </g>
- </g>
- </g>
-</svg>
diff --git a/src/inkscape/PLIC-interrupt-flow.svg b/src/inkscape/PLIC-interrupt-flow.svg
deleted file mode 100644
index d6c9497..0000000
--- a/src/inkscape/PLIC-interrupt-flow.svg
+++ /dev/null
@@ -1,775 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- version="1.1"
- viewBox="34.01575 51.02363 371.33862 380.34256"
- width="371.33862"
- height="380.34256"
- id="svg179"
- sodipodi:docname="PLIC-interrupt-flow.svg"
- inkscape:version="0.92.2 5c3e80d, 2017-08-06">
- <metadata
- id="metadata183">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <sodipodi:namedview
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1"
- objecttolerance="10"
- gridtolerance="10"
- guidetolerance="10"
- inkscape:pageopacity="0"
- inkscape:pageshadow="2"
- inkscape:window-width="1124"
- inkscape:window-height="798"
- id="namedview181"
- showgrid="false"
- inkscape:zoom="1.75502"
- inkscape:cx="185.66931"
- inkscape:cy="190.17128"
- inkscape:window-x="298"
- inkscape:window-y="316"
- inkscape:window-maximized="0"
- inkscape:current-layer="Canvas_1: Layer 2" />
- <defs
- id="defs13">
- <font-face
- font-family="Helvetica Neue"
- font-size="12"
- panose-1="2 0 5 3 0 0 0 2 0 4"
- units-per-em="1000"
- underline-position="-100"
- underline-thickness="50"
- slope="0"
- x-height="517"
- cap-height="714"
- ascent="951.9958"
- descent="-212.99744"
- font-weight="400"
- id="font-face2">
- <font-face-src>
- <font-face-name
- name="HelveticaNeue" />
- </font-face-src>
- </font-face>
- <marker
- orient="auto"
- overflow="visible"
- markerUnits="strokeWidth"
- id="FilledArrow_Marker"
- stroke-linejoin="miter"
- stroke-miterlimit="10"
- viewBox="-1 -4 10 8"
- markerWidth="10"
- markerHeight="8"
- color="black">
- <g
- id="g6">
- <path
- d="M 8 0 L 0 -3 L 0 3 Z"
- fill="currentColor"
- stroke="currentColor"
- stroke-width="1"
- id="path4" />
- </g>
- </marker>
- <font-face
- font-family="Helvetica Neue"
- font-size="12"
- panose-1="2 0 4 3 0 0 0 9 0 4"
- units-per-em="1000"
- underline-position="-100"
- underline-thickness="50"
- slope="-1e3"
- x-height="523"
- cap-height="721"
- ascent="951.004"
- descent="-212.99744"
- font-style="italic"
- font-weight="300"
- id="font-face9">
- <font-face-src>
- <font-face-name
- name="HelveticaNeue-LightItalic" />
- </font-face-src>
- </font-face>
- <font-face
- font-family="Helvetica Neue"
- font-size="111"
- panose-1="2 0 2 6 0 0 0 2 0 4"
- units-per-em="1000"
- underline-position="-100"
- underline-thickness="50"
- slope="0"
- x-height="520"
- cap-height="722"
- ascent="930.9998"
- descent="-212.99744"
- font-weight="200"
- id="font-face11">
- <font-face-src>
- <font-face-name
- name="HelveticaNeue-UltraLight" />
- </font-face-src>
- </font-face>
- </defs>
- <g
- id="Canvas_1"
- fill-opacity="1"
- stroke-dasharray="none"
- stroke="none"
- stroke-opacity="1"
- fill="none">
- <title
- id="title15">Canvas 1</title>
- <g
- id="Canvas_1: Layer 2">
- <title
- id="title17">Layer 2</title>
- <g
- id="Group_38">
- <g
- id="Line_42">
- <line
- x1="56.69292"
- y1="116.22049"
- x2="56.69292"
- y2="396.85044"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line19" />
- </g>
- <g
- id="Line_41">
- <line
- x1="56.69292"
- y1="399.6851"
- x2="56.69292"
- y2="430.8662"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line22" />
- </g>
- <g
- id="Line_40">
- <line
- x1="56.69292"
- y1="85.03938"
- x2="56.69292"
- y2="116.22049"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line25" />
- </g>
- <g
- id="Graphic_39">
- <text
- transform="translate(34.01575 51.18763)"
- fill="black"
- id="text32">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="4.147137"
- y="11"
- id="tspan28">Interrupt </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="7.927137"
- y="25.336"
- id="tspan30">Source</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_33">
- <g
- id="Line_37">
- <line
- x1="138.89765"
- y1="116.22049"
- x2="138.89765"
- y2="396.85044"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line36" />
- </g>
- <g
- id="Line_36">
- <line
- x1="138.89765"
- y1="399.6851"
- x2="138.89765"
- y2="430.8662"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line39" />
- </g>
- <g
- id="Line_35">
- <line
- x1="138.89765"
- y1="85.03938"
- x2="138.89765"
- y2="116.22049"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line42" />
- </g>
- <g
- id="Graphic_34">
- <text
- transform="translate(113.38584 65.52886)"
- fill="black"
- id="text47">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="3.271137"
- y="11"
- id="tspan45">Gateway</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_28">
- <g
- id="Line_32">
- <line
- x1="226.77168"
- y1="116.22049"
- x2="226.77168"
- y2="396.85044"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line51" />
- </g>
- <g
- id="Line_31">
- <line
- x1="226.77168"
- y1="399.6851"
- x2="226.77168"
- y2="430.8662"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line54" />
- </g>
- <g
- id="Line_30">
- <line
- x1="226.77168"
- y1="85.03938"
- x2="226.77168"
- y2="116.22049"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line57" />
- </g>
- <g
- id="Graphic_29">
- <text
- transform="translate(201.25987 54.022275)"
- fill="black"
- id="text64">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="13.819137"
- y="11"
- id="tspan60">PLIC </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="14.041137"
- y="25.336"
- id="tspan62">Core</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_23">
- <g
- id="Line_27">
- <line
- x1="314.6457"
- y1="116.22049"
- x2="314.6457"
- y2="396.85044"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line68" />
- </g>
- <g
- id="Line_26">
- <line
- x1="314.6457"
- y1="399.6851"
- x2="314.6457"
- y2="430.8662"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line71" />
- </g>
- <g
- id="Line_25">
- <line
- x1="314.6457"
- y1="85.03938"
- x2="314.6457"
- y2="116.22049"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-dasharray="4.0,4.0"
- stroke-width="1"
- id="line74" />
- </g>
- <g
- id="Graphic_24">
- <text
- transform="translate(286.29924 65.52886)"
- fill="black"
- id="text79">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="10.543137"
- y="11"
- id="tspan77">Target</tspan>
- </text>
- </g>
- </g>
- <g
- id="Line_22">
- <line
- x1="56.69292"
- y1="124.72442"
- x2="129.0905"
- y2="134.7103"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line83" />
- </g>
- <g
- id="Line_21">
- <line
- x1="138.89765"
- y1="147.4016"
- x2="216.95308"
- y2="157.47326"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line86" />
- </g>
- <g
- id="Graphic_20">
- <text
- transform="translate(158.07088 121.38449)"
- fill="black"
- id="text93">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="2.554719"
- y="11"
- id="tspan89">Interrupt </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="2.776719"
- y="25.336"
- id="tspan91">Request</tspan>
- </text>
- </g>
- <g
- id="Line_19">
- <line
- x1="226.77168"
- y1="181.41734"
- x2="304.8271"
- y2="191.489"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line96" />
- </g>
- <g
- id="Graphic_18">
- <text
- transform="translate(240.27562 155.40024)"
- fill="black"
- id="text103">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="10.184398"
- y="11"
- id="tspan99">Interrupt </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="3.068398"
- y="25.336"
- id="tspan101">Notification</tspan>
- </text>
- </g>
- <g
- id="Line_17">
- <line
- x1="314.6457"
- y1="218.26774"
- x2="236.54537"
- y2="230.86457"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line106" />
- </g>
- <g
- id="Graphic_16">
- <text
- transform="translate(226.1024 197.34513)"
- fill="black"
- id="text113">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="10.184398"
- y="11"
- id="tspan109">Interrupt </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="17.294398"
- y="25.336"
- id="tspan111">Claim</tspan>
- </text>
- </g>
- <g
- id="Line_15">
- <line
- x1="226.77168"
- y1="255.11814"
- x2="304.872"
- y2="267.71497"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line116" />
- </g>
- <g
- id="Graphic_14">
- <text
- transform="translate(254.44885 231.93568)"
- fill="black"
- id="text123">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="17.294398"
- y="11"
- id="tspan119">Claim </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="5.960398"
- y="25.336"
- id="tspan121">Response</tspan>
- </text>
- </g>
- <g
- id="Graphic_13">
- <text
- transform="translate(73.0315,97.55772)"
- id="text130"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-style="italic"
- font-weight="300"
- x="2.554719"
- y="11"
- id="tspan126"
- style="font-style:italic;font-weight:300;font-size:12px;font-family:'Helvetica Neue';fill:#000000">Interrupt</tspan>
- <tspan
- font-size="12"
- font-style="italic"
- font-weight="300"
- x="0.88071901"
- y="25.336"
- id="tspan128"
- style="font-style:italic;font-weight:300;font-size:12px;font-family:'Helvetica Neue';fill:#000000">Signalled</tspan>
- </text>
- </g>
- <g
- id="Line_12">
- <line
- x1="314.6457"
- y1="312.38586"
- x2="148.71625"
- y2="333.7961"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line133" />
- </g>
- <g
- id="Graphic_11">
- <text
- transform="translate(237.44097 286.63648)"
- fill="black"
- id="text140">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="10.184398"
- y="11"
- id="tspan136">Interrupt </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="2.1803978"
- y="25.336"
- id="tspan138">Completion</tspan>
- </text>
- </g>
- <g
- id="Line_10">
- <line
- x1="56.69292"
- y1="167.24411"
- x2="129.0905"
- y2="177.22999"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line143" />
- </g>
- <g
- id="Line_9">
- <line
- x1="56.69292"
- y1="223.93703"
- x2="129.0905"
- y2="233.9229"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line146" />
- </g>
- <g
- id="Line_8">
- <line
- x1="56.69292"
- y1="246.6142"
- x2="129.0905"
- y2="256.60007"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line149" />
- </g>
- <g
- id="Line_7">
- <line
- x1="138.89765"
- y1="362.8347"
- x2="216.95308"
- y2="372.90635"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line152" />
- </g>
- <g
- id="Graphic_6">
- <text
- transform="translate(160.90553 337.3294)"
- fill="black"
- id="text159">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="12.328719"
- y="11"
- id="tspan155">Next </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-style="italic"
- font-weight="300"
- fill="black"
- x="2.776719"
- y="25.336"
- id="tspan157">Request</tspan>
- </text>
- </g>
- <g
- id="Line_5">
- <line
- x1="56.69292"
- y1="368.504"
- x2="129.0905"
- y2="378.48985"
- marker-end="url(#FilledArrow_Marker)"
- stroke="black"
- stroke-linecap="round"
- stroke-linejoin="round"
- stroke-width="1"
- id="line162" />
- </g>
- <g
- id="Graphic_4">
- <text
- transform="translate(313.9764 192.08853)"
- fill="black"
- id="text167">
- <tspan
- font-family="Helvetica Neue"
- font-size="111"
- font-weight="200"
- fill="black"
- x=".0185"
- y="103"
- id="tspan165">}</tspan>
- </text>
- </g>
- <g
- id="Graphic_3">
- <text
- transform="translate(336.6536 248.94356)"
- fill="black"
- id="text174">
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="10.850398"
- y="11"
- id="tspan170">Handler </tspan>
- <tspan
- font-family="Helvetica Neue"
- font-size="12"
- font-weight="400"
- fill="black"
- x="9.620398"
- y="25.336"
- id="tspan172">Running</tspan>
- </text>
- </g>
- </g>
- </g>
-</svg>
diff --git a/src/inkscape/halimps.svg b/src/inkscape/halimps.svg
deleted file mode 100644
index eafd8af..0000000
--- a/src/inkscape/halimps.svg
+++ /dev/null
@@ -1,994 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- version="1.1"
- viewBox="27.846455 27.846457 522.5748 134.22835"
- width="522.5748"
- height="134.22835"
- id="svg296"
- sodipodi:docname="halimps.svg"
- inkscape:version="0.92.2 5c3e80d, 2017-08-06">
- <metadata
- id="metadata300">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <sodipodi:namedview
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1"
- objecttolerance="10"
- gridtolerance="10"
- guidetolerance="10"
- inkscape:pageopacity="0"
- inkscape:pageshadow="2"
- inkscape:window-width="1182"
- inkscape:window-height="853"
- id="namedview298"
- showgrid="false"
- inkscape:zoom="1.9901456"
- inkscape:cx="236.57548"
- inkscape:cy="0.73366874"
- inkscape:window-x="0"
- inkscape:window-y="0"
- inkscape:window-maximized="0"
- inkscape:current-layer="svg296" />
- <defs
- id="defs4">
- <font-face
- font-family="Helvetica"
- font-size="12"
- units-per-em="1000"
- underline-position="-75.68359"
- underline-thickness="49.316406"
- slope="0"
- x-height="522.9492"
- cap-height="717.28516"
- ascent="770.0195"
- descent="-229.98047"
- font-weight="400"
- id="font-face2">
- <font-face-src>
- <font-face-name
- name="Helvetica" />
- </font-face-src>
- </font-face>
- </defs>
- <g
- id="halimps"
- style="fill:none;fill-opacity:1;stroke:none;stroke-dasharray:none;stroke-opacity:1">
- <title
- id="title6">halimps</title>
- <g
- id="halimps: Layer 1">
- <title
- id="title8">Layer 1</title>
- <g
- id="Group_33">
- <g
- id="Graphic_38">
- <rect
- x="28.346457"
- y="28.346457"
- width="65.196854"
- height="19.842522"
- id="rect10"
- style="fill:#ffffff" />
- <rect
- x="28.346457"
- y="28.346457"
- width="65.196854"
- height="19.842522"
- id="rect12"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(28.346457,31.267718)"
- id="text16"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="3.2458878"
- y="11"
- id="tspan14"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_37">
- <rect
- x="28.346457"
- y="48.18898"
- width="65.196854"
- height="11.338583"
- id="rect19"
- style="fill:#000000" />
- <rect
- x="28.346457"
- y="48.18898"
- width="65.196854"
- height="11.338583"
- id="rect21"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(28.346457,46.85827)"
- id="text25"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="22.927528"
- y="11"
- id="tspan23"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_36">
- <rect
- x="28.346455"
- y="59.527561"
- width="65.196854"
- height="17.007874"
- id="rect28"
- style="fill:#ffffff" />
- <rect
- x="28.346455"
- y="59.527561"
- width="65.196854"
- height="17.007874"
- id="rect30"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(28.346455,61.0315)"
- id="text34"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="20.592567"
- y="11"
- id="tspan32"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">AEE</tspan>
- </text>
- </g>
- <g
- id="Graphic_35">
- <rect
- x="28.346457"
- y="76.535439"
- width="65.196854"
- height="11.338583"
- id="rect37"
- style="fill:#000000" />
- <rect
- x="28.346457"
- y="76.535439"
- width="65.196854"
- height="11.338583"
- id="rect39"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(28.346457,75.20473)"
- id="text43"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="20.926552"
- y="11"
- id="tspan41"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">HAL</tspan>
- </text>
- </g>
- <g
- id="Graphic_34">
- <rect
- x="28.346457"
- y="87.874023"
- width="65.196854"
- height="17.007874"
- id="rect46"
- style="fill:#ffffff" />
- <rect
- x="28.346457"
- y="87.874023"
- width="65.196854"
- height="17.007874"
- id="rect48"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(28.346457,89.37796)"
- id="text52"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="6.5886612"
- y="11"
- id="tspan50"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Hardware</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_23">
- <g
- id="Graphic_32">
- <rect
- x="124.72442"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect56"
- style="fill:#ffffff" />
- <rect
- x="124.72442"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect58"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72442,31.26772)"
- id="text62"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan60"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_31">
- <rect
- x="124.72442"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect65"
- style="fill:#000000" />
- <rect
- x="124.72442"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect67"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72442,46.85827)"
- id="text71"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan69"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_30">
- <rect
- x="124.72441"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect74"
- style="fill:#ffffff" />
- <rect
- x="124.72441"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect76"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72441,61.0315)"
- id="text80"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="56.527908"
- y="11"
- id="tspan78"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">OS</tspan>
- </text>
- </g>
- <g
- id="Graphic_29">
- <rect
- x="124.72441"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect83"
- style="fill:#000000" />
- <rect
- x="124.72441"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect85"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72441,75.20473)"
- id="text89"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="55.525955"
- y="11"
- id="tspan87"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">SBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_28">
- <rect
- x="124.72441"
- y="87.874023"
- width="130.39371"
- height="17.007874"
- id="rect92"
- style="fill:#ffffff" />
- <rect
- x="124.72441"
- y="87.874023"
- width="130.39371"
- height="17.007874"
- id="rect94"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72441,89.37796)"
- id="text98"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="53.190994"
- y="11"
- id="tspan96"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">SEE</tspan>
- </text>
- </g>
- <g
- id="Graphic_27">
- <rect
- x="192.75591"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect101"
- style="fill:#ffffff" />
- <rect
- x="192.75591"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect103"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(192.75591,31.26772)"
- id="text107"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan105"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_26">
- <rect
- x="192.75591"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect110"
- style="fill:#000000" />
- <rect
- x="192.75591"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect112"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(192.75591,46.85827)"
- id="text116"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan114"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_25">
- <rect
- x="124.72441"
- y="104.88189"
- width="130.39371"
- height="11.338583"
- id="rect119"
- style="fill:#000000" />
- <rect
- x="124.72441"
- y="104.88189"
- width="130.39371"
- height="11.338583"
- id="rect121"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72441,103.55118)"
- id="text125"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="53.524979"
- y="11"
- id="tspan123"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">HAL</tspan>
- </text>
- </g>
- <g
- id="Graphic_24">
- <rect
- x="124.72441"
- y="116.22048"
- width="130.39371"
- height="17.007874"
- id="rect128"
- style="fill:#ffffff" />
- <rect
- x="124.72441"
- y="116.22048"
- width="130.39371"
- height="17.007874"
- id="rect130"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72441,117.72441)"
- id="text134"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="39.187092"
- y="11"
- id="tspan132"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Hardware</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_3">
- <g
- id="Graphic_22">
- <rect
- x="283.46457"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect138"
- style="fill:#000000" />
- <rect
- x="283.46457"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect140"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46457,75.20473)"
- id="text144"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="55.525955"
- y="11"
- id="tspan142"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">SBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_21">
- <rect
- x="283.46457"
- y="87.874023"
- width="266.4567"
- height="17.007874"
- id="rect147"
- style="fill:#ffffff" />
- <rect
- x="283.46457"
- y="87.874023"
- width="266.4567"
- height="17.007874"
- id="rect149"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46457,89.37796)"
- id="text153"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="104.5555"
- y="11"
- id="tspan151"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Hypervisor</tspan>
- </text>
- </g>
- <g
- id="Group_15">
- <g
- id="Graphic_20">
- <rect
- x="283.46457"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect156"
- style="fill:#ffffff" />
- <rect
- x="283.46457"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect158"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46458,31.26772)"
- id="text162"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan160"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_19">
- <rect
- x="283.46457"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect165"
- style="fill:#000000" />
- <rect
- x="283.46457"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect167"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46458,46.85827)"
- id="text171"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan169"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_18">
- <rect
- x="283.46457"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect174"
- style="fill:#ffffff" />
- <rect
- x="283.46457"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect176"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46457,61.0315)"
- id="text180"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="56.527908"
- y="11"
- id="tspan178"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">OS</tspan>
- </text>
- </g>
- <g
- id="Graphic_17">
- <rect
- x="351.49609"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect183"
- style="fill:#ffffff" />
- <rect
- x="351.49609"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect185"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(351.49608,31.26772)"
- id="text189"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan187"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_16">
- <rect
- x="351.49609"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect192"
- style="fill:#000000" />
- <rect
- x="351.49609"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect194"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(351.49608,46.85827)"
- id="text198"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan196"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_9">
- <g
- id="Graphic_14">
- <rect
- x="419.52756"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect202"
- style="fill:#ffffff" />
- <rect
- x="419.52756"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect204"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(419.52757,31.26772)"
- id="text208"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan206"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_13">
- <rect
- x="419.52756"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect211"
- style="fill:#000000" />
- <rect
- x="419.52756"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect213"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(419.52757,46.85827)"
- id="text217"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan215"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_12">
- <rect
- x="419.52756"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect220"
- style="fill:#ffffff" />
- <rect
- x="419.52756"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect222"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(419.52757,61.0315)"
- id="text226"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="56.527908"
- y="11"
- id="tspan224"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">OS</tspan>
- </text>
- </g>
- <g
- id="Graphic_11">
- <rect
- x="487.55908"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect229"
- style="fill:#ffffff" />
- <rect
- x="487.55908"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect231"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(487.55907,31.26772)"
- id="text235"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan233"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_10">
- <rect
- x="487.55908"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect238"
- style="fill:#000000" />
- <rect
- x="487.55908"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect240"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(487.55907,46.85827)"
- id="text244"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan242"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- </g>
- <g
- id="Graphic_8">
- <rect
- x="419.52756"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect248"
- style="fill:#000000" />
- <rect
- x="419.52756"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect250"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(419.52757,75.20473)"
- id="text254"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="55.525955"
- y="11"
- id="tspan252"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">SBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_7">
- <rect
- x="283.46457"
- y="104.88189"
- width="266.4567"
- height="11.338583"
- id="rect257"
- style="fill:#000000" />
- <rect
- x="283.46457"
- y="104.88189"
- width="266.4567"
- height="11.338583"
- id="rect259"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46457,103.55118)"
- id="text263"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="123.2264"
- y="11"
- id="tspan261"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">HBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_6">
- <rect
- x="283.46457"
- y="116.22048"
- width="266.4567"
- height="17.007874"
- id="rect266"
- style="fill:#ffffff" />
- <rect
- x="283.46457"
- y="116.22048"
- width="266.4567"
- height="17.007874"
- id="rect268"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46458,117.72441)"
- id="text272"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="120.89143"
- y="11"
- id="tspan270"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">HEE</tspan>
- </text>
- </g>
- <g
- id="Graphic_5">
- <rect
- x="283.46457"
- y="144.56693"
- width="266.4567"
- height="17.007874"
- id="rect275"
- style="fill:#ffffff" />
- <rect
- x="283.46457"
- y="144.56693"
- width="266.4567"
- height="17.007874"
- id="rect277"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46457,146.07087)"
- id="text281"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="107.21858"
- y="11"
- id="tspan279"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Hardware</tspan>
- </text>
- </g>
- <g
- id="Graphic_4">
- <rect
- x="283.46457"
- y="133.22835"
- width="266.4567"
- height="11.338583"
- id="rect284"
- style="fill:#000000" />
- <rect
- x="283.46457"
- y="133.22835"
- width="266.4567"
- height="11.338583"
- id="rect286"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46457,131.89764)"
- id="text290"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="121.55647"
- y="11"
- id="tspan288"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">HAL</tspan>
- </text>
- </g>
- </g>
- </g>
- </g>
-</svg>
diff --git a/src/inkscape/halmode.svg b/src/inkscape/halmode.svg
deleted file mode 100644
index 0b2f722..0000000
--- a/src/inkscape/halmode.svg
+++ /dev/null
@@ -1,799 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- version="1.1"
- viewBox="98.7126 27.846457 381.11024 106.88189"
- width="381.11024"
- height="106.88189"
- id="svg233"
- sodipodi:docname="halmode.svg"
- inkscape:version="0.92.2 5c3e80d, 2017-08-06">
- <metadata
- id="metadata237">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <sodipodi:namedview
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1"
- objecttolerance="10"
- gridtolerance="10"
- guidetolerance="10"
- inkscape:pageopacity="0"
- inkscape:pageshadow="2"
- inkscape:window-width="640"
- inkscape:window-height="480"
- id="namedview235"
- showgrid="false"
- inkscape:zoom="1.929602"
- inkscape:cx="184.7919"
- inkscape:cy="38.21387"
- inkscape:window-x="0"
- inkscape:window-y="0"
- inkscape:window-maximized="0"
- inkscape:current-layer="svg233" />
- <defs
- id="defs14">
- <font-face
- font-family="Helvetica"
- font-size="12"
- units-per-em="1000"
- underline-position="-75.68359"
- underline-thickness="49.316406"
- slope="0"
- x-height="522.9492"
- cap-height="717.28516"
- ascent="770.0195"
- descent="-229.98047"
- font-weight="400"
- id="font-face2">
- <font-face-src>
- <font-face-name
- name="Helvetica" />
- </font-face-src>
- </font-face>
- <marker
- orient="auto"
- overflow="visible"
- markerUnits="strokeWidth"
- id="FilledArrow_Marker"
- stroke-linejoin="miter"
- stroke-miterlimit="10"
- viewBox="-1 -4 10 8"
- markerWidth="10"
- markerHeight="8"
- color="black">
- <g
- id="g6">
- <path
- d="M 8 0 L 0 -3 L 0 3 Z"
- fill="currentColor"
- stroke="currentColor"
- stroke-width="1"
- id="path4" />
- </g>
- </marker>
- <marker
- orient="auto"
- overflow="visible"
- markerUnits="strokeWidth"
- id="FilledArrow_Marker_2"
- stroke-linejoin="miter"
- stroke-miterlimit="10"
- viewBox="-9 -4 10 8"
- markerWidth="10"
- markerHeight="8"
- color="black">
- <g
- id="g11">
- <path
- d="M -8 0 L 0 3 L 0 -3 Z"
- fill="currentColor"
- stroke="currentColor"
- stroke-width="1"
- id="path9" />
- </g>
- </marker>
- </defs>
- <g
- id="halmode"
- style="fill:none;fill-opacity:1;stroke:none;stroke-dasharray:none;stroke-opacity:1">
- <title
- id="title16">halmode</title>
- <g
- id="halmode: Layer 1">
- <title
- id="title18">Layer 1</title>
- <g
- id="Group_36">
- <g
- id="Graphic_41">
- <rect
- x="99.212601"
- y="45.354328"
- width="65.196854"
- height="19.842522"
- id="rect20"
- style="fill:#ffffff" />
- <rect
- x="99.212601"
- y="45.354328"
- width="65.196854"
- height="19.842522"
- id="rect22"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(99.2126,48.27559)"
- id="text26"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="3.2458878"
- y="11"
- id="tspan24"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_40">
- <rect
- x="99.212601"
- y="65.196854"
- width="65.196854"
- height="11.338583"
- id="rect29"
- style="fill:#000000" />
- <rect
- x="99.212601"
- y="65.196854"
- width="65.196854"
- height="11.338583"
- id="rect31"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(99.2126,63.866144)"
- id="text35"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="22.927528"
- y="11"
- id="tspan33"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_39">
- <rect
- x="99.212601"
- y="76.535439"
- width="65.196854"
- height="17.007874"
- id="rect38"
- style="fill:#ffffff" />
- <rect
- x="99.212601"
- y="76.535439"
- width="65.196854"
- height="17.007874"
- id="rect40"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(99.2126,78.03937)"
- id="text44"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="20.592567"
- y="11"
- id="tspan42"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">AEE</tspan>
- </text>
- </g>
- <g
- id="Graphic_38">
- <rect
- x="99.212601"
- y="93.543312"
- width="65.196854"
- height="11.338583"
- id="rect47"
- style="fill:#000000" />
- <rect
- x="99.212601"
- y="93.543312"
- width="65.196854"
- height="11.338583"
- id="rect49"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(99.2126,92.2126)"
- id="text53"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="20.926552"
- y="11"
- id="tspan51"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">HAL</tspan>
- </text>
- </g>
- <g
- id="Graphic_37">
- <rect
- x="99.212601"
- y="104.8819"
- width="65.196854"
- height="17.007874"
- id="rect56"
- style="fill:#ffffff" />
- <rect
- x="99.212601"
- y="104.8819"
- width="65.196854"
- height="17.007874"
- id="rect58"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(99.2126,106.38583)"
- id="text62"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="6.5886612"
- y="11"
- id="tspan60"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Hardware</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_26">
- <g
- id="Graphic_35">
- <rect
- x="269.29135"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect66"
- style="fill:#ffffff" />
- <rect
- x="269.29135"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect68"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(269.29135,31.26772)"
- id="text72"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan70"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_34">
- <rect
- x="269.29135"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect75"
- style="fill:#000000" />
- <rect
- x="269.29135"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect77"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(269.29135,46.85827)"
- id="text81"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan79"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_33">
- <rect
- x="269.29135"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect84"
- style="fill:#ffffff" />
- <rect
- x="269.29135"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect86"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(269.29135,61.0315)"
- id="text90"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="56.527908"
- y="11"
- id="tspan88"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">OS</tspan>
- </text>
- </g>
- <g
- id="Graphic_32">
- <rect
- x="269.29135"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect93"
- style="fill:#000000" />
- <rect
- x="269.29135"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect95"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(269.29135,75.20473)"
- id="text99"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="55.525955"
- y="11"
- id="tspan97"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">SBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_31">
- <rect
- x="269.29135"
- y="87.874023"
- width="130.39371"
- height="17.007874"
- id="rect102"
- style="fill:#ffffff" />
- <rect
- x="269.29135"
- y="87.874023"
- width="130.39371"
- height="17.007874"
- id="rect104"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(269.29135,89.37796)"
- id="text108"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="53.190994"
- y="11"
- id="tspan106"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">SEE</tspan>
- </text>
- </g>
- <g
- id="Graphic_30">
- <rect
- x="337.32285"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect111"
- style="fill:#ffffff" />
- <rect
- x="337.32285"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect113"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(337.32285,31.26772)"
- id="text117"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan115"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_29">
- <rect
- x="337.32285"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect120"
- style="fill:#000000" />
- <rect
- x="337.32285"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect122"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(337.32285,46.85827)"
- id="text126"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan124"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_28">
- <rect
- x="269.29135"
- y="104.88189"
- width="130.39371"
- height="11.338583"
- id="rect129"
- style="fill:#000000" />
- <rect
- x="269.29135"
- y="104.88189"
- width="130.39371"
- height="11.338583"
- id="rect131"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(269.29135,103.55118)"
- id="text135"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="53.524979"
- y="11"
- id="tspan133"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">HAL</tspan>
- </text>
- </g>
- <g
- id="Graphic_27">
- <rect
- x="269.29135"
- y="116.22048"
- width="130.39371"
- height="17.007874"
- id="rect138"
- style="fill:#ffffff" />
- <rect
- x="269.29135"
- y="116.22048"
- width="130.39371"
- height="17.007874"
- id="rect140"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(269.29135,117.72441)"
- id="text144"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="39.187092"
- y="11"
- id="tspan142"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Hardware</tspan>
- </text>
- </g>
- </g>
- <g
- id="Line_25">
- <line
- x1="172.91341"
- y1="70.866142"
- x2="223.93701"
- y2="70.866142"
- id="line148"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_24">
- <line
- x1="172.91341"
- y1="45.354328"
- x2="223.93701"
- y2="45.354328"
- id="line151"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_23">
- <line
- x1="182.1496"
- y1="55.25433"
- x2="182.1496"
- y2="60.966145"
- id="line154"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_22">
- <text
- transform="translate(191.20866,50.192915)"
- id="text159"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.33203125"
- y="11"
- id="tspan157"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">User</tspan>
- </text>
- </g>
- <g
- id="Line_21">
- <line
- x1="172.91341"
- y1="96.37796"
- x2="223.93701"
- y2="96.37796"
- id="line162"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_20">
- <line
- x1="182.1496"
- y1="80.766144"
- x2="182.1496"
- y2="86.477959"
- id="line165"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_19">
- <text
- transform="translate(189.3819,75.70473)"
- id="text170"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.32128906"
- y="11"
- id="tspan168"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Supervisor</tspan>
- </text>
- </g>
- <g
- id="Line_18">
- <line
- x1="172.91341"
- y1="121.88977"
- x2="223.93701"
- y2="121.88977"
- id="line173"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_17">
- <line
- x1="182.1496"
- y1="106.27796"
- x2="182.1496"
- y2="111.98977"
- id="line176"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_16">
- <text
- transform="translate(189.8819,101.21654)"
- id="text181"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.37207031"
- y="11"
- id="tspan179"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">HAL Mode</tspan>
- </text>
- </g>
- <g
- id="Line_15">
- <line
- x1="405.35434"
- y1="53.858269"
- x2="456.37796"
- y2="53.858269"
- id="line184"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_14">
- <line
- x1="405.35434"
- y1="28.346457"
- x2="456.37796"
- y2="28.346457"
- id="line187"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_13">
- <line
- x1="414.59055"
- y1="38.246456"
- x2="414.59055"
- y2="43.958271"
- id="line190"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_12">
- <text
- transform="translate(423.6496,33.18504)"
- id="text195"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.33203125"
- y="11"
- id="tspan193"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">User</tspan>
- </text>
- </g>
- <g
- id="Line_11">
- <line
- x1="405.35434"
- y1="82.204727"
- x2="456.37796"
- y2="82.204727"
- id="line198"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_10">
- <line
- x1="414.59055"
- y1="63.75827"
- x2="414.59055"
- y2="72.304733"
- id="line201"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_9">
- <text
- transform="translate(421.82284,61.5315)"
- id="text206"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.32128906"
- y="11"
- id="tspan204"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Supervisor</tspan>
- </text>
- </g>
- <g
- id="Line_8">
- <line
- x1="405.35434"
- y1="107.71654"
- x2="456.37796"
- y2="107.71654"
- id="line209"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_7">
- <line
- x1="414.36813"
- y1="92.101158"
- x2="414.21457"
- y2="97.820099"
- id="line212"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_6">
- <text
- transform="translate(421.82284,89.87796)"
- id="text217"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.32714844"
- y="11"
- id="tspan215"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Hypervisor</tspan>
- </text>
- </g>
- <g
- id="Line_5">
- <line
- x1="405.35434"
- y1="133.22835"
- x2="456.37796"
- y2="133.22835"
- id="line220"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_4">
- <line
- x1="413.9137"
- y1="117.61648"
- x2="413.8934"
- y2="123.32841"
- id="line223"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_3">
- <text
- transform="translate(422.32284,112.55512)"
- id="text228"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.37207031"
- y="11"
- id="tspan226"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">HAL Mode</tspan>
- </text>
- </g>
- </g>
- </g>
-</svg>
diff --git a/src/inkscape/htif.svg b/src/inkscape/htif.svg
deleted file mode 100644
index 87de7a7..0000000
--- a/src/inkscape/htif.svg
+++ /dev/null
@@ -1,626 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- version="1.1"
- viewBox="39.18504 50.023623 429.532 143.733"
- width="429.532"
- height="143.733"
- id="svg177"
- sodipodi:docname="htif.svg"
- inkscape:version="0.92.2 5c3e80d, 2017-08-06">
- <metadata
- id="metadata181">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <sodipodi:namedview
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1"
- objecttolerance="10"
- gridtolerance="10"
- guidetolerance="10"
- inkscape:pageopacity="0"
- inkscape:pageshadow="2"
- inkscape:window-width="640"
- inkscape:window-height="480"
- id="namedview179"
- showgrid="false"
- inkscape:zoom="1.2106199"
- inkscape:cx="259.29759"
- inkscape:cy="80.412747"
- inkscape:window-x="0"
- inkscape:window-y="0"
- inkscape:window-maximized="0"
- inkscape:current-layer="svg177" />
- <defs
- id="defs16">
- <font-face
- font-family="Helvetica"
- font-size="12"
- units-per-em="1000"
- underline-position="-75.68359"
- underline-thickness="49.316406"
- slope="0"
- x-height="522.9492"
- cap-height="717.28516"
- ascent="770.0195"
- descent="-229.98047"
- font-weight="400"
- id="font-face2">
- <font-face-src>
- <font-face-name
- name="Helvetica" />
- </font-face-src>
- </font-face>
- <marker
- orient="auto"
- overflow="visible"
- markerUnits="strokeWidth"
- id="FilledArrow_Marker"
- stroke-linejoin="miter"
- stroke-miterlimit="10"
- viewBox="-1 -4 10 8"
- markerWidth="10"
- markerHeight="8"
- color="black">
- <g
- id="g6">
- <path
- d="M 8 0 L 0 -3 L 0 3 Z"
- fill="currentColor"
- stroke="currentColor"
- stroke-width="1"
- id="path4" />
- </g>
- </marker>
- <marker
- orient="auto"
- overflow="visible"
- markerUnits="strokeWidth"
- id="FilledArrow_Marker_2"
- stroke-linejoin="miter"
- stroke-miterlimit="10"
- viewBox="-9 -4 10 8"
- markerWidth="10"
- markerHeight="8"
- color="black">
- <g
- id="g11">
- <path
- d="M -8 0 L 0 3 L 0 -3 Z"
- fill="currentColor"
- stroke="currentColor"
- stroke-width="1"
- id="path9" />
- </g>
- </marker>
- <font-face
- font-family="Helvetica"
- font-size="12"
- units-per-em="1000"
- underline-position="-75.68359"
- underline-thickness="49.316406"
- slope="-1e3"
- x-height="522.9492"
- cap-height="717.28516"
- ascent="770.0195"
- descent="-229.98047"
- font-style="italic"
- font-weight="400"
- id="font-face14">
- <font-face-src>
- <font-face-name
- name="Helvetica-Oblique" />
- </font-face-src>
- </font-face>
- </defs>
- <g
- id="Canvas_6"
- style="fill:none;fill-opacity:1;stroke:none;stroke-dasharray:none;stroke-opacity:1">
- <title
- id="title18">Canvas 2</title>
- <g
- id="Canvas_6: Layer 1">
- <title
- id="title20">Layer 1</title>
- <g
- id="Group_18">
- <g
- id="Graphic_29">
- <rect
- x="311.81104"
- y="51.023624"
- width="155.90601"
- height="141.733"
- id="rect22"
- style="fill:#ffffff" />
- <rect
- x="311.81104"
- y="51.023624"
- width="155.90601"
- height="141.733"
- id="rect24"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(316.81103,174.25662)"
- id="text28"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0"
- y="11"
- id="tspan26"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Target System</tspan>
- </text>
- </g>
- <g
- id="Graphic_28">
- <ellipse
- cx="388.34653"
- cy="150.23532"
- rx="59.527596"
- ry="19.842531"
- id="ellipse31"
- style="fill:#ffffff" />
- <ellipse
- cx="388.34653"
- cy="150.23532"
- rx="59.527596"
- ry="19.842531"
- id="ellipse33"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(345.72453,143.23532)"
- id="text37"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="14.942313"
- y="11"
- id="tspan35"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">OS Kernel</tspan>
- </text>
- </g>
- <g
- id="Graphic_27">
- <ellipse
- cx="341.57553"
- cy="87.873466"
- rx="24.094538"
- ry="17.007877"
- id="ellipse40"
- style="fill:#ffffff" />
- <ellipse
- cx="341.57553"
- cy="87.873466"
- rx="24.094538"
- ry="17.007877"
- id="ellipse42"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(327.29993,73.87347)"
- id="text48"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="3.5998187"
- y="11"
- id="tspan44"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">App</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="10.938686"
- y="25"
- id="tspan46"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">1</tspan>
- </text>
- </g>
- <g
- id="Line_26">
- <line
- x1="359.39191"
- y1="111.62886"
- x2="367.36697"
- y2="122.26233"
- id="line51"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Line_25">
- <line
- x1="311.81104"
- y1="113.38562"
- x2="467.71704"
- y2="113.38462"
- id="line54"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:4, 4" />
- </g>
- <g
- id="Graphic_24">
- <text
- transform="rotate(-90,274.20833,-176.16971)"
- id="text59"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.33203125"
- y="11"
- id="tspan57"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">User</tspan>
- </text>
- </g>
- <g
- id="Graphic_23">
- <text
- transform="rotate(-90,315.18923,-135.18961)"
- id="text64"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.085089"
- y="11"
- id="tspan62"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Supervisor</tspan>
- </text>
- </g>
- <g
- id="Graphic_22">
- <ellipse
- cx="382.67752"
- cy="68.030823"
- rx="19.842531"
- ry="14.173223"
- id="ellipse67"
- style="fill:#ffffff" />
- <ellipse
- cx="382.67752"
- cy="68.030823"
- rx="19.842531"
- ry="14.173223"
- id="ellipse69"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(371.80353,54.030823)"
- id="text75"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.19821875"
- y="11"
- id="tspan71"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">App</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="7.537086"
- y="25"
- id="tspan73"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">2</tspan>
- </text>
- </g>
- <g
- id="Line_21">
- <line
- x1="384.40369"
- y1="93.06115"
- x2="386.22861"
- y2="119.52385"
- id="line78"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_20">
- <ellipse
- cx="416.69354"
- cy="87.872818"
- rx="19.842531"
- ry="14.173223"
- id="ellipse81"
- style="fill:#ffffff" />
- <ellipse
- cx="416.69354"
- cy="87.872818"
- rx="19.842531"
- ry="14.173223"
- id="ellipse83"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(405.81953,73.87282)"
- id="text89"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.19821875"
- y="11"
- id="tspan85"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">App</tspan>
- <tspan
- font-size="12"
- font-style="italic"
- font-weight="400"
- x="7.537086"
- y="25"
- id="tspan87"
- style="font-style:italic;font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">n</tspan>
- </text>
- </g>
- <g
- id="Line_19">
- <line
- x1="406.05414"
- y1="111.27913"
- x2="401.7753"
- y2="120.69249"
- id="line92"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- </g>
- <g
- id="Graphic_17">
- <text
- transform="translate(250.47217,129.06228)"
- id="text98"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="15.921872"
- y="11"
- id="tspan96"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">HTIF</tspan>
- </text>
- </g>
- <g
- id="Group_4">
- <g
- id="Graphic_16">
- <rect
- x="62.66061"
- y="51.023624"
- width="195.29214"
- height="141.73228"
- id="rect101"
- style="fill:#ffffff" />
- <rect
- x="62.66061"
- y="51.023624"
- width="195.29214"
- height="141.73228"
- id="rect103"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(67.66061,174.2559)"
- id="text107"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0"
- y="11"
- id="tspan105"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Front-End Host</tspan>
- </text>
- </g>
- <g
- id="Graphic_15">
- <ellipse
- cx="194.71414"
- cy="161.9639"
- rx="41.643337"
- ry="19.453461"
- id="ellipse110"
- style="fill:#ffffff" />
- <ellipse
- cx="194.71414"
- cy="161.9639"
- rx="41.643337"
- ry="19.453461"
- id="ellipse112"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(166.39952,147.9639)"
- id="text118"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.636881"
- y="11"
- id="tspan114"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Front-End</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="10.64274"
- y="25"
- id="tspan116"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Server</tspan>
- </text>
- </g>
- <g
- id="Graphic_14">
- <path
- d="M 186.15432,94.09913 V 60.75035 c 0,-2.301066 13.50965,-4.1686 30.15548,-4.1686 16.6458,0 30.15546,1.867534 30.15546,4.1686 v 33.34878 c 0,2.30107 -13.50966,4.1686 -30.15546,4.1686 -16.64583,0 -30.15548,-1.86753 -30.15548,-4.1686"
- id="path121"
- inkscape:connector-curvature="0"
- style="fill:#ffffff" />
- <path
- d="M 186.15432,94.09913 V 60.75035 c 0,-2.301066 13.50965,-4.1686 30.15548,-4.1686 16.6458,0 30.15546,1.867534 30.15546,4.1686 v 33.34878 c 0,2.30107 -13.50966,4.1686 -30.15546,4.1686 -16.64583,0 -30.15548,-1.86753 -30.15548,-4.1686 m 0,-33.34878 c 0,2.301066 13.50965,4.1686 30.15548,4.1686 16.6458,0 30.15546,-1.867534 30.15546,-4.1686"
- id="path123"
- inkscape:connector-curvature="0"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(191.15432,65.50904)"
- id="text129"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.4835932"
- y="11"
- id="tspan125"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Host File</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="5.1515622"
- y="25"
- id="tspan127"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">System</tspan>
- </text>
- </g>
- <g
- id="Line_13">
- <line
- x1="204.72881"
- y1="132.42577"
- x2="213.131"
- y2="107.64351"
- id="line132"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Line_12">
- <path
- d="m 142.53103,158.72025 c -13.28267,-1.05683 -27.54461,-2.45853 -36.7912,-2.09218 -11.6064,0.45983 -11.96755,6.48439 -22.97558,5.55813 -8.66237,-0.7289 -21.476615,-4.8999 -33.54093,-8.4498"
- id="path135"
- inkscape:connector-curvature="0"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_11">
- <text
- transform="translate(88.50842,124.59751)"
- id="text142"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="12.367048"
- y="11"
- id="tspan138"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Host</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="4.3572826"
- y="25"
- id="tspan140"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Internet</tspan>
- </text>
- </g>
- <g
- id="Group_6">
- <g
- id="Graphic_10">
- <rect
- x="117.2276"
- y="56.58157"
- width="60.310936"
- height="38.90686"
- id="rect145"
- style="fill:#ffffff" />
- <rect
- x="117.2276"
- y="56.58157"
- width="60.310936"
- height="38.90686"
- id="rect147"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Graphic_9">
- <rect
- x="120.0995"
- y="59.360691"
- width="54.567135"
- height="33.348724"
- id="rect150"
- style="fill:#ffffff" />
- <rect
- x="120.0995"
- y="59.360691"
- width="54.567135"
- height="33.348724"
- id="rect152"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Graphic_8">
- <text
- transform="translate(122.38661,62.204805)"
- id="text159"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="12.367048"
- y="11"
- id="tspan155"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Host</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="2.6902905"
- y="25"
- id="tspan157"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Console</tspan>
- </text>
- </g>
- <g
- id="Graphic_7">
- <path
- d="m 177.53844,95.48876 -17.23169,16.67428 c 0,3e-5 -63.18276,3e-5 -63.18276,3e-5 -8e-5,0 20.10353,-16.67431 20.10353,-16.67431 z"
- id="path162"
- inkscape:connector-curvature="0"
- style="fill:#ffffff" />
- <path
- d="m 177.53844,95.48876 -17.23169,16.67428 c 0,3e-5 -63.18276,3e-5 -63.18276,3e-5 -8e-5,0 20.10353,-16.67431 20.10353,-16.67431 z"
- id="path164"
- inkscape:connector-curvature="0"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- </g>
- <g
- id="Line_5">
- <path
- d="m 164.37481,116.91032 13.16373,6.36898 4.29436,9.67219"
- id="path168"
- inkscape:connector-curvature="0"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- </g>
- <g
- id="Line_3">
- <line
- x1="246.8938"
- y1="158.8033"
- x2="318.89279"
- y2="154.44225"
- id="line172"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- </g>
- </g>
-</svg>
diff --git a/src/inkscape/privimps.svg b/src/inkscape/privimps.svg
deleted file mode 100644
index 9d02c86..0000000
--- a/src/inkscape/privimps.svg
+++ /dev/null
@@ -1,820 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- version="1.1"
- viewBox="27.846455 27.846457 522.5748 105.88189"
- width="522.5748"
- height="105.88189"
- id="svg242"
- sodipodi:docname="privimps.svg"
- inkscape:version="0.92.2 5c3e80d, 2017-08-06">
- <metadata
- id="metadata246">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <sodipodi:namedview
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1"
- objecttolerance="10"
- gridtolerance="10"
- guidetolerance="10"
- inkscape:pageopacity="0"
- inkscape:pageshadow="2"
- inkscape:window-width="640"
- inkscape:window-height="480"
- id="namedview244"
- showgrid="false"
- inkscape:zoom="0.4975364"
- inkscape:cx="261.28741"
- inkscape:cy="52.940945"
- inkscape:window-x="0"
- inkscape:window-y="0"
- inkscape:window-maximized="0"
- inkscape:current-layer="svg242" />
- <defs
- id="defs4">
- <font-face
- font-family="Helvetica"
- font-size="12"
- units-per-em="1000"
- underline-position="-75.68359"
- underline-thickness="49.316406"
- slope="0"
- x-height="522.9492"
- cap-height="717.28516"
- ascent="770.0195"
- descent="-229.98047"
- font-weight="400"
- id="font-face2">
- <font-face-src>
- <font-face-name
- name="Helvetica" />
- </font-face-src>
- </font-face>
- </defs>
- <g
- id="privimps"
- style="fill:none;fill-opacity:1;stroke:none;stroke-dasharray:none;stroke-opacity:1">
- <title
- id="title6">privimps</title>
- <g
- id="privimps: Layer 1">
- <title
- id="title8">Layer 1</title>
- <g
- id="Group_29">
- <g
- id="Graphic_32">
- <rect
- x="28.346457"
- y="28.346457"
- width="65.196854"
- height="19.842522"
- id="rect10"
- style="fill:#ffffff" />
- <rect
- x="28.346457"
- y="28.346457"
- width="65.196854"
- height="19.842522"
- id="rect12"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(28.346457,31.267718)"
- id="text16"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="3.2458878"
- y="11"
- id="tspan14"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_31">
- <rect
- x="28.346457"
- y="48.18898"
- width="65.196854"
- height="11.338583"
- id="rect19"
- style="fill:#000000" />
- <rect
- x="28.346457"
- y="48.18898"
- width="65.196854"
- height="11.338583"
- id="rect21"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(28.346457,46.85827)"
- id="text25"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="22.927528"
- y="11"
- id="tspan23"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_30">
- <rect
- x="28.346455"
- y="59.527561"
- width="65.196854"
- height="17.007874"
- id="rect28"
- style="fill:#ffffff" />
- <rect
- x="28.346455"
- y="59.527561"
- width="65.196854"
- height="17.007874"
- id="rect30"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(28.346455,61.0315)"
- id="text34"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="20.592567"
- y="11"
- id="tspan32"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">AEE</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_21">
- <g
- id="Graphic_28">
- <rect
- x="124.72442"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect38"
- style="fill:#ffffff" />
- <rect
- x="124.72442"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect40"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72442,31.26772)"
- id="text44"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan42"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_27">
- <rect
- x="124.72442"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect47"
- style="fill:#000000" />
- <rect
- x="124.72442"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect49"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72442,46.85827)"
- id="text53"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan51"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_26">
- <rect
- x="124.72441"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect56"
- style="fill:#ffffff" />
- <rect
- x="124.72441"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect58"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72441,61.0315)"
- id="text62"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="56.527908"
- y="11"
- id="tspan60"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">OS</tspan>
- </text>
- </g>
- <g
- id="Graphic_25">
- <rect
- x="124.72441"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect65"
- style="fill:#000000" />
- <rect
- x="124.72441"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect67"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72441,75.20473)"
- id="text71"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="55.525955"
- y="11"
- id="tspan69"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">SBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_24">
- <rect
- x="124.72441"
- y="87.874023"
- width="130.39371"
- height="17.007874"
- id="rect74"
- style="fill:#ffffff" />
- <rect
- x="124.72441"
- y="87.874023"
- width="130.39371"
- height="17.007874"
- id="rect76"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(124.72441,89.37796)"
- id="text80"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="53.190994"
- y="11"
- id="tspan78"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">SEE</tspan>
- </text>
- </g>
- <g
- id="Graphic_23">
- <rect
- x="192.75591"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect83"
- style="fill:#ffffff" />
- <rect
- x="192.75591"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect85"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(192.75591,31.26772)"
- id="text89"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan87"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_22">
- <rect
- x="192.75591"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect92"
- style="fill:#000000" />
- <rect
- x="192.75591"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect94"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(192.75591,46.85827)"
- id="text98"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan96"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_3">
- <g
- id="Graphic_20">
- <rect
- x="283.46457"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect102"
- style="fill:#000000" />
- <rect
- x="283.46457"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect104"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46457,75.20473)"
- id="text108"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="55.525955"
- y="11"
- id="tspan106"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">SBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_19">
- <rect
- x="283.46457"
- y="87.874023"
- width="266.4567"
- height="17.007874"
- id="rect111"
- style="fill:#ffffff" />
- <rect
- x="283.46457"
- y="87.874023"
- width="266.4567"
- height="17.007874"
- id="rect113"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46457,89.37796)"
- id="text117"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="104.5555"
- y="11"
- id="tspan115"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Hypervisor</tspan>
- </text>
- </g>
- <g
- id="Group_13">
- <g
- id="Graphic_18">
- <rect
- x="283.46457"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect120"
- style="fill:#ffffff" />
- <rect
- x="283.46457"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect122"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46458,31.26772)"
- id="text126"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan124"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_17">
- <rect
- x="283.46457"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect129"
- style="fill:#000000" />
- <rect
- x="283.46457"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect131"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46458,46.85827)"
- id="text135"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan133"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_16">
- <rect
- x="283.46457"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect138"
- style="fill:#ffffff" />
- <rect
- x="283.46457"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect140"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46457,61.0315)"
- id="text144"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="56.527908"
- y="11"
- id="tspan142"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">OS</tspan>
- </text>
- </g>
- <g
- id="Graphic_15">
- <rect
- x="351.49609"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect147"
- style="fill:#ffffff" />
- <rect
- x="351.49609"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect149"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(351.49608,31.26772)"
- id="text153"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan151"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_14">
- <rect
- x="351.49609"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect156"
- style="fill:#000000" />
- <rect
- x="351.49609"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect158"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(351.49608,46.85827)"
- id="text162"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan160"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_7">
- <g
- id="Graphic_12">
- <rect
- x="419.52756"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect166"
- style="fill:#ffffff" />
- <rect
- x="419.52756"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect168"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(419.52757,31.26772)"
- id="text172"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan170"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_11">
- <rect
- x="419.52756"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect175"
- style="fill:#000000" />
- <rect
- x="419.52756"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect177"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(419.52757,46.85827)"
- id="text181"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan179"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_10">
- <rect
- x="419.52756"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect184"
- style="fill:#ffffff" />
- <rect
- x="419.52756"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect186"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(419.52757,61.0315)"
- id="text190"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="56.527908"
- y="11"
- id="tspan188"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">OS</tspan>
- </text>
- </g>
- <g
- id="Graphic_9">
- <rect
- x="487.55908"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect193"
- style="fill:#ffffff" />
- <rect
- x="487.55908"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect195"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(487.55907,31.26772)"
- id="text199"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan197"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_8">
- <rect
- x="487.55908"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect202"
- style="fill:#000000" />
- <rect
- x="487.55908"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect204"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(487.55907,46.85827)"
- id="text208"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan206"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- </g>
- <g
- id="Graphic_6">
- <rect
- x="419.52756"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect212"
- style="fill:#000000" />
- <rect
- x="419.52756"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect214"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(419.52757,75.20473)"
- id="text218"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="55.525955"
- y="11"
- id="tspan216"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">SBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_5">
- <rect
- x="283.46457"
- y="104.88189"
- width="266.4567"
- height="11.338583"
- id="rect221"
- style="fill:#000000" />
- <rect
- x="283.46457"
- y="104.88189"
- width="266.4567"
- height="11.338583"
- id="rect223"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46457,103.55118)"
- id="text227"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="123.2264"
- y="11"
- id="tspan225"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">HBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_4">
- <rect
- x="283.46457"
- y="116.22048"
- width="266.4567"
- height="17.007874"
- id="rect230"
- style="fill:#ffffff" />
- <rect
- x="283.46457"
- y="116.22048"
- width="266.4567"
- height="17.007874"
- id="rect232"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(283.46458,117.72441)"
- id="text236"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="120.89143"
- y="11"
- id="tspan234"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">HEE</tspan>
- </text>
- </g>
- </g>
- </g>
- </g>
-</svg>
diff --git a/src/inkscape/proxy.svg b/src/inkscape/proxy.svg
deleted file mode 100644
index 7ee4457..0000000
--- a/src/inkscape/proxy.svg
+++ /dev/null
@@ -1,635 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- version="1.1"
- viewBox="36.3504 24.3018 412.5236 146.777"
- width="412.5236"
- height="146.777"
- id="svg179"
- sodipodi:docname="proxy.svg"
- inkscape:version="0.92.2 5c3e80d, 2017-08-06">
- <metadata
- id="metadata183">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <sodipodi:namedview
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1"
- objecttolerance="10"
- gridtolerance="10"
- guidetolerance="10"
- inkscape:pageopacity="0"
- inkscape:pageshadow="2"
- inkscape:window-width="640"
- inkscape:window-height="480"
- id="namedview181"
- showgrid="false"
- inkscape:zoom="0.63026699"
- inkscape:cx="206.2618"
- inkscape:cy="73.388496"
- inkscape:window-x="0"
- inkscape:window-y="0"
- inkscape:window-maximized="0"
- inkscape:current-layer="svg179" />
- <defs
- id="defs16">
- <font-face
- font-family="Helvetica"
- font-size="12"
- units-per-em="1000"
- underline-position="-75.68359"
- underline-thickness="49.316406"
- slope="0"
- x-height="522.9492"
- cap-height="717.28516"
- ascent="770.0195"
- descent="-229.98047"
- font-weight="400"
- id="font-face2">
- <font-face-src>
- <font-face-name
- name="Helvetica" />
- </font-face-src>
- </font-face>
- <marker
- orient="auto"
- overflow="visible"
- markerUnits="strokeWidth"
- id="FilledArrow_Marker"
- stroke-linejoin="miter"
- stroke-miterlimit="10"
- viewBox="-1 -4 10 8"
- markerWidth="10"
- markerHeight="8"
- color="black">
- <g
- id="g6">
- <path
- d="M 8 0 L 0 -3 L 0 3 Z"
- fill="currentColor"
- stroke="currentColor"
- stroke-width="1"
- id="path4" />
- </g>
- </marker>
- <marker
- orient="auto"
- overflow="visible"
- markerUnits="strokeWidth"
- id="FilledArrow_Marker_2"
- stroke-linejoin="miter"
- stroke-miterlimit="10"
- viewBox="-9 -4 10 8"
- markerWidth="10"
- markerHeight="8"
- color="black">
- <g
- id="g11">
- <path
- d="M -8 0 L 0 3 L 0 -3 Z"
- fill="currentColor"
- stroke="currentColor"
- stroke-width="1"
- id="path9" />
- </g>
- </marker>
- <font-face
- font-family="Helvetica"
- font-size="12"
- units-per-em="1000"
- underline-position="-75.68359"
- underline-thickness="49.316406"
- slope="-1e3"
- x-height="522.9492"
- cap-height="717.28516"
- ascent="770.0195"
- descent="-229.98047"
- font-style="italic"
- font-weight="400"
- id="font-face14">
- <font-face-src>
- <font-face-name
- name="Helvetica-Oblique" />
- </font-face-src>
- </font-face>
- </defs>
- <g
- id="Canvas_1"
- style="fill:none;fill-opacity:1;stroke:none;stroke-dasharray:none;stroke-opacity:1">
- <title
- id="title18">Canvas 1</title>
- <g
- id="Canvas_1: Layer 1">
- <title
- id="title20">Layer 1</title>
- <g
- id="Group_3">
- <g
- id="Group_18">
- <g
- id="Graphic_29">
- <rect
- x="291.96799"
- y="28.3458"
- width="155.90601"
- height="141.733"
- id="rect22"
- style="fill:#ffffff" />
- <rect
- x="291.96799"
- y="28.3458"
- width="155.90601"
- height="141.733"
- id="rect24"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(296.968,151.5788)"
- id="text28"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0"
- y="11"
- id="tspan26"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Target System</tspan>
- </text>
- </g>
- <g
- id="Graphic_28">
- <ellipse
- cx="368.50351"
- cy="127.5575"
- rx="59.527596"
- ry="19.842531"
- id="ellipse31"
- style="fill:#ffffff" />
- <ellipse
- cx="368.50351"
- cy="127.5575"
- rx="59.527596"
- ry="19.842531"
- id="ellipse33"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(325.8815,120.5575)"
- id="text37"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="14.942313"
- y="11"
- id="tspan35"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">OS Kernel</tspan>
- </text>
- </g>
- <g
- id="Graphic_27">
- <ellipse
- cx="321.73251"
- cy="65.195648"
- rx="24.094538"
- ry="17.007877"
- id="ellipse40"
- style="fill:#ffffff" />
- <ellipse
- cx="321.73251"
- cy="65.195648"
- rx="24.094538"
- ry="17.007877"
- id="ellipse42"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(307.4569,51.19565)"
- id="text48"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="3.5998187"
- y="11"
- id="tspan44"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">App</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="10.938686"
- y="25"
- id="tspan46"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">1</tspan>
- </text>
- </g>
- <g
- id="Line_26">
- <line
- x1="339.54889"
- y1="88.951027"
- x2="347.52393"
- y2="99.584503"
- id="line51"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Line_25">
- <line
- x1="291.96799"
- y1="90.707802"
- x2="447.87399"
- y2="90.706802"
- id="line54"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:4, 4" />
- </g>
- <g
- id="Graphic_24">
- <text
- transform="rotate(-90,252.9479,-177.5871)"
- id="text59"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.33203125"
- y="11"
- id="tspan57"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">User</tspan>
- </text>
- </g>
- <g
- id="Graphic_23">
- <text
- transform="rotate(-90,293.9288,-136.607)"
- id="text64"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.085089"
- y="11"
- id="tspan62"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Supervisor</tspan>
- </text>
- </g>
- <g
- id="Graphic_22">
- <ellipse
- cx="362.8345"
- cy="45.353001"
- rx="19.842531"
- ry="14.173223"
- id="ellipse67"
- style="fill:#ffffff" />
- <ellipse
- cx="362.8345"
- cy="45.353001"
- rx="19.842531"
- ry="14.173223"
- id="ellipse69"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(351.9605,31.353)"
- id="text75"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.19821875"
- y="11"
- id="tspan71"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">App</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="7.537086"
- y="25"
- id="tspan73"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">2</tspan>
- </text>
- </g>
- <g
- id="Line_21">
- <line
- x1="364.56064"
- y1="70.383324"
- x2="366.38556"
- y2="96.846024"
- id="line78"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_20">
- <ellipse
- cx="396.85049"
- cy="65.195"
- rx="19.842531"
- ry="14.173223"
- id="ellipse81"
- style="fill:#ffffff" />
- <ellipse
- cx="396.85049"
- cy="65.195"
- rx="19.842531"
- ry="14.173223"
- id="ellipse83"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(385.9765,51.195)"
- id="text89"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.19821875"
- y="11"
- id="tspan85"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">App</tspan>
- <tspan
- font-size="12"
- font-style="italic"
- font-weight="400"
- x="7.537086"
- y="25"
- id="tspan87"
- style="font-style:italic;font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">n</tspan>
- </text>
- </g>
- <g
- id="Line_19">
- <line
- x1="386.21109"
- y1="88.601303"
- x2="381.93225"
- y2="98.014664"
- id="line92"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- </g>
- <g
- id="Graphic_17">
- <rect
- x="85.039398"
- y="28.3458"
- width="141.73199"
- height="141.733"
- id="rect96"
- style="fill:#ffffff" />
- <rect
- x="85.039398"
- y="28.3458"
- width="141.73199"
- height="141.733"
- id="rect98"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(90.0394,151.5788)"
- id="text102"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0"
- y="11"
- id="tspan100"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Front-End Host</tspan>
- </text>
- </g>
- <g
- id="Graphic_16">
- <ellipse
- cx="171.496"
- cy="53.858299"
- rx="43.937069"
- ry="19.842531"
- id="ellipse105"
- style="fill:#ffffff" />
- <ellipse
- cx="171.496"
- cy="53.858299"
- rx="43.937069"
- ry="19.842531"
- id="ellipse107"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(141.3464,39.8583)"
- id="text113"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="3.4718657"
- y="11"
- id="tspan109"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Front-End</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="12.477725"
- y="25"
- id="tspan111"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Server</tspan>
- </text>
- </g>
- <g
- id="Graphic_15">
- <path
- d="m 161.575,145.98473 v -34.01576 c 0,-2.34709 13.33418,-4.25197 29.7638,-4.25197 16.42962,0 29.7638,1.90488 29.7638,4.25197 v 34.01576 c 0,2.34709 -13.33418,4.25197 -29.7638,4.25197 -16.42962,0 -29.7638,-1.90488 -29.7638,-4.25197"
- id="path116"
- inkscape:connector-curvature="0"
- style="fill:#ffffff" />
- <path
- d="m 161.575,145.98473 v -34.01576 c 0,-2.34709 13.33418,-4.25197 29.7638,-4.25197 16.42962,0 29.7638,1.90488 29.7638,4.25197 v 34.01576 c 0,2.34709 -13.33418,4.25197 -29.7638,4.25197 -16.42962,0 -29.7638,-1.90488 -29.7638,-4.25197 m 0,-34.01576 c 0,2.34709 13.33418,4.25197 29.7638,4.25197 16.42962,0 29.7638,-1.90488 29.7638,-4.25197"
- id="path118"
- inkscape:connector-curvature="0"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(166.575,117.10284)"
- id="text124"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.091925"
- y="11"
- id="tspan120"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Host File</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="4.7598939"
- y="25"
- id="tspan122"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">System</tspan>
- </text>
- </g>
- <g
- id="Line_14">
- <line
- x1="182.47607"
- y1="83.661171"
- x2="187.91631"
- y2="98.427406"
- id="line127"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Line_13">
- <line
- x1="215.54337"
- y1="70.336128"
- x2="318.69199"
- y2="108.92334"
- id="line130"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_12">
- <text
- transform="translate(227.795,49.6922)"
- id="text137"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="8.9082003"
- y="11"
- id="tspan133"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Proxied</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="7.912106"
- y="25"
- id="tspan135"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Devices</tspan>
- </text>
- </g>
- <g
- id="Line_11">
- <path
- d="M 118.19149,46.849605 C 111.044,44.920685 103.9098,42.83136 96.378,45.3543 85.45987,49.011565 72.282474,69.92131 62.3622,70.8661 55.270754,71.54148 49.62638,64.49124 43.877895,57.99966"
- id="path140"
- inkscape:connector-curvature="0"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_10">
- <text
- transform="translate(36.8504,24.3018)"
- id="text147"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="12.046186"
- y="11"
- id="tspan143"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Host</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="4.0364203"
- y="25"
- id="tspan145"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Internet</tspan>
- </text>
- </g>
- <g
- id="Group_5">
- <g
- id="Graphic_9">
- <rect
- x="90.708603"
- y="90.708702"
- width="59.527599"
- height="39.685001"
- id="rect150"
- style="fill:#ffffff" />
- <rect
- x="90.708603"
- y="90.708702"
- width="59.527599"
- height="39.685001"
- id="rect152"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Graphic_8">
- <rect
- x="93.543198"
- y="93.543404"
- width="53.858398"
- height="34.015701"
- id="rect155"
- style="fill:#ffffff" />
- <rect
- x="93.543198"
- y="93.543404"
- width="53.858398"
- height="34.015701"
- id="rect157"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Graphic_7">
- <text
- transform="translate(95.8006,96.7244)"
- id="text164"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="12.046186"
- y="11"
- id="tspan160"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Host</tspan>
- <tspan
- font-size="12"
- font-weight="400"
- x="2.3694279"
- y="25"
- id="tspan162"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Console</tspan>
- </text>
- </g>
- <g
- id="Graphic_6">
- <path
- d="m 150.2361,130.39403 -17.00788,17.00777 c 0,3e-5 -62.36212,3e-5 -62.36212,3e-5 -8e-5,0 19.84242,-17.0078 19.84242,-17.0078 z"
- id="path167"
- inkscape:connector-curvature="0"
- style="fill:#ffffff" />
- <path
- d="m 150.2361,130.39403 -17.00788,17.00777 c 0,3e-5 -62.36212,3e-5 -62.36212,3e-5 -8e-5,0 19.84242,-17.0078 19.84242,-17.0078 z"
- id="path169"
- inkscape:connector-curvature="0"
- style="stroke:#000000;stroke-width:2;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- </g>
- <g
- id="Line_4">
- <line
- x1="145.62236"
- y1="82.606789"
- x2="147.6561"
- y2="80.347092"
- id="line173"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- </g>
- </g>
- </g>
-</svg>
diff --git a/src/inkscape/virtimps.svg b/src/inkscape/virtimps.svg
deleted file mode 100644
index 11516c1..0000000
--- a/src/inkscape/virtimps.svg
+++ /dev/null
@@ -1,730 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- version="1.1"
- viewBox="18.01575 11.338583 454.8504 95.04331"
- width="454.8504"
- height="95.04331"
- id="svg212"
- sodipodi:docname="virtimps.svg"
- inkscape:version="0.92.2 5c3e80d, 2017-08-06">
- <metadata
- id="metadata216">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <sodipodi:namedview
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1"
- objecttolerance="10"
- gridtolerance="10"
- guidetolerance="10"
- inkscape:pageopacity="0"
- inkscape:pageshadow="2"
- inkscape:window-width="640"
- inkscape:window-height="480"
- id="namedview214"
- showgrid="false"
- inkscape:zoom="0.57161651"
- inkscape:cx="227.4252"
- inkscape:cy="47.521656"
- inkscape:window-x="0"
- inkscape:window-y="0"
- inkscape:window-maximized="0"
- inkscape:current-layer="svg212" />
- <defs
- id="defs14">
- <font-face
- font-family="Helvetica"
- font-size="12"
- units-per-em="1000"
- underline-position="-75.68359"
- underline-thickness="49.316406"
- slope="0"
- x-height="522.9492"
- cap-height="717.28516"
- ascent="770.0195"
- descent="-229.98047"
- font-weight="400"
- id="font-face2">
- <font-face-src>
- <font-face-name
- name="Helvetica" />
- </font-face-src>
- </font-face>
- <marker
- orient="auto"
- overflow="visible"
- markerUnits="strokeWidth"
- id="FilledArrow_Marker"
- stroke-linejoin="miter"
- stroke-miterlimit="10"
- viewBox="-1 -4 10 8"
- markerWidth="10"
- markerHeight="8"
- color="black">
- <g
- id="g6">
- <path
- d="M 8 0 L 0 -3 L 0 3 Z"
- fill="currentColor"
- stroke="currentColor"
- stroke-width="1"
- id="path4" />
- </g>
- </marker>
- <marker
- orient="auto"
- overflow="visible"
- markerUnits="strokeWidth"
- id="FilledArrow_Marker_2"
- stroke-linejoin="miter"
- stroke-miterlimit="10"
- viewBox="-9 -4 10 8"
- markerWidth="10"
- markerHeight="8"
- color="black">
- <g
- id="g11">
- <path
- d="M -8 0 L 0 3 L 0 -3 Z"
- fill="currentColor"
- stroke="currentColor"
- stroke-width="1"
- id="path9" />
- </g>
- </marker>
- </defs>
- <g
- id="virtimps"
- style="fill:none;fill-opacity:1;stroke:none;stroke-dasharray:none;stroke-opacity:1">
- <title
- id="title16">virtimps</title>
- <g
- id="virtimps: Layer 1">
- <title
- id="title18">Layer 1</title>
- <g
- id="Graphic_36">
- <rect
- x="113.38583"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect20"
- style="fill:#000000" />
- <rect
- x="113.38583"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect22"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(113.38583,75.20473)"
- id="text26"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="55.525955"
- y="11"
- id="tspan24"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">SBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_35">
- <rect
- x="113.38583"
- y="87.874023"
- width="266.4567"
- height="17.007874"
- id="rect29"
- style="fill:#ffffff" />
- <rect
- x="113.38583"
- y="87.874023"
- width="266.4567"
- height="17.007874"
- id="rect31"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(113.38583,89.37796)"
- id="text35"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="70.307449"
- y="11"
- id="tspan33"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Virtual Machine Monitor</tspan>
- </text>
- </g>
- <g
- id="Group_29">
- <g
- id="Graphic_34">
- <rect
- x="113.38583"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect38"
- style="fill:#ffffff" />
- <rect
- x="113.38583"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect40"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(113.38583,31.26772)"
- id="text44"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan42"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_33">
- <rect
- x="113.38583"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect47"
- style="fill:#000000" />
- <rect
- x="113.38583"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect49"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(113.38583,46.85827)"
- id="text53"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan51"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_32">
- <rect
- x="113.38583"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect56"
- style="fill:#ffffff" />
- <rect
- x="113.38583"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect58"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(113.38583,61.0315)"
- id="text62"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="38.853104"
- y="11"
- id="tspan60"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Guest OS</tspan>
- </text>
- </g>
- <g
- id="Graphic_31">
- <rect
- x="181.41733"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect65"
- style="fill:#ffffff" />
- <rect
- x="181.41733"
- y="28.346457"
- width="62.362206"
- height="19.842522"
- id="rect67"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(181.41733,31.26772)"
- id="text71"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan69"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_30">
- <rect
- x="181.41733"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect74"
- style="fill:#000000" />
- <rect
- x="181.41733"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect76"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(181.41733,46.85827)"
- id="text80"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan78"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- </g>
- <g
- id="Group_23">
- <g
- id="Graphic_28">
- <rect
- x="249.44884"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect84"
- style="fill:#ffffff" />
- <rect
- x="249.44884"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect86"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(249.44883,31.26772)"
- id="text90"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan88"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_27">
- <rect
- x="249.44884"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect93"
- style="fill:#000000" />
- <rect
- x="249.44884"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect95"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(249.44883,46.85827)"
- id="text99"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan97"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- <g
- id="Graphic_26">
- <rect
- x="249.44882"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect102"
- style="fill:#ffffff" />
- <rect
- x="249.44882"
- y="59.527561"
- width="130.39371"
- height="17.007874"
- id="rect104"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(249.44882,61.0315)"
- id="text108"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="38.853104"
- y="11"
- id="tspan106"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Guest OS</tspan>
- </text>
- </g>
- <g
- id="Graphic_25">
- <rect
- x="317.48032"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect111"
- style="fill:#ffffff" />
- <rect
- x="317.48032"
- y="28.346458"
- width="62.362206"
- height="19.842522"
- id="rect113"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(317.48032,31.26772)"
- id="text117"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="1.8285637"
- y="11"
- id="tspan115"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Application</tspan>
- </text>
- </g>
- <g
- id="Graphic_24">
- <rect
- x="317.48032"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect120"
- style="fill:#000000" />
- <rect
- x="317.48032"
- y="48.18898"
- width="62.362206"
- height="11.338583"
- id="rect122"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(317.48032,46.85827)"
- id="text126"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="21.510204"
- y="11"
- id="tspan124"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">ABI</tspan>
- </text>
- </g>
- </g>
- <g
- id="Graphic_22">
- <rect
- x="249.44882"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect130"
- style="fill:#000000" />
- <rect
- x="249.44882"
- y="76.535439"
- width="130.39371"
- height="11.338583"
- id="rect132"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- <text
- transform="translate(249.44882,75.20473)"
- id="text136"
- style="fill:#ffffff">
- <tspan
- font-size="12"
- font-weight="400"
- x="55.525955"
- y="11"
- id="tspan134"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#ffffff">SBI</tspan>
- </text>
- </g>
- <g
- id="Graphic_21">
- <text
- transform="translate(36.850395,11.338583)"
- id="text141"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.25195312"
- y="11"
- id="tspan139"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Classic Virtualization</tspan>
- </text>
- </g>
- <g
- id="Graphic_20">
- <text
- transform="translate(338.0197,11.338583)"
- id="text146"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.4785156"
- y="11"
- id="tspan144"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">With Hypervisor Support</tspan>
- </text>
- </g>
- <g
- id="Line_19">
- <line
- x1="56.692917"
- y1="28.346457"
- x2="107.71654"
- y2="28.346457"
- id="line149"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_18">
- <line
- x1="56.692917"
- y1="79.370079"
- x2="107.71654"
- y2="79.370079"
- id="line152"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_17">
- <line
- x1="56.692917"
- y1="104.88189"
- x2="107.71654"
- y2="104.88189"
- id="line155"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_16">
- <line
- x1="82.097008"
- y1="38.245979"
- x2="82.402992"
- y2="69.470558"
- id="line158"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_15">
- <text
- transform="translate(49.04331,46.85827)"
- id="text163"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.33203125"
- y="11"
- id="tspan161"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">User</tspan>
- </text>
- </g>
- <g
- id="Graphic_14">
- <text
- transform="translate(18.01575,85.03937)"
- id="text168"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.32128906"
- y="11"
- id="tspan166"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Supervisor</tspan>
- </text>
- </g>
- <g
- id="Line_13">
- <line
- x1="82.204727"
- y1="89.270081"
- x2="82.204727"
- y2="95.981888"
- id="line171"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Line_12">
- <line
- x1="385.51181"
- y1="82.204727"
- x2="436.53546"
- y2="82.204727"
- id="line174"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Graphic_11">
- <text
- transform="translate(414.86615,62.36221)"
- id="text179"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.32128906"
- y="11"
- id="tspan177"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Supervisor</tspan>
- </text>
- </g>
- <g
- id="Line_10">
- <line
- x1="408.11566"
- y1="66.592644"
- x2="408.07333"
- y2="72.305"
- id="line182"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Line_9">
- <line
- x1="385.51181"
- y1="56.692917"
- x2="436.53546"
- y2="56.692917"
- id="line185"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Line_8">
- <line
- x1="385.51181"
- y1="104.88189"
- x2="436.53546"
- y2="104.88189"
- id="line188"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- <g
- id="Graphic_7">
- <text
- transform="translate(414.86615,85.03937)"
- id="text193"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.32714844"
- y="11"
- id="tspan191"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">Hypervisor</tspan>
- </text>
- </g>
- <g
- id="Line_6">
- <line
- x1="407.71823"
- y1="92.102318"
- x2="407.78177"
- y2="94.984299"
- id="line196"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Graphic_5">
- <text
- transform="translate(413.8583,36.850395)"
- id="text201"
- style="fill:#000000">
- <tspan
- font-size="12"
- font-weight="400"
- x="0.33203125"
- y="11"
- id="tspan199"
- style="font-weight:400;font-size:12px;font-family:Helvetica;fill:#000000">User</tspan>
- </text>
- </g>
- <g
- id="Line_4">
- <line
- x1="408"
- y1="38.246456"
- x2="408"
- y2="46.792915"
- id="line204"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker-start:url(#FilledArrow_Marker_2);marker-end:url(#FilledArrow_Marker)" />
- </g>
- <g
- id="Line_3">
- <line
- x1="385.51181"
- y1="28.346457"
- x2="436.53546"
- y2="28.346457"
- id="line207"
- style="stroke:#000000;stroke-width:1;stroke-linecap:round;stroke-linejoin:round" />
- </g>
- </g>
- </g>
-</svg>
diff --git a/src/instr-table.tex b/src/instr-table.tex
deleted file mode 100644
index d51317c..0000000
--- a/src/instr-table.tex
+++ /dev/null
@@ -1,2004 +0,0 @@
-
-\newpage
-
-\begin{table}[p]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.4in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.4in}p{0.6in}p{0.4in}p{0.6in}p{0.7in}l}
-& & & & & & & & & & \\
- &
-\multicolumn{1}{l}{\instbit{31}} &
-\multicolumn{1}{r}{\instbit{27}} &
-\instbit{26} &
-\instbit{25} &
-\multicolumn{1}{l}{\instbit{24}} &
-\multicolumn{1}{r}{\instbit{20}} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{funct7} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & R-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & I-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} & S-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[12$\vert$10:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{imm[4:1$\vert$11]} &
-\multicolumn{1}{c|}{opcode} & B-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{8}{|c|}{imm[31:12]} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & U-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{8}{|c|}{imm[20$\vert$10:1$\vert$11$\vert$19:12]} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & J-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV32I Base Instruction Set} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{8}{|c|}{imm[31:12]} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110111} & LUI \\
-\cline{2-11}
-
-
-&
-\multicolumn{8}{|c|}{imm[31:12]} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010111} & AUIPC \\
-\cline{2-11}
-
-
-&
-\multicolumn{8}{|c|}{imm[20$\vert$10:1$\vert$11$\vert$19:12]} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1101111} & JAL \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1100111} & JALR \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[12$\vert$10:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{imm[4:1$\vert$11]} &
-\multicolumn{1}{c|}{1100011} & BEQ \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[12$\vert$10:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{imm[4:1$\vert$11]} &
-\multicolumn{1}{c|}{1100011} & BNE \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[12$\vert$10:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{100} &
-\multicolumn{1}{c|}{imm[4:1$\vert$11]} &
-\multicolumn{1}{c|}{1100011} & BLT \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[12$\vert$10:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{imm[4:1$\vert$11]} &
-\multicolumn{1}{c|}{1100011} & BGE \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[12$\vert$10:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{110} &
-\multicolumn{1}{c|}{imm[4:1$\vert$11]} &
-\multicolumn{1}{c|}{1100011} & BLTU \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[12$\vert$10:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{111} &
-\multicolumn{1}{c|}{imm[4:1$\vert$11]} &
-\multicolumn{1}{c|}{1100011} & BGEU \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0000011} & LB \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0000011} & LH \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0000011} & LW \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{100} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0000011} & LBU \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0000011} & LHU \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{0100011} & SB \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{0100011} & SH \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{0100011} & SW \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & ADDI \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & SLTI \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & SLTIU \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{100} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & XORI \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{110} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & ORI \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{111} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & ANDI \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{shamt} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & SLLI \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{shamt} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & SRLI \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0100000} &
-\multicolumn{2}{c|}{shamt} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & SRAI \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & ADD \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0100000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & SUB \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & SLL \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & SLT \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & SLTU \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{100} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & XOR \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & SRL \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0100000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & SRA \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{110} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & OR \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{111} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & AND \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{fm} &
-\multicolumn{3}{c|}{pred} &
-\multicolumn{1}{c|}{succ} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0001111} & FENCE \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{000000000000} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{1110011} & ECALL \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{000000000001} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{1110011} & EBREAK \\
-\cline{2-11}
-
-
-\end{tabular}
-\end{center}
-\end{small}
-
-\end{table}
-
-
-\newpage
-
-\begin{table}[p]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.4in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.4in}p{0.6in}p{0.4in}p{0.6in}p{0.7in}l}
-& & & & & & & & & & \\
- &
-\multicolumn{1}{l}{\instbit{31}} &
-\multicolumn{1}{r}{\instbit{27}} &
-\instbit{26} &
-\instbit{25} &
-\multicolumn{1}{l}{\instbit{24}} &
-\multicolumn{1}{r}{\instbit{20}} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{funct7} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & R-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & I-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} & S-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV64I Base Instruction Set (in addition to RV32I)} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{110} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0000011} & LWU \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0000011} & LD \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{0100011} & SD \\
-\cline{2-11}
-
-
-&
-\multicolumn{3}{|c|}{000000} &
-\multicolumn{3}{c|}{shamt} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & SLLI \\
-\cline{2-11}
-
-
-&
-\multicolumn{3}{|c|}{000000} &
-\multicolumn{3}{c|}{shamt} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & SRLI \\
-\cline{2-11}
-
-
-&
-\multicolumn{3}{|c|}{010000} &
-\multicolumn{3}{c|}{shamt} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0010011} & SRAI \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0011011} & ADDIW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{shamt} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0011011} & SLLIW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{shamt} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0011011} & SRLIW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0100000} &
-\multicolumn{2}{c|}{shamt} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0011011} & SRAIW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0111011} & ADDW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0100000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0111011} & SUBW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0111011} & SLLW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0111011} & SRLW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0100000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0111011} & SRAW \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV32/RV64 \emph{Zifencei} Standard Extension} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0001111} & FENCE.I \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV32/RV64 \emph{Zicsr} Standard Extension} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{csr} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1110011} & CSRRW \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{csr} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1110011} & CSRRS \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{csr} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1110011} & CSRRC \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{csr} &
-\multicolumn{1}{c|}{zimm} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1110011} & CSRRWI \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{csr} &
-\multicolumn{1}{c|}{zimm} &
-\multicolumn{1}{c|}{110} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1110011} & CSRRSI \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{csr} &
-\multicolumn{1}{c|}{zimm} &
-\multicolumn{1}{c|}{111} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1110011} & CSRRCI \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV32M Standard Extension} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & MUL \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & MULH \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & MULHSU \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & MULHU \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{100} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & DIV \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & DIVU \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{110} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & REM \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{111} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0110011} & REMU \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV64M Standard Extension (in addition to RV32M)} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0111011} & MULW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{100} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0111011} & DIVW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{101} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0111011} & DIVUW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{110} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0111011} & REMW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{111} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0111011} & REMUW \\
-\cline{2-11}
-
-
-\end{tabular}
-\end{center}
-\end{small}
-
-\end{table}
-
-
-\newpage
-
-\begin{table}[p]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.4in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.4in}p{0.6in}p{0.4in}p{0.6in}p{0.7in}l}
-& & & & & & & & & & \\
- &
-\multicolumn{1}{l}{\instbit{31}} &
-\multicolumn{1}{r}{\instbit{27}} &
-\instbit{26} &
-\instbit{25} &
-\multicolumn{1}{l}{\instbit{24}} &
-\multicolumn{1}{r}{\instbit{20}} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{funct7} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & R-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV32A Standard Extension} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{00010} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & LR.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{00011} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & SC.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{00001} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOSWAP.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{00000} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOADD.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{00100} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOXOR.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{01100} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOAND.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{01000} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOOR.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{10000} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOMIN.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{10100} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOMAX.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{11000} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOMINU.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{11100} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOMAXU.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV64A Standard Extension (in addition to RV32A)} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{00010} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & LR.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{00011} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & SC.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{00001} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOSWAP.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{00000} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOADD.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{00100} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOXOR.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{01100} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOAND.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{01000} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOOR.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{10000} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOMIN.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{10100} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOMAX.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{11000} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOMINU.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{11100} &
-\multicolumn{1}{c|}{aq} &
-\multicolumn{1}{c|}{rl} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0101111} & AMOMAXU.D \\
-\cline{2-11}
-
-
-\end{tabular}
-\end{center}
-\end{small}
-
-\end{table}
-
-
-\newpage
-
-\begin{table}[p]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.4in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.4in}p{0.6in}p{0.4in}p{0.6in}p{0.7in}l}
-& & & & & & & & & & \\
- &
-\multicolumn{1}{l}{\instbit{31}} &
-\multicolumn{1}{r}{\instbit{27}} &
-\instbit{26} &
-\instbit{25} &
-\multicolumn{1}{l}{\instbit{24}} &
-\multicolumn{1}{r}{\instbit{20}} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{funct7} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & R-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{rs3} &
-\multicolumn{2}{c|}{funct2} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & R4-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & I-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} & S-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV32F Standard Extension} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0000111} & FLW \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{0100111} & FSW \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{rs3} &
-\multicolumn{2}{c|}{00} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1000011} & FMADD.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{rs3} &
-\multicolumn{2}{c|}{00} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1000111} & FMSUB.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{rs3} &
-\multicolumn{2}{c|}{00} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1001011} & FNMSUB.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{rs3} &
-\multicolumn{2}{c|}{00} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1001111} & FNMADD.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FADD.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000100} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FSUB.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0001000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FMUL.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0001100} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FDIV.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0101100} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FSQRT.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0010000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FSGNJ.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0010000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FSGNJN.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0010000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FSGNJX.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0010100} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FMIN.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0010100} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FMAX.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1100000} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.W.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1100000} &
-\multicolumn{2}{c|}{00001} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.WU.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1110000} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FMV.X.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1010000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FEQ.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1010000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FLT.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1010000} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FLE.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1110000} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCLASS.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1101000} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.S.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1101000} &
-\multicolumn{2}{c|}{00001} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.S.WU \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1111000} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FMV.W.X \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV64F Standard Extension (in addition to RV32F)} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1100000} &
-\multicolumn{2}{c|}{00010} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.L.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1100000} &
-\multicolumn{2}{c|}{00011} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.LU.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1101000} &
-\multicolumn{2}{c|}{00010} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.S.L \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1101000} &
-\multicolumn{2}{c|}{00011} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.S.LU \\
-\cline{2-11}
-
-
-\end{tabular}
-\end{center}
-\end{small}
-
-\end{table}
-
-
-\newpage
-
-\begin{table}[p]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.4in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.4in}p{0.6in}p{0.4in}p{0.6in}p{0.7in}l}
-& & & & & & & & & & \\
- &
-\multicolumn{1}{l}{\instbit{31}} &
-\multicolumn{1}{r}{\instbit{27}} &
-\instbit{26} &
-\instbit{25} &
-\multicolumn{1}{l}{\instbit{24}} &
-\multicolumn{1}{r}{\instbit{20}} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{funct7} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & R-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{rs3} &
-\multicolumn{2}{c|}{funct2} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & R4-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & I-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} & S-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV32D Standard Extension} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{0000111} & FLD \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{011} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{0100111} & FSD \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{rs3} &
-\multicolumn{2}{c|}{01} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1000011} & FMADD.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{rs3} &
-\multicolumn{2}{c|}{01} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1000111} & FMSUB.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{rs3} &
-\multicolumn{2}{c|}{01} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1001011} & FNMSUB.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{2}{|c|}{rs3} &
-\multicolumn{2}{c|}{01} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1001111} & FNMADD.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FADD.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000101} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FSUB.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0001001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FMUL.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0001101} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FDIV.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0101101} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FSQRT.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0010001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FSGNJ.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0010001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FSGNJN.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0010001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FSGNJX.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0010101} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FMIN.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0010101} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FMAX.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0100000} &
-\multicolumn{2}{c|}{00001} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.S.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0100001} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.D.S \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1010001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{010} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FEQ.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1010001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FLT.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1010001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FLE.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1110001} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{001} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCLASS.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1100001} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.W.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1100001} &
-\multicolumn{2}{c|}{00001} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.WU.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1101001} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.D.W \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1101001} &
-\multicolumn{2}{c|}{00001} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.D.WU \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf RV64D Standard Extension (in addition to RV32D)} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1100001} &
-\multicolumn{2}{c|}{00010} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.L.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1100001} &
-\multicolumn{2}{c|}{00011} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.LU.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1110001} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FMV.X.D \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1101001} &
-\multicolumn{2}{c|}{00010} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.D.L \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1101001} &
-\multicolumn{2}{c|}{00011} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FCVT.D.LU \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{1111001} &
-\multicolumn{2}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1010011} & FMV.D.X \\
-\cline{2-11}
-
-
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Instruction listing for RISC-V}
-\end{table}
-
diff --git a/src/intro.adoc b/src/intro.adoc
new file mode 100644
index 0000000..6af0425
--- /dev/null
+++ b/src/intro.adoc
@@ -0,0 +1,696 @@
+== Introduction
+
+
+RISC-V (pronounced "risk-five") is a new instruction-set architecture
+(ISA) that was originally designed to support computer architecture
+research and education, but which we now hope will also become a
+standard free and open architecture for industry implementations. Our
+goals in defining RISC-V include:
+
+* A completely _open_ ISA that is freely available to academia and
+industry.
+* A _real_ ISA suitable for direct native hardware implementation, not
+just simulation or binary translation.
+* An ISA that avoids "over-architecting" for a particular
+microarchitecture style (e.g., microcoded, in-order, decoupled,
+out-of-order) or implementation technology (e.g., full-custom, ASIC,
+FPGA), but which allows efficient implementation in any of these.
+* An ISA separated into a _small_ base integer ISA, usable by itself as
+a base for customized accelerators or for educational purposes, and
+optional standard extensions, to support general-purpose software
+development.
+* Support for the revised 2008 IEEE-754 floating-point standard. cite:[ieee754-2008]
+* An ISA supporting extensive ISA extensions and specialized variants.
+* Both 32-bit and 64-bit address space variants for applications,
+operating system kernels, and hardware implementations.
+* An ISA with support for highly parallel multicore or manycore
+implementations, including heterogeneous multiprocessors.
+* Optional _variable-length instructions_ to both expand available
+instruction encoding space and to support an optional _dense instruction
+encoding_ for improved performance, static code size, and energy
+efficiency.
+* A fully virtualizable ISA to ease hypervisor development.
+* An ISA that simplifies experiments with new privileged architecture
+designs.
+
+[NOTE]
+====
+Commentary on our design decisions is formatted as in this paragraph.
+This non-normative text can be skipped if the reader is only interested
+in the specification itself.
+====
+
+[NOTE]
+====
+The name RISC-V was chosen to represent the fifth major RISC ISA design
+from UC Berkeley (RISC-I cite:[riscI-isca1981], RISC-II cite:[Katevenis:1983], SOAR cite:[Ungar:1984], and SPUR cite:[spur-jsscc1989] were the first
+four). We also pun on the use of the Roman numeral "V" to signify
+"variations" and "vectors", as support for a range of architecture
+research, including various data-parallel accelerators, is an explicit
+goal of the ISA design.
+====
+(((ISA, definition)))
+The RISC-V ISA is defined avoiding implementation details as much as
+possible (although commentary is included on implementation-driven
+decisions) and should be read as the software-visible interface to a
+wide variety of implementations rather than as the design of a
+particular hardware artifact. The RISC-V manual is structured in two
+volumes. This volume covers the design of the base _unprivileged_
+instructions, including optional unprivileged ISA extensions.
+Unprivileged instructions are those that are generally usable in all
+privilege modes in all privileged architectures, though behavior might
+vary depending on privilege mode and privilege architecture. The second
+volume provides the design of the first ("classic") privileged
+architecture. The manuals use IEC 80000-13:2008 conventions, with a byte
+of 8 bits.
+
+[NOTE]
+====
+In the unprivileged ISA design, we tried to remove any dependence on
+particular microarchitectural features, such as cache line size, or on
+privileged architecture details, such as page translation. This is both
+for simplicity and to allow maximum flexibility for alternative
+microarchitectures or alternative privileged architectures.
+====
+
+=== RISC-V Hardware Platform Terminology
+
+
+A RISC-V hardware platform can contain one or more RISC-V-compatible
+processing cores together with other non-RISC-V-compatible cores,
+fixed-function accelerators, various physical memory structures, I/O
+devices, and an interconnect structure to allow the components to
+communicate.
+(((core, component)))
+
+A component is termed a _core_ if it contains an independent instruction
+fetch unit. A RISC-V-compatible core might support multiple
+RISC-V-compatible hardware threads, or _harts_, through multithreading.
+(((core, extensions, coprocessor)))
+
+A RISC-V core might have additional specialized instruction-set
+extensions or an added _coprocessor_. We use the term _coprocessor_ to
+refer to a unit that is attached to a RISC-V core and is mostly
+sequenced by a RISC-V instruction stream, but which contains additional
+architectural state and instruction-set extensions, and possibly some
+limited autonomy relative to the primary RISC-V instruction stream.
+
+We use the term _accelerator_ to refer to either a non-programmable
+fixed-function unit or a core that can operate autonomously but is
+specialized for certain tasks. In RISC-V systems, we expect many
+programmable accelerators will be RISC-V-based cores with specialized
+instruction-set extensions and/or customized coprocessors. An important
+class of RISC-V accelerators are I/O accelerators, which offload I/O
+processing tasks from the main application cores.
+(((core, accelerator)))
+
+The system-level organization of a RISC-V hardware platform can range
+from a single-core microcontroller to a many-thousand-node cluster of
+shared-memory manycore server nodes. Even small systems-on-a-chip might
+be structured as a hierarchy of multicomputers and/or multiprocessors to
+modularize development effort or to provide secure isolation between
+subsystems.
+(((core, cluster, multiprocessors)))
+
+=== RISC-V Software Execution Environments and Harts
+
+
+The behavior of a RISC-V program depends on the execution environment in
+which it runs. A RISC-V execution environment interface (EEI) defines
+the initial state of the program, the number and type of harts in the
+environment including the privilege modes supported by the harts, the
+accessibility and attributes of memory and I/O regions, the behavior of
+all legal instructions executed on each hart (i.e., the ISA is one
+component of the EEI), and the handling of any interrupts or exceptions
+raised during execution including environment calls. Examples of EEIs
+include the Linux application binary interface (ABI), or the RISC-V
+supervisor binary interface (SBI). The implementation of a RISC-V
+execution environment can be pure hardware, pure software, or a
+combination of hardware and software. For example, opcode traps and
+software emulation can be used to implement functionality not provided
+in hardware. Examples of execution environment implementations include:
+
+* "Bare metal" hardware platforms where harts are directly implemented
+by physical processor threads and instructions have full access to the
+physical address space. The hardware platform defines an execution
+environment that begins at power-on reset.
+* RISC-V operating systems that provide multiple user-level execution
+environments by multiplexing user-level harts onto available physical
+processor threads and by controlling access to memory via virtual
+memory.
+* RISC-V hypervisors that provide multiple supervisor-level execution
+environments for guest operating systems.
+* RISC-V emulators, such as Spike, QEMU or rv8, which emulate RISC-V
+harts on an underlying x86 system, and which can provide either a
+user-level or a supervisor-level execution environment.
+
+[NOTE]
+====
+A bare hardware platform can be considered to define an EEI, where the
+accessible harts, memory, and other devices populate the environment,
+and the initial state is that at power-on reset. Generally, most
+software is designed to use a more abstract interface to the hardware,
+as more abstract EEIs provide greater portability across different
+hardware platforms. Often EEIs are layered on top of one another, where
+one higher-level EEI uses another lower-level EEI.
+====
+(((hart, execution environment)))
+From the perspective of software running in a given execution
+environment, a hart is a resource that autonomously fetches and executes
+RISC-V instructions within that execution environment. In this respect,
+a hart behaves like a hardware thread resource even if time-multiplexed
+onto real hardware by the execution environment. Some EEIs support the
+creation and destruction of additional harts, for example, via
+environment calls to fork new harts.
+
+The execution environment is responsible for ensuring the eventual
+forward progress of each of its harts. For a given hart, that
+responsibility is suspended while the hart is exercising a mechanism
+that explicitly waits for an event, such as the wait-for-interrupt
+instruction defined in Volume II of this specification; and that
+responsibility ends if the hart is terminated. The following events
+constitute forward progress:
+
+* The retirement of an instruction.
+* A trap, as defined in <<trap-defn>>.
+* Any other event defined by an extension to constitute forward
+progress.
+
+[NOTE]
+====
+The term hart was introduced in the work on Lithe cite:[lithe-pan-hotpar09] and cite:[lithe-pan-pldi10] to provide a term to
+represent an abstract execution resource as opposed to a software thread
+programming abstraction.
+
+The important distinction between a hardware thread (hart) and a
+software thread context is that the software running inside an execution
+environment is not responsible for causing progress of each of its
+harts; that is the responsibility of the outer execution environment. So
+the environment's harts operate like hardware threads from the
+perspective of the software inside the execution environment.
+
+An execution environment implementation might time-multiplex a set of
+guest harts onto fewer host harts provided by its own execution
+environment but must do so in a way that guest harts operate like
+independent hardware threads. In particular, if there are more guest
+harts than host harts then the execution environment must be able to
+preempt the guest harts and must not wait indefinitely for guest
+software on a guest hart to "yield" control of the guest hart.
+====
+
+=== RISC-V ISA Overview
+
+
+A RISC-V ISA is defined as a base integer ISA, which must be present in
+any implementation, plus optional extensions to the base ISA. The base
+integer ISAs are very similar to that of the early RISC processors
+except with no branch delay slots and with support for optional
+variable-length instruction encodings. A base is carefully restricted to
+a minimal set of instructions sufficient to provide a reasonable target
+for compilers, assemblers, linkers, and operating systems (with
+additional privileged operations), and so provides a convenient ISA and
+software toolchain "skeleton" around which more customized processor
+ISAs can be built.
+
+Although it is convenient to speak of _the_ RISC-V ISA, RISC-V is
+actually a family of related ISAs, of which there are currently four
+base ISAs. Each base integer instruction set is characterized by the
+width of the integer registers and the corresponding size of the address
+space and by the number of integer registers. There are two primary base
+integer variants, RV32I and RV64I, described in
+<<rv32>> and <<rv64>>, which provide 32-bit
+or 64-bit address spaces respectively. We use the term XLEN to refer to
+the width of an integer register in bits (either 32 or 64).
+<<rv32e>> describes the RV32E and RV64E subset variants of the
+RV32I or RV64I base instruction sets respectively, which have been added to support small
+microcontrollers, and which have half the number of integer registers.
+The base integer instruction sets use a two's-complement
+representation for signed integer values.
+
+
+[NOTE]
+====
+Although 64-bit address spaces are a requirement for larger systems, we
+believe 32-bit address spaces will remain adequate for many embedded and
+client devices for decades to come and will be desirable to lower memory
+traffic and energy consumption. In addition, 32-bit address spaces are
+sufficient for educational purposes. A larger flat 128-bit address space
+might eventually be required and could be accommodated with a new RV128I
+base ISA within the existing RISC-V ISA framework.
+====
+
+[NOTE]
+====
+The four base ISAs in RISC-V are treated as distinct base ISAs. A common
+question is why is there not a single ISA, and in particular, why is
+RV32I not a strict subset of RV64I? Some earlier ISA designs (SPARC,
+MIPS) adopted a strict superset policy when increasing address space
+size to support running existing 32-bit binaries on new 64-bit hardware.
+
+The main advantage of explicitly separating base ISAs is that each base
+ISA can be optimized for its needs without requiring to support all the
+operations needed for other base ISAs. For example, RV64I can omit
+instructions and CSRs that are only needed to cope with the narrower
+registers in RV32I. The RV32I variants can use encoding space otherwise
+reserved for instructions only required by wider address-space variants.
+
+The main disadvantage of not treating the design as a single ISA is that
+it complicates the hardware needed to emulate one base ISA on another
+(e.g., RV32I on RV64I). However, differences in addressing and
+illegal-instruction traps generally mean some mode switch would be required in
+hardware in any case even with full superset instruction encodings, and
+the different RISC-V base ISAs are similar enough that supporting
+multiple versions is relatively low cost. Although some have proposed
+that the strict superset design would allow legacy 32-bit libraries to
+be linked with 64-bit code, this is impractical in practice, even with
+compatible encodings, due to the differences in software calling
+conventions and system-call interfaces.
+
+The RISC-V privileged architecture provides fields in `misa` to control
+the unprivileged ISA at each level to support emulating different base
+ISAs on the same hardware. We note that newer SPARC and MIPS ISA
+revisions have deprecated support for running 32-bit code unchanged on
+64-bit systems.
+
+A related question is why there is a different encoding for 32-bit adds
+in RV32I (ADD) and RV64I (ADDW)? The ADDW opcode could be used for
+32-bit adds in RV32I and ADDD for 64-bit adds in RV64I, instead of the
+existing design which uses the same opcode ADD for 32-bit adds in RV32I
+and 64-bit adds in RV64I with a different opcode ADDW for 32-bit adds in
+RV64I. This would also be more consistent with the use of the same LW
+opcode for 32-bit load in both RV32I and RV64I. The very first versions
+of RISC-V ISA did have a variant of this alternate design, but the
+RISC-V design was changed to the current choice in January 2011. Our
+focus was on supporting 32-bit integers in the 64-bit ISA, not on
+providing compatibility with the 32-bit ISA, and the motivation was to
+remove the asymmetry that arose from having not all opcodes in RV32I
+have a *W suffix (e.g., ADDW, but AND not ANDW). In hindsight, this was
+perhaps not well-justified and a consequence of designing both ISAs at
+the same time as opposed to adding one later to sit on top of another,
+and also from a belief we had to fold platform requirements into the ISA
+spec which would imply that all the RV32I instructions would have been
+required in RV64I. It is too late to change the encoding now, but this
+is also of little practical consequence for the reasons stated above.
+
+It has been noted we could enable the *W variants as an extension to
+RV32I systems to provide a common encoding across RV64I and a future
+RV32 variant.
+====
+
+RISC-V has been designed to support extensive customization and
+specialization. Each base integer ISA can be extended with one or more
+optional instruction-set extensions. An extension may be categorized as
+either standard, custom, or non-conforming. For this purpose, we divide
+each RISC-V instruction-set encoding space (and related encoding spaces
+such as the CSRs) into three disjoint categories: _standard_,
+_reserved_, and _custom_. Standard extensions and encodings are defined
+by RISC-V International; any extensions not defined by RISC-V International are
+_non-standard_. Each base ISA and its standard extensions use only
+standard encodings, and shall not conflict with each other in their uses
+of these encodings. Reserved encodings are currently not defined but are
+saved for future standard extensions; once thus used, they become
+standard encodings. Custom encodings shall never be used for standard
+extensions and are made available for vendor-specific non-standard
+extensions. Non-standard extensions are either custom extensions, that
+use only custom encodings, or _non-conforming_ extensions, that use any
+standard or reserved encoding. Instruction-set extensions are generally
+shared but may provide slightly different functionality depending on the
+base ISA. We have also developed a naming convention
+for RISC-V base instructions and instruction-set extensions, described
+in detail in <<naming>>.
+
+To support more general software development, a set of standard
+extensions are defined to provide integer multiply/divide, atomic
+operations, and single and double-precision floating-point arithmetic.
+The base integer ISA is named "I" (prefixed by RV32 or RV64 depending
+on integer register width), and contains integer computational
+instructions, integer loads, integer stores, and control-flow
+instructions. The standard integer multiplication and division extension
+is named "M", and adds instructions to multiply and divide values held
+in the integer registers. The standard atomic instruction extension,
+denoted by "A", adds instructions that atomically read, modify, and
+write memory for inter-processor synchronization. The standard
+single-precision floating-point extension, denoted by "F", adds
+floating-point registers, single-precision computational instructions,
+and single-precision loads and stores. The standard double-precision
+floating-point extension, denoted by "D", expands the floating-point
+registers, and adds double-precision computational instructions, loads,
+and stores. The standard "C" compressed instruction extension provides
+narrower 16-bit forms of common instructions.
+
+Beyond the base integer ISA and these standard extensions, we believe
+it is rare that a new instruction will provide a significant benefit for
+all applications, although it may be very beneficial for a certain
+domain. As energy efficiency concerns are forcing greater
+specialization, we believe it is important to simplify the required
+portion of an ISA specification. Whereas other architectures usually
+treat their ISA as a single entity, which changes to a new version as
+instructions are added over time, RISC-V will endeavor to keep the base
+and each standard extension constant over time, and instead layer new
+instructions as further optional extensions. For example, the base
+integer ISAs will continue as fully supported standalone ISAs,
+regardless of any subsequent extensions.
+
+=== Memory
+
+
+A RISC-V hart has a single byte-addressable address space of
+2^XLEN^ bytes for all memory accesses. A _word_ of
+memory is defined as 32{nbsp}bits (4{nbsp}bytes). Correspondingly, a _halfword_ is 16{nbsp}bits (2{nbsp}bytes), a
+_doubleword_ is 64{nbsp}bits (8{nbsp}bytes), and a _quadword_ is 128{nbsp}bits (16{nbsp}bytes). The memory address space is
+circular, so that the byte at address 2^XLEN^−1 is
+adjacent to the byte at address zero. Accordingly, memory address
+computations done by the hardware ignore overflow and instead wrap
+around modulo 2^XLEN^.
+
+The execution environment determines the mapping of hardware resources
+into a hart's address space. Different address ranges of a hart's
+address space may (1) contain _main memory_, or
+(2) contain one or more _I/O devices_. Reads and writes of I/O devices
+may have visible side effects, but accesses to main memory cannot.
+Vacant address ranges are not a separate category but can be represented as
+either main memory or I/O regions that are not accessible.
+Although it is possible for the execution environment to call everything
+in a hart's address space an I/O device, it is usually expected that
+some portion will be specified as main memory.
+
+When a RISC-V platform has multiple harts, the address spaces of any two
+harts may be entirely the same, or entirely different, or may be partly
+different but sharing some subset of resources, mapped into the same or
+different address ranges.
+
+[NOTE]
+====
+For a purely "bare metal" environment, all harts may see an identical
+address space, accessed entirely by physical addresses. However, when
+the execution environment includes an operating system employing address
+translation, it is common for each hart to be given a virtual address
+space that is largely or entirely its own.
+====
+(((memory access, implicit and explicit)))
+
+Executing each RISC-V machine instruction entails one or more memory
+accesses, subdivided into _implicit_ and _explicit_ accesses. For each
+instruction executed, an _implicit_ memory read (instruction fetch) is
+done to obtain the encoded instruction to execute. Many RISC-V
+instructions perform no further memory accesses beyond instruction
+fetch. Specific load and store instructions perform an _explicit_ read
+or write of memory at an address determined by the instruction. The
+execution environment may dictate that instruction execution performs
+other _implicit_ memory accesses (such as to implement address
+translation) beyond those documented for the unprivileged ISA.
+
+The execution environment determines what portions of the
+address space are accessible for each kind of memory access. For
+example, the set of locations that can be implicitly read for
+instruction fetch may or may not have any overlap with the set of
+locations that can be explicitly read by a load instruction; and the set
+of locations that can be explicitly written by a store instruction may
+be only a subset of locations that can be read. Ordinarily, if an
+instruction attempts to access memory at an inaccessible address, an
+exception is raised for the instruction.
+
+Except when specified otherwise, implicit reads that do not raise an
+exception and that have no side effects may occur arbitrarily early and
+speculatively, even before the machine could possibly prove that the
+read will be needed. For instance, a valid implementation could attempt
+to read all of main memory at the earliest opportunity, cache as many
+fetchable (executable) bytes as possible for later instruction fetches,
+and avoid reading main memory for instruction fetches ever again. To
+ensure that certain implicit reads are ordered only after writes to the
+same memory locations, software must execute specific fence or
+cache-control instructions defined for this purpose (such as the FENCE.I
+instruction defined in <<zifencei>>).
+(((memory access, implicit and explicit)))
+
+The memory accesses (implicit or explicit) made by a hart may appear to
+occur in a different order as perceived by another hart or by any other
+agent that can access the same memory. This perceived reordering of
+memory accesses is always constrained, however, by the applicable memory
+consistency model. The default memory consistency model for RISC-V is
+the RISC-V Weak Memory Ordering (RVWMO), defined in
+<<memorymodel>> and in appendices. Optionally,
+an implementation may adopt the stronger model of Total Store Ordering,
+as defined in <<ztso>>. The execution environment
+may also add constraints that further limit the perceived reordering of
+memory accesses. Since the RVWMO model is the weakest model allowed for
+any RISC-V implementation, software written for this model is compatible
+with the actual memory consistency rules of all RISC-V implementations.
+As with implicit reads, software must execute fence or cache-control
+instructions to ensure specific ordering of memory accesses beyond the
+requirements of the assumed memory consistency model and execution
+environment.
+
+=== Base Instruction-Length Encoding
+
+The base RISC-V ISA has fixed-length 32-bit instructions that must be
+naturally aligned on 32-bit boundaries. However, the standard RISC-V
+encoding scheme is designed to support ISA extensions with
+variable-length instructions, where each instruction can be any number
+of 16-bit instruction _parcels_ in length and parcels are naturally
+aligned on 16-bit boundaries. The standard compressed ISA extension
+described in <<compressed>> reduces code size by
+providing compressed 16-bit instructions and relaxes the alignment
+constraints to allow all instructions (16 bit and 32 bit) to be aligned
+on any 16-bit boundary to improve code density.
+
+We use the term IALIGN (measured in bits) to refer to the
+instruction-address alignment constraint the implementation enforces.
+IALIGN is 32 bits in the base ISA, but some ISA extensions, including
+the compressed ISA extension, relax IALIGN to 16 bits. IALIGN may not
+take on any value other than 16 or 32.
+(((ILEN)))
+
+We use the term ILEN (measured in bits) to refer to the maximum
+instruction length supported by an implementation, and which is always a
+multiple of IALIGN. For implementations supporting only a base
+instruction set, ILEN is 32 bits. Implementations supporting longer
+instructions have larger values of ILEN.
+
+All the 32-bit
+instructions in the base ISA have their lowest two bits set to `11`. The
+optional compressed 16-bit instruction-set extensions have their lowest
+two bits equal to `00`, `01`, or `10`.
+
+[NOTE]
+====
+Given the code size and energy savings of a compressed format, we wanted
+to build in support for a compressed format to the ISA encoding scheme
+rather than adding this as an afterthought, but to allow simpler
+implementations we didn't want to make the compressed format mandatory.
+We also wanted to optionally allow longer instructions to support
+experimentation and larger instruction-set extensions. Although our
+encoding convention required a tighter encoding of the core RISC-V ISA,
+this has several beneficial effects.
+(((IMAFD)))
+
+An implementation of the standard IMAFD ISA need only hold the
+most-significant 30 bits in instruction caches (a 6.25% saving). On
+instruction cache refills, any instructions encountered with either low
+bit clear should be recoded into illegal 30-bit instructions before
+storing in the cache to preserve illegal-instruction exception behavior.
+
+Perhaps more importantly, by condensing our base ISA into a subset of
+the 32-bit instruction word, we leave more space available for
+non-standard and custom extensions. In particular, the base RV32I ISA
+uses less than 1/8 of the encoding space in the 32-bit instruction word.
+An implementation that does not require support
+for the standard compressed instruction extension can map 3 additional non-conforming
+30-bit instruction spaces into the 32-bit fixed-width format, while preserving
+support for standard &#8805;32-bit instruction-set
+extensions.
+====
+
+Encodings with bits [15:0] all zeros are defined as illegal
+instructions. These instructions are considered to be of minimal length:
+16 bits if any 16-bit instruction-set extension is present, otherwise 32
+bits. The encoding with bits [ILEN-1:0] all ones is also illegal; this
+instruction is considered to be ILEN bits long.
+
+[NOTE]
+====
+We consider it a feature that any length of instruction containing all
+zero bits is not legal, as this quickly traps erroneous jumps into
+zeroed memory regions. Similarly, we also reserve the instruction
+encoding containing all ones to be an illegal instruction, to catch the
+other common pattern observed with unprogrammed non-volatile memory
+devices, disconnected memory buses, or broken memory devices.
+
+Software can rely on a naturally aligned 32-bit word containing zero to
+act as an illegal instruction on all RISC-V implementations, to be used
+by software where an illegal instruction is explicitly desired. Defining
+a corresponding known illegal value for all ones is more difficult due
+to the variable-length encoding. Software cannot generally use the
+illegal value of ILEN bits of all 1s, as software might not know ILEN
+for the eventual target machine (e.g., if software is compiled into a
+standard binary library used by many different machines). Defining a
+32-bit word of all ones as illegal was also considered, as all machines
+must support a 32-bit instruction size, but this requires the
+instruction-fetch unit on machines with ILEN >32 report an
+illegal-instruction exception rather than an access-fault exception when
+such an instruction borders a protection boundary, complicating
+variable-instruction-length fetch and decode.
+====
+(((endian, little and big)))
+RISC-V base ISAs have either little-endian or big-endian memory systems,
+with the privileged architecture further defining bi-endian operation.
+Instructions are stored in memory as a sequence of 16-bit little-endian
+parcels, regardless of memory system endianness. Parcels forming one
+instruction are stored at increasing halfword addresses, with the
+lowest-addressed parcel holding the lowest-numbered bits in the
+instruction specification.
+(((bi-endian)))
+(((endian, bi-)))
+
+[NOTE]
+====
+We originally chose little-endian byte ordering for the RISC-V memory
+system because little-endian systems are currently dominant commercially
+(all x86 systems; iOS, Android, and Windows for ARM). A minor point is
+that we have also found little-endian memory systems to be more natural
+for hardware designers. However, certain application areas, such as IP
+networking, operate on big-endian data structures, and certain legacy
+code bases have been built assuming big-endian processors, so we have
+defined big-endian and bi-endian variants of RISC-V.
+
+We have to fix the order in which instruction parcels are stored in
+memory, independent of memory system endianness, to ensure that the
+length-encoding bits always appear first in halfword address order. This
+allows the length of a variable-length instruction to be quickly
+determined by an instruction-fetch unit by examining only the first few
+bits of the first 16-bit instruction parcel.
+
+We further make the instruction parcels themselves little-endian to
+decouple the instruction encoding from the memory system endianness
+altogether. This design benefits both software tooling and bi-endian
+hardware. Otherwise, for instance, a RISC-V assembler or disassembler
+would always need to know the intended active endianness, despite that
+in bi-endian systems, the endianness mode might change dynamically
+during execution. In contrast, by giving instructions a fixed
+endianness, it is sometimes possible for carefully written software to
+be endianness-agnostic even in binary form, much like
+position-independent code.
+
+The choice to have instructions be only little-endian does have
+consequences, however, for RISC-V software that encodes or decodes
+machine instructions. Big-endian JIT compilers, for example, must swap
+the byte order when storing to instruction memory.
+
+Once we had decided to fix on a little-endian instruction encoding, this
+naturally led to placing the length-encoding bits in the LSB positions
+of the instruction format to avoid breaking up opcode fields.
+====
+
+[[trap-defn]]
+=== Exceptions, Traps, and Interrupts
+
+We use the term _exception_ to refer to an unusual condition occurring
+at run time associated with an instruction in the current RISC-V hart.
+We use the term _interrupt_ to refer to an external asynchronous event
+that may cause a RISC-V hart to experience an unexpected transfer of
+control. We use the term _trap_ to refer to the transfer of control to a
+trap handler caused by either an exception or an interrupt.
+(((exceptions)))
+(((traps)))
+(((interrupts)))
+
+The instruction descriptions in following chapters describe conditions
+that can raise an exception during execution. The general behavior of
+most RISC-V EEIs is that a trap to some handler occurs when an exception
+is signaled on an instruction (except for floating-point exceptions,
+which, in the standard floating-point extensions, do not cause traps).
+The manner in which interrupts are generated, routed to, and enabled by
+a hart depends on the EEI.
+
+[NOTE]
+====
+Our use of "exception" and "trap" is compatible with that in the
+IEEE-754 floating-point standard.
+====
+
+How traps are handled and made visible to software running on the hart
+depends on the enclosing execution environment. From the perspective of
+software running inside an execution environment, traps encountered by a
+hart at runtime can have four different effects:
+
+Contained Trap:::
+ The trap is visible to, and handled by, software running inside the
+ execution environment. For example, in an EEI providing both
+ supervisor and user mode on harts, an ECALL by a user-mode hart will
+ generally result in a transfer of control to a supervisor-mode handler
+ running on the same hart. Similarly, in the same environment, when a
+ hart is interrupted, an interrupt handler will be run in supervisor
+ mode on the hart.
+Requested Trap:::
+ The trap is a synchronous exception that is an explicit call to the
+ execution environment requesting an action on behalf of software
+ inside the execution environment. An example is a system call. In this
+ case, execution may or may not resume on the hart after the requested
+ action is taken by the execution environment. For example, a system
+ call could remove the hart or cause an orderly termination of the
+ entire execution environment.
+Invisible Trap:::
+ The trap is handled transparently by the execution environment and
+ execution resumes normally after the trap is handled. Examples include
+ emulating missing instructions, handling non-resident page faults in a
+ demand-paged virtual-memory system, or handling device interrupts for
+ a different job in a multiprogrammed machine. In these cases, the
+ software running inside the execution environment is not aware of the
+ trap (we ignore timing effects in these definitions).
+Fatal Trap:::
+ The trap represents a fatal failure and causes the execution
+ environment to terminate execution. Examples include failing a
+ virtual-memory page-protection check or allowing a watchdog timer to
+ expire. Each EEI should define how execution is terminated and
+ reported to an external environment.
+
+<<trapcharacteristics>> shows the characteristics of each kind of trap.
+
+[[trapcharacteristics]]
+.Characteristics of traps
+[%autowidth,float="center",align="center",cols="<,^,^,^,^",options="header",]
+|===
+| |Contained |Requested |Invisible |Fatal
+|Execution terminates |No |No^1^|No |Yes
+|Software is oblivious |No |No |Yes |Yes^2^|Handled by environment |No |Yes |Yes |Yes
+|===
+
+^1^ Termination may be requested +
+^2^ Imprecise fatal traps might be observable by software
+
+The EEI defines for each trap whether it is handled precisely, though
+the recommendation is to maintain preciseness where possible. Contained
+and requested traps can be observed to be imprecise by software inside
+the execution environment. Invisible traps, by definition, cannot be
+observed to be precise or imprecise by software running inside the
+execution environment. Fatal traps can be observed to be imprecise by
+software running inside the execution environment, if known-errorful
+instructions do not cause immediate termination.
+
+Because this document describes unprivileged instructions, traps are
+rarely mentioned. Architectural means to handle contained traps are
+defined in the privileged architecture manual, along with other features
+to support richer EEIs. Unprivileged instructions that are defined
+solely to cause requested traps are documented here. Invisible traps
+are, by their nature, out of scope for this document. Instruction
+encodings that are not defined here and not defined by some other means
+may cause a fatal trap.
+
+=== UNSPECIFIED Behaviors and Values
+The architecture fully describes what implementations must do and any
+constraints on what they may do. In cases where the architecture
+intentionally does not constrain implementations, the term UNSPECIFIED is
+explicitly used.
+(((unspecified, behaviors)))
+(((unspecified, values)))
+
+The term UNSPECIFIED refers to a behavior or value that is intentionally
+unconstrained. The definition of these behaviors or values is open to
+extensions, platform standards, or implementations. Extensions, platform
+standards, or implementation documentation may provide normative content
+to further constrain cases that the base architecture defines as UNSPECIFIED.
+
+Like the base architecture, extensions should fully describe allowable
+behavior and values and use the term UNSPECIFIED for cases that are intentionally
+unconstrained. These cases may be constrained or defined by other
+extensions, platform standards, or implementations.
diff --git a/src/intro.tex b/src/intro.tex
deleted file mode 100644
index 05977ac..0000000
--- a/src/intro.tex
+++ /dev/null
@@ -1,701 +0,0 @@
-\chapter{Introduction}
-
-RISC-V (pronounced ``risk-five'') is a new instruction-set
-architecture (ISA) that was originally designed to support computer
-architecture research and education, but which we now hope will also
-become a standard free and open architecture for industry
-implementations. Our goals in defining RISC-V include:
-\vspace{-0.1in}
-\begin{itemize}
-\parskip 0pt
-\itemsep 1pt
-\item A completely {\em open} ISA that is freely available to
- academia and industry.
-\item A {\em real} ISA suitable for direct native hardware implementation,
- not just simulation or binary translation.
-\item An ISA that avoids ``over-architecting'' for a particular
- microarchitecture style (e.g., microcoded, in-order, decoupled,
- out-of-order) or implementation technology (e.g., full-custom, ASIC,
- FPGA), but which allows efficient implementation in any of these.
-\item An ISA separated into a {\em small} base integer ISA, usable by
- itself as a base for customized accelerators or for educational
- purposes, and optional standard extensions, to support
- general-purpose software development.
-\item Support for the revised 2008 IEEE-754 floating-point standard~\cite{ieee754-2008}.
-\item An ISA supporting extensive ISA extensions and
- specialized variants.
-\item Both 32-bit and 64-bit address space variants for
- applications, operating system kernels, and hardware implementations.
-\item An ISA with support for highly-parallel multicore
- or manycore implementations, including heterogeneous multiprocessors.
-\item Optional {\em variable-length instructions} to both expand available
- instruction encoding space and to support an optional {\em dense
- instruction encoding} for improved performance, static code size,
- and energy efficiency.
-\item A fully virtualizable ISA to ease hypervisor development.
-\item An ISA that simplifies experiments with new privileged architecture designs.
-\end{itemize}
-\vspace{-0.1in}
-
-\begin{commentary}
- Commentary on our design decisions is formatted as in this
- paragraph. This non-normative text can be skipped if the reader is
- only interested in the specification itself.
-\end{commentary}
-\begin{commentary}
-The name RISC-V was chosen to represent the fifth major RISC ISA
-design from UC Berkeley (RISC-I~\cite{riscI-isca1981},
-RISC-II~\cite{Katevenis:1983}, SOAR~\cite{Ungar:1984}, and
-SPUR~\cite{spur-jsscc1989} were the first four). We also pun on the
-use of the Roman numeral ``V'' to signify ``variations'' and
-``vectors'', as support for a range of architecture research,
-including various data-parallel accelerators, is an explicit goal of
-the ISA design.
-\end{commentary}
-
-The RISC-V ISA is defined avoiding implementation details as much as
-possible (although commentary is included on implementation-driven
-decisions) and should be read as the software-visible interface to a
-wide variety of implementations rather than as the design of a
-particular hardware artifact. The RISC-V manual is structured in two
-volumes. This volume covers the design of the base {\em unprivileged}
-instructions, including optional unprivileged ISA extensions.
-Unprivileged instructions are those that are generally usable in all
-privilege modes in all privileged architectures, though behavior might
-vary depending on privilege mode and privilege architecture. The
-second volume provides the design of the first (``classic'')
-privileged architecture. The manuals use IEC 80000-13:2008
-conventions, with a byte of 8 bits.
-
-\begin{commentary}
-In the unprivileged ISA design, we tried to remove any dependence on
-particular microarchitectural features, such as cache line size, or on
-privileged architecture details, such as page translation. This is
-both for simplicity and to allow maximum flexibility for alternative
-microarchitectures or alternative privileged architectures.
-\end{commentary}
-
-
-\section{RISC-V Hardware Platform Terminology}
-
-A RISC-V hardware platform can contain one or more RISC-V-compatible
-processing cores together with other non-RISC-V-compatible cores,
-fixed-function accelerators, various physical memory structures, I/O
-devices, and an interconnect structure to allow the components to
-communicate.
-
-A component is termed a {\em core} if it contains an independent
-instruction fetch unit. A RISC-V-compatible core might support
-multiple RISC-V-compatible hardware threads, or {\em harts}, through
-multithreading.
-
-A RISC-V core might have additional specialized instruction-set
-extensions or an added {\em coprocessor}. We use the term {\em
- coprocessor} to refer to a unit that is attached to a RISC-V core
-and is mostly sequenced by a RISC-V instruction stream, but which
-contains additional architectural state and instruction-set
-extensions, and possibly some limited autonomy relative to the
-primary RISC-V instruction stream.
-
-We use the term {\em accelerator} to refer to either a
-non-programmable fixed-function unit or a core that can operate
-autonomously but is specialized for certain tasks. In RISC-V systems,
-we expect many programmable accelerators will be RISC-V-based cores
-with specialized instruction-set extensions and/or customized
-coprocessors. An important class of RISC-V accelerators are I/O
-accelerators, which offload I/O processing tasks from the main
-application cores.
-
-The system-level organization of a RISC-V hardware platform can range
-from a single-core microcontroller to a many-thousand-node cluster of
-shared-memory manycore server nodes. Even small systems-on-a-chip
-might be structured as a hierarchy of multicomputers and/or
-multiprocessors to modularize development effort or to provide secure
-isolation between subsystems.
-
-\section{RISC-V Software Execution Environments and Harts}
-
-The behavior of a RISC-V program depends on the execution environment
-in which it runs. A RISC-V execution environment interface (EEI)
-defines the initial state of the program, the number and type of harts
-in the environment including the privilege modes supported by the
-harts, the accessibility and attributes of memory and I/O regions, the
-behavior of all legal instructions executed on each hart (i.e., the
-ISA is one component of the EEI), and the handling of any interrupts
-or exceptions raised during execution including environment calls.
-Examples of EEIs include the Linux application binary interface (ABI),
-or the RISC-V supervisor binary interface (SBI). The implementation
-of a RISC-V execution environment can be pure hardware, pure software,
-or a combination of hardware and software. For example, opcode traps
-and software emulation can be used to implement functionality not
-provided in hardware. Examples of execution environment
-implementations include:
-\begin{itemize}
- \item ``Bare metal'' hardware platforms where harts are directly
- implemented by physical processor threads and instructions have
- full access to the physical address space. The hardware platform
- defines an execution environment that begins at power-on reset.
- \item RISC-V operating systems that provide multiple user-level
- execution environments by multiplexing user-level harts onto
- available physical processor threads and by controlling access to
- memory via virtual memory.
- \item RISC-V hypervisors that provide multiple supervisor-level
- execution environments for guest operating systems.
- \item RISC-V emulators, such as Spike, QEMU or rv8, which emulate
- RISC-V harts on an underlying x86 system, and which can provide
- either a user-level or a supervisor-level execution environment.
-\end{itemize}
-
-\begin{commentary}
- A bare hardware platform can be considered to define an EEI, where
- the accessible harts, memory, and other devices populate the
- environment, and the initial state is that at power-on reset.
- Generally, most software is designed to use a more abstract
- interface to the hardware, as more abstract EEIs provide greater
- portability across different hardware platforms. Often EEIs are
- layered on top of one another, where one higher-level EEI uses
- another lower-level EEI.
-\end{commentary}
-
-From the perspective of software running in a given execution
-environment, a hart is a resource that autonomously fetches and
-executes RISC-V instructions within that execution environment. In
-this respect, a hart behaves like a hardware thread resource even if
-time-multiplexed onto real hardware by the execution environment.
-Some EEIs support the creation and destruction of additional harts,
-for example, via environment calls to fork new harts.
-
-\begin{commentary}
-The term hart was introduced in the work on
-Lithe~\cite{lithe-pan-hotpar09,lithe-pan-pldi10} to provide a term to
-represent an abstract execution resource as opposed to a software
-thread programming abstraction.
-
-The important distinction between a hardware thread (hart) and a
-software thread context is that the software running inside an
-execution environment is not responsible for causing progress of each
-of its harts; that is the responsibility of the outer execution
-environment. So the environment's harts operate like hardware threads
-from the perspective of the software inside the execution environment.
-
-An execution environment implementation might time-multiplex a set of
-guest harts onto fewer host harts provided by its own execution
-environment but must do so in a way that guest harts operate like
-independent hardware threads. In particular, if there are more guest
-harts than host harts then the execution environment must be able to
-preempt the guest harts and must not wait indefinitely for guest
-software on a guest hart to "yield" control of the guest hart.
-\end{commentary}
-
-\section{RISC-V ISA Overview}
-
-A RISC-V ISA is defined as a base integer ISA, which must be present
-in any implementation, plus optional extensions to the base ISA. The
-base integer ISAs are very similar to that of the early RISC processors
-except with no branch delay slots and with support for optional
-variable-length instruction encodings. A base is carefully
-restricted to a minimal set of instructions sufficient to provide a
-reasonable target for compilers, assemblers, linkers, and operating
-systems (with additional privileged operations), and so provides
-a convenient ISA and software toolchain ``skeleton'' around which more
-customized processor ISAs can be built.
-
-Although it is convenient to speak of {\em the} RISC-V ISA, RISC-V is
-actually a family of related ISAs, of which there are currently four
-base ISAs. Each base integer instruction set is characterized by the
-width of the integer registers and the corresponding size of the
-address space and by the number of integer registers. There are two
-primary base integer variants, RV32I and RV64I, described in
-Chapters~\ref{rv32} and \ref{rv64}, which provide 32-bit or 64-bit
-address spaces respectively. We use the term XLEN to refer to the
-width of an integer register in bits (either 32 or 64).
-Chapter~\ref{rv32e} describes the RV32E subset variant of the RV32I
-base instruction set, which has been added to support small
-microcontrollers, and which has half the number of integer registers.
-Chapter~\ref{rv128} sketches a future RV128I variant of the base
-integer instruction set supporting a flat 128-bit address space
-(XLEN=128). The base integer instruction sets use a two's-complement
-representation for signed integer values.
-
-\begin{commentary}
-Although 64-bit address spaces are a requirement for larger systems,
-we believe 32-bit address spaces will remain adequate for many
-embedded and client devices for decades to come and will be desirable
-to lower memory traffic and energy consumption. In addition, 32-bit
-address spaces are sufficient for educational purposes. A larger flat
-128-bit address space might eventually be required, so we ensured this
-could be accommodated within the RISC-V ISA framework.
-\end{commentary}
-
-\begin{commentary}
-The four base ISAs in RISC-V are treated as distinct base ISAs. A
-common question is why is there not a single ISA, and in particular,
-why is RV32I not a strict subset of RV64I? Some earlier ISA designs
-(SPARC, MIPS) adopted a strict superset policy when increasing address
-space size to support running existing 32-bit binaries on new 64-bit
-hardware.
-
-The main advantage of explicitly separating base ISAs is that each
-base ISA can be optimized for its needs without requiring to support
-all the operations needed for other base ISAs. For example, RV64I can
-omit instructions and CSRs that are only needed to cope with the
-narrower registers in RV32I. The RV32I variants can use encoding
-space otherwise reserved for instructions only required by wider
-address-space variants.
-
-The main disadvantage of not treating the design as a single ISA is
-that it complicates the hardware needed to emulate one base ISA on
-another (e.g., RV32I on RV64I). However, differences in addressing
-and illegal instruction traps generally mean some mode switch would be
-required in hardware in any case even with full superset instruction
-encodings, and the different RISC-V base ISAs are similar enough that
-supporting multiple versions is relatively low cost. Although some
-have proposed that the strict superset design would allow legacy
-32-bit libraries to be linked with 64-bit code, this is impractical in
-practice, even with compatible encodings, due to the differences in
-software calling conventions and system-call interfaces.
-
-The RISC-V privileged architecture provides fields in {\tt
- misa} to control the unprivileged ISA at each level to support emulating
-different base ISAs on the same hardware. We note that newer SPARC
-and MIPS ISA revisions have deprecated support for running 32-bit code
-unchanged on 64-bit systems.
-
-A related question is why there is a different encoding for 32-bit
-adds in RV32I (ADD) and RV64I (ADDW)? The ADDW opcode could be used
-for 32-bit adds in RV32I and ADDD for 64-bit adds in RV64I, instead of
-the existing design which uses the same opcode ADD for 32-bit adds in
-RV32I and 64-bit adds in RV64I with a different opcode ADDW for 32-bit
-adds in RV64I. This would also be more consistent with the use of the
-same LW opcode for 32-bit load in both RV32I and RV64I. The very
-first versions of RISC-V ISA did have a variant of this alternate
-design, but the RISC-V design was changed to the current choice in
-January 2011. Our focus was on supporting 32-bit integers in the
-64-bit ISA not on providing compatibility with the 32-bit ISA, and the
-motivation was to remove the asymmetry that arose from having not all
-opcodes in RV32I have a *W suffix (e.g., ADDW, but AND not ANDW). In
-hindsight, this was perhaps not well-justified and a consequence of
-designing both ISAs at the same time as opposed to adding one later to
-sit on top of another, and also from a belief we had to fold platform
-requirements into the ISA spec which would imply that all the RV32I
-instructions would have been required in RV64I. It is too late to
-change the encoding now, but this is also of little practical
-consequence for the reasons stated above.
-
-It has been noted we could enable the *W variants as an extension to
-RV32I systems to provide a common encoding across RV64I and a future
-RV32 variant.
-\end{commentary}
-
-RISC-V has been designed to support extensive customization and
-specialization. Each base integer ISA can be extended with one or
-more optional instruction-set extensions, and we divide each RISC-V
-instruction-set encoding space (and related encoding spaces such as
-the CSRs) into three disjoint categories: {\em standard}, {\em
- reserved}, and {\em custom}. Standard encodings are defined by the
-Foundation, and shall not conflict with other standard extensions for
-the same base ISA. Reserved encodings are currently not defined but
-are saved for future standard extensions. We use the term {\em
- non-standard} to describe an extension that is not defined by the
-Foundation. Custom encodings shall never be used for standard
-extensions and are made available for vendor-specific non-standard
-extensions. We use the term {\em non-conforming} to describe a
-non-standard extension that uses either a standard or a reserved
-encoding (i.e., custom extensions are {\em not} non-conforming).
-Instruction-set extensions are generally shared but may provide slightly different
-functionality depending on the base ISA. Chapter~\ref{extensions}
-describes various ways of extending the RISC-V ISA. We have also
-developed a naming convention for RISC-V base instructions and
-instruction-set extensions, described in detail in
-Chapter~\ref{naming}.
-
-To support more general software development, a set of standard
-extensions are defined to provide integer multiply/divide, atomic
-operations, and single and double-precision floating-point arithmetic.
-The base integer ISA is named ``I'' (prefixed by RV32 or RV64
-depending on integer register width), and contains integer
-computational instructions, integer loads, integer stores, and
-control-flow instructions. The standard integer multiplication and
-division extension is named ``M'', and adds instructions to multiply
-and divide values held in the integer registers. The standard atomic
-instruction extension, denoted by ``A'', adds instructions that
-atomically read, modify, and write memory for inter-processor
-synchronization. The standard single-precision floating-point
-extension, denoted by ``F'', adds floating-point registers,
-single-precision computational instructions, and single-precision
-loads and stores. The standard double-precision floating-point
-extension, denoted by ``D'', expands the floating-point registers, and
-adds double-precision computational instructions, loads, and stores.
-An integer base plus these four standard extensions (``IMAFD'') is
-given the abbreviation ``G'' and provides a general-purpose scalar
-instruction set. The standard ``C'' compressed instruction extension
-provides narrower 16-bit forms of common instructions.
-
-Beyond the base integer ISA and the standard GC extensions, we believe
-it is rare that a new instruction will provide a significant benefit
-for all applications, although it may be very beneficial for a certain
-domain. As energy efficiency concerns are forcing greater
-specialization, we believe it is important to simplify the required
-portion of an ISA specification. Whereas other architectures usually
-treat their ISA as a single entity, which changes to a new version as
-instructions are added over time, RISC-V will endeavor to keep the
-base and each standard extension constant over time, and instead layer
-new instructions as further optional extensions. For example, the
-base integer ISAs will continue as fully supported standalone ISAs,
-regardless of any subsequent extensions.
-
-\section{Memory}
-
-A RISC-V hart has a single byte-addressable address space for all memory
-accesses. A {\em word} of memory is defined as \wunits{32}{bits}
-(\wunits{4}{bytes}). Correspondingly, a {\em halfword} is \wunits{16}{bits}
-(\wunits{2}{bytes}), a {\em doubleword} is \wunits{64}{bits}
-(\wunits{8}{bytes}), and a {\em quadword} is \wunits{128}{bits}
-(\wunits{16}{bytes}).
-
-The execution environment determines the mapping of hardware resources into
-a hart's address space.
-Different address ranges of a hart's address space may (1)~be vacant, or
-(2)~contain {\em main memory}, or (3)~contain one or more {\em I/O devices}.
-Reads and writes of I/O devices may have visible side effects, but accesses
-to main memory cannot.
-Although it is possible for the execution environment to call everything in
-a hart's address space an I/O device, it is usually expected that some
-portion will be specified as main memory.
-
-When a RISC-V platform has multiple harts, the address spaces of any two
-harts may be entirely the same, or entirely different, or may be partly
-different but sharing some subset of resources, mapped into the same or
-different address ranges.
-
-\begin{commentary}
-For a purely ``bare metal'' environment, all harts may see an identical
-address space, accessed entirely by physical addresses.
-However, when the execution environment includes an operating system
-employing address translation, it is common for each hart to be given a
-virtual address space that is largely or entirely its own.
-\end{commentary}
-
-Executing each RISC-V machine instruction entails one or more memory
-accesses, subdivided into {\em
-implicit} and {\em explicit} accesses. For each instruction executed, an {\em
-implicit} memory read (instruction fetch) is done to obtain the encoded
-instruction to execute. Many RISC-V instructions perform no further memory
-accesses beyond instruction fetch. Specific load and store instructions
-perform an {\em explicit} read or write of memory at an address determined by
-the instruction. The execution environment may dictate that instruction
-execution performs other {\em implicit} memory accesses (such as to implement
-address translation) beyond those documented for the unprivileged ISA.
-
-The execution environment determines what portions of the
-non-vacant address space are
-accessible for each kind of memory access. For example, the set of locations
-that can be implicitly read for instruction fetch may or may not have any
-overlap with the set of locations that can be explicitly read by a load
-instruction; and the set of locations that can be explicitly written by
-a store instruction may be only a subset of locations that can be read.
-Ordinarily, if an instruction attempts to access memory at an inaccessible
-address, an exception is raised for the instruction.
-Vacant locations in the address space are never accessible.
-
-Except when specified otherwise, implicit reads that do not raise an
-exception and that have no side effects
-may occur arbitrarily early and speculatively, even before the machine could
-possibly prove that the read will be needed. For instance, a valid
-implementation could attempt to read all of main memory at the earliest
-opportunity, cache as many fetchable (executable) bytes as possible for later
-instruction fetches, and avoid reading main memory for instruction fetches ever
-again. To ensure that certain implicit reads are ordered only after writes to
-the same memory locations, software must execute specific fence or cache-control
-instructions defined for this purpose (such as the FENCE.I instruction
-defined in Chapter~\ref{chap:zifencei}).
-
-The memory accesses (implicit or explicit) made by a hart may appear to occur
-in a different order as perceived by another hart or by any other agent that
-can access the same memory. This perceived reordering of memory accesses is
-always constrained, however, by the applicable memory consistency model. The
-default memory consistency model for RISC-V is the RISC-V Weak Memory Ordering
-(RVWMO), defined in Chapter~\ref{ch:memorymodel} and in appendices.
-Optionally, an implementation may adopt the stronger model of Total Store
-Ordering, as defined in Chapter~\ref{sec:ztso}. The execution environment may
-also add constraints that further limit the perceived reordering of memory
-accesses.
-Since the RVWMO model is the weakest model allowed for any RISC-V
-implementation, software written for this model is compatible with the
-actual memory consistency rules of all RISC-V implementations. As with
-implicit reads, software must execute fence or cache-control instructions to
-ensure specific ordering of memory accesses beyond the requirements of the
-assumed memory consistency model and execution environment.
-
-\section{Instruction Length Encoding}
-
-The base RISC-V ISA has fixed-length 32-bit instructions that must be
-naturally aligned on 32-bit boundaries. However, the standard RISC-V
-encoding scheme is designed to support ISA extensions with
-variable-length instructions, where each instruction can be any number
-of 16-bit instruction {\em parcels} in length and parcels are
-naturally aligned on 16-bit boundaries. The standard compressed ISA
-extension described in Chapter~\ref{compressed} reduces code size by
-providing compressed 16-bit instructions and relaxes the alignment
-constraints to allow all instructions (16 bit and 32 bit) to be
-aligned on any 16-bit boundary to improve code density.
-
-We use the term IALIGN (measured in bits) to refer to the instruction-address
-alignment constraint the implementation enforces. IALIGN is 32 bits in the
-base ISA, but some ISA extensions, including the compressed ISA extension,
-relax IALIGN to 16 bits. IALIGN may not take on any value other than 16 or
-32.
-
-We use the term ILEN (measured in bits) to refer to the maximum
-instruction length supported by an implementation, and which is always
-a multiple of IALIGN. For implementations supporting only a base
-instruction set, ILEN is 32 bits. Implementations supporting longer
-instructions have larger values of ILEN.
-
-Figure~\ref{instlengthcode} illustrates the standard RISC-V
-instruction-length encoding convention. All the 32-bit instructions
-in the base ISA have their lowest two bits set to {\tt 11}. The
-optional compressed 16-bit instruction-set extensions have their
-lowest two bits equal to {\tt 00}, {\tt 01}, or {\tt 10}. Standard
-instruction-set extensions encoded with more than 32 bits have
-additional low-order bits set to {\tt 1}, with the conventions for
-48-bit and 64-bit lengths shown in Figure~\ref{instlengthcode}.
-Instruction lengths between 80 bits and 176 bits are encoded using a
-3-bit field in bits [14:12] giving the number of 16-bit words in
-addition to the first 5$\times$16-bit words. The encoding with bits
-[14:12] set to {\tt 111} is reserved for future longer instruction
-encodings.
-
-\begin{figure}[hbt]
-{
-\begin{center}
-\begin{tabular}{ccccl}
-\cline{4-4}
-& & & \multicolumn{1}{|c|}{\tt xxxxxxxxxxxxxxaa} & 16-bit ({\tt aa}
-$\neq$ {\tt 11})\\
-\cline{4-4}
-\\
-\cline{3-4}
-& & \multicolumn{1}{|c|}{\tt xxxxxxxxxxxxxxxx}
-& \multicolumn{1}{c|}{\tt xxxxxxxxxxxbbb11} & 32-bit ({\tt bbb}
-$\neq$ {\tt 111}) \\
-\cline{3-4}
-\\
-\cline{2-4}
-\hspace{0.1in}
-& \multicolumn{1}{c|}{$\cdot\cdot\cdot${\tt xxxx} }
-& \multicolumn{1}{c|}{\tt xxxxxxxxxxxxxxxx}
-& \multicolumn{1}{c|}{\tt xxxxxxxxxx011111} & 48-bit \\
-\cline{2-4}
-\\
-\cline{2-4}
-\hspace{0.1in}
-& \multicolumn{1}{c|}{$\cdot\cdot\cdot${\tt xxxx} }
-& \multicolumn{1}{c|}{\tt xxxxxxxxxxxxxxxx}
-& \multicolumn{1}{c|}{\tt xxxxxxxxx0111111} & 64-bit \\
-\cline{2-4}
-\\
-\cline{2-4}
-\hspace{0.1in}
-& \multicolumn{1}{c|}{$\cdot\cdot\cdot${\tt xxxx} }
-& \multicolumn{1}{c|}{\tt xxxxxxxxxxxxxxxx}
-& \multicolumn{1}{c|}{\tt xnnnxxxxx1111111} & (80+16*{\tt nnn})-bit,
- {\tt nnn}$\neq${\tt 111} \\
-\cline{2-4}
-\\
-\cline{2-4}
-\hspace{0.1in}
-& \multicolumn{1}{c|}{$\cdot\cdot\cdot${\tt xxxx} }
-& \multicolumn{1}{c|}{\tt xxxxxxxxxxxxxxxx}
-& \multicolumn{1}{c|}{\tt x111xxxxx1111111} & Reserved for $\geq$192-bits \\
-\cline{2-4}
-\\
-Byte Address: & \multicolumn{1}{r}{base+4} & \multicolumn{1}{r}{base+2} & \multicolumn{1}{r}{base} & \\
- \end{tabular}
-\end{center}
-}
-\caption{RISC-V instruction length encoding.}
-\label{instlengthcode}
-\end{figure}
-
-\begin{samepage-commentary}
-Given the code size and energy savings of a compressed format, we
-wanted to build in support for a compressed format to the ISA encoding
-scheme rather than adding this as an afterthought, but to allow
-simpler implementations we didn't want to make the compressed format
-mandatory. We also wanted to optionally allow longer instructions to
-support experimentation and larger instruction-set extensions.
-Although our encoding convention required a tighter encoding of the
-core RISC-V ISA, this has several beneficial effects.
-
-An implementation of the standard G ISA need only hold the
-most-significant 30 bits in instruction caches (a 6.25\% saving). On
-instruction cache refills, any instructions encountered with either
-low bit clear should be recoded into illegal 30-bit instructions
-before storing in the cache to preserve illegal instruction exception
-behavior.
-
-Perhaps more importantly, by condensing our base ISA into a subset of
-the 32-bit instruction word, we leave more space available for
-non-standard and custom extensions. In particular, the base RV32I ISA
-uses less than 1/8 of the encoding space in the 32-bit instruction
-word. As described in Chapter~\ref{extensions}, an implementation
-that does not require support for the standard compressed instruction
-extension can map 3 additional non-conforming 30-bit instruction
-spaces into the 32-bit fixed-width format, while preserving support
-for standard $\geq$32-bit instruction-set extensions. Further, if the
-implementation also does not need instructions $>$32-bits in length,
-it can recover a further four major opcodes for non-conforming extensions.
-\end{samepage-commentary}
-
-Encodings with bits [15:0] all zeros are defined as illegal
-instructions. These instructions are considered to be of minimal
-length: 16 bits if any 16-bit instruction-set extension is present,
-otherwise 32 bits. The encoding with bits [ILEN-1:0] all ones is also
-illegal; this instruction is considered to be ILEN bits long.
-
-\begin{commentary}
-We consider it a feature that any length of instruction containing all
-zero bits is not legal, as this quickly traps erroneous jumps into
-zeroed memory regions. Similarly, we also reserve the instruction
-encoding containing all ones to be an illegal instruction, to catch
-the other common pattern observed with unprogrammed non-volatile
-memory devices, disconnected memory buses, or broken memory devices.
-
-Software can rely on a naturally aligned 32-bit word containing zero
-to act as an illegal instruction on all RISC-V implementations, to be
-used by software where an illegal instruction is explicitly desired.
-Defining a corresponding known illegal value for all ones is more
-difficult due to the variable-length encoding. Software cannot
-generally use the illegal value of ILEN bits of all 1s, as software
-might not know ILEN for the eventual target machine (e.g., if software
-is compiled into a standard binary library used by many different
-machines). Defining a 32-bit word of all ones as illegal was also
-considered, as all machines must support a 32-bit instruction size,
-but this requires the instruction-fetch unit on machines with
-ILEN$>$32 report an illegal instruction exception rather than access
-fault when such an instruction borders a protection boundary,
-complicating variable-instruction-length fetch and decode.
-\end{commentary}
-
-RISC-V base ISAs have little-endian memory systems. Instructions are
-stored in memory with each 16-bit parcel stored in a memory
-halfword. Parcels forming one instruction are stored at increasing
-halfword addresses, with the lowest-addressed parcel holding the
-lowest-numbered bits in the instruction specification.
-
-\begin{commentary}
-We chose little-endian byte ordering for the RISC-V memory system
-because little-endian systems are currently dominant commercially (all
-x86 systems; iOS, Android, and Windows for ARM). A minor point is
-that we have also found little-endian memory systems to be more
-natural for hardware designers. However, certain application areas,
-such as IP networking, operate on big-endian data structures, and
-certain legacy code bases have been built assuming big-endian
-processors, so we expect that future specifications will describe
-big-endian or bi-endian variants of RISC-V.
-
-We have to fix the order in which instruction parcels are stored in
-memory, independent of memory system endianness, to ensure that the
-length-encoding bits always appear first in halfword address
-order. This allows the length of a variable-length instruction to be
-quickly determined by an instruction-fetch unit by examining only the
-first few bits of the first 16-bit instruction parcel. Once we had
-decided to fix on a native little-endian memory system and instruction
-parcel ordering, this naturally led to placing the length-encoding
-bits in the LSB positions of the instruction format to avoid breaking
-up opcode fields.
-\end{commentary}
-
-\section{Exceptions, Traps, and Interrupts}
-
-We use the term {\em exception} to refer to an unusual condition
-occurring at run time associated with an instruction in the current
-RISC-V hart. We use the term {\em interrupt} to refer to an external
-asynchronous event that may cause a RISC-V hart to experience an
-unexpected transfer of control. We use the term {\em trap} to refer
-to the transfer of control to a trap handler caused by either an
-exception or an interrupt.
-
-The instruction descriptions in following chapters describe conditions
-that can raise an exception during execution. The general behavior of
-most RISC-V EEIs is that a trap to some handler occurs when an
-exception is signaled on an instruction (except for floating-point
-exceptions, which, in the standard floating-point extensions, do not
-cause traps). The manner in which interrupts are generated, routed
-to, and enabled by a hart depends on the EEI.
-
-\begin{commentary}
-Our use of ``exception'' and ``trap'' is compatible with that in the IEEE-754
-floating-point standard.
-\end{commentary}
-
-How traps are handled and made visible to software running on the hart
-depends on the enclosing execution environment. From the perspective
-of software running inside an execution environment, traps encountered
-by a hart at runtime can have four different effects:
-\begin{description}
- \item[Contained Trap:] The trap is visible to, and handled by,
- software running inside the execution environment. For example,
- in an EEI providing both supervisor and user
- mode on harts, an ECALL by a user-mode hart will generally result
- in a transfer of control to a supervisor-mode handler running on
- the same hart. Similarly, in the same environment, when a hart is
- interrupted, an interrupt handler will be run in supervisor mode
- on the hart.
- \item[Requested Trap:] The trap is a synchronous exception that is
- an explicit call to the execution environment requesting an action
- of behalf of software inside the execution environment. An
- example is a system call. In this case, execution may or may not
- resume on the hart after the requested action is taken by the
- execution environment. For example, a system call could remove the
- hart or cause an orderly termination of the entire execution environment.
- \item[Invisible Trap:] The trap is handled transparently by the
- execution environment and execution resumes normally after the
- trap is handled. Examples include emulating missing instructions,
- handling non-resident page faults in a demand-paged virtual-memory
- system, or handling device interrupts for a different job in a
- multiprogrammed machine. In these cases, the software running
- inside the execution environment is not aware of the trap (we
- ignore timing effects in these definitions).
- \item[Fatal Trap:] The trap represents a fatal failure and causes
- the execution environment to terminate execution. Examples
- include failing a virtual-memory page-protection check or allowing
- a watchdog timer to expire. Each EEI should define how execution
- is terminated and reported to an external environment.
-\end{description}
-
-The following table shows the characteristics of each kind of trap:
-
-\begin{table}[hbt]
- \centering
- \begin{tabular}{|l|c|c|c|c|}
- \hline
- & Contained & Requested & Invisible & Fatal\\
- \hline
- Execution terminates? & N & N$^{1}$ & N & Y \\
- Software is oblivious? & N & N & Y & Y$^{2}$ \\
- Handled by environment? & N & Y & Y & Y \\
- \hline
- \end{tabular}
- \caption{Characteristics of traps. Notes: 1) termination may be
- requested; 2) imprecise fatal traps might be observable by software.}
-\end{table}
-
-The EEI defines for each trap whether it is handled precisely, though
-the recommendation is to maintain preciseness where possible.
-Contained and requested traps can be observed to be imprecise by
-software inside the execution environment. Invisible traps, by
-definition, cannot be observed to be precise or imprecise by software
-running inside the execution environment. Fatal traps can be observed
-to be imprecise by software running inside the execution environment,
-if known-errorful instructions do not cause immediate termination.
-
-Because this document describes unprivileged instructions, traps are
-rarely mentioned. Architectural means to handle contained traps are
-defined in the privileged architecture manual, along with other
-features to support richer EEIs. Unprivileged instructions that are
-defined solely to cause requested traps are documented here.
-Invisible traps are, by their nature, out of scope for this document.
-Instruction encodings that are not defined here and not defined by
-some other means may cause a fatal trap.
diff --git a/src/j.tex b/src/j.tex
deleted file mode 100644
index 37a8b37..0000000
--- a/src/j.tex
+++ /dev/null
@@ -1,13 +0,0 @@
-\chapter{``J'' Standard Extension for Dynamically Translated Languages, Version 0.0}
-\label{sec:j}
-
-This chapter is a placeholder for a future standard extension to
-support dynamically translated languages.
-
-\begin{commentary}
- Many popular languages are usually implemented via dynamic
- translation, including Java and Javascript. These languages can
- benefit from additional ISA support for dynamic checks and garbage
- collection.
-\end{commentary}
-
diff --git a/src/l.tex b/src/l.tex
deleted file mode 100644
index 30c688d..0000000
--- a/src/l.tex
+++ /dev/null
@@ -1,20 +0,0 @@
-\chapter{``L'' Standard Extension for Decimal Floating-Point, Version 0.0}
-
-{\bf This chapter is a draft proposal that has not been ratified by
- the Foundation.}
-
-This chapter is a placeholder for the specification of a standard
-extension named ``L'' designed to support decimal floating-point
-arithmetic as defined in the IEEE 754-2008 standard.
-
-\section{Decimal Floating-Point Registers}
-
-Existing floating-point registers are used to hold 64-bit and 128-bit
-decimal floating-point values, and the existing floating-point load
-and store instructions are used to move values to and from memory.
-
-\begin{commentary}
-Due to the large opcode space required by the fused multiply-add
-instructions, the decimal floating-point instruction extension will
-require five 25-bit major opcodes in a 30-bit encoding space.
-\end{commentary}
diff --git a/src/m-st-ext.adoc b/src/m-st-ext.adoc
new file mode 100644
index 0000000..fbde003
--- /dev/null
+++ b/src/m-st-ext.adoc
@@ -0,0 +1,157 @@
+[[mstandard]]
+== "M" Extension for Integer Multiplication and Division, Version 2.0
+
+This chapter describes the standard integer multiplication and division
+instruction extension, which is named `M` and contains instructions
+that multiply or divide values held in two integer registers.
+
+[NOTE]
+====
+We separate integer multiply and divide out from the base to simplify
+low-end implementations, or for applications where integer multiply and
+divide operations are either infrequent or better handled in attached
+accelerators.
+====
+
+=== Multiplication Operations
+
+include::images/wavedrom/m-st-ext-for-int-mult.edn[]
+[[m-st-ext-for-int-mult]]
+//.Multiplication operation instructions
+(((MUL, MULH)))
+(((MUL, MULHU)))
+(((MUL, MULHSU)))
+
+[#norm:mul_op]#MUL performs an XLEN-bit×XLEN-bit multiplication of
+`rs1` by `rs2` and places the lower XLEN bits in the destination
+register.# [#norm:mulh_mulhu_mulhsu_op]#MULH, MULHU, and MULHSU perform the same multiplication but
+return the upper XLEN bits of the full 2×XLEN-bit
+product, for signed×signed,
+unsigned×unsigned, and `rs1`×unsigned `rs2` multiplication.#
+If both the high and low bits of the same product are required, then the recommended code sequence is: `MULH[[S]U] rdh, rs1, rs2; MUL rdl, rs1, rs2` (source register specifiers must be in same order and `rdh` cannot be the same as `rs1` or `rs2`). Microarchitectures can then fuse these into a single multiply operation instead of performing two separate multiplies.
+
+[NOTE]
+====
+MULHSU is used in multi-word signed multiplication to multiply the
+most-significant word of the multiplicand (which contains the sign bit)
+with the less-significant words of the multiplier (which are unsigned).
+====
+
+[#norm:mulw_op]#MULW is an RV64 instruction that multiplies the lower 32 bits of the
+source registers, placing the sign extension of the lower 32 bits of the
+result into the destination register.#
+
+[NOTE]
+====
+In RV64, MUL can be used to obtain the upper 32 bits of the 64-bit
+product, but signed arguments must be proper 32-bit signed values,
+whereas unsigned arguments must have their upper 32 bits clear. If the
+arguments are not known to be sign- or zero-extended, an alternative is
+to shift both arguments left by 32 bits, then use MULH[[S]U].
+====
+
+=== Division Operations
+
+include::images/wavedrom/division-op.edn[]
+[[division-op]]
+//.Division operation instructions
+(((MUL, DIV)))
+(((MUL, DIVU)))
+
+[#norm:div_divu_op]#DIV and DIVU perform an XLEN bits by XLEN bits signed and unsigned
+integer division of `rs1` by `rs2`, rounding towards zero.# [#norm:rem_remu_op]#REM and REMU
+provide the remainder of the corresponding division operation.# [#norm:rem_result_sign]#For REM,
+the sign of a nonzero result equals the sign of the dividend.#
+
+[NOTE]
+====
+For both signed and unsigned division, except in the case of overflow, it holds
+that dividend = divisor {times} quotient + remainder.
+====
+
+If both the quotient and remainder are required from the same division,
+the recommended code sequence is: `DIV[U] rdq, rs1, rs2; REM[U] rdr,`
+`rs1, rs2` (`rdq` cannot be the same as `rs1` or `rs2`).
+Microarchitectures can then fuse these into a single divide operation
+instead of performing two separate divides.
+
+[#norm:divw_divuw_op]#DIVW and DIVUW are RV64 instructions that divide the lower 32 bits of
+`rs1` by the lower 32 bits of `rs2`, treating them as signed and
+unsigned integers, placing the 32-bit quotient in `rd`,
+sign-extended to 64 bits.# [#norm:remw_remuw_op]#REMW and REMUW are RV64 instructions that
+provide the corresponding signed and unsigned remainder
+operations.# [#norm:remw_remuw_result_sign]#BothREMW and REMUW always sign-extend the 32-bit result
+to 64 bits, including on a divide by zero.#
+(((MUL, div by zero)))
+
+The semantics for division by zero and division overflow are summarized
+in <<divby0>>. [#norm:div_by_zero]#The quotient of division by zero has all bits
+set#, and [#norm:rem_by_zero]#the remainder of division by zero equals the dividend.#
+[#norm:signed_div_overflow]#Signed division overflow occurs only when the most-negative integer is divided
+by −1. The quotient of a signed division with overflow is
+equal to the dividend, and the remainder is zero.# Unsigned division
+overflow cannot occur.
+
+[[divby0]]
+.Semantics for division by zero and division overflow. L is the width of the operation in bits: XLEN for DIV[U] and REM[U], or 32 for DIV[U]W and REM[U]W.
+[cols="<2,^,^,^,^,^,^",options="header",]
+|===
+|Condition |Dividend |Divisor |DIVU[W] |REMU[W] |DIV[W] |REM[W]
+
+|Division by zero +
+Overflow (signed only) |_x_ +
+-2^L-1^ |0 +
+−1 |2^L^-1 +
+ - |_x_ +
+ - |−1 +
+ -2^L-1^ +
+ |_x_ +
+ 0
+|===
+
+//|Overflow (signed only) |−2^L−1^ |−1 |– |– |−2^L−1^ |0
+//|===
+
+[NOTE]
+====
+We considered raising exceptions on integer divide by zero, with these
+exceptions causing a trap in most execution environments. However, this
+would be the only arithmetic trap in the standard ISA (floating-point
+exceptions set flags and write default values, but do not cause traps)
+and would require language implementers to interact with the execution
+environment's trap handlers for this case. Further, where language
+standards mandate that a divide-by-zero exception must cause an
+immediate control flow change, only a single branch instruction needs to
+be added to each divide operation, and this branch instruction can be
+inserted after the divide and should normally be very predictably not
+taken, adding little runtime overhead.
+
+The value of all bits set is returned for both unsigned and signed
+divide by zero to simplify the divider circuitry. The value of all 1s is
+both the natural value to return for unsigned divide, representing the
+largest unsigned number, and also the natural result for simple unsigned
+divider implementations. Signed division is often implemented using an
+unsigned division circuit and specifying the same overflow result
+simplifies the hardware.
+====
+
+=== `Zmmul` Extension, Version 1.0
+
+The `Zmmul` extension implements the multiplication subset of the M
+extension. It adds all of the instructions defined in
+<<Multiplication Operations>>, namely: MUL, MULH, MULHU,
+MULHSU, and (for RV64 only) MULW. The encodings are identical to those
+of the corresponding M-extension instructions. `M` implies `Zmmul`.
+(((MUL, Zmmul)))
+
+[NOTE]
+====
+The `Zmmul` extension enables low-cost implementations that require
+multiplication operations but not division. For many microcontroller
+applications, division operations are too infrequent to justify the cost
+of divider hardware. By contrast, multiplication operations are more
+frequent, making the cost of multiplier hardware more justifiable.
+Simple FPGA soft cores particularly benefit from eliminating division
+but retaining multiplication, since many FPGAs provide hardwired
+multipliers but require dividers be implemented in soft logic.
+====
diff --git a/src/m.tex b/src/m.tex
deleted file mode 100644
index 9f0ee4c..0000000
--- a/src/m.tex
+++ /dev/null
@@ -1,162 +0,0 @@
-\chapter{``M'' Standard Extension for Integer Multiplication and
- Division, Version 2.0}
-
-This chapter describes the standard integer multiplication and
-division instruction extension, which is named ``M'' and contains
-instructions that multiply or divide values held in two integer
-registers.
-
-\begin{commentary}
-We separate integer multiply and divide out from the base to simplify
-low-end implementations, or for applications where integer multiply
-and divide operations are either infrequent or better handled in
-attached accelerators.
-\end{commentary}
-
-\section{Multiplication Operations}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}R@{}R@{}S@{}R@{}O}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct7} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-MULDIV & multiplier & multiplicand & MUL/MULH[[S]U] & dest & OP \\
-MULDIV & multiplier & multiplicand & MULW & dest & OP-32 \\
-\end{tabular}
-\end{center}
-
-MUL performs an XLEN-bit$\times$XLEN-bit multiplication
-of {\em rs1} by {\em rs2} and places the
-lower XLEN bits in the destination register. MULH, MULHU, and MULHSU
-perform the same multiplication but return the upper XLEN bits of the
-full 2$\times$XLEN-bit product, for signed$\times$signed,
-unsigned$\times$unsigned, and \wunits{signed}{\em rs1}$\times$\wunits{unsigned}{\em rs2} multiplication,
-respectively. If both the high and low bits of the same product are
-required, then the recommended code sequence is: MULH[[S]U] {\em rdh,
- rs1, rs2}; MUL {\em rdl, rs1, rs2} (source register specifiers must
-be in same order and {\em rdh} cannot be the same as {\em rs1} or {\em
- rs2}). Microarchitectures can then fuse these into a single
-multiply operation instead of performing two separate multiplies.
-
-\begin{commentary}
-MULHSU is used in multi-word signed multiplication to multiply the
-most-significant word of the multiplier (which contains the sign bit)
-with the less-significant words of the multiplicand (which are unsigned).
-\end{commentary}
-
-MULW is an RV64 instruction that multiplies the lower 32 bits of the source
-registers, placing the sign-extension of the lower 32 bits of the result
-into the destination register.
-
-\begin{commentary}
-In RV64, MUL can be used to obtain the upper 32 bits of the 64-bit product,
-but signed arguments must be proper 32-bit signed values, whereas unsigned
-arguments must have their upper 32 bits clear. If the
-arguments are not known to be sign- or zero-extended, an alternative is to
-shift both arguments left by 32 bits, then use MULH[[S]U].
-\end{commentary}
-
-\section{Division Operations}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}R@{}R@{}O@{}R@{}O}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct7} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-MULDIV & divisor & dividend & DIV[U]/REM[U] & dest & OP \\
-MULDIV & divisor & dividend & DIV[U]W/REM[U]W & dest & OP-32 \\
-\end{tabular}
-\end{center}
-
-DIV and DIVU perform an XLEN bits by XLEN bits signed and unsigned integer
-division of {\em rs1} by {\em rs2}, rounding towards zero.
-REM and REMU provide the remainder of the
-corresponding division operation. If both the quotient and remainder
-are required from the same division, the recommended code sequence is:
-DIV[U] {\em rdq, rs1, rs2}; REM[U] {\em rdr, rs1, rs2} ({\em rdq}
-cannot be the same as {\em rs1} or {\em rs2}). Microarchitectures can
-then fuse these into a single divide operation instead of performing
-two separate divides.
-
-DIVW and DIVUW are RV64 instructions that divide the
-lower 32 bits of {\em rs1} by the lower 32 bits of {\em rs2}, treating
-them as signed and unsigned integers respectively, placing the 32-bit
-quotient in {\em rd}, sign-extended to 64 bits. REMW and REMUW
-are RV64 instructions that provide the corresponding
-signed and unsigned remainder operations respectively. Both REMW and
-REMUW always sign-extend the 32-bit result to 64 bits, including on a
-divide by zero.
-
-The semantics for division by zero and division overflow are summarized in
-Table~\ref{tab:divby0}. The quotient of division by zero has all bits set, and
-the remainder of division by zero equals the dividend. Signed division overflow
-occurs only when the most-negative integer is divided by $-1$. The quotient of
-a signed division with overflow is equal to the dividend, and the remainder is
-zero. Unsigned division overflow cannot occur.
-
-\vspace{0.1in}
-\begin{table}[h]
-\center
-\begin{tabular}{|l|c|c||c|c|c|c|}
-\hline
-Condition & Dividend & Divisor & DIVU[W] & REMU[W] & DIV[W] & REM[W] \\ \hline
-Division by zero & $x$ & 0 & $2^{L}-1$ & $x$ & $-1$ & $x$ \\
-Overflow (signed only) & $-2^{L-1}$ & $-1$ & -- & -- & $-2^{L-1}$ & 0 \\
-\hline
-\end{tabular}
-\caption{Semantics for division by zero and division overflow.
-L is the width of the operation in bits: XLEN for DIV[U] and REM[U], or
-32 for DIV[U]W and REM[U]W.}
-\label{tab:divby0}
-\end{table}
-
-\begin{commentary}
-We considered raising exceptions on integer divide by zero, with these
-exceptions causing a trap in most execution environments. However,
-this would be the only arithmetic trap in the standard ISA
-(floating-point exceptions set flags and write default values, but do
-not cause traps) and would require language implementors to interact
-with the execution environment's trap handlers for this case.
-Further, where language standards mandate that a divide-by-zero
-exception must cause an immediate control flow change, only a single
-branch instruction needs to be added to each divide operation, and
-this branch instruction can be inserted after the divide and should
-normally be very predictably not taken, adding little runtime
-overhead.
-
-The value of all bits set is returned for both unsigned and signed
-divide by zero to simplify the divider circuitry. The value of all 1s
-is both the natural value to return for unsigned divide, representing
-the largest unsigned number, and also the natural result for simple
-unsigned divider implementations. Signed division is often
-implemented using an unsigned division circuit and specifying the same
-overflow result simplifies the hardware.
-\end{commentary}
diff --git a/src/machine.adoc b/src/machine.adoc
new file mode 100644
index 0000000..914ed63
--- /dev/null
+++ b/src/machine.adoc
@@ -0,0 +1,3341 @@
+[[machine]]
+== Machine-Level ISA, Version 1.13
+
+This chapter describes the machine-level operations available in
+[#norm:M_highest_priv_mode]#machine-mode (M-mode), which is the highest privilege mode in a RISC-V
+hart.# [#norm:M_mode_at_reset]#M-mode is used for low-level access to a hardware platform and
+is the first mode entered at reset.# M-mode can also be used to implement
+features that are too difficult or expensive to implement in hardware
+directly. The RISC-V machine-level ISA contains a common core that is
+extended depending on which other privilege levels are supported and
+other details of the hardware implementation.
+
+=== Machine-Level CSRs
+
+In addition to the machine-level CSRs described in this section,
+[#norm:M_access_all_lower_priv_CSRs]#M-mode code can access all CSRs at lower privilege levels.#
+
+[[misa]]
+==== Machine ISA (`misa`) Register
+
+[#norm:misa_acc]#The `misa` CSR is a *WARL* read-write register# reporting the ISA supported by the hart.
+[#norm:misa_always_rd]#This register must be readable in any implementation#,
+but [#norm:MISA_CSR_IMPLEMENTED]#a value of zero can be returned to indicate the `misa` register has not been implemented#, requiring that CPU capabilities be determined through a separate non-standard mechanism.
+
+.Machine ISA register (misa)
+include::images/bytefield/misareg.edn[]
+
+[#norm:misa_mxl_op_isa]#The MXL (Machine XLEN) field encodes the native base integer ISA width as
+shown in <<misabase>>.#
+[#norm:misa_mxl_acc]#The MXL field is read-only.#
+[#norm:misa_mxl_op_nz]#If `misa` is nonzero, the
+MXL field indicates the effective XLEN in M-mode, a constant termed _MXLEN_.#
+XLEN is never greater than MXLEN, but XLEN might be smaller than MXLEN in
+less-privileged modes.
+
+[[misabase]]
+.Encoding of MXL field in `misa`
+[%autowidth,float="center",align="center",cols=">,>",options="header",]
+|===
+|MXL |XLEN
+|1 +
+2 +
+3
+|32 +
+64 +
+_Reserved_
+|===
+
+[#norm:misa_sz]#The `misa` CSR is MXLEN bits wide.#
+
+[NOTE]
+====
+The base width can be quickly ascertained using branches on the sign of
+the returned `misa` value, and possibly a shift left by one and a second
+branch on the sign. These checks can be written in assembly code without
+knowing the register width (MXLEN) of the hart. The base width is
+given by __MXLEN=2^MXL+4^__.
+
+The base width can also be found if `misa` is zero, by placing the
+immediate 2 in a register, then shifting the register left by 31 bits.
+If zero, the hart is RV32, else it is RV64.
+====
+
+[#norm:misa_extensions_enc]#The Extensions field encodes the presence of the standard extensions,
+with a single bit per letter of the alphabet (bit 0 encodes presence of
+extension "A" , bit 1 encodes presence of extension "B", through to
+bit 25 which encodes "Z").#
+[#norm:misa_i_op]#The "I" bit will be set for the RV32I and RV64I base ISAs#,
+and [#norm:misa_e_op]#the "E" bit will be set for RV32E and RV64E.#
+[#norm:misa_extensions_op]#The Extensions field is a *WARL* field that can contain writable bits where the
+implementation allows the supported ISA to be modified.#
+[#norm:misa_extensions_rst]#At reset,
+the Extensions field shall contain the maximal set of supported extensions,
+and "I" shall be selected over "E" if both are available.#
+
+[[norm:misa_extensions_disabling]]
+When a standard extension is disabled by clearing its bit in `misa`, the
+instructions and CSRs defined or modified by the extension revert to
+their defined or reserved behaviors as if the extension is not
+implemented.
+
+[NOTE]
+====
+[[norm:misa_extensions_impl_def]]
+For a given RISC-V execution environment, an instruction, extension, or
+other feature of the RISC-V ISA is ordinarily judged to be _implemented_
+or not by the observable execution behavior in that environment. For
+example, the F extension is said to be implemented for an execution
+environment if and only if the instructions that the RISC-V Unprivileged
+ISA defines for F execute as specified.
+
+[[norm:misa_extensions_disabling_def]]
+With this definition of _implemented_, disabling an extension by
+clearing its bit in `misa` results in the extension being considered
+_not implemented_ in M-mode. For example, setting `misa`.F=0 results in
+the F extension being not implemented for M-mode, because the F
+extension's instructions will not act as the Unprivileged ISA requires
+but may instead raise an illegal-instruction exception.
+
+Defining the term _implemented_ based strictly on the observable
+behavior might conflict with other common understandings of the same
+word. In particular, although common usage may allow for the combination
+"implemented but disabled," in this document it is considered a
+contradiction of terms, because _disabled_ implies execution will not
+behave as required for the feature to be considered _implemented_. In
+the same vein, "implemented and enabled" is redundant here;
+"implemented" suffices.
+====
+
+[#norm:misa_extensions_rsv_ret_0]#All bits that are reserved for future use must return zero when read.#
+
+.Encoding of Extensions field in `misa`.
+[%autowidth,float="center",align="center",cols=">,>,<",options="header",]
+|===
+|Bit |Character |Description
+|0 +
+1 +
+2 +
+3 +
+4 +
+5 +
+6 +
+7 +
+8 +
+9 +
+10 +
+11 +
+12 +
+13 +
+14 +
+15 +
+16 +
+17 +
+18 +
+19 +
+20 +
+21 +
+22 +
+23 +
+24 +
+25 +
+|A +
+B +
+C +
+D +
+E +
+F +
+G +
+H +
+I +
+J +
+K +
+L +
+M +
+N +
+O +
+P +
+Q +
+R +
+S +
+T +
+U +
+V +
+W +
+X +
+Y +
+Z
+|Atomic extension +
+B extension +
+Compressed extension +
+Double-precision floating-point extension +
+RV32E/64E base ISA +
+Single-precision floating-point extension +
+_Reserved_ +
+Hypervisor extension +
+RV32I/64I base ISA +
+_Reserved_ +
+_Reserved_ +
+_Reserved_ +
+Integer Multiply/Divide extension +
+_Tentatively reserved for User-Level Interrupts extension_ +
+_Reserved_ +
+_Tentatively reserved for Packed-SIMD extension_ +
+Quad-precision floating-point extension +
+_Reserved_ +
+Supervisor mode implemented +
+_Reserved_ +
+User mode implemented +
+Vector extension +
+_Reserved_ +
+Non-standard extensions present +
+_Reserved_ +
+_Reserved_
+|===
+
+[#norm:misa_x_op]#The "X" bit will be set if there are any non-standard extensions.#
+
+[#norm:misa_b_op]#When the "B" bit is 1, the implementation supports the instructions provided by the
+Zba, Zbb, and Zbs extensions.# When the "B" bit is 0, it indicates that the
+implementation might not support one or more of the Zba, Zbb, or Zbs extensions.
+
+[#norm:misa_m_op]#When the "M" bit is 1, the implementation supports all multiply and
+division instructions defined by the M extension.# When the "M" bit
+is 0, it indicates that the implementation might not support those
+instructions. However [#norm:Zmmul_misa_m]#if the Zmmul extension is supported then
+the multiply instructions it specifies are supported irrespective
+of the value of the "M" bit.#
+
+[#norm:misa_s_op]#When the "S" bit is 1, the implementation supports supervisor mode.#
+When the "S" bit is 0, the implementation might not support supervisor mode.
+
+[#norm:misa_u_op]#When the "U" bit is 1, the implementation supports user mode.#
+When the "U" bit is 0, the implementation might not support user mode.
+
+[NOTE]
+====
+The `misa` CSR exposes a rudimentary catalog of CPU features to
+machine-mode code. More extensive information can be obtained in machine
+mode by probing other machine registers, and examining other ROM storage
+in the system as part of the boot process.
+
+We require that lower privilege levels execute environment calls instead
+of reading CPU registers to determine features available at each
+privilege level. This enables virtualization layers to alter the ISA
+observed at any level, and supports a much richer command interface
+without burdening hardware designs.
+====
+
+[#norm:misa_e_acc]#The "E" bit is read-only.#
+[#norm:misa_e_not_i]#Unless `misa` is all read-only zero, the
+"E" bit always reads as the complement of the "I" bit.#
+If an execution environment supports both RV32E and RV32I, software can select
+RV32E by clearing the "I" bit.
+
+[#norm:misa_extensions_dependencies]#If an ISA feature _x_ depends on an ISA feature _y_, then attempting to
+enable feature _x_ but disable feature _y_ results in both features
+being disabled.#
+For example, setting "F"=0 and "D"=1 results in both "F" and "D" being cleared.
+Similarly, setting "U"=0 and "S"=1" results in both "U" and "S" being cleared.
+
+An implementation may impose additional constraints on the collective
+setting of two or more `misa` fields, in which case they function
+collectively as a single *WARL* field. An attempt to write an unsupported combination causes those bits to be set to some supported combination.
+
+[#norm:misa_inc_ialign]#Writing `misa` may increase IALIGN, e.g., by disabling the "C"
+extension. If an instruction that would write `misa` increases IALIGN,
+and the subsequent instruction's address is not IALIGN-bit aligned, the
+write to `misa` is suppressed, leaving `misa` unchanged.#
+
+When software enables an extension that was previously disabled, then
+all state uniquely associated with that extension is UNSPECIFIED, unless otherwise specified by that extension.
+
+NOTE: Although one of the bits 25--0 in `misa` being set to 1 implies that
+the corresponding feature is implemented, the inverse is not necessarily
+true: one of these bits being clear does not necessarily imply that the
+corresponding feature is not implemented. This follows from the fact that,
+when a feature is not implemented, the corresponding opcodes and CSRs become
+reserved, not necessarily illegal.
+
+==== Machine Vendor ID (`mvendorid`) Register
+
+[#norm:mvendorid_sz_acc_op]#The `mvendorid` CSR is a 32-bit read-only register providing the JEDEC
+manufacturer ID of the provider of the core.#
+[#norm:mvendorid_always_rd]#This register must be readable in any implementation, but a value of 0 can be returned to
+indicate the field is not implemented or that this is a non-commercial implementation.#
+
+//.Vendor ID register (`mvendorid`)
+//image::png/mvendorid.png[align="center"]
+
+.Vendor ID register (`mvendorid`)
+include::images/bytefield/mvendorid.edn[]
+
+[#norm:mvendorid_enc]#JEDEC manufacturer IDs are ordinarily encoded as a sequence of one-byte
+continuation codes `0x7f`, terminated by a one-byte ID not equal to
+`0x7f`, with an odd parity bit in the most-significant bit of each byte.
+`mvendorid` encodes the number of one-byte continuation codes in the
+Bank field, and encodes the final byte in the Offset field, discarding
+the parity bit.# For example, the JEDEC manufacturer ID
+`0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x8a`
+(twelve continuation codes followed by `0x8a`) would be encoded in the
+`mvendorid` CSR as `0x60a`.
+
+[NOTE]
+====
+[[norm:mvendorid_bank_1_less_than_JEDEC]]
+In JEDEC's parlance, the bank number is one greater than the number of
+continuation codes; hence, the `mvendorid` Bank field encodes a value
+that is one less than the JEDEC bank number.
+
+***
+Previously the vendor ID was to be a number allocated by RISC-V
+International, but this duplicates the work of JEDEC in maintaining a
+manufacturer ID standard. At time of writing, registering a manufacturer
+ID with JEDEC has a one-time cost of $500.
+====
+
+==== Machine Architecture ID (`marchid`) Register
+
+[#norm:marchid_sz_acc_op]#The `marchid` CSR is an MXLEN-bit read-only register encoding the base
+microarchitecture of the hart.#
+[#norm:marchid_always_rd]#This register must be readable in any
+implementation, but a value of 0 can be returned to indicate the field is not implemented.#
+The combination of `mvendorid` and `marchid` should uniquely identify the type of hart microarchitecture that is implemented.
+
+.Machine Architecture ID (`marchid`) register
+include::images/bytefield/marchid.edn[]
+
+Open-source project architecture IDs are allocated globally by RISC-V
+International, and have non-zero architecture IDs with a zero
+most-significant-bit (MSB). Commercial architecture IDs are allocated by
+each commercial vendor independently, but must have the MSB set and
+cannot contain zero in the remaining MXLEN-1 bits.
+
+[NOTE]
+====
+The intent is for the architecture ID to represent the microarchitecture
+associated with the project around which development occurs rather than a
+particular organization. Commercial fabrications of open-source designs
+should (and might be required by the license to) retain the original
+architecture ID. This will aid in reducing fragmentation and tool
+support costs, as well as provide attribution. Open-source architecture
+IDs are administered by RISC-V International and should only be
+allocated to released, functioning open-source projects. Commercial
+architecture IDs can be managed independently by any registered vendor
+but are required to have IDs disjoint from the open-source architecture
+IDs (MSB set) to prevent collisions if a vendor wishes to use both
+closed-source and open-source microarchitectures.
+
+The convention adopted within the following Implementation field can be
+used to segregate branches of the same architecture design, including by
+organization. The `misa` register also helps distinguish different
+variants of a design.
+====
+
+==== Machine Implementation ID (`mimpid`) Register
+
+[#norm:mimpid_op]#The `mimpid` CSR provides a unique encoding of the version of the
+processor implementation.#
+[#norm:mimpid_always_rd]#This register must be readable in any
+implementation, but a value of 0 can be returned to indicate that the field is not implemented.#
+The Implementation value should reflect the design of the RISC-V processor itself and not any surrounding system.
+
+.Machine Implementation ID (`mimpid`) register
+include::images/bytefield/mimpid.edn[]
+
+[NOTE]
+====
+The format of this field is left to the provider of the architecture
+source code, but will often be printed by standard tools as a
+hexadecimal string without any leading or trailing zeros, so the
+Implementation value can be left-justified (i.e., filled in from
+most-significant nibble down) with subfields aligned on nibble
+boundaries to ease human readability.
+====
+
+==== Hart ID (`mhartid`) Register
+
+[#norm:mhartid_sz_acc_op]#The `mhartid` CSR is an MXLEN-bit read-only register containing the
+integer ID of the hardware thread running the code.#
+[#norm:mhartid_always_rd]#This register must be readable in any implementation.#
+Hart IDs might not necessarily be
+numbered contiguously in a multiprocessor system, but at least one hart
+must have a hart ID of zero. Hart IDs must be unique within the
+execution environment.
+
+.Hart ID (`mhartid`) register
+include::images/bytefield/mhartid.edn[]
+
+[NOTE]
+====
+In certain cases, we must ensure exactly one hart runs some code (e.g.,
+at reset), and so require one hart to have a known hart ID of zero.
+
+For efficiency, system implementers should aim to reduce the magnitude
+of the largest hart ID used in a system.
+====
+
+==== Machine Status (`mstatus` and `mstatush`) Registers
+
+[#norm:mstatus_sz_acc]#The `mstatus` register is an MXLEN-bit read/write register formatted as
+shown in <<mstatusreg-rv32>> for RV32 and <<mstatusreg>> for RV64.#
+The `mstatus` register keeps track of and controls the hart’s current operating state. A
+restricted view of `mstatus` appears as the `sstatus` register in the S-level ISA.
+
+[[mstatusreg-rv32]]
+.Machine-mode status (`mstatus`) register for RV32
+include::images/wavedrom/mstatusreg-rv321.edn[]
+
+[[mstatusreg]]
+.Machine-mode status (`mstatus`) register for RV64
+include::images/wavedrom/mstatusreg.edn[]
+
+[#norm:mstatush_sz_acc]#For RV32 only, `mstatush` is a 32-bit read/write register formatted as shown in <<mstatushreg>>.#
+[#norm:mstatush_enc]#Bits 30:4 of `mstatush` generally contain the same fields found in bits 62:36 of `mstatus` for RV64. Fields SD, SXL, and UXL do not exist in `mstatush`.#
+
+[[mstatushreg]]
+.Additional machine-mode status (`mstatush`) register for RV32.
+include::images/wavedrom/mstatushreg.edn[]
+
+[[privstack]]
+===== Privilege and Global Interrupt-Enable Stack in `mstatus` register
+
+Global interrupt-enable bits, MIE and SIE, are provided for M-mode and
+S-mode respectively. These bits are primarily used to guarantee
+atomicity with respect to interrupt handlers in the current privilege
+mode.
+
+[NOTE]
+====
+The global __x__IE bits are located in the low-order bits of `mstatus`,
+allowing them to be atomically set or cleared with a single CSR
+instruction.
+====
+
+When a hart is executing in privilege mode _x_, interrupts are globally
+enabled when __x__IE=1 and globally disabled when __x__IE=0. Interrupts for
+lower-privilege modes, __w__<__x__, are always globally
+disabled regardless of the setting of any global __w__IE bit for the
+lower-privilege mode. Interrupts for higher-privilege modes,
+__y__>__x__, are always globally enabled regardless of the
+setting of the global __y__IE bit for the higher-privilege mode.
+Higher-privilege-level code can use separate per-interrupt enable bits
+to disable selected higher-privilege-mode interrupts before ceding
+control to a lower-privilege mode.
+If supervisor mode is not implemented, then SIE and SPIE are read-only 0.
+
+[NOTE]
+====
+A higher-privilege mode _y_ could disable all of its interrupts before
+ceding control to a lower-privilege mode but this would be unusual as it
+would leave only a synchronous trap, non-maskable interrupt, or reset as
+means to regain control of the hart.
+====
+
+To support nested traps, each privilege mode _x_ that can respond to
+interrupts has a two-level stack of interrupt-enable bits and privilege
+modes. __x__PIE holds the value of the interrupt-enable bit active prior
+to the trap, and __x__PP holds the previous privilege mode. The __x__PP
+fields can only hold privilege modes up to _x_, so MPP is two bits wide
+and SPP is one bit wide. When a trap is taken from privilege mode _y_
+into privilege mode _x_, __x__PIE is set to the value of __x__IE; __x__IE is
+set to 0; and __x__PP is set to _y_.
+
+[NOTE]
+====
+For lower privilege modes, any trap (synchronous or asynchronous) is
+usually taken at a higher privilege mode with interrupts disabled upon
+entry. The higher-level trap handler will either service the trap and
+return using the stacked information, or, if not returning immediately
+to the interrupted context, will save the privilege stack before
+re-enabling interrupts, so only one entry per stack is required.
+====
+
+An MRET or SRET instruction is used to return from a trap in M-mode or
+S-mode respectively. When executing an __x__RET instruction, supposing
+__x__PP holds the value _y_, __x__IE is set to __x__PIE; the privilege mode is
+changed to _y_; __x__PIE is set to 1; and __x__PP is set to the
+least-privileged supported mode (U if U-mode is implemented, else M). If
+__y__{ne}M, __x__RET also sets MPRV=0.
+
+[NOTE]
+====
+Setting __x__PP to the least-privileged supported mode on an __x__RET helps identify software bugs in the management of the two-level privilege-mode stack.
+====
+
+[NOTE]
+====
+Trap handlers must be designed to neither enable interrupts nor cause exceptions
+during the phase of handling where the trap handler preserves the critical state
+information required to handle and resume from the trap. An exception or
+interrupt in this critical phase of trap handling may lead to a trap that can
+overwrite such critical state. This could result in the loss of data needed to
+recover from the initial trap. Further, if an exception occurs in the code path
+needed to handle traps, then such a situation may lead to an infinite loop of
+traps. To prevent this, trap handlers must be meticulously designed to identify
+and safely manage exceptions within their operational flow.
+====
+
+__x__PP fields are *WARL* fields that can hold only privilege mode _x_ and any implemented privilege mode lower than _x_. If privilege mode _x_ is not implemented, then __x__PP must be read-only 0.
+
+[NOTE]
+====
+M-mode software can determine whether a privilege mode is implemented by
+writing that mode to MPP then reading it back.
+
+If the machine provides only U and M modes, then only a single hardware
+storage bit is required to represent either 00 or 11 in MPP.
+====
+
+[[machine-double-trap]]
+===== Double Trap Control in `mstatus` Register
+
+A double trap typically arises during a sensitive phase in trap handling
+operations -- when an exception or interrupt occurs while the trap handler (the
+component responsible for managing these events) is in a non-reentrant state.
+This non-reentrancy usually occurs in the early phase of trap handling, wherein
+the trap handler has not yet preserved the necessary state to handle and resume
+from the trap. The occurrence of a trap during this phase can lead to an
+overwrite of critical state information, resulting in the loss of data needed to
+recover from the initial trap. The trap that caused this critical error
+condition is henceforth called the _unexpected trap_. Trap handlers are designed
+to neither enable interrupts nor cause exceptions during this phase of handling.
+However, managing Hardware-Error exceptions, which may occur unpredictably,
+presents significant challenges in trap handler implementation due to the
+potential risk of a double trap.
+
+The M-mode-disable-trap (`MDT`) bit is a WARL field introduced by the Smdbltrp
+extension. Upon reset, the `MDT` field is set to 1. When the `MDT` bit is set to
+1 by an explicit CSR write, the `MIE` (Machine Interrupt Enable) bit is cleared
+to 0. For RV64, this clearing occurs regardless of the value written, if any, to
+the `MIE` bit by the same write. The `MIE` bit can only be set to 1 by an
+explicit CSR write if the `MDT` bit is already 0 or, for RV64, is being set to 0
+by the same write (For RV32, the `MDT` bit is in `mstatush` and the `MIE` bit in
+`mstatus` register).
+
+When a trap is to be taken into M-mode, if the `MDT` bit is currently 0, it is
+then set to 1, and the trap is delivered as expected. However, if `MDT` is
+already set to 1, then this is an _unexpected trap_. When the Smrnmi extension
+is implemented, a trap caused by an RNMI is not considered an _unexpected trap_
+irrespective of the state of the `MDT` bit. A trap caused by an RNMI does not
+set the `MDT` bit. However, a trap that occurs when executing in M-mode with
+`mnstatus.NMIE` set to 0 is an _unexpected trap_.
+
+In the event of a _unexpected trap_, the handling is as follows:
+
+* When the Smrnmi extension is implemented and `mnstatus.NMIE` is 1, the hart
+ traps to the RNMI handler. To deliver this trap, the `mnepc` and `mncause`
+ registers are written with the values that the _unexpected trap_ would have
+ written to the `mepc` and `mcause` registers respectively. The privilege
+ mode information fields in the `mnstatus` register are written to indicate
+ M-mode and its `NMIE` field is set to 0.
+
+[NOTE]
+====
+The consequence of this specification is that on occurrence of double trap the
+RNMI handler is not provided with information that a trap reports in the
+`mtval` and the `mtval2` registers. This information, if needed, can be obtained
+by the RNMI handler by decoding the instruction at the address in `mnepc` and
+examining its source register contents.
+====
+
+* When the Smrnmi extension is not implemented, or if the Smrnmi extension is
+ implemented and `mnstatus.NMIE` is 0, the hart enters a critical-error state
+ without updating any architectural state, including the `pc`. This state
+ involves ceasing execution, disabling all interrupts (including NMIs), and
+ asserting a `critical-error` signal to the platform.
+
+[NOTE]
+====
+The actions performed by the platform when a hart asserts a `critical-error` signal
+are platform-specific. The range of possible actions include restarting
+the affected hart or restarting the entire platform, among others.
+====
+
+The `MRET` and `SRET` instructions, when executed in M-mode, set the `MDT` bit
+to 0. If the new privilege mode is U, VS, or VU, then `sstatus.SDT` is also set
+to 0. Additionally, if it is VU, then `vsstatus.SDT` is also set to 0.
+
+The `MNRET` instruction, provided by the Smrnmi extension, sets the `MDT` bit to
+0 if the new privilege mode is not M. If it is U, VS, or VU, then `sstatus.SDT` is
+also set to 0. Additionally, if it is VU, then `vsstatus.SDT` is also set to 0.
+
+[[xlen-control]]
+===== Base ISA Control in `mstatus` Register
+
+For RV64 harts, the SXL and UXL fields are *WARL* fields that control the
+value of XLEN for S-mode and U-mode, respectively. The encoding of these
+fields is the same as the MXL field of `misa`, shown in
+<<misabase>>. The effective XLEN in S-mode and
+U-mode are termed _SXLEN_ and _UXLEN_, respectively.
+
+When MXLEN=32, the SXL and UXL fields do not exist, and SXLEN=32 and
+UXLEN=32.
+
+When MXLEN=64, if S-mode is not supported, then SXL is read-only
+zero. Otherwise, it is a *WARL* field that encodes the current value of SXLEN.
+In particular, an implementation may make SXL be a read-only field whose
+value always ensures that SXLEN=MXLEN.
+
+When MXLEN=64, if U-mode is not supported, then UXL is read-only
+zero. Otherwise, it is a *WARL* field that encodes the current value of UXLEN.
+In particular, an implementation may make UXL be a read-only field whose
+value always ensures that UXLEN=MXLEN or UXLEN=SXLEN.
+
+If S-mode is implemented, the set of legal values that the UXL field may
+assume excludes those that would cause UXLEN to be greater than SXLEN.
+
+Whenever XLEN in any mode is set to a value less than the widest
+supported XLEN, all operations must ignore source operand register bits
+above the configured XLEN, and must sign-extend results to fill the
+entire widest supported XLEN in the destination register. Similarly,
+`pc` bits above XLEN are ignored, and when the `pc` is written, it is
+sign-extended to fill the widest supported XLEN.
+
+[NOTE]
+====
+We require that operations always fill the entire underlying hardware
+registers with defined values to avoid implementation-defined behavior.
+
+To reduce hardware complexity, the architecture imposes no checks that
+lower-privilege modes have XLEN settings less than or equal to the
+next-higher privilege mode. In practice, such settings would almost
+always be a software bug, but machine operation is well-defined even in
+this case.
+====
+
+Some HINT instructions are encoded as integer computational instructions that
+overwrite their destination register with its current value, e.g.,
+`c.addi x8, 0`.
+When such a HINT is executed with XLEN < MXLEN and bits MXLEN..XLEN of the
+destination register not all equal to bit XLEN-1, it is implementation-defined
+whether bits MXLEN..XLEN of the destination register are unchanged or are
+overwritten with copies of bit XLEN-1.
+
+NOTE: This definition allows implementations to elide register write-back for
+some HINTs, while allowing them to execute other HINTs in the same manner as
+other integer computational instructions.
+The implementation choice is observable only by privilege modes with an XLEN
+setting greater than the current XLEN; it is invisible to the current
+privilege mode.
+
+===== Memory Privilege in `mstatus` Register
+
+The MPRV (Modify PRiVilege) bit modifies the _effective privilege mode_,
+i.e., the privilege level at which loads and stores execute. When
+MPRV=0, loads and stores behave as normal, using the translation and
+protection mechanisms of the current privilege mode. When MPRV=1, load
+and store memory addresses are translated and protected, and endianness
+is applied, as though the current privilege mode were set to MPP.
+Instruction address-translation and protection are unaffected by the
+setting of MPRV. MPRV is read-only 0 if U-mode is not supported.
+
+An MRET or SRET instruction that changes the privilege mode to a mode
+less privileged than M also sets MPRV=0.
+
+The MXR (Make eXecutable Readable) bit modifies the privilege with which
+loads access virtual memory. When MXR=0, only loads from pages marked
+readable (R=1 in <<sv32pte>>) will succeed. When
+MXR=1, loads from pages marked either readable or executable (R=1 or
+X=1) will succeed. MXR has no effect when page-based virtual memory is
+not in effect. MXR is read-only 0 if S-mode is not supported.
+
+[NOTE]
+====
+The MPRV and MXR mechanisms were conceived to improve the efficiency of
+M-mode routines that emulate missing hardware features, e.g., misaligned
+loads and stores. MPRV obviates the need to perform address translation
+in software. MXR allows instruction words to be loaded from pages marked
+execute-only.
+
+The current privilege mode and the privilege mode specified by MPP might
+have different XLEN settings. When MPRV=1, load and store memory
+addresses are treated as though the current XLEN were set to MPP’s XLEN,
+following the rules in <<xlen-control>>.
+====
+The SUM (permit Supervisor User Memory access) bit modifies the
+privilege with which S-mode loads and stores access virtual memory. When
+SUM=0, S-mode memory accesses to pages that are accessible by U-mode
+(U=1 in <<sv32pte>>) will fault. When SUM=1, these
+accesses are permitted. SUM has no effect when page-based virtual memory
+is not in effect. Note that, while SUM is ordinarily ignored when not
+executing in S-mode, it _is_ in effect when MPRV=1 and MPP=S. SUM is
+read-only 0 if S-mode is not supported or if `satp`.MODE is read-only 0.
+
+The MXR and SUM mechanisms only affect the interpretation of permissions
+encoded in page-table entries. In particular, they have no impact on
+whether access-fault exceptions are raised due to PMAs or PMP.
+
+===== Endianness Control in `mstatus` and `mstatush` Registers
+
+The MBE, SBE, and UBE bits in `mstatus` and `mstatush` are *WARL* fields that
+control the endianness of memory accesses other than instruction
+fetches. Instruction fetches are always little-endian.
+
+MBE controls whether non-instruction-fetch memory accesses made from
+M-mode (assuming `mstatus`.MPRV=0) are little-endian (MBE=0) or
+big-endian (MBE=1).
+
+If S-mode is not supported, SBE is read-only 0. Otherwise, SBE controls
+whether explicit load and store memory accesses made from S-mode are
+little-endian (SBE=0) or big-endian (SBE=1).
+
+If U-mode is not supported, UBE is read-only 0. Otherwise, UBE controls
+whether explicit load and store memory accesses made from U-mode are
+little-endian (UBE=0) or big-endian (UBE=1).
+
+For _implicit_ accesses to supervisor-level memory management data
+structures, such as page tables, endianness is always controlled by SBE.
+Since changing SBE alters the implementation’s interpretation of these
+data structures, if any such data structures remain in use across a
+change to SBE, M-mode software must follow such a change to SBE by
+executing an SFENCE.VMA instruction with _rs1_=`x0` and _rs2_=`x0`.
+
+[NOTE]
+====
+Only in contrived scenarios will a given memory-management data
+structure be interpreted as both little-endian and big-endian. In
+practice, SBE will only be changed at runtime on world switches, in
+which case neither the old nor new memory-management data structure will
+be reinterpreted in a different endianness. In this case, no additional
+SFENCE.VMA is necessary, beyond what would ordinarily be required for a
+world switch.
+====
+
+If S-mode is supported, an implementation may make SBE be a read-only
+copy of MBE. If U-mode is supported, an implementation may make UBE be a
+read-only copy of either MBE or SBE.
+
+[NOTE]
+====
+An implementation supports only little-endian memory accesses if fields
+MBE, SBE, and UBE are all read-only 0. An implementation supports only
+big-endian memory accesses (aside from instruction fetches) if MBE is
+read-only 1 and SBE and UBE are each read-only 1 when S-mode and U-mode
+are supported.
+
+'''
+
+Volume I defines a hart’s address space as a circular sequence of
+2^XLEN^ bytes at consecutive addresses. The
+correspondence between addresses and byte locations is fixed and not
+affected by any endianness mode. Rather, the applicable endianness mode
+determines the order of mapping between memory bytes and a multibyte
+quantity (halfword, word, etc.).
+
+---
+
+Standard RISC-V ABIs are expected to be purely little-endian-only or
+big-endian-only, with no accommodation for mixing endianness.
+Nevertheless, endianness control has been defined so as to permit, for
+instance, an OS of one endianness to execute user-mode programs of the
+opposite endianness. Consideration has been given also to the
+possibility of non-standard usages whereby software flips the endianness
+of memory accesses as needed.
+
+***
+
+RISC-V instructions are uniformly little-endian to decouple instruction
+encoding from the current endianness settings, for the benefit of both
+hardware and software. Otherwise, for instance, a RISC-V assembler or
+disassembler would always need to know the intended active endianness,
+despite that the endianness mode might change dynamically during
+execution. In contrast, by giving instructions a fixed endianness, it is
+sometimes possible for carefully written software to be
+endianness-agnostic even in binary form, much like position-independent
+code.
+
+The choice to have instructions be only little-endian does have
+consequences, however, for RISC-V software that encodes or decodes
+machine instructions. In big-endian mode, such software must account for
+the fact that explicit loads and stores have endianness opposite that of
+instructions, for example by swapping byte order after loads and before
+stores.
+====
+
+[[virt-control]]
+===== Virtualization Support in `mstatus` Register
+
+The TVM (Trap Virtual Memory) bit is a *WARL* field that supports intercepting
+supervisor virtual-memory management operations. When TVM=1, attempts to
+read or write the `satp` CSR or execute an SFENCE.VMA or SINVAL.VMA
+instruction while executing in S-mode will raise an illegal-instruction
+exception. When TVM=0, these operations are permitted in S-mode. TVM is
+read-only 0 when S-mode is not supported.
+
+[NOTE]
+====
+The TVM mechanism improves virtualization efficiency by permitting guest
+operating systems to execute in S-mode, rather than classically
+virtualizing them in U-mode. This approach obviates the need to trap
+accesses to most S-mode CSRs.
+
+Trapping `satp` accesses and the SFENCE.VMA and SINVAL.VMA instructions
+provides the hooks necessary to lazily populate shadow page tables.
+====
+
+The TW (Timeout Wait) bit is a *WARL* field that supports intercepting the WFI
+instruction (see <<wfi>>). When TW=0, the WFI
+instruction may execute in lower privilege modes when not prevented for
+some other reason. When TW=1, then if WFI is executed in any
+less-privileged mode, and it does not complete within an
+implementation-specific, bounded time limit, the WFI instruction causes
+an illegal-instruction exception. An implementation may have WFI always
+raise an illegal-instruction exception in less-privileged modes when
+TW=1, even if there are pending globally-disabled interrupts when the
+instruction is executed. TW is read-only 0 when there are no modes less
+privileged than M.
+
+[NOTE]
+====
+Trapping the WFI instruction can trigger a world switch to another guest
+OS, rather than wastefully idling in the current guest.
+====
+
+When S-mode is implemented, then executing WFI in U-mode causes an
+illegal-instruction exception, unless it completes within an
+implementation-specific, bounded time limit. A future revision of this
+specification might add a feature that allows S-mode to selectively
+permit WFI in U-mode. Such a feature would only be active when TW=0.
+
+The TSR (Trap SRET) bit is a *WARL* field that supports intercepting the
+supervisor exception return instruction, SRET. When TSR=1, attempts to
+execute SRET while executing in S-mode will raise an illegal-instruction
+exception. When TSR=0, this operation is permitted in S-mode. TSR is
+read-only 0 when S-mode is not supported.
+
+[NOTE]
+====
+Trapping SRET is necessary to emulate the hypervisor extension (see
+<<hypervisor>>) on implementations that do not
+provide it.
+====
+
+===== Extension Context Status in `mstatus` Register
+
+Supporting substantial extensions is one of the primary goals of RISC-V,
+and hence we define a standard interface to allow unchanged
+privileged-mode code, particularly a supervisor-level OS, to support
+arbitrary user-mode state extensions.
+
+[NOTE]
+====
+To date, the V extension is the only standard extension that defines
+additional state beyond the floating-point CSR and data registers.
+====
+
+The FS[1:0] and VS[1:0] *WARL* fields and the XS[1:0] read-only field are used
+to reduce the cost of context save and restore by setting and tracking
+the current state of the floating-point unit and any other user-mode
+extensions respectively. The FS field encodes the status of the
+floating-point unit state, including the floating-point registers
+`f0`–`f31` and the CSRs `fcsr`, `frm`, and `fflags`. The VS field
+encodes the status of the vector extension state, including the vector
+registers `v0`–`v31` and the CSRs `vcsr`, `vxrm`, `vxsat`, `vstart`,
+`vl`, `vtype`, and `vlenb`. The XS field encodes the status of
+additional user-mode extensions and associated state. These fields can
+be checked by a context switch routine to quickly determine whether a
+state save or restore is required. If a save or restore is required,
+additional instructions and CSRs are typically required to effect and
+optimize the process.
+
+[NOTE]
+====
+The design anticipates that most context switches will not need to
+save/restore state in either or both of the floating-point unit or other
+extensions, so provides a fast check via the SD bit.
+====
+
+The FS, VS, and XS fields use the same status encoding as shown in
+<<fsxsencoding>>, with the four possible status
+values being Off, Initial, Clean, and Dirty.
+
+[[fsxsencoding]]
+.Encoding of FS[1:0], VS[1:0], and XS[1:0] status fields
+[%autowidth,float="center",align="center",cols=">,<,<",options="header",]
+|===
+|Status |FS and VS Meaning |XS Meaning
+|0 +
+1 +
+2 +
+3
+|Off +
+Initial +
+Clean +
+Dirty
+|All off +
+None dirty or clean, some on +
+None dirty, some clean +
+Some dirty
+|===
+
+If the F extension is implemented, the FS field shall not be read-only
+zero.
+
+If neither the F extension nor S-mode is implemented, then FS is
+read-only zero. If S-mode is implemented but the F extension is not, FS
+may optionally be read-only zero.
+
+[NOTE]
+====
+Implementations with S-mode but without the F extension are permitted,
+but not required, to make the FS field be read-only zero. Some such
+implementations will choose _not_ to have the FS field be read-only
+zero, so as to enable emulation of the F extension for both S-mode and
+U-mode via invisible traps into M-mode.
+====
+
+If the `v` registers are implemented, the VS field shall not be
+read-only zero.
+
+If neither the `v` registers nor S-mode is implemented, then VS is
+read-only zero. If S-mode is implemented but the `v` registers are not,
+VS may optionally be read-only zero.
+
+In harts without additional user extensions requiring new state, the
+XS field is read-only zero. Every additional extension with state
+provides a CSR field that encodes the equivalent of the XS states. The
+XS field represents a summary of all extensions' status as shown in
+<<fsxsencoding>>.
+
+[NOTE]
+====
+The XS field effectively reports the maximum status value across all
+user-extension status fields, though individual extensions can use a
+different encoding than XS.
+====
+
+The SD bit is a read-only bit that summarizes whether either the FS, VS,
+or XS fields signal the presence of some dirty state that will require
+saving extended user context to memory. If FS, XS, and VS are all
+read-only zero, then SD is also always zero.
+
+When an extension's status is set to Off, any instruction that attempts
+to read or write the corresponding state will cause an
+illegal-instruction exception. When the status is Initial, the corresponding
+state should have an initial constant value. When the status is Clean,
+the corresponding state is potentially different from the initial value,
+but matches the last value stored on a context swap. When the status is
+Dirty, the corresponding state has potentially been modified since the
+last context save.
+
+During a context save, the responsible privileged code need only write
+out the corresponding state if its status is Dirty, and can then reset
+the extension's status to Clean. During a context restore, the context
+need only be loaded from memory if the status is Clean (it should never
+be Dirty at restore). If the status is Initial, the context must be set
+to an initial constant value on context restore to avoid a security
+hole, but this can be done without accessing memory. For example, the
+floating-point registers can all be initialized to the immediate value
+0.
+
+The FS and XS fields are read by the privileged code before saving the
+context. The FS field is set directly by privileged code when resuming a
+user context, while the XS field is set indirectly by writing to the
+status register of the individual extensions. The status fields will
+also be updated during execution of instructions, regardless of
+privilege mode.
+
+Extensions to the user-mode ISA often include additional user-mode
+state, and this state can be considerably larger than the base integer
+registers. The extensions might only be used for some applications, or
+might only be needed for short phases within a single application. To
+improve performance, the user-mode extension can define additional
+instructions to allow user-mode software to return the unit to an
+initial state or even to turn off the unit.
+
+For example, a coprocessor might require to be configured before use and
+can be "unconfigured" after use. The unconfigured state would be
+represented as the Initial state for context save. If the same
+application remains running between the unconfigure and the next
+configure (which would set status to Dirty), there is no need to
+actually reinitialize the state at the unconfigure instruction, as all
+state is local to the user process, i.e., the Initial state may only
+cause the coprocessor state to be initialized to a constant value at
+context restore, not at every unconfigure.
+
+Executing a user-mode instruction to disable a unit and place it into
+the Off state will cause an illegal-instruction exception to be raised
+if any subsequent instruction tries to use the unit before it is turned
+back on. A user-mode instruction to turn a unit on must also ensure the
+unit's state is properly initialized, as the unit might have been used
+by another context meantime.
+
+Changing the setting of FS has no effect on the contents of the
+floating-point register state. In particular, setting FS=Off does not
+destroy the state, nor does setting FS=Initial clear the contents.
+Similarly, the setting of VS has no effect on the contents of the vector
+register state. Other extensions, however, might not preserve state when
+set to Off.
+
+Implementations may choose to track the dirtiness of the floating-point
+register state imprecisely by reporting the state to be dirty even when
+it has not been modified. On some implementations, some instructions
+that do not mutate the floating-point state may cause the state to
+transition from Initial or Clean to Dirty. On other implementations,
+dirtiness might not be tracked at all, in which case the valid FS states
+are Off and Dirty, and an attempt to set FS to Initial or Clean causes
+it to be set to Dirty.
+
+[NOTE]
+====
+This definition of FS does not disallow setting FS to Dirty as a result
+of errant speculation. Some platforms may choose to disallow
+speculatively writing FS to close a potential side channel.
+====
+
+If an instruction explicitly or implicitly writes a floating-point
+register or the `fcsr` but does not alter its contents, and FS=Initial
+or FS=Clean, it is implementation-defined whether FS transitions to
+Dirty.
+
+Implementations may choose to track the dirtiness of the vector register
+state in an analogous imprecise fashion, including possibly setting VS
+to Dirty when software attempts to set VS=Initial or VS=Clean. When
+VS=Initial or VS=Clean, it is implementation-defined whether an
+instruction that writes a vector register or vector CSR but does not
+alter its contents causes VS to transition to Dirty.
+
+<<fsxsstates>> shows all the possible state
+transitions for the FS, VS, or XS status bits. Note that the standard
+floating-point and vector extensions do not support user-mode
+unconfigure or disable/enable instructions.
+
+<<<
+
+[[fsxsstates]]
+.FS, VS, and XS state transitions.
+[width=75,align=center,float=center,cols="<,<,<,<,<"]
+|===
+|Current State +
+Action |Off |Initial |Clean |Dirty
+|===
+
+[width=75,align=center,float=center,cols="<,<,<,<,<"]
+|===
+5+^|At context save in privileged code
+
+|Save state? +
+Next state
+|No +
+Off
+|No +
+Initial
+|No +
+Clean
+|Yes +
+Clean
+|===
+
+[width=75,align=center,float=center,cols="<,<,<,<,<"]
+|===
+5+^|At context restore in privileged code
+
+|Restore state? +
+Next state
+|No +
+Off
+|Yes, to initial +
+Initial
+|Yes, from memory +
+Clean
+|N/A +
+N/A
+|===
+
+[width=75,align=center,float=center,cols="<,<,<,<,<"]
+|===
+5+^|Execute instruction to read state
+
+|Action? +
+Next state
+|Exception +
+Off
+|Execute +
+Initial
+|Execute +
+Clean
+|Execute +
+Dirty
+|===
+
+[width=75,align=center,float=center,cols="<,<,<,<,<"]
+|===
+5+^|Execute instruction that possibly modifies state, including configuration
+
+|Action? +
+Next state
+|Exception +
+Off
+|Execute +
+Dirty
+|Execute +
+Dirty
+|Execute +
+Dirty
+|===
+
+[width=75,align=center,float=center,cols="<,<,<,<,<"]
+|===
+5+^|Execute instruction to unconfigure unit
+
+|Action? +
+Next state
+|Exception +
+Off
+|Execute +
+Initial
+|Execute +
+Initial
+|Execute +
+Initial
+|===
+
+[width=75,align=center,float=center,cols="<,<,<,<,<"]
+|===
+5+^|Execute instruction to disable unit
+
+|Action? +
+Next state
+|Execute +
+Off
+|Execute +
+Off
+|Execute +
+Off
+|Execute +
+Off
+|===
+
+[width=75,align=center,float=center,cols="<,<,<,<,<"]
+|===
+5+^|Execute instruction to enable unit
+
+|Action? +
+Next state
+|Execute +
+Initial
+|Execute +
+Initial
+|Execute +
+Initial
+|Execute +
+Initial
+|===
+
+Standard privileged instructions to initialize, save, and restore
+extension state are provided to insulate privileged code from details of
+the added extension state by treating the state as an opaque object.
+
+[NOTE]
+====
+Many coprocessor extensions are only used in limited contexts that
+allows software to safely unconfigure or even disable units when done.
+This reduces the context-switch overhead of large stateful coprocessors.
+
+We separate out floating-point state from other extension state, as when
+a floating-point unit is present the floating-point registers are part
+of the standard calling convention, and so user-mode software cannot
+know when it is safe to disable the floating-point unit.
+====
+
+The XS field provides a summary of all added extension state, but
+additional microarchitectural bits might be maintained in the extension
+to further reduce context save and restore overhead.
+
+The SD bit is read-only and is set when either the FS, VS, or XS bits
+encode a Dirty state (i.e., `SD=(FS==0b11 OR XS==0b11 OR VS==0b11)`). This
+allows privileged code to quickly determine when no additional context
+save is required beyond the integer register set and `pc`.
+
+The floating-point unit state is always initialized, saved, and restored
+using standard instructions (F, D, and/or Q), and privileged code must
+be aware of FLEN to determine the appropriate space to reserve for each
+`f` register.
+
+Machine and Supervisor modes share a single copy of the FS, VS, and XS
+bits. Supervisor-level software normally uses the FS, VS, and XS bits
+directly to record the status with respect to the supervisor-level saved
+context. Machine-level software must be more conservative in saving and
+restoring the extension state in their corresponding version of the
+context.
+
+[NOTE]
+====
+In any reasonable use case, the number of context switches between user
+and supervisor level should far outweigh the number of context switches
+to other privilege levels. Note that coprocessors should not require
+their context to be saved and restored to service asynchronous
+interrupts, unless the interrupt results in a user-level context swap.
+====
+
+===== Previous Expected Landing Pad (ELP) State in `mstatus` Register
+
+The Zicfilp extension adds the `SPELP` and `MPELP` fields that hold the previous
+`ELP`, and are updated as specified in <<ZICFILP_FORWARD_TRAPS>>. The
+*__x__*`PELP` fields are encoded as follows:
+
+* 0 - `NO_LP_EXPECTED` - no landing pad instruction expected.
+* 1 - `LP_EXPECTED` - a landing pad instruction is expected.
+
+==== Machine Trap-Vector Base-Address (`mtvec`) Register
+
+The `mtvec` register is an MXLEN-bit *WARL* read/write register that holds
+trap vector configuration, consisting of a vector base address (BASE)
+and a vector mode (MODE).
+
+
+.Encoding of mtvec MODE field.
+include::images/bytefield/mtvec.edn[]
+
+The `mtvec` register must always be implemented, but can contain a
+read-only value. If `mtvec` is writable, the set of values the register
+may hold can vary by implementation. The value in the BASE field must
+always be aligned on a 4-byte boundary, and the MODE setting may impose
+additional alignment constraints on the value in the BASE field.
+Note that the CSR contains only bits XLEN-1 through 2 of the address BASE.
+When used as an address, the lower two bits are filled with zeroes to obtain
+an XLEN-bit address that is always aligned on a 4-byte boundary.
+
+[NOTE]
+====
+We allow for considerable flexibility in implementation of the trap
+vector base address. On the one hand, we do not wish to burden low-end
+implementations with a large number of state bits, but on the other
+hand, we wish to allow flexibility for larger systems.
+====
+
+[[mtvec-mode]]
+.Encoding of mtvec MODE field.
+[%autowidth,float="center",align="center",cols=">,^,<",options="header"]
+|===
+|Value |Name |Description
+|0 +
+1 +
+&#8805;2
+|Direct +
+Vectored +
+---
+|All traps set `pc` to BASE. +
+Asynchronous interrupts set `pc` to BASE+4&#215;cause. +
+_Reserved_
+|===
+
+The encoding of the MODE field is shown in
+<<mtvec-mode>>. When MODE=Direct, all traps into
+machine mode cause the `pc` to be set to the address in the BASE field.
+When MODE=Vectored, all synchronous exceptions into machine mode cause
+the `pc` to be set to the address in the BASE field, whereas interrupts
+cause the `pc` to be set to the address in the BASE field plus four
+times the interrupt cause number. For example, a machine-mode timer
+interrupt (see <<mcauses>>) causes the `pc`
+to be set to BASE+`0x1c`.
+
+
+An implementation may have different alignment constraints for different
+modes. In particular, MODE=Vectored may have stricter alignment
+constraints than MODE=Direct.
+
+[NOTE]
+====
+Allowing coarser alignments in Vectored mode enables vectoring to be
+implemented without a hardware adder circuit.
+
+***
+
+Reset and NMI vector locations are given in a platform specification.
+====
+
+==== Machine Trap Delegation (`medeleg` and `mideleg`) Registers
+
+By default, all traps at any privilege level are handled in machine
+mode, though a machine-mode handler can redirect traps back to the
+appropriate level with the MRET instruction
+(<<otherpriv>>). To increase performance,
+implementations can provide individual read/write bits within `medeleg`
+and `mideleg` to indicate that certain exceptions and interrupts should
+be processed directly by a lower privilege level. The machine exception
+delegation register (`medeleg`) is a 64-bit read/write register.
+The machine interrupt delegation (`mideleg`) register is an MXLEN-bit
+read/write register.
+
+In harts with S-mode, the `medeleg` and `mideleg` registers must
+exist, and setting a bit in `medeleg` or `mideleg` will delegate the
+corresponding trap, when occurring in S-mode or U-mode, to the S-mode
+trap handler. In harts without S-mode, the `medeleg` and `mideleg`
+registers should not exist.
+
+[NOTE]
+====
+In versions 1.9.1 and earlier , these registers existed but were
+hardwired to zero in M-mode only, or M/U without N harts. There is no
+reason to require they return zero in those cases, as the `misa`
+register indicates whether they exist.
+====
+
+When a trap is delegated to S-mode, the `scause` register is written
+with the trap cause; the `sepc` register is written with the virtual
+address of the instruction that took the trap; the `stval` register is
+written with an exception-specific datum; the SPP field of `mstatus` is
+written with the active privilege mode at the time of the trap; the SPIE
+field of `mstatus` is written with the value of the SIE field at the
+time of the trap; and the SIE field of `mstatus` is cleared. The
+`mcause`, `mepc`, and `mtval` registers and the MPP and MPIE fields of
+`mstatus` are not written.
+
+An implementation can choose to subset the delegatable traps, with the
+supported delegatable bits found by writing one to every bit location,
+then reading back the value in `medeleg` or `mideleg` to see which bit
+positions hold a one.
+
+An implementation shall not have any bits of `medeleg` be read-only one,
+i.e., any synchronous trap that can be delegated must support not being
+delegated. Similarly, an implementation shall not fix as read-only one
+any bits of `mideleg` corresponding to machine-level interrupts (but may
+do so for lower-level interrupts).
+
+[NOTE]
+====
+Version 1.11 and earlier prohibited having any bits of `mideleg` be
+read-only one. Platform standards may always add such restrictions.
+====
+
+Traps never transition from a more-privileged mode to a less-privileged
+mode. For example, if M-mode has delegated illegal-instruction
+exceptions to S-mode, and M-mode software later executes an illegal
+instruction, the trap is taken in M-mode, rather than being delegated to
+S-mode. By contrast, traps may be taken horizontally. Using the same
+example, if M-mode has delegated illegal-instruction exceptions to
+S-mode, and S-mode software later executes an illegal instruction, the
+trap is taken in S-mode.
+
+Delegated interrupts result in the interrupt being masked at the
+delegator privilege level. For example, if the supervisor timer
+interrupt (STI) is delegated to S-mode by setting `mideleg`[5], STIs
+will not be taken when executing in M-mode. By contrast, if `mideleg`[5]
+is clear, STIs can be taken in any mode and regardless of current mode
+will transfer control to M-mode.
+
+.Machine Exception Delegation (`medeleg`) register.
+include::images/bytefield/medeleg.edn[]
+
+`medeleg` has a bit position allocated for every synchronous exception
+shown in <<mcauses>>, with the index of the
+bit position equal to the value returned in the `mcause` register (i.e.,
+setting bit 8 allows user-mode environment calls to be delegated to a
+lower-privilege trap handler).
+
+When XLEN=32, `medelegh` is a 32-bit read/write register
+that aliases bits 63:32 of `medeleg`.
+The `medelegh` register does not exist when XLEN=64.
+
+.Machine Interrupt Delegation (`mideleg`) Register.
+include::images/bytefield/mideleg.edn[]
+
+`mideleg` holds trap delegation bits for individual interrupts, with the
+layout of bits matching those in the `mip` register (i.e., STIP
+interrupt delegation control is located in bit 5).
+
+For exceptions that cannot occur in less privileged modes, the
+corresponding `medeleg` bits should be read-only zero. In particular,
+`medeleg`[11] is read-only zero.
+
+The `medeleg`[16] is read-only zero as double trap is not delegatable.
+
+==== Machine Interrupt (`mip` and `mie`) Registers
+
+The `mip` register is an MXLEN-bit read/write register containing
+information on pending interrupts, while `mie` is the corresponding
+MXLEN-bit read/write register containing interrupt enable bits.
+Interrupt cause number _i_ (as reported in CSR `mcause`,
+<<mcause>>) corresponds with bit _i_ in both `mip` and
+`mie`. Bits 15:0 are allocated to standard interrupt causes only, while
+bits 16 and above are designated for platform use.
+
+NOTE: Interrupts designated for platform use may be designated for custom use
+at the platform's discretion.
+
+.Machine Interrupt-Pending (`mip`) register.
+include::images/bytefield/mideleg.edn[]
+
+.Machine Interrupt-Enable (`mie`) register
+include::images/bytefield/mideleg.edn[]
+
+An interrupt _i_ will trap to M-mode (causing the privilege mode to
+change to M-mode) if all of the following are true: (a) either the
+current privilege mode is M and the MIE bit in the `mstatus` register is
+set, or the current privilege mode has less privilege than M-mode;
+(b) bit _i_ is set in both `mip` and `mie`; and (c) if register
+`mideleg` exists, bit _i_ is not set in `mideleg`.
+
+These conditions for an interrupt trap to occur must be evaluated in a
+bounded amount of time from when an interrupt becomes, or ceases to be,
+pending in `mip`, and must also be evaluated immediately following the
+execution of an __x__RET instruction or an explicit write to a CSR on
+which these interrupt trap conditions expressly depend (including `mip`,
+`mie`, `mstatus`, and `mideleg`).
+
+Interrupts to M-mode take priority over any interrupts to lower
+privilege modes.
+
+Each individual bit in register `mip` may be writable or may be
+read-only. When bit _i_ in `mip` is writable, a pending interrupt _i_
+can be cleared by writing 0 to this bit. If interrupt _i_ can become
+pending but bit _i_ in `mip` is read-only, the implementation must
+provide some other mechanism for clearing the pending interrupt.
+
+A bit in `mie` must be writable if the corresponding interrupt can ever
+become pending. Bits of `mie` that are not writable must be read-only
+zero.
+
+The standard portions (bits 15:0) of the `mip` and `mie` registers are
+formatted as shown in <<mipreg-standard>> and <<miereg-standard>> respectively.
+
+[[mipreg-standard]]
+.Standard portion (bits 15:0) of `mip`.
+include::images/bytefield/mipreg-standard.edn[]
+
+[[miereg-standard]]
+.Standard portion (bits 15:0) of `mie`.
+include::images/bytefield/miereg-standard.edn[]
+
+[NOTE]
+====
+The machine-level interrupt registers handle a few root interrupt
+sources which are assigned a fixed service priority for simplicity,
+while separate external interrupt controllers can implement a more
+complex prioritization scheme over a much larger set of interrupts that
+are then multiplexed into the machine-level interrupt sources.
+
+'''
+
+The non-maskable interrupt is not made visible via the `mip` register as
+its presence is implicitly known when executing the NMI trap handler.
+====
+
+Bits `mip`.MEIP and `mie`.MEIE are the interrupt-pending and
+interrupt-enable bits for machine-level external interrupts. MEIP is
+read-only in `mip`, and is set and cleared by a platform-specific
+interrupt controller.
+
+Bits `mip`.MTIP and `mie`.MTIE are the interrupt-pending and
+interrupt-enable bits for machine timer interrupts. MTIP is read-only in
+the `mip` register, and is cleared by writing to the memory-mapped machine-mode timer
+compare register.
+
+Bits `mip`.MSIP and `mie`.MSIE are the interrupt-pending and
+interrupt-enable bits for machine-level software interrupts. MSIP is
+read-only in `mip`, and is written by accesses to memory-mapped control
+registers, which are used by remote harts to provide machine-level
+interprocessor interrupts. A hart can write its own MSIP bit using the
+same memory-mapped control register. If a system has only one hart, or
+if a platform standard supports the delivery of machine-level
+interprocessor interrupts through external interrupts (MEI) instead,
+then `mip`.MSIP and `mie`.MSIE may both be read-only zeros.
+
+If supervisor mode is not implemented, bits SEIP, STIP, and SSIP of
+`mip` and SEIE, STIE, and SSIE of `mie` are read-only zeros.
+
+If supervisor mode is implemented, bits `mip`.SEIP and `mie`.SEIE are
+the interrupt-pending and interrupt-enable bits for supervisor-level
+external interrupts. SEIP is writable in `mip`, and may be written by
+M-mode software to indicate to S-mode that an external interrupt is
+pending. Additionally, the platform-level interrupt controller may
+generate supervisor-level external interrupts. Supervisor-level external
+interrupts are made pending based on the logical-OR of the
+software-writable SEIP bit and the signal from the external interrupt
+controller. When `mip` is read with a CSR instruction, the value of the
+SEIP bit returned in the `rd` destination register is the logical-OR of
+the software-writable bit and the interrupt signal from the interrupt
+controller, but the signal from the interrupt controller is not used to
+calculate the value written to SEIP. Only the software-writable SEIP bit
+participates in the read-modify-write sequence of a CSRRS or CSRRC
+instruction.
+
+[NOTE]
+====
+For example, if we name the software-writable SEIP bit `B` and the
+signal from the external interrupt controller `E`, then if
+`csrrs t0, mip, t1` is executed, `t0[9]` is written with `B || E`, then
+`B` is written with `B || t1[9]`. If `csrrw t0, mip, t1` is executed,
+then `t0[9]` is written with `B || E`, and `B` is simply written with
+`t1[9]`. In neither case does `B` depend upon `E`.
+
+The SEIP field behavior is designed to allow a higher privilege layer to
+mimic external interrupts cleanly, without losing any real external
+interrupts. The behavior of the CSR instructions is slightly modified
+from regular CSR accesses as a result.
+====
+
+If supervisor mode is implemented, bits `mip`.STIP and `mie`.STIE are
+the interrupt-pending and interrupt-enable bits for supervisor-level
+timer interrupts. STIP is writable in `mip`, and may be written by
+M-mode software to deliver timer interrupts to S-mode.
+
+If supervisor mode is implemented, bits `mip`.SSIP and `mie`.SSIE are
+the interrupt-pending and interrupt-enable bits for supervisor-level
+software interrupts. SSIP is writable in `mip` and may also be set to 1
+by a platform-specific interrupt controller.
+
+If the Sscofpmf extension is implemented, bits `mip`.LCOFIP and `mie`.LCOFIE
+are the interrupt-pending and interrupt-enable bits for local-counter-overflow
+interrupts.
+LCOFIP is read-write in `mip` and reflects the occurrence of a local
+counter-overflow overflow interrupt request resulting from any of the
+`mhpmevent__n__`.OF bits being set.
+If the Sscofpmf extension is not implemented, `mip`.LCOFIP and `mie`.LCOFIE are
+read-only zeros.
+
+Multiple simultaneous interrupts destined for M-mode are handled in the
+following decreasing priority order: MEI, MSI, MTI, SEI, SSI, STI, LCOFI.
+
+[NOTE]
+====
+The machine-level interrupt fixed-priority ordering rules were developed
+with the following rationale.
+
+Interrupts for higher privilege modes must be serviced before interrupts
+for lower privilege modes to support preemption.
+
+The platform-specific machine-level interrupt sources in bits 16 and
+above have platform-specific priority, but are typically chosen to have
+the highest service priority to support very fast local vectored
+interrupts.
+
+External interrupts are handled before internal (timer/software)
+interrupts as external interrupts are usually generated by devices that
+might require low interrupt service times.
+
+Software interrupts are handled before internal timer interrupts,
+because internal timer interrupts are usually intended for time slicing,
+where time precision is less important, whereas software interrupts are
+used for inter-processor messaging. Software interrupts can be avoided
+when high-precision timing is required, or high-precision timer
+interrupts can be routed via a different interrupt path. Software
+interrupts are located in the lowest four bits of `mip` as these are
+often written by software, and this position allows the use of a single
+CSR instruction with a five-bit immediate.
+====
+
+Restricted views of the `mip` and `mie` registers appear as the `sip`
+and `sie` registers for supervisor level. If an interrupt is delegated
+to S-mode by setting a bit in the `mideleg` register, it becomes visible
+in the `sip` register and is maskable using the `sie` register.
+Otherwise, the corresponding bits in `sip` and `sie` are read-only zero.
+
+==== Hardware Performance Monitor
+
+M-mode includes a basic hardware performance-monitoring facility. The
+`mcycle` CSR counts the number of clock cycles executed by the processor
+core on which the hart is running. The `minstret` CSR counts the number
+of instructions the hart has retired. The `mcycle` and `minstret`
+registers have 64-bit precision on all RV32 and RV64 harts.
+
+The counter registers have an arbitrary value after the hart is reset,
+and can be written with a given value. Any CSR write takes effect after
+the writing instruction has otherwise completed. The `mcycle` CSR may be
+shared between harts on the same core, in which case writes to `mcycle`
+will be visible to those harts. The platform should provide a mechanism
+to indicate which harts share an `mcycle` CSR.
+
+The hardware performance monitor includes 29 additional 64-bit event
+counters, `mhpmcounter3`-`mhpmcounter31`. The event selector CSRs,
+`mhpmevent3`-`mhpmevent31`, are 64-bit *WARL* registers that control which
+event causes the corresponding counter to increment. The meaning of
+these events is defined by the platform, but event 0 is defined to mean
+"no event." All counters should be implemented, but a legal
+implementation is to make both the counter and its corresponding event
+selector be read-only 0.
+
+.Hardware performance monitor counters.
+include::images/bytefield/hpmevents.edn[]
+
+The `mhpmcounters` are *WARL* registers that support up to 64 bits of
+precision on RV32 and RV64.
+
+When XLEN=32, reads of the `mcycle`, `minstret`, `mhpmcounter__n__`, and `mhpmevent__n__`
+CSRs return bits 31-0 of the corresponding register, and writes change
+only bits 31-0; reads of the `mcycleh`, `minstreth`, `mhpmcounter__n__h`, and `mhpmevent__n__h`
+CSRs return bits 63-32 of the corresponding register, and writes change
+only bits 63-32.
+The `mhpmevent__n__h` CSRs are provided only if the Sscofpmf extension is implemented.
+
+[[mcounteren]]
+==== Machine Counter-Enable (`mcounteren`) Register
+
+The counter-enable `mcounteren` register is a 32-bit register that
+controls the availability of the hardware performance-monitoring
+counters to the next-lower privileged mode.
+
+.Counter-enable (`mcounteren`) register.
+include::images/bytefield/counteren.edn[]
+
+The settings in this register only control accessibility. The act of
+reading or writing this register does not affect the underlying
+counters, which continue to increment even when not accessible.
+
+When the CY, TM, IR, or HPM__n__ bit in the `mcounteren` register is
+clear, attempts to read the `cycle`, `time`, `instret`, or
+`hpmcountern` register while executing in S-mode or U-mode will cause an
+illegal-instruction exception. When one of these bits is set, access to
+the corresponding register is permitted in the next implemented
+privilege mode (S-mode if implemented, otherwise U-mode).
+
+[NOTE]
+====
+The counter-enable bits support two common use cases with minimal
+hardware. For harts that do not need high-performance timers and
+counters, machine-mode software can trap accesses and implement all
+features in software. For harts that need high-performance timers and
+counters but are not concerned with obfuscating the underlying hardware
+counters, the counters can be directly exposed to lower privilege modes.
+====
+
+The `cycle`, `instret`, and `hpmcountern` CSRs are read-only shadows of
+`mcycle`, `minstret`, and `mhpmcounter n`, respectively. The `time` CSR
+is a read-only shadow of the memory-mapped `mtime` register.
+Analogously, when XLEN=32, the `cycleh`, `instreth` and `hpmcounternh` CSRs
+are read-only shadows of `mcycleh`, `minstreth` and `mhpmcounternh`,
+respectively. When XLEN=32, the `timeh` CSR is a read-only shadow of the
+upper 32 bits of the memory-mapped `mtime` register, while `time`
+shadows only the lower 32 bits of `mtime`.
+
+[NOTE]
+====
+Implementations can convert reads of the `time` and `timeh` CSRs into
+loads to the memory-mapped `mtime` register, or emulate this
+functionality on behalf of less-privileged modes in M-mode software.
+====
+
+In harts with U-mode, the `mcounteren` must be implemented, but all
+fields are *WARL* and may be read-only zero, indicating reads to the
+corresponding counter will cause an illegal-instruction exception when
+executing in a less-privileged mode. In harts without U-mode, the
+`mcounteren` register should not exist.
+
+==== Machine Counter-Inhibit (`mcountinhibit`) Register
+
+.Counter-inhibit `mcountinhibit` register
+include::images/bytefield/counterinh.edn[]
+
+The counter-inhibit register `mcountinhibit` is a 32-bit *WARL* register that
+controls which of the hardware performance-monitoring counters
+increment. The settings in this register only control whether the
+counters increment; their accessibility is not affected by the setting
+of this register.
+
+When the CY, IR, or HPM__n__ bit in the `mcountinhibit` register is clear,
+the `mcycle`, `minstret`, or `mhpmcountern` register increments as usual.
+When the CY, IR, or HPM__n__ bit is set, the corresponding counter does
+not increment.
+
+The `mcycle` CSR may be shared between harts on the same core, in which
+case the `mcountinhibit.CY` field is also shared between those harts,
+and so writes to `mcountinhibit.CY` will be visible to those harts.
+
+If the `mcountinhibit` register is not implemented, the implementation
+behaves as though the register were set to zero.
+
+[NOTE]
+====
+When the `mcycle` and `minstret` counters are not needed, it is desirable
+to conditionally inhibit them to reduce energy consumption. Providing a
+single CSR to inhibit all counters also allows the counters to be
+atomically sampled.
+
+Because the `mtime` counter can be shared between multiple cores, it
+cannot be inhibited with the `mcountinhibit` mechanism.
+====
+
+==== Machine Scratch (`mscratch`) Register
+
+The `mscratch` register is an MXLEN-bit read/write register dedicated
+for use by machine mode. Typically, it is used to hold a pointer to a
+machine-mode hart-local context space and swapped with a user register
+upon entry to an M-mode trap handler.
+
+.Machine-mode scratch register.
+include::images/bytefield/mscratch.edn[]
+
+[NOTE]
+====
+The MIPS ISA allocated two user registers (`k0`/`k1`) for use by the
+operating system. Although the MIPS scheme provides a fast and simple
+implementation, it also reduces available user registers, and does not
+scale to further privilege levels, or nested traps. It can also require
+both registers are cleared before returning to user level to avoid a
+potential security hole and to provide deterministic debugging behavior.
+
+The RISC-V user ISA was designed to support many possible privileged
+system environments and so we did not want to infect the user-level ISA
+with any OS-dependent features. The RISC-V CSR swap instructions can
+quickly save/restore values to the `mscratch` register. Unlike the MIPS
+design, the OS can rely on holding a value in the `mscratch` register
+while the user context is running.
+====
+
+==== Machine Exception Program Counter (`mepc`) Register
+
+`mepc` is an MXLEN-bit read/write register formatted as shown in
+<<mepcreg>>. The low bit of `mepc` (`mepc[0]`) is
+always zero. On implementations that support only IALIGN=32, the two low
+bits (`mepc[1:0]`) are always zero.
+
+If an implementation allows IALIGN to be either 16 or 32 (by changing
+CSR `misa`, for example), then, whenever IALIGN=32, bit `mepc[1]` is
+masked on reads so that it appears to be 0. This masking occurs also for
+the implicit read by the MRET instruction. Though masked, `mepc[1]`
+remains writable when IALIGN=32.
+
+`mepc` is a *WARL* register that must be able to hold all valid virtual
+addresses. It need not be capable of holding all possible invalid
+addresses. Prior to writing `mepc`, implementations may convert an
+invalid address into some other invalid address that `mepc` is capable
+of holding.
+
+[NOTE]
+====
+When address translation is not in effect, virtual addresses and
+physical addresses are equal. Hence, the set of addresses `mepc` must be
+able to represent includes the set of physical addresses that can be
+used as a valid `pc` or effective address.
+====
+
+When a trap is taken into M-mode, `mepc` is written with the virtual
+address of the instruction that was interrupted or that encountered the
+exception. Otherwise, `mepc` is never written by the implementation,
+though it may be explicitly written by software.
+
+[[mepcreg]]
+.Machine exception program counter register.
+include::images/bytefield/mepcreg.edn[]
+
+[[mcause]]
+==== Machine Cause (`mcause`) Register
+
+The `mcause` register is an MXLEN-bit read-write register formatted as
+shown in <<mcausereg>>. When a trap is taken into
+M-mode, `mcause` is written with a code indicating the event that
+caused the trap. Otherwise, `mcause` is never written by the
+implementation, though it may be explicitly written by software.
+
+The Interrupt bit in the `mcause` register is set if the trap was caused
+by an interrupt. The Exception Code field contains a code identifying
+the last exception or interrupt. <<mcauses>> lists
+the possible machine-level exception codes. The Exception Code is a
+*WLRL* field, so is only guaranteed to hold supported exception codes.
+
+[[mcausereg]]
+.Machine Cause (`mcause`) register.
+include::images/bytefield/mcausereg.edn[]
+
+Note that load and load-reserved instructions generate load exceptions,
+whereas store, store-conditional, and AMO instructions generate
+store/AMO exceptions.
+
+[NOTE]
+====
+Interrupts can be separated from other traps with a single branch on the
+sign of the `mcause` register value. A shift left can remove the
+interrupt bit and scale the exception codes to index into a trap vector
+table.
+
+***
+
+We do not distinguish privileged instruction exceptions from
+illegal-instruction exceptions. This simplifies the architecture and also hides
+details of which higher-privilege instructions are supported by an
+implementation. The privilege level servicing the trap can implement a
+policy on whether these need to be distinguished, and if so, whether a
+given opcode should be treated as illegal or privileged.
+====
+If an instruction may raise multiple synchronous exceptions, the
+decreasing priority order of
+<<exception-priority>> indicates which
+exception is taken and reported in `mcause`. The priority of any custom
+synchronous exceptions is implementation-defined.
+
+<<<
+
+[[mcauses]]
+.Machine cause (`mcause`) register values after trap.
+[%autowidth,float="center",align="center",cols=">,>,<",options="header",]
+|===
+|Interrupt |Exception Code |Description
+|1 +
+1 +
+1 +
+1
+|0 +
+1 +
+2 +
+3
+|_Reserved_ +
+Supervisor software interrupt +
+_Reserved_ +
+Machine software interrupt
+
+|1 +
+1 +
+1 +
+1
+|4 +
+5 +
+6 +
+7
+|_Reserved_ +
+Supervisor timer interrupt +
+_Reserved_ +
+Machine timer interrupt
+|1 +
+1 +
+1 +
+1
+|8 +
+9 +
+10 +
+11
+|_Reserved_ +
+Supervisor external interrupt +
+_Reserved_ +
+Machine external interrupt
+|1 +
+1 +
+1 +
+1
+|12 +
+13 +
+14-15 +
+&#8805;16
+|_Reserved_ +
+Counter-overflow interrupt +
+_Reserved_ +
+_Designated for platform use_
+|0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0
+|0 +
+1 +
+2 +
+3 +
+4 +
+5 +
+6 +
+7 +
+8 +
+9 +
+10 +
+11 +
+12 +
+13 +
+14 +
+15 +
+16 +
+17 +
+18 +
+19 +
+20-23 +
+24-31 +
+32-47 +
+48-63 +
+&#8805;64
+|Instruction address misaligned +
+Instruction access fault +
+Illegal instruction +
+Breakpoint +
+Load address misaligned +
+Load access fault +
+Store/AMO address misaligned +
+Store/AMO access fault +
+Environment call from U-mode +
+Environment call from S-mode +
+_Reserved_ +
+Environment call from M-mode +
+Instruction page fault +
+Load page fault +
+_Reserved_ +
+Store/AMO page fault +
+Double trap +
+_Reserved_ +
+Software check +
+Hardware error +
+_Reserved_ +
+_Designated for custom use_ +
+_Reserved_ +
+_Designated for custom use_ +
+_Reserved_
+|===
+
+<<<
+
+[[exception-priority]]
+.Synchronous exception priority in decreasing priority order.
+[%autowidth,float="center",align="center",cols="<,>,<",options="header",]
+|===
+|Priority |Exc.Code |Description
+|_Highest_ |3 |Instruction address breakpoint
+| .>|12, 1 .<|During instruction address translation: +
+First encountered page fault or access fault
+| .>|1 .<|With physical address for instruction: +
+Instruction access fault
+
+| .>|2 +
+0 +
+8,9,11 +
+3 +
+3 .<|Illegal instruction +
+Instruction address misaligned +
+Environment call +
+Environment break +
+Load/store/AMO address breakpoint
+
+| .>|4,6 .<|Optionally: +
+Load/store/AMO address misaligned
+| .>|13, 15, 5, 7 .<|During address translation for an explicit memory access: +
+First encountered page fault or access fault
+| .>|5,7 .<|With physical address for an explicit memory access: +
+Load/store/AMO access fault
+.>|_Lowest_ .>|4,6 .<|If not higher priority: +
+Load/store/AMO address misaligned
+|===
+
+When a virtual address is translated into a physical address, the
+address translation algorithm determines what specific exception may be
+raised.
+
+Load/store/AMO address-misaligned exceptions may have either higher or
+lower priority than load/store/AMO page-fault and access-fault
+exceptions.
+
+[NOTE]
+====
+The relative priority of load/store/AMO address-misaligned and
+page-fault exceptions is implementation-defined to flexibly cater to two
+design points. Implementations that never support misaligned accesses
+can unconditionally raise the misaligned-address exception without
+performing address translation or protection checks. Implementations
+that support misaligned accesses only to some physical addresses must
+translate and check the address before determining whether the
+misaligned access may proceed, in which case raising the page-fault
+exception or access is more appropriate.
+
+***
+
+Instruction address breakpoints have the same cause value as, but
+different priority than, data address breakpoints (a.k.a. watchpoints)
+and environment break exceptions (which are raised by the EBREAK
+instruction).
+
+***
+
+Instruction address-misaligned exceptions are raised by control-flow
+instructions with misaligned targets, rather than by the act of fetching
+an instruction. Therefore, these exceptions have lower priority than
+other instruction address exceptions.
+====
+
+[NOTE]
+====
+A software-check exception is a synchronous exception that is triggered when
+there are violations of checks and assertions defined by ISA extensions that
+aim to safeguard the integrity of software assets, including e.g. control-flow
+and memory-access constraints. When this exception is raised, the `__x__tval`
+register is set either to 0 or to an informative value defined by the extension
+that stipulated the exception be raised. The priority of this exception,
+relative to other synchronous exceptions, depends on the cause of this exception
+and is defined by the extension that stipulated the exception be raised.
+
+A hardware-error exception is a synchronous exception triggered when corrupted or
+uncorrectable data is accessed explicitly or implicitly by an instruction. In
+this context, "data" encompasses all types of information used within a RISC-V
+hart. Upon a hardware-error exception, the `__x__epc` register is set to the
+address of the instruction that attempted to access corrupted data, while the
+`__x__tval` register is set either to 0 or to the virtual address of an
+instruction fetch, load, or store that attempted to access corrupted data. The
+priority of hardware-error exception is implementation-defined, but any given
+occurrence is generally expected to be recognized at the point in the overall
+priority order at which the hardware error is discovered.
+====
+
+==== Machine Trap Value (`mtval`) Register
+
+The `mtval` register is an MXLEN-bit read-write register formatted as
+shown in <<mtvalreg>>. When a trap is taken into
+M-mode, `mtval` is either set to zero or written with exception-specific
+information to assist software in handling the trap. Otherwise, `mtval`
+is never written by the implementation, though it may be explicitly
+written by software. The hardware platform will specify which exceptions
+must set `mtval` informatively, which may unconditionally set it to
+zero, and which may exhibit either behavior, depending on the underlying event
+that caused the exception.
+If the hardware platform specifies that no exceptions set `mtval`
+to a nonzero value, then `mtval` is read-only zero.
+
+If `mtval` is written with a nonzero value when a breakpoint,
+address-misaligned, access-fault, page-fault, or hardware-error exception
+occurs on an
+instruction fetch, load, or store, then `mtval` will contain the
+faulting virtual address.
+
+On a breakpoint exception raised by an EBREAK or C.EBREAK instruction, `mtval`
+is written with either zero or the virtual address of the instruction.
+
+NOTE: For breakpoint exceptions raised by [C.]EBREAK, the virtual address of
+the instruction is already recorded in `mepc`.
+Recording the same address in `mtval` is redundant; the option is provided for
+backwards compatibility.
+
+When page-based virtual memory is enabled, `mtval` is written with the
+faulting virtual address, even for physical-memory access-fault
+exceptions. This design reduces datapath cost for most implementations,
+particularly those with hardware page-table walkers.
+
+[[mtvalreg]]
+.Machine Trap Value (`mtval`) register.
+include::images/bytefield/mtvalreg.edn[]
+
+
+If `mtval` is written with a nonzero value when a misaligned load or
+store causes an access-fault, page-fault, or hardware-error exception,
+then `mtval` will
+contain the virtual address of the portion of the access that caused the
+fault.
+
+If `mtval` is written with a nonzero value when an instruction
+access-fault, page-fault, or hardware-error exception occurs on a hart with
+variable-length instructions, then `mtval` will contain the virtual
+address of the portion of the instruction that caused the fault, while
+`mepc` will point to the beginning of the instruction.
+
+The `mtval` register can optionally also be used to return the faulting
+instruction bits on an illegal-instruction exception (`mepc` points to
+the faulting instruction in memory). If `mtval` is written with a
+nonzero value when an illegal-instruction exception occurs, then `mtval`
+will contain the shortest of:
+
+* the actual faulting instruction
+
+* the first ILEN bits of the faulting instruction
+
+* the first MXLEN bits of the faulting instruction
+
+The value loaded into `mtval` on an illegal-instruction exception is
+right-justified and all unused upper bits are cleared to zero.
+
+[NOTE]
+====
+Capturing the faulting instruction in `mtval` reduces the overhead of
+instruction emulation, potentially avoiding several partial instruction
+loads if the instruction is misaligned, and likely data cache misses or
+slow uncached accesses when loads are used to fetch the instruction into
+a data register. There is also a problem of atomicity if another agent
+is manipulating the instruction memory, as might occur in a dynamic
+translation system.
+
+A requirement is that the entire instruction (or at least the first
+MXLEN bits) are fetched into `mtval` before taking the trap. This should
+not constrain implementations, which would typically fetch the entire
+instruction before attempting to decode the instruction, and avoids
+complicating software handlers.
+
+A value of zero in `mtval` signifies either that the feature is not
+supported, or an illegal zero instruction was fetched. A load from the
+instruction memory pointed to by `mepc` can be used to distinguish these
+two cases (or alternatively, the system configuration information can be
+interrogated to install the appropriate trap handling before runtime).
+====
+
+On a trap caused by a software-check exception, the `mtval` register holds
+the cause for the exception. The following encodings are defined:
+
+* 0 - No information provided.
+* 2 - Landing Pad Fault. Defined by the Zicfilp extension (<<priv-forward>>).
+* 3 - Shadow Stack Fault. Defined by the Zicfiss extension (<<priv-backward>>).
+
+For other traps, `mtval` is set to zero, but a future standard may
+redefine `mtval`’s setting for other traps.
+
+If `mtval` is not read-only zero, it is a *WARL* register that must be able to
+hold all valid virtual addresses and the value zero. It need not be
+capable of holding all possible invalid addresses. Prior to writing
+`mtval`, implementations may convert an invalid address into some other
+invalid address that `mtval` is capable of holding. If the feature to
+return the faulting instruction bits is implemented, `mtval` must also
+be able to hold all values less than 2^__N__^, where
+_N_ is the smaller of MXLEN and ILEN.
+
+==== Machine Configuration Pointer (`mconfigptr`) Register
+
+The `mconfigptr` register is an MXLEN-bit read-only CSR, formatted as shown in
+<<mconfigptrreg>>, that holds the physical
+address of a configuration data structure. Software can traverse this
+data structure to discover information about the harts, the platform,
+and their configuration.
+
+[[mconfigptrreg]]
+.Machine Configuration Pointer (`mconfigptr`) register.
+include::images/bytefield/mconfigptrreg.edn[]
+
+
+The pointer alignment in bits must be no smaller than MXLEN:
+i.e., if MXLEN is
+8{times}__n__, then `mconfigptr`[log~2n~-1:0]
+must be zero.
+
+The `mconfigptr` register must be implemented, but it may be zero to indicate the
+configuration data structure does not exist or that an alternative
+mechanism must be used to locate it.
+
+[NOTE]
+====
+The format and schema of the configuration data structure have yet to be
+standardized.
+
+***
+
+While the `mconfigptr` register will simply be hardwired in some implementations,
+other implementations may provide a means to configure the value
+returned on CSR reads. For example, `mconfigptr` might present the value
+of a memory-mapped register that is programmed by the platform or by
+M-mode software towards the beginning of the boot process.
+====
+
+[[sec:menvcfg]]
+==== Machine Environment Configuration (`menvcfg`) Register
+
+The `menvcfg` CSR is a 64-bit read/write register, formatted
+as shown in <<menvcfgreg>>, that controls
+certain characteristics of the execution environment for modes less
+privileged than M.
+
+[[menvcfgreg]]
+.Machine environment configuration (`menvcfg`) register.
+include::images/wavedrom/menvcfgreg.edn[]
+
+
+If bit FIOM (Fence of I/O implies Memory) is set to one in `menvcfg`,
+FENCE instructions executed in modes less privileged than M are modified
+so the requirement to order accesses to device I/O implies also the
+requirement to order main memory accesses. <<menvcfg-FIOM>>
+details the modified interpretation of FENCE instruction bits PI, PO,
+SI, and SO for modes less privileged than M when FIOM=1.
+
+Similarly, for modes less privileged than M when FIOM=1, if an atomic
+instruction that accesses a region ordered as device I/O has its _aq_
+and/or _rl_ bit set, then that instruction is ordered as though it
+accesses both device I/O and memory.
+
+If S-mode is not supported, or if `satp`.MODE is read-only zero (always
+Bare), the implementation may make FIOM read-only zero.
+
+[[menvcfg-FIOM]]
+.Modified interpretation of FENCE predecessor and successor sets for modes less privileged than M when FIOM=1.
+[%autowidth,float="center",align="center",cols="^,<",options="header"]
+|===
+|Instruction bit |Meaning when set
+|PI +
+PO
+|Predecessor device input and memory reads (PR implied) +
+Predecessor device output and memory writes (PW implied)
+|SI +
+SO
+|Successor device input and memory reads (SR implied) +
+Successor device output and memory writes (SW implied)
+|===
+
+[NOTE]
+====
+Bit FIOM is needed in `menvcfg` so M-mode can emulate the hypervisor
+extension of <<hypervisor>>, which has an
+equivalent FIOM bit in the hypervisor CSR `henvcfg`.
+====
+
+The PBMTE bit controls whether the Svpbmt extension is available for use
+in S-mode and G-stage address translation (i.e., for page tables pointed
+to by `satp` or `hgatp`). When PBMTE=1, Svpbmt is available for S-mode
+and G-stage address translation. When PBMTE=0, the implementation
+behaves as though Svpbmt were not implemented. If Svpbmt is not
+implemented, PBMTE is read-only zero. Furthermore, for implementations
+with the hypervisor extension, `henvcfg`.PBMTE is read-only zero if
+`menvcfg`.PBMTE is zero.
+
+After changing `menvcfg`.PBMTE, executing an SFENCE.VMA instruction with
+_rs1_=`x0` and _rs2_=`x0` suffices to synchronize address-translation caches
+with respect to the altered interpretation of page-table entries' PBMT fields.
+See <<hyp-mm-fences>> for additional synchronization requirements when the
+hypervisor extension is implemented.
+
+If the Svadu extension is implemented, the ADUE bit controls whether hardware
+updating of PTE A/D bits is enabled for S-mode and G-stage address
+translations.
+When ADUE=1, hardware updating of PTE A/D bits is enabled during S-mode
+address translation, and the implementation behaves as though the Svade
+extension were not implemented for S-mode address translation.
+When the hypervisor extension is implemented, if ADUE=1, hardware updating of
+PTE A/D bits is enabled during G-stage address translation, and the
+implementation behaves as though the Svade extension were not implemented for
+G-stage address translation.
+When ADUE=0, the implementation behaves as though Svade were implemented for
+S-mode and G-stage address translation.
+If Svadu is not implemented, ADUE is read-only zero.
+Furthermore, for implementations with the hypervisor extension, `henvcfg`.ADUE
+is read-only zero if `menvcfg`.ADUE is zero.
+
+After changing `menvcfg`.ADUE, executing an SFENCE.VMA instruction with
+_rs1_=`x0` and _rs2_=`x0` suffices to synchronize address-translation caches
+with respect to the altered interpretation of page-table entries' A/D bits.
+See <<hyp-mm-fences>> for additional synchronization requirements when the
+hypervisor extension is implemented.
+
+NOTE: The Svade extension requires page-fault exceptions be raised when PTE
+A/D bits need be set, hence Svade is implemented when ADUE=0.
+
+If the Smcdeleg extension is implemented, the CDE (Counter Delegation Enable) bit controls whether Zicntr and Zihpm counters can be delegated to S-mode. When CDE=1, the Smcdeleg extension is enabled, see <<smcdeleg>>. When CDE=0, the Smcdeleg and Ssccfg extensions appear to be not implemented. If Smcdeleg is not implemented, CDE is read-only zero.
+
+The definition of the STCE field is furnished by the Sstc extension.
+
+The definition of the CBZE field is furnished by the Zicboz extension.
+
+The definitions of the CBCFE and CBIE fields are furnished by the Zicbom extension.
+
+The definition of the PMM field is furnished by the Smnpm extension.
+
+The Zicfilp extension adds the `LPE` field in `menvcfg`. When the `LPE` field is
+set to 1 and S-mode is implemented, the Zicfilp extension is enabled in S-mode.
+If `LPE` field is set to 1 and S-mode is not implemented, the Zicfilp extension
+is enabled in U-mode. When the `LPE` field is 0, the Zicfilp extension is not
+enabled in S-mode, and the following rules apply to S-mode. If the `LPE` field
+is 0 and S-mode is not implemented, then the same rules apply to U-mode.
+
+* The hart does not update the `ELP` state; it remains as `NO_LP_EXPECTED`.
+* The `LPAD` instruction operates as a no-op.
+
+The Zicfiss extension adds the `SSE` field to `menvcfg`. When the `SSE` field is
+set to 1 the Zicfiss extension is activated in S-mode. When `SSE` field is 0,
+the following rules apply to privilege modes that are less than M:
+
+* 32-bit Zicfiss instructions will revert to their behavior as defined by Zimop.
+* 16-bit Zicfiss instructions will revert to their behavior as defined by Zcmop.
+* The `pte.xwr=010b` encoding in VS/S-stage page tables becomes reserved.
+* `SSAMOSWAP.W/D` raises an illegal-instruction exception.
+
+When `menvcfg.SSE` is 0, the `henvcfg.SSE` and `senvcfg.SSE` fields are
+read-only zero.
+
+The Ssdbltrp extension adds the double-trap-enable (`DTE`) field in `menvcfg`.
+When `menvcfg.DTE` is zero, the implementation behaves as though Ssdbltrp is not
+implemented. When Ssdbltrp is not implemented `sstatus.SDT`, `vsstatus.SDT`, and
+`henvcfg.DTE` bits are read-only zero.
+
+When XLEN=32, `menvcfgh` is a 32-bit read/write register
+that aliases bits 63:32 of `menvcfg`.
+The `menvcfgh` register does not exist when XLEN=64.
+
+If U-mode is not supported, then registers `menvcfg` and `menvcfgh` do
+not exist.
+
+==== Machine Security Configuration (`mseccfg`) Register
+
+`mseccfg` is an optional 64-bit read/write register, formatted as
+shown in <<mseccfg>>, that controls security features.
+
+[[mseccfg]]
+.Machine security configuration (`mseccfg`) register.
+include::images/wavedrom/mseccfg.edn[]
+
+The definitions of the SSEED and USEED fields are furnished by the
+entropy-source extension, Zkr.
+
+The definitions of the RLB, MMWP, and MML fields are furnished by the
+PMP-enhancement extension, Smepmp.
+
+The definition of the PMM field is furnished by the Smmpm extension.
+
+The Zicfilp extension adds the `MLPE` field in `mseccfg`. When `MLPE` field is
+1, Zicfilp extension is enabled in M-mode. When the `MLPE` field is 0, the
+Zicfilp extension is not enabled in M-mode and the following rules apply to
+M-mode.
+
+* The hart does not update the `ELP` state; it remains as `NO_LP_EXPECTED`.
+* The `LPAD` instruction operates as a no-op.
+
+When XLEN=32 only, `mseccfgh` is a 32-bit read/write register that
+aliases bits 63:32 of `mseccfg`.
+Register `mseccfgh` does not exist when XLEN=64.
+
+=== Machine-Level Memory-Mapped Registers
+
+==== Machine Timer (`mtime` and `mtimecmp`) Registers
+
+Platforms provide a real-time counter, exposed as a memory-mapped
+machine-mode read-write register, `mtime`. `mtime` must increment at
+constant frequency, and the platform must provide a mechanism for
+determining the period of an `mtime` tick. The `mtime` register will
+wrap around if the count overflows.
+
+The `mtime` register has a 64-bit precision on all RV32 and RV64
+systems. Platforms provide a 64-bit memory-mapped machine-mode timer
+compare register (`mtimecmp`). A machine timer interrupt becomes pending
+whenever `mtime` contains a value greater than or equal to `mtimecmp`,
+treating the values as unsigned integers. The interrupt remains posted
+until `mtimecmp` becomes greater than `mtime` (typically as a result of
+writing `mtimecmp`). The interrupt will only be taken if interrupts are
+enabled and the MTIE bit is set in the `mie` register.
+
+.Machine time register (memory-mapped control register).
+include::images/bytefield/mtime.edn[]
+
+.Machine time compare register (memory-mapped control register).
+include::images/bytefield/mtimecmp.edn[]
+
+[NOTE]
+====
+The timer facility is defined to use wall-clock time rather than a cycle
+counter to support modern processors that run with a highly variable
+clock frequency to save energy through dynamic voltage and frequency
+scaling.
+
+Accurate real-time clocks (RTCs) are relatively expensive to provide
+(requiring a crystal or MEMS oscillator) and have to run even when the
+rest of system is powered down, and so there is usually only one in a
+system located in a different frequency/voltage domain from the
+processors. Hence, the RTC must be shared by all the harts in a system
+and accesses to the RTC will potentially incur the penalty of a
+voltage-level-shifter and clock-domain crossing. It is thus more natural
+to expose `mtime` as a memory-mapped register than as a CSR.
+
+Lower privilege levels do not have their own `timecmp` registers.
+Instead, machine-mode software can implement any number of virtual
+timers on a hart by multiplexing the next timer interrupt into the
+`mtimecmp` register.
+
+Simple fixed-frequency systems can use a single clock for both cycle
+counting and wall-clock time.
+====
+
+If the result of the comparison between `mtime` and `mtimecmp` changes, it is
+guaranteed to be reflected in MTIP eventually, but not necessarily
+immediately.
+
+[NOTE]
+====
+A spurious timer interrupt might occur if an interrupt handler
+increments `mtimecmp` then immediately returns, because MTIP might not
+yet have fallen in the interim. All software should be written to assume
+this event is possible, but most software should assume this event is
+extremely unlikely. It is almost always more performant to incur an
+occasional spurious timer interrupt than to poll MTIP until it falls.
+====
+
+In RV32, memory-mapped writes to `mtimecmp` modify only one 32-bit part
+of the register. The following code sequence sets a 64-bit `mtimecmp`
+value without spuriously generating a timer interrupt due to the
+intermediate value of the comparand:
+
+For RV64, naturally aligned 64-bit memory accesses to the `mtime` and
+`mtimecmp` registers are additionally supported and are atomic.
+
+.Sample code for setting the 64-bit time comparand in RV32 assuming a little-endian memory system and that the registers live in a strongly ordered I/O region. Storing -1 to the low-order bits of `mtimecmp` prevents `mtimecmp` from temporarily becoming smaller than the lesser of the old and new values.
+....
+ # New comparand is in a1:a0.
+ li t0, -1
+ la t1, mtimecmp
+ sw t0, 0(t1) # No smaller than old value.
+ sw a1, 4(t1) # No smaller than new value.
+ sw a0, 0(t1) # New value.
+....
+
+
+The `time` CSR is a read-only shadow of the memory-mapped `mtime` register.
+When XLEN=32, the `timeh` CSR is a read-only shadow of the upper 32 bits of the
+memory-mapped `mtime` register, while `time` shadows only the lower 32 bits of
+`mtime`.
+When `mtime` changes, it is guaranteed to be reflected in `time` and `timeh`
+eventually, but not necessarily immediately.
+
+
+=== Machine-Mode Privileged Instructions
+
+==== Environment Call and Breakpoint
+
+include::images/wavedrom/mm-env-call.edn[]
+
+The ECALL instruction is used to make a request to the supporting
+execution environment. When executed in U-mode, S-mode, or M-mode, it
+generates an environment-call-from-U-mode exception,
+environment-call-from-S-mode exception, or environment-call-from-M-mode
+exception, respectively, and performs no other operation.
+
+[NOTE]
+====
+ECALL generates a different exception for each originating privilege
+mode so that environment call exceptions can be selectively delegated. A
+typical use case for Unix-like operating systems is to delegate to
+S-mode the environment-call-from-U-mode exception but not the others.
+====
+
+The EBREAK instruction is used by debuggers to cause control to be
+transferred back to a debugging environment.
+Unless overridden by an external debug environment, EBREAK raises
+a breakpoint exception and performs no other operation.
+
+[NOTE]
+====
+As described in the "C" Standard Extension for Compressed Instructions
+in Volume I of this manual, the C.EBREAK instruction performs the same
+operation as the EBREAK instruction.
+====
+
+ECALL and EBREAK cause the receiving privilege mode’s `epc` register to
+be set to the address of the ECALL or EBREAK instruction itself, _not_
+the address of the following instruction. As ECALL and EBREAK cause
+synchronous exceptions, they are not considered to retire, and should
+not increment the `minstret` CSR.
+
+[[otherpriv]]
+==== Trap-Return Instructions
+
+Instructions to return from trap are encoded under the PRIV minor
+opcode.
+
+include::images/wavedrom/trap-return.edn[]
+
+To return after handling a trap, there are separate trap return
+instructions per privilege level, MRET and SRET. MRET is always
+provided. SRET must be provided if supervisor mode is supported, and
+should raise an illegal-instruction exception otherwise. SRET should
+also raise an illegal-instruction exception when TSR=1 in `mstatus`, as
+described in <<virt-control>>. An __x__RET instruction
+can be executed in privilege mode _x_ or higher, where executing a
+lower-privilege __x__RET instruction will pop the relevant lower-privilege
+interrupt enable and privilege mode stack. Attempting to execute an __x__RET
+instruction in a mode less privileged than _x_ will raise an
+illegal-instruction exception. In addition to manipulating
+the privilege stack as described in <<privstack>>,
+__x__RET sets the `pc` to the value stored in the `__x__epc` register.
+
+If the A extension is supported, the __x__RET instruction is allowed to
+clear any outstanding LR address reservation but is not required to.
+Trap handlers should explicitly clear the reservation if required (e.g.,
+by using a dummy SC) before executing the __x__RET.
+
+[NOTE]
+====
+If __x__RET instructions always cleared LR reservations, it would be
+impossible to single-step through LR/SC sequences using a debugger.
+====
+
+[[wfi]]
+==== Wait for Interrupt
+
+The Wait for Interrupt instruction (WFI) informs the
+implementation that the current hart can be stalled until an interrupt
+might need servicing. Execution of the WFI instruction can also be used
+to inform the hardware platform that suitable interrupts should
+preferentially be routed to this hart. WFI is available in all
+privileged modes, and optionally available to U-mode. This instruction
+may raise an illegal-instruction exception when TW=1 in `mstatus`, as
+described in <<virt-control>>.
+
+include::images/wavedrom/wfi.edn[]
+
+If an enabled interrupt is present or later becomes present while the
+hart is stalled, the interrupt trap will be taken on the following
+instruction, i.e., execution resumes in the trap handler and `mepc` =
+`pc` + 4.
+
+[NOTE]
+====
+The following instruction takes the interrupt trap so that a simple
+return from the trap handler will execute code after the WFI
+instruction.
+====
+
+Implementations are permitted to resume execution for any reason, even if an
+enabled interrupt has not become pending. Hence, a legal implementation is to
+simply implement the WFI instruction as a NOP.
+
+[NOTE]
+====
+If the implementation does not stall the hart on execution of the
+instruction, then the interrupt will be taken on some instruction in the
+idle loop containing the WFI, and on a simple return from the handler,
+the idle loop will resume execution.
+====
+
+The WFI instruction can also be executed when interrupts are disabled.
+The operation of WFI must be unaffected by the global interrupt bits in
+`mstatus` (MIE and SIE) and the delegation register `mideleg` (i.e.,
+the hart must resume if a locally enabled interrupt becomes pending,
+even if it has been delegated to a less-privileged mode), but should
+honor the individual interrupt enables (e.g, MTIE) (i.e.,
+implementations should avoid resuming the hart if the interrupt is
+pending but not individually enabled). WFI is also required to resume
+execution for locally enabled interrupts pending at any privilege level,
+regardless of the global interrupt enable at each privilege level.
+
+If the event that causes the hart to resume execution does not cause an
+interrupt to be taken, execution will resume at `pc` + 4, and software
+must determine what action to take, including looping back to repeat the
+WFI if there was no actionable event.
+
+[NOTE]
+====
+By allowing wake-up when interrupts are disabled, an alternate entry
+point to an interrupt handler can be called that does not require saving
+the current context, as the current context can be saved or discarded
+before the WFI is executed.
+
+As implementations are free to implement WFI as a NOP, software must
+explicitly check for any relevant pending but disabled interrupts in the
+code following an WFI, and should loop back to the WFI if no suitable
+interrupt was detected. The `mip` or `sip` registers can be interrogated
+to determine the presence of any interrupt in machine or supervisor mode
+respectively.
+
+The operation of WFI is unaffected by the delegation register settings.
+
+WFI is defined so that an implementation can trap into a higher
+privilege mode, either immediately on encountering the WFI or after some
+interval to initiate a machine-mode transition to a lower power state,
+for example.
+
+***
+
+The same "wait-for-event" template might be used for possible future
+extensions that wait on memory locations changing, or message arrival.
+====
+
+==== Custom SYSTEM Instructions
+
+The subspace of the SYSTEM major opcode shown in <<customsys>> is designated for custom use. It is recommended that these instructions use bits 29:28 to designate the
+minimum required privilege mode, as do other SYSTEM instructions.
+
+[[customsys]]
+.SYSTEM instruction encodings designated for custom use.
+include::images/bytefield/cust-sys-instr.edn[]
+
+[[reset]]
+=== Reset
+
+Upon reset, a hart’s privilege mode is set to M. The `mstatus` fields
+MIE and MPRV are reset to 0. If little-endian memory accesses are
+supported, the `mstatus`/`mstatush` field MBE is reset to 0. The `misa`
+register is reset to enable the maximal set of supported extensions,
+as described in <<misa>>. For
+implementations with the "A" standard extension, there is no valid
+load reservation. The `pc` is set to an implementation-defined reset
+vector. The `mcause` register is set to a value indicating the cause of
+the reset. Writable PMP registers’ A and L fields are set to 0, unless
+the platform mandates a different reset value for some PMP registers’ A
+and L fields. If the hypervisor extension is implemented, the
+`hgatp`.MODE and `vsatp`.MODE fields are reset to 0. If the Smrnmi
+extension is implemented, the `mnstatus`.NMIE field is reset to 0. No
+ *WARL* field contains an illegal value. If the Zicfilp extension is
+implemented, the `mseccfg`.MLPE field is reset to 0. All other hart
+state is UNSPECIFIED.
+
+The `mcause` values after reset have implementation-specific
+interpretation, but the value 0 should be returned on implementations
+that do not distinguish different reset conditions. Implementations that
+distinguish different reset conditions should only use 0 to indicate the
+most complete reset.
+
+[NOTE]
+====
+Some designs may have multiple causes of reset (e.g., power-on reset,
+external hard reset, brownout detected, watchdog timer elapse,
+sleep-mode wake-up), which machine-mode software and debuggers may wish
+to distinguish.
+
+`mcause` reset values may alias `mcause` values following synchronous
+exceptions. There should be no ambiguity in this overlap, since on reset
+the `pc` is typically set to a different value than on other traps.
+====
+
+[[nmi]]
+=== Non-Maskable Interrupts
+
+Non-maskable interrupts (NMIs) are only used for hardware error
+conditions, and cause an immediate jump to an implementation-defined NMI
+vector running in M-mode regardless of the state of a hart’s interrupt
+enable bits. The `mepc` register is written with the virtual address of
+the instruction that was interrupted, and `mcause` is set to a value
+indicating the source of the NMI. The NMI can thus overwrite state in an
+active machine-mode interrupt handler.
+
+The values written to `mcause` on an NMI are implementation-defined. The
+high Interrupt bit of `mcause` should be set to indicate that this was
+an interrupt. An Exception Code of 0 is reserved to mean "unknown
+cause" and implementations that do not distinguish sources of NMIs via
+the `mcause` register should return 0 in the Exception Code.
+
+Unlike resets, NMIs do not reset processor state, enabling diagnosis,
+reporting, and possible containment of the hardware error.
+
+[[pma]]
+=== Physical Memory Attributes
+
+The physical memory map for a complete system includes various address
+ranges, some corresponding to memory regions and some to memory-mapped
+control registers, portions of which might not be accessible. Some
+memory regions might not support reads, writes, or execution; some might
+not support subword or subblock accesses; some might not support atomic
+operations; and some might not support cache coherence or might have
+different memory models. Similarly, memory-mapped control registers vary
+in their supported access widths, support for atomic operations, and
+whether read and write accesses have associated side effects. In RISC-V
+systems, these properties and capabilities of each region of the
+machine's physical address space are termed _physical memory attributes_
+(PMAs). This section describes RISC-V PMA terminology and how RISC-V
+systems implement and check PMAs.
+
+PMAs are inherent properties of the underlying hardware and rarely
+change during system operation. Unlike physical memory protection values
+described in <<pmp>>, PMAs do not vary by execution
+context. The PMAs of some memory regions are fixed at chip design
+time—for example, for an on-chip ROM. Others are fixed at board design
+time, depending, for example, on which other chips are connected to
+off-chip buses. Off-chip buses might also support devices that could be
+changed on every power cycle (cold pluggable) or dynamically while the
+system is running (hot pluggable). Some devices might be configurable at
+run time to support different uses that imply different PMAs—for
+example, an on-chip scratchpad RAM might be cached privately by one core
+in one end-application, or accessed as a shared non-cached memory in
+another end-application.
+
+Most systems will require that at least some PMAs are dynamically
+checked in hardware later in the execution pipeline after the physical
+address is known, as some operations will not be supported at all
+physical memory addresses, and some operations require knowing the
+current setting of a configurable PMA attribute. While many other
+architectures specify some PMAs in the virtual memory page tables and
+use the TLB to inform the pipeline of these properties, this approach
+injects platform-specific information into a virtualized layer and can
+cause system errors unless attributes are correctly initialized in each
+page-table entry for each physical memory region. In addition, the
+available page sizes might not be optimal for specifying attributes in
+the physical memory space, leading to address-space fragmentation and
+inefficient use of expensive TLB entries.
+
+For RISC-V, we separate out specification and checking of PMAs into a
+separate hardware structure, the _PMA checker_. In many cases, the
+attributes are known at system design time for each physical address
+region, and can be hardwired into the PMA checker. Where the attributes
+are run-time configurable, platform-specific memory-mapped control
+registers can be provided to specify these attributes at a granularity
+appropriate to each region on the platform (e.g., for an on-chip SRAM
+that can be flexibly divided between cacheable and uncacheable uses).
+PMAs are checked for any access to physical memory, including accesses
+that have undergone virtual to physical memory translation. To aid in
+system debugging, we strongly recommend that, where possible, RISC-V
+processors precisely trap physical memory accesses that fail PMA checks.
+Precisely trapped PMA violations manifest as instruction, load, or store
+access-fault exceptions, distinct from virtual-memory page-fault
+exceptions. Precise PMA traps might not always be possible, for example,
+when probing a legacy bus architecture that uses access failures as part
+of the discovery mechanism. In this case, error responses from
+peripheral devices will be reported as imprecise bus-error interrupts.
+
+PMAs must also be readable by software to correctly access certain
+devices or to correctly configure other hardware components that access
+memory, such as DMA engines. As PMAs are tightly tied to a given
+physical platform’s organization, many details are inherently
+platform-specific, as is the means by which software can learn the PMA
+values for a platform. Some devices, particularly legacy buses, do not
+support discovery of PMAs and so will give error responses or time out
+if an unsupported access is attempted. Typically, platform-specific
+machine-mode code will extract PMAs and ultimately present this
+information to higher-level less-privileged software using some standard
+representation.
+
+Where platforms support dynamic reconfiguration of PMAs, an interface
+will be provided to set the attributes by passing requests to a
+machine-mode driver that can correctly reconfigure the platform. For
+example, switching cacheability attributes on some memory regions might
+involve platform-specific operations, such as cache flushes, that are
+available only to machine-mode.
+
+==== Main Memory versus I/O Regions
+
+The most important characterization of a given memory address range is
+whether it holds regular main memory or I/O devices.
+Regular main memory is required to have a number of properties,
+specified below, whereas I/O devices can have a much broader range of
+attributes. Memory regions that do not fit into regular main memory, for
+example, device scratchpad RAMs, are categorized as I/O regions.
+
+NOTE: What previous versions of this specification termed _vacant_ regions are
+no longer a distinct category; they are now described as I/O regions that are
+not accessible (i.e. lacking read, write, and execute permissions).
+Main memory regions that are not accessible are also allowed.
+
+==== Supported Access Type PMAs
+
+Access types specify which access widths, from 8-bit byte to long
+multi-word burst, are supported, and also whether misaligned accesses
+are supported for each access width.
+
+[NOTE]
+====
+Although software running on a RISC-V hart cannot directly generate
+bursts to memory, software might have to program DMA engines to access
+I/O devices and might therefore need to know which access sizes are
+supported.
+====
+
+Main memory regions always support read and write of all access widths
+required by the attached devices, and can specify whether instruction
+fetch is supported.
+
+[NOTE]
+====
+Some platforms might mandate that all of main memory support instruction
+fetch. Other platforms might prohibit instruction fetch from some main
+memory regions.
+
+***
+
+In some cases, the design of a processor or device accessing main memory
+might support other widths, but must be able to function with the types
+supported by the main memory.
+====
+
+I/O regions can specify which combinations of read, write, or execute
+accesses to which data widths are supported.
+
+For systems with page-based virtual memory, I/O and memory regions can
+specify which combinations of hardware page-table reads and hardware
+page-table writes are supported.
+
+[NOTE]
+====
+Unix-like operating systems generally require that all of cacheable main
+memory supports page-table walks.
+====
+
+==== Atomicity PMAs
+
+Atomicity PMAs describes which atomic instructions are supported in this
+address region. Support for atomic instructions is divided into two
+categories: _LR/SC_ and _AMOs_.
+
+[NOTE]
+====
+Some platforms might mandate that all of cacheable main memory support
+all atomic operations required by the attached processors.
+====
+
+===== AMO PMA
+
+Within AMOs, there are four levels of support: _AMONone_, _AMOSwap_,
+_AMOLogical_, and _AMOArithmetic_. AMONone indicates that no AMO
+operations are supported. AMOSwap indicates that only `amoswap`
+instructions are supported in this address range. AMOLogical indicates
+that swap instructions plus all the logical AMOs (`amoand`, `amoor`,
+`amoxor`) are supported. AMOArithmetic indicates that all RISC-V AMOs
+are supported. For each level of support, naturally aligned AMOs of a
+given width are supported if the underlying memory region supports reads
+and writes of that width. Main memory and I/O regions may only support a
+subset or none of the processor-supported atomic operations.
+
+.Classes of AMOs supported by I/O regions.
+[i%autowidth,float="center",align="center",cols="<,<",options="header"]
+|===
+|AMO Class |Supported Operations
+|AMONone +
+AMOSwap +
+AMOLogical +
+AMOArithmetic
+|_None_ +
+`amoswap` +
+above + `amoand`, `amoor`, `amoxor` +
+above + `amoadd`, `amomin`, `amomax`, `amominu`,
+`amomaxu`
+|===
+
+[NOTE]
+====
+We recommend providing at least AMOLogical support for I/O regions where
+possible.
+====
+
+===== Reservability PMA
+
+For _LR/SC_, there are three levels of support indicating combinations
+of the reservability and eventuality properties: _RsrvNone_,
+_RsrvNonEventual_, and _RsrvEventual_. RsrvNone indicates that no LR/SC
+operations are supported (the location is non-reservable).
+RsrvNonEventual indicates that the operations are supported (the
+location is reservable), but without the eventual success guarantee
+described in the unprivileged ISA specification. RsrvEventual indicates
+that the operations are supported and provide the eventual success
+guarantee.
+
+[NOTE]
+====
+We recommend providing RsrvEventual support for main memory regions
+where possible. Most I/O regions will not support LR/SC accesses, as
+these are most conveniently built on top of a cache-coherence scheme,
+but some may support RsrvNonEventual or RsrvEventual.
+
+***
+
+When LR/SC is used for memory locations marked RsrvNonEventual, software
+should provide alternative fall-back mechanisms used when lack of
+progress is detected.
+====
+
+==== Misaligned Atomicity Granule PMA
+
+The misaligned atomicity granule PMA provides constrained support for
+misaligned AMOs.
+This PMA, if present, specifies the size of a _misaligned atomicity granule_,
+a naturally aligned power-of-two number of bytes.
+Specific supported values for this PMA are represented by MAG__NN__, e.g.,
+MAG16 indicates the misaligned atomicity granule is at least 16 bytes.
+
+The misaligned atomicity granule PMA applies only to AMOs, loads and stores
+defined in the base ISAs, and loads and stores of no more than XLEN bits
+defined in the F, D, and Q extensions.
+For an instruction in that set, if all accessed bytes lie within the same
+misaligned atomicity granule, the instruction will not raise an exception for
+reasons of address alignment, and the instruction will give rise to only one
+memory operation for the purposes of RVWMO--i.e., it will execute atomically.
+
+If a misaligned AMO accesses a region that does not specify a misaligned
+atomicity granule PMA, or if not all accessed bytes lie within the same
+misaligned atomicity granule, then an exception is raised.
+For regular loads and stores that access such a region or for which not all
+accessed bytes lie within the same atomicity granule, then either an exception
+is raised, or the access proceeds but is not guaranteed to be atomic.
+Implementations may raise access-fault exceptions instead of
+address-misaligned exceptions for some misaligned accesses, indicating the
+instruction should not be emulated by a trap handler.
+
+NOTE: LR/SC instructions are unaffected by this PMA and so always raise an
+exception when misaligned. Vector memory accesses are also unaffected, so
+might execute non-atomically even when contained within a misaligned atomicity
+granule. Implicit accesses are similarly unaffected by this PMA.
+
+==== Memory-Ordering PMAs
+
+Regions of the address space are classified as either _main memory_ or
+_I/O_ for the purposes of ordering by the FENCE instruction and
+atomic-instruction ordering bits.
+
+Accesses by one hart to main memory regions are observable not only by
+other harts but also by other devices with the capability to initiate
+requests in the main memory system (e.g., DMA engines). Coherent main
+memory regions always have either the RVWMO or RVTSO memory model.
+Incoherent main memory regions have an implementation-defined memory
+model.
+
+Accesses by one hart to an I/O region are observable not only by other
+harts and bus mastering devices but also by the targeted I/O devices,
+and I/O regions may be accessed with either _relaxed_ or _strong_
+ordering. Accesses to an I/O region with relaxed ordering are generally
+observed by other harts and bus mastering devices in a manner similar to
+the ordering of accesses to an RVWMO memory region, as discussed in
+the I/O Ordering section in the RVWMO Explanatory Material appendix
+of Volume I of this specification.
+By contrast, accesses
+to an I/O region with strong ordering are generally observed by other
+harts and bus mastering devices in program order.
+
+Each strongly ordered I/O region specifies a numbered ordering channel,
+which is a mechanism by which ordering guarantees can be provided
+between different I/O regions. Channel 0 is used to indicate
+point-to-point strong ordering only, where only accesses by the hart to
+the single associated I/O region are strongly ordered.
+
+Channel 1 is used to provide global strong ordering across all I/O
+regions. Any accesses by a hart to any I/O region associated with
+channel 1 can only be observed to have occurred in program order by all
+other harts and I/O devices, including relative to accesses made by that
+hart to relaxed I/O regions or strongly ordered I/O regions with
+different channel numbers. In other words, any access to a region in
+channel 1 is equivalent to executing a `fence io,io` instruction before
+and after the instruction.
+
+Other larger channel numbers provide program ordering to accesses by
+that hart across any regions with the same channel number.
+
+Systems might support dynamic configuration of ordering properties on
+each memory region.
+
+[NOTE]
+====
+Strong ordering can be used to improve compatibility with legacy device
+driver code, or to enable increased performance compared to insertion of
+explicit ordering instructions when the implementation is known to not
+reorder accesses.
+
+Local strong ordering (channel 0) is the default form of strong ordering
+as it is often straightforward to provide if there is only a single
+in-order communication path between the hart and the I/O device.
+
+Generally, different strongly ordered I/O regions can share the same
+ordering channel without additional ordering hardware if they share the
+same interconnect path and the path does not reorder requests.
+====
+
+==== Coherence and Cacheability PMAs
+
+Coherence is a property defined for a single physical address, and
+indicates that writes to that address by one agent will eventually be
+made visible to other coherent agents in the system. Coherence is not to be
+confused with the memory consistency model of a system, which defines
+what values a memory read can return given the previous history of reads
+and writes to the entire memory system. In RISC-V platforms, the use of
+hardware-incoherent regions is discouraged due to software complexity,
+performance, and energy impacts.
+
+The cacheability of a memory region should not affect the software view
+of the region except for differences reflected in other PMAs, such as
+main memory versus I/O classification, memory ordering, supported
+accesses and atomic operations, and coherence. For this reason, we treat
+cacheability as a platform-level setting managed by machine-mode
+software only.
+
+Where a platform supports configurable cacheability settings for a
+memory region, a platform-specific machine-mode routine will change the
+settings and flush caches if necessary, so the system is only incoherent
+during the transition between cacheability settings. This transitory
+state should not be visible to lower privilege levels.
+
+[NOTE]
+====
+Coherence is straightforward to provide for a shared memory region that
+is not cached by any agent. The PMA for such a region would simply
+indicate it should not be cached in a private or shared cache.
+
+Coherence is also straightforward for read-only regions, which can be
+safely cached by multiple agents without requiring a cache-coherence
+scheme. The PMA for this region would indicate that it can be cached,
+but that writes are not supported.
+
+Some read-write regions might only be accessed by a single agent, in
+which case they can be cached privately by that agent without requiring
+a coherence scheme. The PMA for such regions would indicate they can be
+cached. The data can also be cached in a shared cache, as other agents
+should not access the region.
+
+If an agent can cache a read-write region that is accessible by other
+agents, whether caching or non-caching, a cache-coherence scheme is
+required to avoid use of stale values. In regions lacking hardware cache
+coherence (hardware-incoherent regions), cache coherence can be
+implemented entirely in software, but software coherence schemes are
+notoriously difficult to implement correctly and often have severe
+performance impacts due to the need for conservative software-directed
+cache-flushing. Hardware cache-coherence schemes require more complex
+hardware and can impact performance due to the cache-coherence probes,
+but are otherwise invisible to software.
+
+For each hardware cache-coherent region, the PMA would indicate that the
+region is coherent and which hardware coherence controller to use if the
+system has multiple coherence controllers. For some systems, the
+coherence controller might be an outer-level shared cache, which might
+itself access further outer-level cache-coherence controllers
+hierarchically.
+
+Most memory regions within a platform will be coherent to software,
+because they will be fixed as either uncached, read-only, hardware
+cache-coherent, or only accessed by one agent.
+====
+
+If a PMA indicates non-cacheability, then accesses to that region must
+be satisfied by the memory itself, not by any caches.
+
+[NOTE]
+====
+For implementations with a cacheability-control mechanism, the situation
+may arise that a program uncacheably accesses a memory location that is
+currently cache-resident. In this situation, the cached copy must be
+ignored. This constraint is necessary to prevent more-privileged modes’
+speculative cache refills from affecting the behavior of less-privileged
+modes’ uncacheable accesses.
+====
+
+==== Idempotency PMAs
+
+Idempotency PMAs describe whether reads and writes to an address region
+are idempotent. Main memory regions are assumed to be idempotent. For
+I/O regions, idempotency on reads and writes can be specified separately
+(e.g., reads are idempotent but writes are not). If accesses are
+non-idempotent, i.e., there is potentially a side effect on any read or
+write access, then speculative or redundant accesses must be avoided.
+
+For the purposes of defining the idempotency PMAs, changes in observed
+memory ordering created by redundant accesses are not considered a side
+effect.
+
+[NOTE]
+====
+While hardware should always be designed to avoid speculative or
+redundant accesses to memory regions marked as non-idempotent, it is
+also necessary to ensure software or compiler optimizations do not
+generate spurious accesses to non-idempotent memory regions.
+
+Non-idempotent regions might not support misaligned accesses. Misaligned
+accesses to such regions should raise access-fault exceptions rather
+than address-misaligned exceptions, indicating that software should not
+emulate the misaligned access using multiple smaller accesses, which
+could cause unexpected side effects.
+====
+
+For non-idempotent regions, implicit reads and writes must not be
+performed early or speculatively, with the following exceptions. When a
+non-speculative implicit read is performed, an implementation is
+permitted to additionally read any of the bytes within a naturally
+aligned power-of-2 region containing the address of the non-speculative
+implicit read. Furthermore, when a non-speculative instruction fetch is
+performed, an implementation is permitted to additionally read any of
+the bytes within the _next_ naturally aligned power-of-2 region of the
+same size (with the address of the region taken modulo
+2^XLEN^). The results of these additional reads
+may be used to satisfy subsequent early or speculative implicit reads.
+The size of these naturally aligned power-of-2 regions is
+implementation-defined, but, for systems with page-based virtual memory,
+must not exceed the smallest supported page size.
+
+[[pmp]]
+=== Physical Memory Protection
+
+To support secure processing and contain faults, it is desirable to
+limit the physical addresses accessible by software running on a hart.
+An optional physical memory protection (PMP) unit provides per-hart
+machine-mode control registers to allow physical memory access
+privileges (read, write, execute) to be specified for each physical
+memory region. The PMP values are checked in parallel with the PMA
+checks described in <<pma>>.
+
+The granularity of PMP access control settings are platform-specific,
+but the standard PMP encoding supports regions as small as four bytes.
+Certain regions’ privileges can be hardwired—for example, some regions
+might only ever be visible in machine mode but in no lower-privilege
+layers.
+
+[NOTE]
+====
+Platforms vary widely in demands for physical memory protection, and
+some platforms may provide other PMP structures in addition to or
+instead of the scheme described in this section.
+====
+
+PMP checks are applied to all accesses whose effective privilege mode is
+S or U, including instruction fetches and data accesses in S and U mode,
+and data accesses in M-mode when the MPRV bit in `mstatus` is set and
+the MPP field in `mstatus` contains S or U. PMP checks are also applied
+to page-table accesses for virtual-address translation, for which the
+effective privilege mode is S. Optionally, PMP checks may additionally
+apply to M-mode accesses, in which case the PMP registers themselves are
+locked, so that even M-mode software cannot change them until the hart
+is reset. In effect, PMP can _grant_ permissions to S and U modes, which
+by default have none, and can _revoke_ permissions from M-mode, which by
+default has full permissions.
+
+PMP violations are always trapped precisely at the processor.
+
+==== Physical Memory Protection CSRs
+
+PMP entries are described by an 8-bit configuration register and one
+MXLEN-bit address register. Some PMP settings additionally use the
+address register associated with the preceding PMP entry. Up to 64 PMP
+entries are supported. Implementations may implement zero, 16, or 64 PMP
+entries; the lowest-numbered PMP entries must be implemented first. All
+PMP CSR fields are *WARL* and may be read-only zero. PMP CSRs are only
+accessible to M-mode.
+
+The PMP configuration registers are densely packed into CSRs to minimize
+context-switch time. For RV32, sixteen CSRs, `pmpcfg0`–`pmpcfg15`, hold
+the configurations `pmp0cfg`–`pmp63cfg` for the 64 PMP entries, as shown
+in <<pmpcfg-rv32>>. For RV64, eight
+even-numbered CSRs, `pmpcfg0`, `pmpcfg2`, …, `pmpcfg14`, hold the
+configurations for the 64 PMP entries, as shown in
+<<pmpcfg-rv64>>. For RV64, the odd-numbered
+configuration registers, `pmpcfg1`, `pmpcfg3`, …, `pmpcfg15`, are
+illegal.
+
+[NOTE]
+====
+RV64 harts use `pmpcfg2`, rather than `pmpcfg1`, to hold
+configurations for PMP entries 8-15. This design reduces the cost of
+supporting multiple MXLEN values, since the configurations for PMP
+entries 8-11 appear in `pmpcfg2`[31:0] for both RV32 and RV64.
+====
+
+[[pmpcfg-rv32]]
+.RV32 PMP configuration CSR layout.
+include::images/bytefield/pmp-rv32.edn[]
+
+[[pmpcfg-rv64]]
+.RV64 PMP configuration CSR layout.
+include::images/bytefield/pmp-rv64.edn[]
+
+
+The PMP address registers are CSRs named `pmpaddr0`-`pmpaddr63`. Each
+PMP address register encodes bits 33-2 of a 34-bit physical address for
+RV32, as shown in <<pmpaddr-rv32>>. For RV64,
+each PMP address register encodes bits 55-2 of a 56-bit physical
+address, as shown in <<pmpaddr-rv64>>. Not all
+physical address bits may be implemented, and so the `pmpaddr` registers
+are *WARL*.
+
+[NOTE]
+====
+The Sv32 page-based virtual-memory scheme described in
+<<sv32>> supports 34-bit physical addresses for
+RV32, so the PMP scheme must support addresses wider than XLEN for RV32.
+The Sv39 and Sv48 page-based virtual-memory schemes described in
+<<sv39>> and <<sv48>> support a
+56-bit physical address space, so the RV64 PMP address registers impose
+the same limit.
+====
+
+[[pmpaddr-rv32]]
+.PMP address register format, RV32.
+include::images/bytefield/pmpaddr-rv32.edn[]
+
+[[pmpaddr-rv64]]
+.PMP address register format, RV64.
+include::images/bytefield/pmpaddr-rv64.edn[]
+
+<<pmpcfg>> shows the layout of a PMP configuration
+register. The R, W, and X bits, when set, indicate that the PMP entry
+permits read, write, and instruction execution, respectively. When one
+of these bits is clear, the corresponding access type is denied. The R,
+W, and X fields form a collective *WARL* field for which the combinations with R=0 and W=1 are reserved. The remaining two fields, A and L, are described in the following sections.
+
+[[pmpcfg]]
+.PMP configuration register format.
+include::images/bytefield/pmpcfg.edn[]
+
+
+Attempting to fetch an instruction from a PMP region that does not have
+execute permissions raises an instruction access-fault exception.
+Attempting to execute a load or load-reserved instruction which accesses
+a physical address within a PMP region without read permissions raises a
+load access-fault exception. Attempting to execute a store,
+store-conditional, or AMO instruction which accesses a physical address
+within a PMP region without write permissions raises a store
+access-fault exception.
+
+===== Address Matching
+
+The A field in a PMP entry's configuration register encodes the
+address-matching mode of the associated PMP address register. The
+encoding of this field is shown in <<pmpcfg-a>>.
+When A=0, this PMP entry is disabled and matches no addresses. Two other
+address-matching modes are supported: naturally aligned power-of-2
+regions (NAPOT), including the special case of naturally aligned
+four-byte regions (NA4); and the top boundary of an arbitrary range
+(TOR). These modes support four-byte granularity.
+
+[[pmpcfg-a]]
+.Encoding of A field in PMP configuration registers.
+[%autowidth,float="center",align="center",cols=">,^,<",options="header"]
+|===
+|A |Name |Description
+|0 +
+1 +
+2 +
+3
+|OFF +
+TOR +
+NA4 +
+NAPOT
+|Null region (disabled) +
+Top of range +
+Naturally aligned four-byte region +
+Naturally aligned power-of-two region, &#8805;8
+bytes
+|===
+
+NAPOT ranges make use of the low-order bits of the associated address
+register to encode the size of the range, as shown in
+<<pmpcfg-napot>>.
+
+[[pmpcfg-napot]]
+.`NAPOT` range encoding in PMP address and configuration registers.
+[%autowidth,float="center",align="center",cols="^,^,<",options="header"]
+|===
+|`pmpaddr` |`pmpcfg`.A |Match type and size
+|`yyyy...yyyy` +
+`yyyy...yyy0` +
+`yyyy...yy01` +
+`yyyy...y011` +
+... +
+`yy01...1111` +
+`y011...1111` +
+`0111...1111` +
+`1111...1111`
+|NA4 +
+NAPOT +
+NAPOT +
+NAPOT +
+... +
+NAPOT +
+NAPOT +
+NAPOT +
+NAPOT
+|4-byte NAPOT range +
+8-byte NAPOT range +
+16-byte NAPOT range +
+32-byte NAPOT range +
+… +
+2^XLEN^-byte NAPOT range +
+2^XLEN+1^-byte NAPOT range +
+2^XLEN+2^-byte NAPOT range +
+2^XLEN+3^-byte NAPOT range
+|===
+
+If TOR is selected, the associated address register forms the top of the
+address range, and the preceding PMP address register forms the bottom
+of the address range. If PMP entry __i__'s A field is set to
+TOR, the entry matches any address _y_ such that `pmpaddr~i-1~`&#8804;__y__<``pmpaddr~i~`` (irrespective of the value of `pmpcfg~i-1~`). If PMP entry 0's A field is set to TOR, zero is used for the lower bound, and so it matches
+any address `y<pmpaddr~0~`.
+
+[NOTE]
+====
+If `pmpaddr~i-1~&#8805;``pmpaddr~i~``` and `pmpcfg~i~.A`=TOR, then PMP entry _i_ matches no addresses.
+====
+
+Although the PMP mechanism supports regions as small as four bytes,
+platforms may specify coarser PMP regions. In general, the PMP grain is
+2^G+2^ bytes and must be the same across all PMP regions.
+When G {ge} 1, the NA4 mode is not selectable. When
+G {ge} 2 and pmpcfg~i~.A[1] is set,
+i.e. the mode is NAPOT, then bits pmpaddr~i~[G-2:0]
+read as all ones. When G {ge} 1 and
+pmpcfg~i~.A[1] is clear, i.e. the mode is OFF or TOR,
+then bits pmpaddr~i~[G-1:0] read as all zeros. Bits
+pmpaddr~i~[G-1:0] do not affect the TOR address-matching logic.
+Although changing pmpcfg~i~.A[1] affects the value
+read from pmpaddr~i~, it does not affect the
+underlying value stored in that register—in particular,
+pmpaddr~i~[G-1] retains its original value when
+pmpcfg~i~.A is changed from NAPOT to TOR/OFF then
+back to NAPOT.
+
+[NOTE]
+====
+Software may determine the PMP granularity by writing zero to `pmp0cfg`, then writing all ones to `pmpaddr0`, then reading back `pmpaddr0`. If _G_ is the index of the least-significant bit set, the PMP granularity is 2^G+2^ bytes.
+====
+
+===== Locking and Privilege Mode
+
+The L bit indicates that the PMP entry is locked, i.e., writes to the
+configuration register and associated address registers are ignored.
+Locked PMP entries remain locked until the hart is reset. If PMP entry
+_i_ is locked, writes to ``pmp``__i__``cfg`` and ``pmpaddr``__i__ are ignored. Additionally, if PMP
+entry _i_ is locked and ``pmp``__i__``cfg.A`` is set
+to TOR, writes to ``pmpaddr``__i__-1 are ignored.
+
+[NOTE]
+====
+Setting the L bit locks the PMP entry even when the A field is set to
+OFF.
+====
+
+In addition to locking the PMP entry, the L bit indicates whether the
+R/W/X permissions are additionally enforced on M-mode accesses.
+When the L bit is
+set, these permissions are enforced for all privilege modes. When the L
+bit is clear, any M-mode access matching the PMP entry will succeed; the
+R/W/X permissions apply only to S and U modes.
+
+===== Priority and Matching Logic
+
+PMP entries are statically prioritized. The lowest-numbered PMP entry
+that matches any byte of an access determines whether that access
+succeeds or fails. The matching PMP entry must match all bytes of an
+access, or the access fails, irrespective of the L, R, W, and X bits.
+For example, if a PMP entry is configured to match the four-byte range
+`0xC`–`0xF`, then an 8-byte access to the range `0x8`–`0xF` will fail,
+assuming that PMP entry is the highest-priority entry that matches those
+addresses.
+
+If a PMP entry matches all bytes of an access, then the L, R, W, and X
+bits determine whether the access succeeds or fails. If the L bit is
+clear and the privilege mode of the access is M, the access succeeds.
+Otherwise, if the L bit is set or the privilege mode of the access is S
+or U, then the access succeeds only if the R, W, or X bit corresponding
+to the access type is set.
+
+If no PMP entry matches an M-mode access, the access succeeds. If no PMP
+entry matches an S-mode or U-mode access, but at least one PMP entry is
+implemented, the access fails.
+
+[NOTE]
+====
+If at least one PMP entry is implemented, but all PMP entries’ A fields
+are set to OFF, then all S-mode and U-mode memory accesses will fail.
+====
+
+Failed accesses generate an instruction, load, or store access-fault
+exception. Note that a single instruction may generate multiple
+accesses, which may not be mutually atomic. An access-fault exception is
+generated if at least one access generated by an instruction fails,
+though other accesses generated by that instruction may succeed with
+visible side effects. Notably, instructions that reference virtual
+memory are decomposed into multiple accesses.
+
+On some implementations, misaligned loads, stores, and instruction
+fetches may also be decomposed into multiple accesses, some of which may
+succeed before an access-fault exception occurs. In particular, a
+portion of a misaligned store that passes the PMP check may become
+visible, even if another portion fails the PMP check. The same behavior
+may manifest for stores wider than XLEN bits (e.g., the FSD instruction
+in RV32D), even when the store address is naturally aligned.
+
+[[pmp-vmem]]
+==== Physical Memory Protection and Paging
+
+The Physical Memory Protection mechanism is designed to compose with the
+page-based virtual memory systems described in
+<<supervisor>>. When paging is enabled,
+instructions that access virtual memory may result in multiple
+physical-memory accesses, including implicit references to the page
+tables. The PMP checks apply to all of these accesses. The effective
+privilege mode for implicit page-table accesses is S.
+
+Implementations with virtual memory are permitted to perform address
+translations speculatively and earlier than required by an explicit
+memory access, and are permitted to cache them in address translation
+cache structures—including possibly caching the identity mappings from
+effective address to physical address used in Bare translation modes and
+M-mode. The PMP settings for the resulting physical address may be
+checked (and possibly cached) at any point between the address
+translation and the explicit memory access. Hence, when the PMP settings
+are modified, M-mode software must synchronize the PMP settings with the
+virtual memory system and any PMP or address-translation caches. This is
+accomplished by executing an SFENCE.VMA instruction with _rs1_=`x0` and
+_rs2_=`x0`, after the PMP CSRs are written.
+See <<hyp-mm-fences>> for additional synchronization requirements when the
+hypervisor extension is implemented.
+
+If page-based virtual memory is not implemented, memory accesses check
+the PMP settings synchronously, so no SFENCE.VMA is needed.
diff --git a/src/machine.tex b/src/machine.tex
deleted file mode 100644
index 2e88a1f..0000000
--- a/src/machine.tex
+++ /dev/null
@@ -1,3098 +0,0 @@
-\chapter{Machine-Level ISA, version \privrev}
-\label{machine}
-
-This chapter describes the machine-level operations available in
-machine-mode (M-mode), which is the highest privilege mode in a RISC-V
-system. M-mode is the only mandatory privilege mode in a RISC-V
-hardware implementation. M-mode is used for low-level access to a
-hardware platform and is the first mode entered at reset. M-mode can
-also be used to implement features that are too difficult or expensive
-to implement in hardware directly. The RISC-V machine-level ISA
-contains a common core that is extended depending on which other
-privilege levels are supported and other details of the hardware
-implementation.
-
-\section{Machine-Level CSRs}
-
-In addition to the machine-level CSRs described in this section,
-M-mode code can access all CSRs at lower privilege levels.
-
-\subsection{Machine ISA Register {\tt misa}}
-
-The {\tt misa} CSR is a \warl\ read-write register
-reporting the ISA supported by the hart. This register must be
-readable in any implementation, but a value of zero can be returned to
-indicate the {\tt misa} register has not been implemented, requiring
-that CPU capabilities be determined through a separate non-standard
-mechanism.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{c@{}c@{}L}
-\instbitrange{MXLEN-1}{MXLEN-2} &
-\instbitrange{MXLEN-3}{26} &
-\instbitrange{25}{0} \\
-\hline
-\multicolumn{1}{|c|}{MXL[1:0] (\warl)} &
-\multicolumn{1}{c|}{\wlrl} &
-\multicolumn{1}{c|}{Extensions[25:0] (\warl)} \\
-\hline
-2 & MXLEN-28 & 26 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine ISA register ({\tt misa}).}
-\label{misareg}
-\end{figure*}
-
-The MXL (Machine XLEN) field encodes the native base integer ISA width
-as shown in Table~\ref{misabase}. The MXL field may be writable in
-implementations that support multiple base ISA widths. The effective
-XLEN in M-mode, {\em MXLEN}, is given by the setting of MXL, or has a
-fixed value if {\tt misa} is zero. The MXL field is always set to the
-widest supported ISA variant at reset.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|r|r|}
-\hline
-MXL & XLEN \\
-\hline
-1 & 32 \\
-2 & 64 \\
-3 & 128 \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Encoding of MXL field in {\tt misa}}
-\label{misabase}
-\end{table*}
-
-The {\tt misa} CSR is MXLEN bits wide. If the value read from {\tt misa} is
-nonzero, field MXL of that value always denotes the current MXLEN. If a write
-to {\tt misa} causes MXLEN to change, the position of MXL moves to the
-most-significant two bits of {\tt misa} at the new width.
-
-\begin{commentary}
-The base width can be quickly ascertained using branches on the sign
-of the returned {\tt misa} value, and possibly a shift left by one and
-a second branch on the sign. These checks can be written in assembly
-code without knowing the register width (XLEN) of the machine. The
-base width is given by $\mbox{XLEN}=2^{\mbox{MXL+4}}$.
-
-The base width can also be found if {\tt misa} is zero, by placing the
-immediate 4 in a register then shifting the register left by 31 bits
-at a time. If zero after one shift, then the machine is RV32. If
-zero after two shifts, then the machine is RV64, else RV128.
-\end{commentary}
-
-When MXL is set to a value less than the widest supported XLEN, all
-operations must ignore source operand register bits above the
-configured XLEN, and must sign-extend results to fill the entire
-widest supported XLEN in the destination register.
-
-\begin{commentary}
-We require that operations always fill the entire underlying hardware
-registers with defined values to avoid implementation-defined
-behavior.
-\end{commentary}
-
-The Extensions field encodes the presence of the standard extensions,
-with a single bit per letter of the alphabet (bit 0 encodes presence
-of extension ``A'' , bit 1 encodes presence of extension ``B'',
-through to bit 25 which encodes ``Z''). The ``I'' bit will be set for
-RV32I, RV64I, RV128I base ISAs, and the ``E'' bit will be set for
-RV32E. The Extension is a \warl\ field that can contain writable bits
-where the implementation allows the supported ISA to be modified. At
-reset, the Extension field should contain the maximal set of supported
-extensions, and I should be selected over E if both are available.
-
-The ``G'' bit is used as an escape to allow expansion to a larger
-space of standard extension names.
-\begin{commentary}
-G is used to indicate the combination IMAFD, so is redundant in the
-{\tt misa} CSR, hence we reserve the bit to indicate that
-additional standard extensions are present.
-\end{commentary}
-
-The ``U'' and ``S'' bits will be set if there is support for user and
-supervisor modes respectively.
-
-The ``X'' bit will be set if there are any non-standard extensions.
-
-\begin{table*}
-\begin{center}
-\begin{tabular}{|r|r|l|}
-\hline
-Bit & Character & Description \\
-\hline
- 0 & A & Atomic extension \\
- 1 & B & {\em Tentatively reserved for Bit operations extension} \\
- 2 & C & Compressed extension \\
- 3 & D & Double-precision floating-point extension \\
- 4 & E & RV32E base ISA \\
- 5 & F & Single-precision floating-point extension \\
- 6 & G & Additional standard extensions present \\
- 7 & H & Hypervisor extension \\
- 8 & I & RV32I/64I/128I base ISA \\
- 9 & J & {\em Tentatively reserved for Dynamically Translated Languages extension} \\
- 10 & K & {\em Reserved} \\
- 11 & L & {\em Tentatively reserved for Decimal Floating-Point extension} \\
- 12 & M & Integer Multiply/Divide extension \\
- 13 & N & User-level interrupts supported \\
- 14 & O & {\em Reserved} \\
- 15 & P & {\em Tentatively reserved for Packed-SIMD extension} \\
- 16 & Q & Quad-precision floating-point extension \\
- 17 & R & {\em Reserved} \\
- 18 & S & Supervisor mode implemented \\
- 19 & T & {\em Tentatively reserved for Transactional Memory extension} \\
- 20 & U & User mode implemented \\
- 21 & V & {\em Tentatively reserved for Vector extension} \\
- 22 & W & {\em Reserved} \\
- 23 & X & Non-standard extensions present \\
- 24 & Y & {\em Reserved} \\
- 25 & Z & {\em Reserved} \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Encoding of Extensions field in {\tt misa}. All bits that are
- reserved for future use must return zero when read.}
-\label{misaletters}
-\end{table*}
-
-
-\begin{commentary}
-The {\tt misa} CSR exposes a rudimentary catalog of CPU features
-to machine-mode code. More extensive information can be obtained in
-machine mode by probing other machine registers, and examining other
-ROM storage in the system as part of the boot process.
-
-We require that lower privilege levels execute environment calls
-instead of reading CPU registers to determine features available at
-each privilege level. This enables virtualization layers to alter the
-ISA observed at any level, and supports a much richer command
-interface without burdening hardware designs.
-\end{commentary}
-
-Unless {\tt misa} is hardwired to zero, the I and E bits are always
-complements of each other. Hence, either both are read-only or both are
-writable. If they are writable, then an attempt to set them to the same value
-{\em x} causes I to be set to {\em x} and E to be set to !{\em x}.
-
-The implementation may impose additional constraints on the collective setting
-of two or more {\tt misa} fields, in which case they function collectively as
-a single \warl\ field. For example, an implementation might require that the
-D bit be clear unless the F bit is set. An attempt to write an unsupported
-combination causes those bits to be set to some supported combination.
-\begin{commentary}
-In the event that an unsupported combination is written to {\tt misa},
-it is recommended that the implementation select the supported combination
-with the fewest features enabled, to aid debugging of the error.
-\end{commentary}
-
-Writing {\tt misa} may increase IALIGN, e.g., by disabling the ``C''
-extension.
-If an instruction that would write {\tt misa} increases IALIGN, and
-the subsequent instruction's address is not IALIGN-bit aligned, the
-write to {\tt misa} is suppressed, leaving {\tt misa} unchanged.
-
-\clearpage
-
-\subsection{Machine Vendor ID Register {\tt mvendorid}}
-
-The {\tt mvendorid} CSR is a 32-bit read-only register providing
-the JEDEC manufacturer ID of the provider of the core. This register
-must be readable in any implementation, but a value of 0 can be
-returned to indicate the field is not implemented or that this is a
-non-commercial implementation.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{JS}
-\instbitrange{31}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{Bank} &
-\multicolumn{1}{c|}{Offset} \\
-\hline
-25 & 7 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Vendor ID register ({\tt mvendorid}).}
-\label{mvendorreg}
-\end{figure*}
-
-JEDEC manufacturer IDs are ordinarily encoded as a sequence of one-byte
-continuation codes {\tt 0x7f}, terminated by a one-byte ID not equal to
-{\tt 0x7f}, with an odd parity bit in the most-significant bit of each byte.
-{\tt mvendorid} encodes the number of one-byte continuation
-codes in the Bank field, and encodes the final byte in the Offset field,
-discarding the parity bit. For example, the JEDEC manufacturer ID
-{\tt 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x7f 0x8a}
-(twelve continuation codes followed by {\tt 0x8a}) would be encoded in the
-{\tt mvendorid} field as {\tt 0x60a}.
-
-\begin{commentary}
-Previously the vendor ID was to be a number allocated by the RISC-V
-Foundation, but this duplicates the work of JEDEC in maintaining a
-manufacturer ID standard. At time of writing, registering a
-manufacturer ID with JEDEC has a one-time cost of \$500.
-\end{commentary}
-
-\subsection{Machine Architecture ID Register {\tt marchid}}
-
-The {\tt marchid} CSR is an MXLEN-bit read-only register encoding the
-base microarchitecture of the hart. This register must be readable in
-any implementation, but a value of 0 can be returned to indicate the
-field is not implemented. The combination of {\tt mvendorid} and {\tt
- marchid} should uniquely identify the type of hart microarchitecture
-that is implemented.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{J}
-\instbitrange{MXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{Architecture ID} \\
-\hline
-MXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine Architecture ID register ({\tt marchid}).}
-\label{marchreg}
-\end{figure*}
-
-Open-source project architecture IDs are allocated globally by the
-RISC-V Foundation, and have non-zero architecture IDs with a zero
-most-significant-bit (MSB). Commercial architecture IDs are allocated
-by each commercial vendor independently, but must have the MSB set and
-cannot contain zero in the remaining MXLEN-1 bits.
-
-\begin{commentary}
-The intent is for the architecture ID to represent the
-microarchitecture associated with the repo around which development
-occurs rather than a particular organization. Commercial fabrications
-of open-source designs should (and might be required by the license
-to) retain the original architecture ID. This will aid in reducing
-fragmentation and tool support costs, as well as provide attribution.
-Open-source architecture IDs should be administered by the Foundation
-and should only be allocated to released, functioning open-source
-projects. Commercial architecture IDs can be managed independently by
-any registered vendor but are required to have IDs disjoint from the
-open-source architecture IDs (MSB set) to prevent collisions if a
-vendor wishes to use both closed-source and open-source
-microarchitectures.
-
-The convention adopted within the following Implementation field can
-be used to segregate branches of the same architecture design,
-including by organization. The {\tt misa} register also helps
-distinguish different variants of a design, as does the configuration
-string if present.
-\end{commentary}
-
-\subsection{Machine Implementation ID Register {\tt mimpid}}
-
-The {\tt mimpid} CSR provides a unique encoding of the version of the
-processor implementation. This register must be readable in any
-implementation, but a value of 0 can be returned to indicate that the
-field is not implemented. The Implementation value should reflect the
-design of the RISC-V processor itself and not any surrounding system.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{J}
-\instbitrange{MXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{Implementation} \\
-\hline
-MXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine Implementation ID register ({\tt mimpid}).}
-\label{mimpidreg}
-\end{figure*}
-
-\begin{commentary}
-The format of this field is left to the provider of the architecture
-source code, but will be often be printed by standard tools as a
-hexadecimal string without any leading or trailing zeros, so the
-Implementation value can be left-justified (i.e., filled in from
-most-significant nibble down) with subfields aligned on nibble
-boundaries to ease human readability.
-\end{commentary}
-
-\subsection{Hart ID Register {\tt mhartid}}
-
-The {\tt mhartid} CSR is an MXLEN-bit read-only register
-containing the integer ID of the hardware thread running the code.
-This register must be readable in any implementation. Hart IDs might
-not necessarily be numbered contiguously in a multiprocessor system,
-but at least one hart must have a hart ID of zero. Hart IDs must be unique.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{J}
-\instbitrange{MXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{Hart ID}\\
-\hline
-MXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Hart ID register ({\tt mhartid}).}
-\label{mhartidreg}
-\end{figure*}
-
-
-\begin{commentary}
-In certain cases, we must ensure exactly one hart runs some code
-(e.g., at reset), and so require one hart to have a known hart ID of
-zero.
-
-For efficiency, system implementers should aim to reduce the magnitude
-of the largest hart ID used in a system.
-\end{commentary}
-
-\subsection{Machine Status Register ({\tt mstatus})}
-
-The {\tt mstatus} register is an MXLEN-bit read/write register
-formatted as shown in Figure~\ref{mstatusreg-rv32} for RV32 and
-Figure~\ref{mstatusreg} for RV64 and RV128. The {\tt mstatus}
-register keeps track of and controls the hart's current operating
-state. Restricted views of the {\tt mstatus} register appear as the
-{\tt sstatus} and {\tt ustatus} registers in the S-level and U-level
-ISAs respectively.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{cKccccccc}
-\\
-\instbit{31} &
-\instbitrange{30}{23} &
-\instbit{22} &
-\instbit{21} &
-\instbit{20} &
-\instbit{19} &
-\instbit{18} &
-\instbit{17} &
- \\
-\hline
-\multicolumn{1}{|c|}{SD} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{TSR} &
-\multicolumn{1}{c|}{TW} &
-\multicolumn{1}{c|}{TVM} &
-\multicolumn{1}{c|}{MXR} &
-\multicolumn{1}{c|}{SUM} &
-\multicolumn{1}{c|}{MPRV} &
- \\
-\hline
-1 & 8 & 1 & 1 & 1 & 1 & 1 & 1 & \\
-\end{tabular}
-\begin{tabular}{cccccccccccccc}
-\\
-&
-\instbitrange{16}{15} &
-\instbitrange{14}{13} &
-\instbitrange{12}{11} &
-\instbitrange{10}{9} &
-\instbit{8} &
-\instbit{7} &
-\instbit{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
- &
-\multicolumn{1}{|c|}{XS[1:0]} &
-\multicolumn{1}{c|}{FS[1:0]} &
-\multicolumn{1}{c|}{MPP[1:0]} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPP} &
-\multicolumn{1}{c|}{MPIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPIE} &
-\multicolumn{1}{c|}{UPIE} &
-\multicolumn{1}{c|}{MIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SIE} &
-\multicolumn{1}{c|}{UIE} \\
-\hline
- & 2 & 2 & 2 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine-mode status register ({\tt mstatus}) for RV32.}
-\label{mstatusreg-rv32}
-\end{figure*}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{cRccYccccccc}
-\\
-\instbit{MXLEN-1} &
-\instbitrange{MXLEN-2}{36} &
-\instbitrange{35}{34} &
-\instbitrange{33}{32} &
-\instbitrange{31}{23} &
-\instbit{22} &
-\instbit{21} &
-\instbit{20} &
-\instbit{19} &
-\instbit{18} &
-\instbit{17} &
- \\
-\hline
-\multicolumn{1}{|c|}{SD} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SXL[1:0]} &
-\multicolumn{1}{c|}{UXL[1:0]} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{TSR} &
-\multicolumn{1}{c|}{TW} &
-\multicolumn{1}{c|}{TVM} &
-\multicolumn{1}{c|}{MXR} &
-\multicolumn{1}{c|}{SUM} &
-\multicolumn{1}{c|}{MPRV} &
- \\
-\hline
-1 & MXLEN-37 & 2 & 2 & 9 & 1 & 1 & 1 & 1 & 1 & 1 & \\
-\end{tabular}
-\begin{tabular}{cccccccccccccc}
-\\
-&
-\instbitrange{16}{15} &
-\instbitrange{14}{13} &
-\instbitrange{12}{11} &
-\instbitrange{10}{9} &
-\instbit{8} &
-\instbit{7} &
-\instbit{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
- &
-\multicolumn{1}{|c|}{XS[1:0]} &
-\multicolumn{1}{c|}{FS[1:0]} &
-\multicolumn{1}{c|}{MPP[1:0]} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPP} &
-\multicolumn{1}{c|}{MPIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPIE} &
-\multicolumn{1}{c|}{UPIE} &
-\multicolumn{1}{c|}{MIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SIE} &
-\multicolumn{1}{c|}{UIE} \\
-\hline
- & 2 & 2 & 2 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine-mode status register ({\tt mstatus}) for RV64 and RV128.}
-\label{mstatusreg}
-\end{figure*}
-
-
-\subsection{Privilege and Global Interrupt-Enable Stack in {\tt mstatus} register}
-\label{privstack}
-
-Global interrupt-enable bits, MIE, SIE, and UIE, are provided for each
-privilege mode. These bits are primarily used to guarantee atomicity
-with respect to interrupt handlers in the current privilege mode.
-
-\begin{commentary}
-The global {\em x}IE bits are located in the low-order bits of {\tt mstatus},
-allowing them to be atomically set or cleared with a single CSR
-instruction.
-\end{commentary}
-
-When a hart is executing in privilege mode {\em x}, interrupts are
-globally enabled when {\em x}\,IE=1 and globally disabled when {\em
- x}\,IE=0. Interrupts for lower-privilege modes, {\em w}$<${\em x},
-are always globally disabled regardless of the setting of the
-lower-privilege mode's global {\em w}\,IE bit. Interrupts for
-higher-privilege modes, {\em y}$>${\em x}, are always globally enabled
-regardless of the setting of the higher-privilege mode's global {\em
- y}\,IE bit. Higher-privilege-level code can use separate
-per-interrupt enable bits to disable selected high-privilege-mode
-interrupts before ceding control to a lower-privilege mode.
-
-\begin{commentary}
- A higher-privilege mode {\em y} could disable all of its interrupts
- before ceding control to a lower-privilege mode but this would be
- unusual as it would leave only a synchronous trap, non-maskable
- interrupt, or reset as means to regain control of the hart.
-\end{commentary}
-
-To support nested traps, each privilege mode {\em x} has a two-level
-stack of interrupt-enable bits and privilege modes. {\em x}\,PIE
-holds the value of the interrupt-enable bit active prior to the trap,
-and {\em x}\,PP holds the previous privilege mode. The {\em x}\,PP
-fields can only hold privilege modes up to {\em x}, so MPP is
-two bits wide, SPP is one bit wide, and UPP is implicitly zero. When
-a trap is taken from privilege mode {\em y} into privilege mode {\em
- x}, {\em x}\,PIE is set to the value of {\em x}\,IE; {\em x}\,IE is set to
-0; and {\em x}\,PP is set to {\em y}.
-
-\begin{commentary}
-For lower privilege modes, any trap (synchronous or asynchronous) is
-usually taken at a higher privilege mode with interrupts disabled upon entry.
-The higher-level trap handler will either service the trap and return
-using the stacked information, or, if not returning immediately to the
-interrupted context, will save the privilege stack before re-enabling
-interrupts, so only one entry per stack is required.
-\end{commentary}
-
-The MRET, SRET, or URET instructions are used to return from
-traps in M-mode, S-mode, or U-mode respectively. When
-executing an {\em x}RET instruction, supposing {\em x}\,PP holds the
-value {\em y}, {\em x}\,IE is set to {\em x}\,PIE; the privilege mode
-is changed to {\em y}; {\em x}\,PIE is set to 1; and {\em x}\,PP is
-set to U (or M if user-mode is not supported).
-
-{\em x}\,PP fields are \warl\ fields that can hold only privilege mode {\em x}
-and any implemented privilege mode lower than {\em x}. If privilege mode {\em
-x} is not implemented, then {\em x}\,PP must be hardwired to 0.
-
-\begin{commentary}
-M-mode software can determine whether a privilege mode is implemented
-by writing that mode to MPP then reading it back.
-
-If the machine provides only U and M modes, then only a single
-hardware storage bit is required to represent either 00 or 11 in MPP.
-\end{commentary}
-
-User-level interrupts are an optional extension and have been
-allocated the ISA extension letter N.
-If user-level interrupts are omitted, the
-UIE and UPIE bits are hardwired to zero. For all other supported
-privilege modes {\em x}, the {\em x}\,IE and {\em x}\,PIE must not
-be hardwired.
-
-\begin{commentary}
-User-level interrupts are primarily intended to support secure
-embedded systems with only M-mode and U-mode present, but can also be
-supported in systems running Unix-like operating systems to support
-user-level trap handling.
-\end{commentary}
-
-\begin{commentary}
-Fields that were previously allocated for H-mode support in {\tt
- mstatus} have now been reserved as \wpri\ fields. To reduce
-backwards incompatibility with existing implementations, we did not
-compact the register after removing these fields.
-\end{commentary}
-
-\subsection{Base ISA Control in {\tt mstatus} Register}
-\label{xlen-control}
-
-For RV64 and RV128 systems, the SXL and UXL fields are \warl\ fields
-that control the value of XLEN for S-mode and U-mode,
-respectively. The encoding of these fields is the same as the MXL
-field of {\tt misa}, shown in Table~\ref{misabase}. The effective
-XLEN in S-mode and U-mode are termed {\em SXLEN} and {\em UXLEN},
-respectively.
-
-For RV32 systems, the SXL and UXL fields do not exist, and
-SXLEN=32 and UXLEN=32.
-
-For RV64 and RV128 systems, if S-mode is not supported, then SXL is hardwired
-to zero. Otherwise, it is a \warl\ field that encodes the current value of
-SXLEN. In particular, the implementation may hardwire SXL so that
-SXLEN=MXLEN.
-
-For RV64 and RV128 systems, if U-mode is not supported, then UXL is hardwired
-to zero. Otherwise, it is a \warl\ field that encodes the current value of
-UXLEN. In particular, the implementation may hardwire UXL so that
-UXLEN=MXLEN or UXLEN=SXLEN.
-
-Whenever XLEN in any mode is set to a value less than the widest
-supported XLEN, all operations must ignore source operand register
-bits above the configured XLEN, and must sign-extend results to fill
-the entire widest supported XLEN in the destination register.
-
-\begin{commentary}
-To reduce hardware complexity, the architecture imposes no checks that
-lower-privilege modes have XLEN settings less than or equal to the
-next-higher privilege mode. In practice, such settings would almost
-always be an error, but machine operation is well-defined even in this
-case.
-\end{commentary}
-
-If MXLEN is changed from 32 to a wider width, each of {\tt mstatus} fields SXL and
-UXL, if not hardwired to a forced value, gets the value corresponding to the
-widest supported width not wider than the new MXLEN.
-
-\subsection{Memory Privilege in {\tt mstatus} Register}
-
-The MPRV (Modify PRiVilege) bit modifies the privilege level at which loads
-and stores execute in all privilege modes. When MPRV=0, loads and stores
-behave as normal, using the translation and protection mechanisms of the
-current privilege mode. When MPRV=1, load and store memory addresses are
-translated and protected as though the current privilege mode were set to MPP.
-Instruction address-translation and protection are unaffected by the setting
-of MPRV. MPRV is hardwired to 0 if U-mode is not supported.
-
-The MXR (Make eXecutable Readable) bit modifies the privilege with which loads
-access virtual memory. When MXR=0, only loads from pages marked readable (R=1
-in Figure~\ref{sv32pte}) will succeed. When MXR=1, loads from pages marked
-either readable or executable (R=1 or X=1) will succeed. MXR has no effect
-when page-based virtual memory is not in effect. MXR is hardwired to 0 if
-S-mode is not supported.
-
-\begin{commentary}
-The MPRV and MXR mechanisms were conceived to improve the efficiency of M-mode
-routines that emulate missing hardware features, e.g., misaligned loads and
-stores. MPRV obviates the need to perform address translation in software.
-MXR allows instruction words to be loaded from pages marked execute-only.
-
-For simplicity, MPRV and MXR are in effect regardless of privilege
-mode, but in normal use will only be enabled for short sequences in
-machine mode.
-
-The current privilege mode and the privilege mode specified by MPP might have
-different XLEN settings. When MPRV=1, load and store memory addresses are
-treated as though the current XLEN were set to MPP's XLEN, following the rules
-in Section~\ref{xlen-control}.
-\end{commentary}
-
-The SUM (permit Supervisor User Memory access) bit modifies the privilege with
-which S-mode loads and stores access virtual memory.
-When SUM=0, S-mode memory accesses to pages that are accessible by U-mode (U=1
-in Figure~\ref{sv32pte}) will fault. When SUM=1, these accesses are
-permitted. SUM has no effect when page-based virtual memory is not in effect.
-Note that, while SUM is ordinarily ignored when not executing in S-mode, it
-{\em is} in effect when MPRV=1 and MPP=S. SUM is hardwired to 0 if S-mode is
-not supported.
-
-\subsection{Virtualization Support in {\tt mstatus} Register}
-\label{virt-control}
-
-The TVM (Trap Virtual Memory) bit supports intercepting
-supervisor virtual-memory management operations. When TVM=1,
-attempts to read or write the {\tt satp} CSR or execute the SFENCE.VMA
-instruction while executing in S-mode will raise an illegal instruction
-exception. When TVM=0, these operations are permitted in S-mode.
-TVM is hard-wired to 0 when S-mode is not supported.
-
-\begin{commentary}
-The TVM mechanism improves virtualization efficiency by permitting guest
-operating systems to execute in S-mode, rather than classically virtualizing
-them in U-mode. This approach obviates the need to trap accesses to most
-S-mode CSRs.
-
-Trapping {\tt satp} accesses and the SFENCE.VMA instruction provides the
-hooks necessary to lazily populate shadow page tables.
-\end{commentary}
-
-The TW (Timeout Wait) bit supports intercepting the WFI instruction (see
-Section~\ref{wfi}). When TW=0, the WFI instruction is permitted in S-mode.
-When TW=1, if WFI is executed in S-mode, and it does not complete within an
-implementation-specific, bounded time limit, the WFI instruction causes an
-illegal instruction trap. The time limit may always be 0, in which case WFI
-always causes an illegal instruction trap in S-mode when TW=1.
-TW is hard-wired to 0 when S-mode is not supported.
-
-\begin{commentary}
-Trapping the WFI
-instruction can trigger a world switch to another guest OS, rather than
-wastefully idling in the current guest.
-\end{commentary}
-
-The TSR (Trap SRET) bit supports intercepting the supervisor exception return
-instruction, SRET. When TSR=1, attempts to execute SRET while executing in
-S-mode will raise an illegal instruction exception. When TSR=0, this
-operation is permitted in S-mode. TSR is hard-wired to 0 when S-mode is not
-supported.
-
-\begin{commentary}
-Trapping SRET is necessary to emulate the Augmented Virtualization mechanism
-(see Chapter~\ref{hypervisor}) on implementations that do not provide it.
-\end{commentary}
-
-\subsection{Extension Context Status in {\tt mstatus} Register}
-
-Supporting substantial extensions is one of the primary goals of
-RISC-V, and hence we define a standard interface to allow unchanged
-privileged-mode code, particularly a supervisor-level OS, to support
-arbitrary user-mode state extensions.
-
-\begin{commentary}
- To date, the V extension is the only standard extension that defines
- additional state beyond the floating-point CSR and data registers.
-\end{commentary}
-
-The FS[1:0] read/write field and the XS[1:0] read-only field are used
-to reduce the cost of context save and restore by setting and tracking
-the current state of the floating-point unit and any other user-mode
-extensions respectively. The FS field encodes the status of the
-floating-point unit, including the CSR {\tt fcsr} and floating-point
-data registers {\tt f0}--{\tt f31}, while the XS field encodes the
-status of additional user-mode extensions and associated state.
-These fields can be checked by a context switch routine to quickly
-determine whether a state save or restore is required. If a save or
-restore is required, additional instructions and CSRs are typically
-required to effect and optimize the process.
-
-\begin{commentary}
- The design anticipates that most context switches will not need to
- save/restore state in either or both of the floating-point unit or
- other extensions, so provides a fast check via the SD bit.
-\end{commentary}
-
-The FS and XS fields use the same status encoding as shown in
-Table~\ref{fsxsencoding}, with the four possible status values being
-Off, Initial, Clean, and Dirty.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|r|l|l|}
-\hline
-Status & FS Meaning & XS Meaning\\
-\hline
-0 & Off & All off \\
-1 & Initial & None dirty or clean, some on\\
-2 & Clean & None dirty, some clean \\
-3 & Dirty & Some dirty \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Encoding of FS[1:0] and XS[1:0] status fields.}
-\label{fsxsencoding}
-\end{table*}
-
-In systems that do not implement S-mode and do not have a
-floating-point unit, the FS field is hardwired to zero.
-
-In systems without additional user extensions requiring new state, the
-XS field is hardwired to zero. Every additional extension with state
-provides a CSR field that encodes the equivalent of the XS states.
-The XS field represents a summary of all
-extensions' status as shown in Table~\ref{fsxsencoding}.
-
-\begin{commentary}
-The XS field effectively reports the maximum status value across all
-user-extension status fields, though individual extensions can use a
-different encoding than XS.
-\end{commentary}
-
-The SD bit is a read-only bit that summarizes whether either the FS
-field or XS field signals the presence of some dirty state that will
-require saving extended user context to memory. If both XS and FS are
-hardwired to zero, then SD is also always zero.
-
-When an extension's status is set to Off, any instruction that
-attempts to read or write the corresponding state will cause an
-exception. When the status is Initial, the corresponding state should
-have an initial constant value. When the status is Clean, the
-corresponding state is potentially different from the initial value,
-but matches the last value stored on a context swap. When the status
-is Dirty, the corresponding state has potentially been modified since
-the last context save.
-
-During a context save, the responsible privileged code need only write
-out the corresponding state if its status is Dirty, and can then reset
-the extension's status to Clean. During a context restore, the
-context need only be loaded from memory if the status is Clean (it
-should never be Dirty at restore). If the status is Initial, the
-context must be set to an initial constant value on context restore to
-avoid a security hole, but this can be done without accessing memory.
-For example, the floating-point registers can all be initialized to
-the immediate value 0.
-
-The FS and XS fields are read by the privileged code before saving the
-context. The FS field is set directly by privileged code when
-resuming a user context, while the XS field is set indirectly by
-writing to the status register of the individual extensions. The
-status fields will also be updated during execution of instructions,
-regardless of privilege mode.
-
-Extensions to the user-mode ISA often include additional user-mode
-state, and this state can be considerably larger than the base integer
-registers. The extensions might only be used for some applications,
-or might only be needed for short phases within a single application.
-To improve performance, the user-mode extension can define additional
-instructions to allow user-mode software to return the unit to an
-initial state or even to turn off the unit.
-
-For example, a coprocessor might require to be configured before use
-and can be ``unconfigured'' after use. The unconfigured state would
-be represented as the Initial state for context save. If the same
-application remains running between the unconfigure and the next
-configure (which would set status to Dirty), there is no need to
-actually reinitialize the state at the unconfigure instruction, as all
-state is local to the user process, i.e., the Initial state may only
-cause the coprocessor state to be initialized to a constant value at
-context restore, not at every unconfigure.
-
-Executing a user-mode instruction to disable a unit and place it into
-the Off state will cause an illegal instruction exception to be raised
-if any subsequent instruction tries to use the unit before it is
-turned back on. A user-mode instruction to turn a unit on must also
-ensure the unit's state is properly initialized, as the unit might
-have been used by another context meantime.
-
-Changing the setting of FS has no effect on the contents of the floating-point
-register state. In particular, setting FS=Off does not destroy the state, nor
-does setting FS=Initial clear the contents. Other extensions might not
-preserve state when set to Off.
-
-Implementations may choose to track the dirtiness of the floating-point
-register state imprecisely by reporting the state to be dirty even when
-it has not been modified. On some implementations, some instructions that
-do not mutate the floating-point state may cause the state to transition from
-Initial or Clean to Dirty. On other implementations, dirtiness might not be
-tracked at all, in which case the valid FS states are Off and Dirty, and an
-attempt to set FS to Initial or Clean causes it to be set to Dirty.
-\begin{commentary}
-This definition of FS does not disallow setting FS to Dirty as a result of
-errant speculation. Some platforms may choose to disallow speculatively
-writing FS to close a potential side channel.
-\end{commentary}
-
-Table~\ref{fsxsstates} shows all the possible state transitions for
-the FS or XS status bits. Note that the standard floating-point
-extensions do not support user-mode unconfigure or disable/enable
-instructions.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|l|l|l|l|l|}
-\hline
-\multicolumn{1}{|r|}{Current State} & Off & Initial & Clean & Dirty \\
-Action & & & &\\
-\hline
-\hline
-\multicolumn{5}{|c|}{At context save in privileged code}\\
-\hline
-Save state? & No & No & No & Yes \\
-Next state & Off & Initial & Clean & Clean \\
-\hline
-\hline
-\multicolumn{5}{|c|}{At context restore in privileged code}\\
-\hline
-Restore state? & No & Yes, to initial & Yes, from memory & N/A \\
-Next state & Off & Initial & Clean & N/A \\
-\hline
-\hline
-\multicolumn{5}{|c|}{Execute instruction to read state}\\
-\hline
-Action? & Exception & Execute & Execute & Execute \\
-Next state & Off & Initial & Clean & Dirty \\
-\hline
-\hline
-\multicolumn{5}{|c|}{Execute instruction to modify state, including configuration}\\
-\hline
-Action? & Exception & Execute & Execute & Execute \\
-Next state & Off & Dirty & Dirty & Dirty \\
-\hline
-\hline
-\multicolumn{5}{|c|}{Execute instruction to unconfigure unit}\\
-\hline
-Action? & Exception & Execute & Execute & Execute \\
-Next state & Off & Initial & Initial & Initial \\
-\hline
-\hline
-\multicolumn{5}{|c|}{Execute instruction to disable unit}\\
-\hline
-Action? & Execute & Execute & Execute & Execute \\
-Next state & Off & Off & Off & Off \\
-\hline
-\hline
-\multicolumn{5}{|c|}{Execute instruction to enable unit}\\
-\hline
-Action? & Execute & Execute & Execute & Execute \\
-Next state & Initial & Initial & Initial & Initial \\
-\hline
-\end{tabular}
-\end{center}
-\caption{FS and XS state transitions.}
-\label{fsxsstates}
-\end{table*}
-
-Standard privileged instructions to initialize, save, and restore
-extension state are provided to insulate privileged code from details
-of the added extension state by treating the state as an opaque
-object.
-
-\begin{commentary}
-Many coprocessor extensions are only used in limited contexts that
-allows software to safely unconfigure or even disable units when done.
-This reduces the context-switch overhead of large stateful
-coprocessors.
-
-We separate out floating-point state from other extension state, as
-when a floating-point unit is present the floating-point registers are
-part of the standard calling convention, and so user-mode software
-cannot know when it is safe to disable the floating-point unit.
-\end{commentary}
-
-The XS field provides a summary of all added extension state, but
-additional microarchitectural bits might be maintained in the
-extension to further reduce context save and restore overhead.
-
-The SD bit is read-only and is set when either the FS or XS bits
-encode a Dirty state (i.e., SD=((FS==11) OR (XS==11))). This allows
-privileged code to quickly determine when no additional context save is
-required beyond the integer register set and PC.
-
-The floating-point unit state is always initialized, saved, and
-restored using standard instructions (F, D, and/or Q), and privileged
-code must be aware of FLEN to determine the appropriate space to
-reserve for each {\tt f} register.
-
-In a supervisor-level OS, any additional user-mode state should be
-initialized, saved, and restored using SBI calls that treats the
-additional context as an opaque object of a fixed maximum size. The
-implementation of the SBI initialize, save, and restore calls might
-require additional implementation-dependent privileged instructions to
-initialize, save, and restore microarchitectural state inside a
-coprocessor.
-
-All privileged modes share a single copy of the FS and XS bits. In a
-system with more than one privileged mode, supervisor mode would
-normally use the FS and XS bits directly to record the status with
-respect to the supervisor-level saved context. Other more-privileged
-active modes must be more conservative in saving and restoring the
-extension state in their corresponding version of the context.
-
-\begin{commentary}
-In any reasonable use case, the number of context switches between
-user and supervisor level should far outweigh the number of context
-switches to other privilege levels. Note that coprocessors should not
-require their context to be saved and restored to service asynchronous
-interrupts, unless the interrupt results in a user-level context swap.
-\end{commentary}
-
-\subsection{Machine Trap-Vector Base-Address Register ({\tt mtvec})}
-
-The {\tt mtvec} register is an MXLEN-bit read/write register that holds
-trap vector configuration, consisting of a vector base address (BASE) and a
-vector mode (MODE).
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{J@{}S}
-\instbitrange{MXLEN-1}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{BASE[MXLEN-1:2] (\warl)} &
-\multicolumn{1}{c|}{MODE (\warl)} \\
-\hline
-MXLEN-2 & 2 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine trap-vector base-address register ({\tt mtvec}).}
-\label{mtvecreg}
-\end{figure*}
-
-The {\tt mtvec} register must always be implemented, but can contain
-a hardwired read-only value. If {\tt mtvec} is writable, the set of values
-the register may hold can vary by implementation. The value in the BASE field
-must always be aligned on a 4-byte boundary, and the MODE setting may impose
-additional alignment constraints on the value in the BASE field.
-
-\begin{commentary}
-We allow for considerable flexibility in implementation of the trap
-vector base address. On the one hand, we do not wish to burden low-end
-implementations with a large number of state bits, but on the other
-hand, we wish to allow flexibility for larger systems.
-\end{commentary}
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|r|c|l|}
-\hline
-Value & Name & Description \\
-\hline
-0 & Direct & All exceptions set {\tt pc} to BASE. \\
-1 & Vectored & Asynchronous interrupts set {\tt pc} to BASE+4$\times$cause. \\
-$\ge$2 & --- & {\em Reserved} \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Encoding of {\tt mtvec} MODE field.}
-\label{mtvec-mode}
-\end{table*}
-
-The encoding of the MODE field is shown in Table~\ref{mtvec-mode}. When
-MODE=Direct, all traps into machine mode cause the {\tt pc} to be set to the
-address in the BASE field. When MODE=Vectored, all synchronous exceptions
-into machine mode cause the {\tt pc} to be set to the address in the BASE
-field, whereas interrupts cause the {\tt pc} to be set to the address in
-the BASE field plus four times the interrupt cause number. For example,
-a machine-mode timer interrupt (see Table~\ref{mcauses}) causes the {\tt pc}
-to be set to BASE+{\tt 0x1c}.
-
-\begin{commentary}
-When vectored interrupts are enabled, interrupt cause 0, which corresponds to
-user-mode software interrupts, are vectored to the same location as
-synchronous exceptions. This ambiguity does not arise in practice, since
-user-mode software interrupts are either disabled or delegated to
-a less-privileged mode.
-\end{commentary}
-
-An implementation may have different alignment constraints for
-different modes. In particular, MODE=Vectored may have stricter
-alignment constraints than MODE=Direct.
-
-\begin{commentary}
- Allowing coarser alignments in Vectored mode enables vectoring to be
- implemented without a hardware adder circuit.
-\end{commentary}
-
-\begin{commentary}
-Reset and NMI vector locations are given in a platform specification.
-\end{commentary}
-
-\subsection{Machine Trap Delegation Registers ({\tt medeleg} and {\tt mideleg})}
-
-By default, all traps at any privilege level are handled in machine
-mode, though a machine-mode handler can redirect traps back to the
-appropriate level with the MRET instruction (Section~\ref{otherpriv}).
-To increase performance, implementations can provide individual
-read/write bits within {\tt medeleg} and {\tt mideleg} to indicate
-that certain exceptions and interrupts should be processed directly by
-a lower privilege level. The machine exception delegation register
-({\tt medeleg}) and machine interrupt delegation register ({\tt
- mideleg}) are MXLEN-bit read/write registers.
-
-In systems with all three privilege modes (M/S/U), setting a bit in
-{\tt medeleg} or {\tt mideleg} will delegate the corresponding trap in
-S-mode or U-mode to the S-mode trap handler. If U-mode traps are
-supported, S-mode may in turn set corresponding bits in the {\tt
- sedeleg} and {\tt sideleg} registers to delegate traps that occur in
-U-mode to the U-mode trap handler.
-
-In systems with two privilege modes (M/U) and support for U-mode
-traps, setting a bit in {\tt medeleg} or {\tt mideleg} will
-delegate the corresponding trap in U-mode to the U-mode trap handler.
-
-In systems with only M-mode, or with both M-mode and U-mode but
-without U-mode trap support, the {\tt medeleg} and {\tt mideleg}
-registers should not exist.
-\begin{commentary}
- In versions 1.9.1 and earlier , these registers existed but were
- hardwired to zero in M-mode only, or M/U without N systems. There
- is no reason to require they return zero in those cases, as the {\tt
- misa} register indicates whether they exist.
-\end{commentary}
-
-
-When a trap is delegated to a less-privileged mode {\em x}, the
-{\em x}\,{\tt cause} register is written with the trap cause; the
-{\em x}\,{\tt epc} register is written with the virtual address of
-the instruction that took the trap; the
-{\em x}\,{\tt tval} register is written with an
-exception-specific datum; the {\em x}\,PP field
-of {\tt mstatus} is written with the active privilege mode at the time of
-the trap; the {\em x}\,PIE field of {\tt mstatus} is written with the
-value of the {\em x}\,IE field at the time of the trap; and
-the {\em x}\,IE field of {\tt mstatus} is cleared. The {\tt mcause} and
-{\tt mepc} registers and the MPP and MPIE fields of {\tt mstatus} are
-not written.
-
-An implementation shall not hardwire any delegation bits to one, i.e.,
-any trap that can be delegated must support not being delegated. An
-implementation can choose to subset the delegatable traps, with the
-supported delegatable bits found by writing one to every bit location,
-then reading back the value in {\tt medeleg} or {\tt mideleg} to see
-which bit positions hold a one.
-
-Traps never transition from a more-privileged mode to a less-privileged mode.
-For example, if M-mode has delegated illegal instruction exceptions to S-mode, and
-M-mode software later executes an illegal instruction, the trap is taken in
-M-mode, rather than being delegated to S-mode. By contrast, traps may be
-taken horizontally. Using the same example, if M-mode has delegated illegal
-instruction exceptions to S-mode, and S-mode software later executes an illegal
-instruction, the trap is taken in S-mode.
-
-Delegated interrupts result in the interrupt being masked at the delegator
-privilege level. For example, if the supervisor timer interrupt (STI) is
-delegated to S-mode by setting {\tt mideleg}[5], STIs will not be taken when
-executing in M-mode. By contrast, if {\tt mideleg}[5] is clear, STIs can
-be taken in any mode and regardless of current mode will transfer control to
-M-mode.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}U}
-\instbitrange{MXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{Synchronous Exceptions (\warl)} \\
-\hline
-MXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine Exception Delegation Register {\tt medeleg}.}
-\label{medelegreg}
-\end{figure}
-
-{\tt medeleg} has a bit position allocated for every synchronous exception
-shown in Table~\ref{mcauses}, with the index of the bit position equal to the
-value returned in the {\tt mcause} register (i.e., setting bit 8 allows
-user-mode environment calls to be delegated to a lower-privilege trap
-handler).
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}U}
-\instbitrange{MXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{Interrupts (\warl)} \\
-\hline
-MXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine Interrupt Delegation Register {\tt mideleg}.}
-\label{midelegreg}
-\end{figure}
-
-{\tt mideleg} holds trap delegation bits for individual interrupts, with the
-layout of bits matching those in the {\tt mip} register (i.e., STIP interrupt
-delegation control is located in bit 5).
-
-Some exceptions cannot occur at less privileged modes, and corresponding
-{\em x}\,{\tt edeleg} bits should be hardwired to zero. In particular,
-{\tt medeleg}[11] and {\tt sedeleg}[11:9] are all hardwired to zero.
-
-\subsection{Machine Interrupt Registers ({\tt mip} and {\tt mie})}
-
-The {\tt mip} register is an MXLEN-bit read/write register containing
-information on pending interrupts, while {\tt mie} is the
-corresponding MXLEN-bit read/write register containing interrupt enable
-bits. Only the bits corresponding to lower-privilege software
-interrupts (USIP, SSIP), timer interrupts (UTIP, STIP),
-and external interrupts (UEIP, SEIP) in {\tt mip}
-are writable through this CSR address; the remaining bits are
-read-only.
-
-\begin{commentary}
- The machine-level interrupt registers handle a few root interrupt
- sources which are assigned a fixed service priority for simplicity,
- while separate external interrupt controllers can implement a more
- complex prioritization scheme over a much larger set of interrupts
- that are then muxed into the machine-level interrupt sources.
-\end{commentary}
-
-Restricted views of the {\tt mip} and {\tt mie} registers appear as
-the {\tt sip}/{\tt sie}, and {\tt uip}/{\tt uie} registers in
-S-mode and U-mode respectively. If an interrupt is delegated to
-privilege mode {\em x} by setting a bit in the {\tt mideleg} register,
-it becomes visible in the {\em x}\,{\tt ip} register and is maskable
-using the {\em x}\,{\tt ie} register. Otherwise, the corresponding
-bits in {\em x}\,{\tt ip} and {\em x}\,{\tt ie} appear to be hardwired
-to zero.
-
-\begin{figure*}[h!]
-{\scriptsize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{Rccccccccccccc}
-\instbitrange{MXLEN-1}{16} &
-\instbitrange{15}{12} &
-\instbit{11} &
-\instbit{10} &
-\instbit{9} &
-\instbit{8} &
-\instbit{7} &
-\instbit{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{\em Res. Custom} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{MEIP} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SEIP} &
-\multicolumn{1}{c|}{UEIP} &
-\multicolumn{1}{c|}{MTIP} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{STIP} &
-\multicolumn{1}{c|}{UTIP} &
-\multicolumn{1}{c|}{MSIP} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SSIP} &
-\multicolumn{1}{c|}{USIP} \\
-\hline
-MXLEN-16 & 4 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine interrupt-pending register ({\tt mip}).}
-\label{mipreg}
-\end{figure*}
-
-\begin{figure*}[h!]
-{\scriptsize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{Rccccccccccccc}
-\instbitrange{MXLEN-1}{16} &
-\instbitrange{15}{12} &
-\instbit{11} &
-\instbit{10} &
-\instbit{9} &
-\instbit{8} &
-\instbit{7} &
-\instbit{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{\em Res. Custom} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{MEIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SEIE} &
-\multicolumn{1}{c|}{UEIE} &
-\multicolumn{1}{c|}{MTIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{STIE} &
-\multicolumn{1}{c|}{UTIE} &
-\multicolumn{1}{c|}{MSIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SSIE} &
-\multicolumn{1}{c|}{USIE} \\
-\hline
-MXLEN-16 & 4 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine interrupt-enable register ({\tt mie}).}
-\label{miereg}
-\end{figure*}
-
-The MTIP, STIP, UTIP bits correspond to timer interrupt-pending bits
-for machine, supervisor, and user timer interrupts, respectively. The
-MTIP bit is read-only and is cleared by writing to the memory-mapped
-machine-mode timer compare register. The UTIP and STIP bits may be
-written by M-mode software to deliver timer interrupts to lower
-privilege levels. User and supervisor software may clear the UTIP and
-STIP bits with calls to the AEE and SEE respectively.
-
-There is a separate timer interrupt-enable bit, named MTIE, STIE, and
-UTIE for M-mode, S-mode, and U-mode timer interrupts respectively.
-
-Each lower privilege level has a separate software interrupt-pending
-bit (SSIP, USIP), which can be both read and written by CSR accesses
-from code running on the local hart at the associated or any higher
-privilege level. The machine-level MSIP bits are written by accesses
-to memory-mapped control registers, which are used by remote harts to
-provide machine-mode interprocessor interrupts. Interprocessor
-interrupts for lower privilege levels are implemented through ABI and
-SBI calls to the AEE or SEE respectively, which might ultimately
-result in a machine-mode write to the receiving hart's MSIP bit. A
-hart can write its own MSIP bit using the same memory-mapped control
-register.
-
-The MSIE, SSIE, and USIE fields in the {\tt mie} CSR enable M-mode software
-interrupts, S-mode software interrupts, and U-mode software interrupts,
-respectively.
-
-\begin{commentary}
-We only allow a hart to directly write its own SSIP or USIP
-bits when running in the appropriate mode, as other harts might be
-virtualized and possibly descheduled by higher privilege levels. We
-rely on ABI and SBI calls to provide interprocessor interrupts
-for this reason. Machine-mode harts are not virtualized and can
-directly interrupt other harts by setting their MSIP bits, typically
-using uncached I/O writes to memory-mapped control registers depending
-on the platform specification.
-\end{commentary}
-
-The MEIP field in {\tt mip} is a read-only bit that indicates a machine-mode
-external interrupt is pending. MEIP is set and cleared by a platform-specific
-interrupt controller, such as the standard platform-level interrupt controller
-specified in Chapter~\ref{plic}. The MEIE field in {\tt mie} enables machine
-external interrupts when set.
-
-The SEIP field in {\tt mip} contains a single read-write bit. SEIP
-may be written by M-mode software to indicate to S-mode that an
-external interrupt is pending. Additionally, the platform-level
-interrupt controller may generate supervisor-level external interrupts. The
-logical-OR of the software-writable bit and the signal from the
-external interrupt controller is used to generate external interrupts
-to the supervisor. When the SEIP bit is read with a CSRRW, CSRRS, or
-CSRRC instruction, the value returned in the {\tt rd} destination
-register contains the logical-OR of the software-writable bit and the
-interrupt signal from the interrupt controller. However, the value
-used in the read-modify-write sequence of a CSRRS or CSRRC instruction
-is only the software-writable SEIP bit, ignoring the interrupt value
-from the external interrupt controller.
-
-\begin{commentary}
- The SEIP field behavior is designed to allow a higher privilege
- layer to mimic external interrupts cleanly, without losing any real
- external interrupts. The behavior of the CSR instructions is
- slightly modified from regular CSR accesses as a result.
-\end{commentary}
-
-The UEIP field in {\tt mip} provides user-mode external interrupts when the
-N extension for user-mode interrupts is implemented. It is defined
-analogously to SEIP.
-
-The MEIE, SEIE, and UEIE fields in the {\tt mie} CSR enable M-mode external
-interrupts, S-mode external interrupts, and U-mode external interrupts,
-respectively.
-
-\begin{commentary}
-The non-maskable interrupt is not made visible via the {\tt mip}
-register as its presence is implicitly known when executing the NMI
-trap handler.
-\end{commentary}
-
-For all the various interrupt types (software, timer, and external),
-if a privilege level is not supported, or if U-mode is supported but
-the N extension is not supported, than the associated pending and
-interrupt-enable bits are hardwired to zero in the {\tt mip} and {\tt
- mie} registers respectively. Hence, these are all effectively
-\warl\ fields.
-
-Implementations may add additional custom machine-level interrupt sources to
-bits 16 and above of the {\tt mip} and {\tt mie} registers. The other
-unallocated interrupt sources (15--12, 10, 6, and 2) are reserved for future
-standard use. The corresponding fields are all \wpri.
-
-An interrupt {\em i} will be taken if bit {\em i} is set in both {\tt
- mip} and {\tt mie}, and if interrupts are globally enabled. By
-default, M-mode interrupts are globally enabled if the hart's current
-privilege mode is less than M, or if the current privilege mode is M
-and the MIE bit in the {\tt mstatus} register is set. If bit {\em i}
-in {\tt mideleg} is set, however, interrupts are considered to be
-globally enabled if the hart's current privilege mode equals the
-delegated privilege mode (S or U) and that mode's interrupt enable
-bit (SIE or UIE in {\tt mstatus}) is set, or if the current
-privilege mode is less than the delegated privilege mode.
-
-Multiple simultaneous interrupts destined for different privilege modes are
-handled in decreasing order of destined privilege mode. Multiple simultaneous
-interrupts destined for the same privilege mode are handled in the following
-decreasing priority order: MEI, MSI, MTI, SEI, SSI, STI, UEI, USI, UTI.
-Synchronous exceptions are of lower priority than all interrupts.
-
-\begin{commentary}
- The machine-level interrupt fixed-priority ordering rules were developed
- with the following rationale.
-
- Interrupts for higher privilege modes must be serviced before
- interrupts for lower privilege modes to support preemption.
-
- The platform-specific machine-level interrupt sources in bits 16 and above
- have platform-specific priority, but are typically chosen to have the
- highest service priority to support very fast local vectored interrupts.
-
- External interrupts are handled before internal (timer/software)
- interrupts as external interrupts are usually generated by devices
- that might require low interrupt service times.
-
- Software interrupts are handled before internal timer interrupts,
- because internal timer interrupts are usually intended for time
- slicing, where time precision is less important, whereas software
- interrupts are used for inter-processor messaging. Software
- interrupts can be avoided when high-precision timing is required, or
- high-precision timer interrupts can be routed via a different
- interrupt path.
- Software interrupts are located in the lowest four bits of {\tt mip}
- as these are often written by software, and this position allows the
- use of a single CSR instruction with a five-bit immediate.
-
- Synchronous exceptions are given the lowest priority to minimize
- worst-case interrupt latency.
-\end{commentary}
-
-\subsection{Machine Timer Registers ({\tt mtime} and {\tt mtimecmp})}
-
-Platforms provide a real-time counter, exposed as a memory-mapped
-machine-mode register, {\tt mtime}. {\tt mtime} must run at constant
-frequency, and the platform must provide a mechanism for determining
-the timebase of {\tt mtime}.
-
-The {\tt mtime} register has a 64-bit precision on all RV32, RV64, and
-RV128 systems. Platforms provide a 64-bit memory-mapped machine-mode
-timer compare register ({\tt mtimecmp}), which causes a timer
-interrupt to be posted when the {\tt mtime} register contains a value
-greater than or equal to the value in the {\tt mtimecmp} register.
-The interrupt remains posted until it is cleared by writing the {\tt
- mtimecmp} register. The interrupt will only be taken if interrupts
-are enabled and the MTIE bit is set in the {\tt mie} register.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{63}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt mtime} \\
-\hline
-64 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine time register (memory-mapped control register).}
-\end{figure}
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{63}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt mtimecmp} \\
-\hline
-64 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine time compare register (memory-mapped control register).}
-\end{figure}
-
-\begin{commentary}
-The timer facility is defined to use wall-clock time rather than a
-cycle counter to support modern processors that run with a highly
-variable clock frequency to save energy through dynamic voltage and
-frequency scaling.
-
-Accurate real-time clocks (RTCs) are relatively expensive to provide
-(requiring a crystal or MEMS oscillator) and have to run even when the
-rest of system is powered down, and so there is usually only one in a
-system located in a different frequency/voltage domain from the
-processors. Hence, the RTC must be shared by all the harts in a
-system and accesses to the RTC will potentially incur the penalty of a
-voltage-level-shifter and clock-domain crossing. It is thus more
-natural to expose {\tt mtime} as a memory-mapped register than as a CSR.
-
-Lower privilege levels do not have their own {\tt timecmp} registers.
-Instead, machine-mode software can implement any number of virtual timers on
-a hart by multiplexing the next timer interrupt into the {\tt mtimecmp}
-register.
-
-Simple fixed-frequency systems can use a single clock for both cycle
-counting and wall-clock time.
-\end{commentary}
-
-Writes to {\tt mtime} and {\tt mtimecmp} are guaranteed to be reflected in
-MTIP eventually, but not necessarily immediately.
-
-\begin{commentary}
-A spurious timer interrupt might occur if an interrupt handler increments {\tt
-mtimecmp} then immediately returns, because MTIP might not yet have fallen in
-the interim. All software should be written to assume this event is possible,
-but most software should assume this event is extremely unlikely. It is
-almost always more performant to incur an occasional spurious timer interrupt
-than to poll MTIP until it falls.
-\end{commentary}
-
-In RV32, memory-mapped writes to {\tt mtimecmp} modify only one 32-bit
-part of the register. The following code sequence sets a 64-bit {\tt
- mtimecmp} value without spuriously generating a timer interrupt due
-to the intermediate value of the comparand:
-
-\begin{figure}[h!]
-\begin{center}
-\begin{verbatim}
- # New comparand is in a1:a0.
- li t0, -1
- sw t0, mtimecmp # No smaller than old value.
- sw a1, mtimecmp+4 # No smaller than new value.
- sw a0, mtimecmp # New value.
-\end{verbatim}
-\end{center}
-\caption{Sample code for setting the 64-bit time comparand in RV32
- assuming the registers live in a strongly ordered I/O region.}
-\label{mtimecmph}
-\end{figure}
-
-\subsection{Hardware Performance Monitor}
-
-M-mode includes a basic hardware performance-monitoring facility. The
-{\tt mcycle} CSR counts the number of clock cycles executed by the
-processor core on which the hart is running.
-The {\tt minstret} CSR counts the number of instructions the hart has
-retired. The {\tt mcycle} and {\tt minstret} registers have 64-bit
-precision on all RV32, RV64, and RV128 systems.
-
-The counter registers have an arbitrary value after system reset, and
-can be written with a given value. Any CSR write takes effect after
-the writing instruction has otherwise completed.
-
-The hardware performance monitor includes 29 additional 64-bit event counters, {\tt
-mhpmcounter3}--{\tt mhpmcounter31}. The event selector CSRs, {\tt
-mhpmevent3}--{\tt mhpmevent31}, are MXLEN-bit \warl\ registers that control which event
-causes the corresponding counter to increment. The meaning of these events is
-defined by the platform, but event 0 is defined to mean ``no event.''
-All counters should be implemented, but a legal implementation is to hard-wire
-both the counter and its corresponding event selector to 0.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}K@{}W@{}K}
-\instbitrange{63}{0} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\tt mcycle} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\tt minstret} \\ \cline{1-1}
- & & \instbitrange{MXLEN-1}{0} \\ \cline{1-1}\cline{3-3}
-\multicolumn{1}{|c|}{\tt mhpmcounter3} & & \multicolumn{1}{|c|}{\tt mhpmevent3} \\ \cline{1-1}\cline{3-3}
-\multicolumn{1}{|c|}{\tt mhpmcounter4} & & \multicolumn{1}{|c|}{\tt mhpmevent4} \\ \cline{1-1}\cline{3-3}
-\multicolumn{1}{c}{\vdots} & & \multicolumn{1}{c}{\vdots} \\ \cline{1-1}\cline{3-3}
-\multicolumn{1}{|c|}{\tt mhpmcounter30} & & \multicolumn{1}{|c|}{\tt mhpmevent30} \\ \cline{1-1}\cline{3-3}
-\multicolumn{1}{|c|}{\tt mhpmcounter31} & & \multicolumn{1}{|c|}{\tt mhpmevent31} \\ \cline{1-1}\cline{3-3}
-64 & & MXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Hardware performance monitor counters.}
-\end{figure}
-
-All of these counters have 64-bit precision on RV32, RV64, and RV128.
-
-On RV32 only, reads of the {\tt mcycle}, {\tt minstret}, and {\tt
-mhpmcounter{\em n}} CSRs return the low 32 bits, while reads of the {\tt
-mcycleh}, {\tt minstreth}, and {\tt mhpmcounter{\em n}h} CSRs return bits
-63--32 of the corresponding counter.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}K}
-\instbitrange{31}{0} \\ \hline
-\multicolumn{1}{|c|}{\tt mcycleh} \\ \hline
-\multicolumn{1}{|c|}{\tt minstreth} \\ \hline
-\multicolumn{1}{|c|}{\tt mhpmcounter3h} \\ \hline
-\multicolumn{1}{|c|}{\tt mhpmcounter4h} \\ \hline
-\multicolumn{1}{c}{\vdots} \\ \hline
-\multicolumn{1}{|c|}{\tt mhpmcounter30h} \\ \hline
-\multicolumn{1}{|c|}{\tt mhpmcounter31h} \\ \hline
-32 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Upper 32 bits of hardware performance monitor counters, RV32 only.}
-\end{figure}
-
-On RV128 systems, the 64-bit values in {\tt mcycle}, {\tt minstret}, and
-{\tt mhpmcounter{\em n}} are sign-extended to 128-bits when read.
-\begin{samepage-commentary}
-On RV128 systems, both signed and unsigned 64-bit values are held in a
-canonical form with bit 63 repeated in all higher bit positions. The
-counters are 64-bit values even in RV128, and so the counter CSR reads
-preserve the sign-extension invariant. Implementations may choose to
-implement fewer bits of the counters, provided software would be unlikely
-to experience wraparound (e.g., $2^{63}$ instructions executed)
-and thereby avoid having to actually implement the sign-extension
-circuitry.
-\end{samepage-commentary}
-
-\subsection{Counter-Enable Registers ({\tt [m|s]counteren})}
-\label{sec:mcounteren}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{cccMcccccc}
-\instbit{31} &
-\instbit{30} &
-\instbit{29} &
-\instbitrange{28}{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{HPM31} &
-\multicolumn{1}{c|}{HPM30} &
-\multicolumn{1}{c|}{HPM29} &
-\multicolumn{1}{c|}{...} &
-\multicolumn{1}{c|}{HPM5} &
-\multicolumn{1}{c|}{HPM4} &
-\multicolumn{1}{c|}{HPM3} &
-\multicolumn{1}{c|}{IR} &
-\multicolumn{1}{c|}{TM} &
-\multicolumn{1}{c|}{CY} \\
-\hline
-1 & 1 & 1 & 23 & 1 & 1 & 1 & 1 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Counter-enable registers ({\tt mcounteren} and {\tt scounteren}).}
-\label{mcounteren}
-\end{figure*}
-
-The counter-enable registers {\tt mcounteren} and {\tt scounteren}
-are 32-bit registers that
-control the availability of the hardware performance-monitoring
-counters to the next-lowest privileged mode.
-
-The settings in these registers only control accessibility. The act
-of reading or writing these registers does not affect the underlying
-counters, which continue to increment even when not accessible.
-
-When the CY, TM, IR, or HPM{\em n} bit in the {\tt mcounteren}
-register is clear, attempts to read the {\tt cycle}, {\tt time}, {\tt
- instret}, or {\tt hpmcounter{\em n}} register while executing in
-S-mode or U-mode will cause an illegal instruction exception. When
-one of these bits is set, access to the corresponding register is
-permitted in the next implemented privilege mode (S-mode if
-implemented, otherwise U-mode).
-
-If S-mode is implemented, the same bit positions in the {\tt scounteren}
-register analogously control access to these registers while executing
-in U-mode. If S-mode is permitted to access a counter register and the
-corresponding bit is set in {\tt scounteren}, then U-mode is also permitted
-to access that register.
-
-Registers {\tt mcounteren} and {\tt scounteren} are \warl\ registers
-that must be implemented if U-mode and S-mode are implemented,
-Any of the bits may contain
-a hardwired value of zero, indicating reads to the corresponding counter will
-cause an exception when executing in a less-privileged mode.
-\begin{commentary}
-The counter-enable bits support two common use cases with minimal hardware.
-For systems that do not need high-performance timers and counters,
-machine-mode software can trap accesses and implement all features in
-software. For systems that need high-performance timers and counters
-but are not concerned with obfuscating the underlying hardware
-counters, the counters can be directly exposed to lower privilege modes.
-\end{commentary}
-
-The {\tt cycle}, {\tt instret}, and {\tt hpmcounter{\em n}} CSRs are
-read-only shadows of {\tt mcycle}, {\tt minstret}, and {\tt mhpmcounter{\em
-n}}, respectively. The {\tt time} CSR is a read-only shadow of the
-memory-mapped {\tt mtime} register.
-\begin{commentary}
-Implementations can convert reads of the {\tt time} CSR into loads to
-the memory-mapped {\tt mtime} register, or hard-wire the TM bit in
-{\tt mcounteren} to 0
-and emulate this functionality in M-mode software.
-\end{commentary}
-
-\subsection{Machine Counter-Inhibit CSR ({\tt mcountinhibit})}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{cccMcccccc}
-\instbit{31} &
-\instbit{30} &
-\instbit{29} &
-\instbitrange{28}{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{HPM31} &
-\multicolumn{1}{c|}{HPM30} &
-\multicolumn{1}{c|}{HPM29} &
-\multicolumn{1}{c|}{...} &
-\multicolumn{1}{c|}{HPM5} &
-\multicolumn{1}{c|}{HPM4} &
-\multicolumn{1}{c|}{HPM3} &
-\multicolumn{1}{c|}{IR} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{1}{c|}{CY} \\
-\hline
-1 & 1 & 1 & 23 & 1 & 1 & 1 & 1 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Counter-inhibit register {\tt mcountinhibit}.}
-\label{mcountinhibit}
-\end{figure*}
-
-The counter-inhibit register {\tt mcountinhibit} is a 32-bit \warl\ register
-that controls which of the hardware performance-monitoring counters increment.
-The settings in this register only control whether the counters increment;
-their accessibility is not affected by the setting of this register.
-
-When the CY, IR, or HPM{\em n} bit in the {\tt mcountinhibit} register is
-clear, the {\tt cycle}, {\tt instret}, or {\tt hpmcounter{\em n}} register
-increments as usual. When the CY, IR, or HPM{\em n} bit is set, the
-corresponding counter does not increment.
-
-If the {\tt mcountinhibit} register is not implemented, the implementation
-behaves as though the register were set to zero.
-
-\begin{commentary}
-When the {\tt cycle} and {\tt instret} counters are not needed, it is
-desirable to conditionally inhibit them to reduce energy consumption.
-Providing a single CSR to inhibit all counters also allows the counters to be
-atomically sampled.
-
-As all the harts on a processor core share a {\tt cycle} counter,
-so they share an {\tt mcountinhibit}.CY bit.
-
-Because the {\tt time} counter can be shared between multiple cores, it
-cannot be inhibited with the {\tt mcountinhibit} mechanism.
-\end{commentary}
-
-\subsection{Machine Scratch Register ({\tt mscratch})}
-
-The {\tt mscratch} register is an MXLEN-bit read/write register
-dedicated for use by machine mode. Typically, it is used to hold a
-pointer to a machine-mode hart-local context space and swapped with a
-user register upon entry to an M-mode trap handler.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{MXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt mscratch} \\
-\hline
-MXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine-mode scratch register.}
-\label{mscratchreg}
-\end{figure}
-
-\begin{commentary}
-The MIPS ISA allocated two user registers ({\tt k0}/{\tt k1}) for use
-by the operating system. Although the MIPS scheme provides a fast and
-simple implementation, it also reduces available user registers, and
-does not scale to further privilege levels, or nested traps. It can
-also require both registers are cleared before returning to user level
-to avoid a potential security hole and to provide deterministic
-debugging behavior.
-
-The RISC-V user ISA was designed to support many possible privileged
-system environments and so we did not want to infect the user-level
-ISA with any OS-dependent features. The RISC-V CSR swap instructions
-can quickly save/restore values to the {\tt mscratch} register.
-Unlike the MIPS design, the OS can rely on holding a value in the {\tt
- mscratch} register while the user context is running.
-\end{commentary}
-
-\subsection{Machine Exception Program Counter ({\tt mepc})}
-
-{\tt mepc} is an MXLEN-bit read/write register formatted as shown in
-Figure~\ref{mepcreg}. The low bit of {\tt mepc} ({\tt mepc[0]}) is
-always zero. On implementations that support only IALIGN=32, the two low bits
-({\tt mepc[1:0]}) are always zero.
-
-If an implementation allows IALIGN to be either 16 or 32 (by
-changing CSR {\tt misa}, for example), then, whenever IALIGN=32, bit
-{\tt mepc[1]} is masked on reads so that it appears to be 0. This
-masking occurs also for the implicit read by the MRET instruction.
-Though masked, {\tt mepc[1]} remains writable when IALIGN=32.
-
-{\tt mepc} is a \warl\ register that must be able to hold all valid physical
-and virtual addresses. It need not be capable of holding all possible invalid
-addresses. Implementations may convert some invalid address patterns into
-other invalid addresses prior to writing them to {\tt mepc}.
-
-When a trap is taken into M-mode, {\tt mepc} is written with the
-virtual address of the instruction that was interrupted or that
-encountered the exception. Otherwise, {\tt mepc} is never written by
-the implementation, though it may be explicitly written by software.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{MXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt mepc} \\
-\hline
-MXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine exception program counter register.}
-\label{mepcreg}
-\end{figure}
-
-\subsection{Machine Cause Register ({\tt mcause})}
-
-The {\tt mcause} register is an MXLEN-bit read-write register formatted as
-shown in Figure~\ref{mcausereg}. When a trap is taken into M-mode, {\tt
-mcause} is written with a code indicating the event that caused the trap.
-Otherwise, {\tt mcause} is never written by the implementation, though it may be
-explicitly written by software.
-
-The Interrupt bit in the {\tt mcause} register is set if the
-trap was caused by an interrupt. The Exception Code field
- contains a code identifying the last exception. Table~\ref{mcauses}
-lists the possible machine-level exception codes. The Exception Code
-is an \wlrl\ field, so is only guaranteed to hold supported exception
-codes.
-
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{c@{}U}
-\instbit{MXLEN-1} &
-\instbitrange{MXLEN-2}{0} \\
-\hline
-\multicolumn{1}{|c|}{Interrupt} &
-\multicolumn{1}{c|}{Exception Code (\wlrl)} \\
-\hline
-1 & MXLEN-1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine Cause register {\tt mcause}.}
-\label{mcausereg}
-\end{figure*}
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|r|r|l|l|}
-
- \hline
- Interrupt & Exception Code & Description \\
- \hline
- 1 & 0 & User software interrupt \\
- 1 & 1 & Supervisor software interrupt \\
- 1 & 2 & {\em Reserved} \\
- 1 & 3 & Machine software interrupt \\ \hline
- 1 & 4 & User timer interrupt \\
- 1 & 5 & Supervisor timer interrupt \\
- 1 & 6 & {\em Reserved} \\
- 1 & 7 & Machine timer interrupt \\ \hline
- 1 & 8 & User external interrupt \\
- 1 & 9 & Supervisor external interrupt \\
- 1 & 10 & {\em Reserved} \\
- 1 & 11 & Machine external interrupt \\ \hline
- 1 & $\ge$12 & {\em Reserved} \\ \hline
- 0 & 0 & Instruction address misaligned \\
- 0 & 1 & Instruction access fault \\
- 0 & 2 & Illegal instruction \\
- 0 & 3 & Breakpoint \\
- 0 & 4 & Load address misaligned \\
- 0 & 5 & Load access fault \\
- 0 & 6 & Store/AMO address misaligned \\
- 0 & 7 & Store/AMO access fault \\
- 0 & 8 & Environment call from U-mode\\
- 0 & 9 & Environment call from S-mode \\
- 0 & 10 & {\em Reserved} \\
- 0 & 11 & Environment call from M-mode \\
- 0 & 12 & Instruction page fault \\
- 0 & 13 & Load page fault \\
- 0 & 14 & {\em Reserved} \\
- 0 & 15 & Store/AMO page fault \\
- 0 & $\ge$16 & {\em Reserved} \\
- \hline
-
-\end{tabular}
-\end{center}
-\caption{Machine cause register ({\tt mcause}) values after trap.}
-\label{mcauses}
-\end{table*}
-
-\begin{commentary}
-We do not distinguish privileged instruction exceptions from illegal
-opcode exceptions. This simplifies the architecture and also hides
-details of which higher-privilege instructions are supported by an
-implementation. The privilege level servicing the trap can implement
-a policy on whether these need to be distinguished, and if so, whether
-a given opcode should be treated as illegal or privileged.
-\end{commentary}
-
-\begin{commentary}
-Interrupts can be separated from other traps with a single branch on the sign of
-the {\tt mcause} register value. A shift left can remove the
-interrupt bit and scale the exception codes to index into a trap
-vector table.
-\end{commentary}
-
-\subsection{Machine Trap Value ({\tt mtval}) Register}
-
-The {\tt mtval} register is an MXLEN-bit read-write register formatted as shown
-in Figure~\ref{mtvalreg}. When a trap is taken into M-mode, {\tt mtval} is
-either set to zero or written with exception-specific information to assist
-software in handling the trap. Otherwise, {\tt mtval} is never written by the
-implementation, though it may be explicitly written by software. The hardware
-platform will specify which exceptions must set {\tt mtval} informatively and
-which may unconditionally set it to zero.
-
-When a hardware breakpoint is triggered, or an instruction-fetch, load, or
-store address-misaligned, access, or page-fault exception occurs, {\tt
- mtval} is written with the faulting virtual address. On an illegal
-instruction trap, {\tt mtval} may be written with the first XLEN or ILEN
-bits of the faulting instruction as described below. For other traps,
-{\tt mtval} is set to zero, but a future standard may redefine {\tt
- mtval}'s setting for other traps.
-
-\begin{commentary}
- The {\tt mtval} register replaces the {\tt mbadaddr} register in
- the previous specification. In addition to providing bad addresses,
- the register can now provide the bad instruction that triggered an
- illegal instruction trap (and may in future be used to return other
- information). Returning the instruction bits accelerates instruction emulation and also
- removes some races that might be present when trying to emulate
- illegal instructions.
-\end{commentary}
-\begin{commentary}
- When page-based virtual memory is enabled, {\tt mtval} is written with
- the faulting virtual address, even for physical-memory access exceptions.
- This design reduces datapath cost for most implementations, particularly
- those with hardware page-table walkers.
-\end{commentary}
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{MXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt mtval} \\
-\hline
-MXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Machine Trap Value register.}
-\label{mtvalreg}
-\end{figure}
-
-For misaligned loads and stores that cause access or page-fault exceptions,
-{\tt mtval} will contain the virtual address of the portion of the access that
-caused the fault. For instruction-fetch access or page-fault exceptions on
-systems with variable-length instructions, {\tt mtval} will contain the
-virtual address of the portion of the instruction that caused the fault while
-{\tt mepc} will point to the beginning of the instruction.
-
-The {\tt mtval} register can optionally also be used to return the
-faulting instruction bits on an illegal instruction exception ({\tt
- mepc} points to the faulting instruction in memory).
-
-If this feature is not provided, then {\tt mtval} is set to zero on
-an illegal instruction fault.
-
-If this feature is provided, after an illegal instruction trap, {\tt mtval}
-will contain the shortest of:
-\begin{compactitem}
-\item the actual faulting instruction
-\item the first ILEN bits of the faulting instruction
-\item the first XLEN bits of the faulting instruction
-\end{compactitem}
-The value loaded into {\tt mtval} is right-justified and all unused upper
-bits are cleared to zero.
-
-\begin{commentary}
- Capturing the faulting instruction in {\tt mtval} reduces the
- overhead of instruction emulation, potentially avoiding several
- partial instruction loads if the instruction is misaligned, and
- likely data cache misses or slow uncached accesses when loads are
- used to fetch the instruction into a data register. There is also a
- problem of atomicity if another agent is manipulating the
- instruction memory, as might occur in a dynamic translation system.
-
- A requirement is that the entire instruction (or at least the first
- XLEN bits) are fetched into {\tt mtval} before taking the trap.
- This should not constrain implementations, which would typically
- fetch the entire instruction before attempting to decode the
- instruction, and avoids complicating software handlers.
-
- A value of zero in {\tt mtval} signifies either that the feature is
- not supported, or an illegal zero instruction was fetched. A load
- from the instruction memory pointed to by {\tt mepc} can be used to
- distinguish these two cases (or alternatively, the system
- configuration information can be interrogated to install the
- appropriate trap handling before runtime).
-\end{commentary}
-
-If the hardware platform specifies that no exceptions set {\tt mtval} to a
-nonzero value, then it may be hardwired to zero. Otherwise,
-{\tt mtval} is a \warl\ register that must be able to hold all valid physical
-and virtual addresses and the value 0. It need not be capable of holding all
-possible invalid addresses. Implementations may convert some invalid address
-patterns into other invalid addresses prior to writing them to {\tt mtval}.
-If the feature to return the faulting instruction bits is implemented, {\tt
-mtval} must also be able to hold all values less than $2^N$, where $N$ is the
-smaller of XLEN and the width of the longest supported instruction.
-
-\section{Machine-Mode Privileged Instructions}
-
-\subsection{Environment Call and Breakpoint}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}S}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct12} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-ECALL & 0 & PRIV & 0 & SYSTEM \\
-EBREAK & 0 & PRIV & 0 & SYSTEM \\
-\end{tabular}
-\end{center}
-
-The ECALL instruction is used to make a request to the supporting execution
-environment. When executed in U-mode, S-mode, or M-mode, it generates an
-environment-call-from-U-mode exception, environment-call-from-S-mode exception, or environment-call-from-M-mode exception, respectively, and performs no other operation.
-\begin{commentary}
-ECALL generates a different exception for each originating privilege mode
-so that environment call exceptions can be selectively delegated. A typical
-use case for Unix-like operating systems is to delegate to S-mode the
-environment-call-from-U-mode exception but not the others.
-\end{commentary}
-
-The EBREAK instruction is used by debuggers to cause control to be transferred
-back to a debugging environment. It generates a breakpoint exception and
-performs no other operation.
-\begin{commentary}
-As described in the ``C'' Standard Extension for Compressed Instructions in
-Volume I of this manual, the C.EBREAK instruction performs the same operation
-as the EBREAK instruction.
-\end{commentary}
-
-ECALL and EBREAK cause the receiving privilege mode's {\tt epc} register
-to be set to the address of the ECALL or EBREAK instruction itself, {\em not}
-the address of the following instruction.
-
-\subsection{Trap-Return Instructions}
-\label{otherpriv}
-
-Instructions to return from trap are encoded under the PRIV
-minor opcode.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}S}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct12} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-MRET/SRET/URET & 0 & PRIV & 0 & SYSTEM \\
-\end{tabular}
-\end{center}
-
-To return after handling a trap, there are separate trap return
-instructions per privilege level: MRET, SRET, and URET. MRET is
-always provided. SRET must be provided if supervisor mode is
-supported, and should raise an illegal instruction exception otherwise. SRET
-should also raise an illegal instruction exception when TSR=1 in {\tt mstatus},
-as described in Section~\ref{virt-control}. URET is only provided if user-mode
-traps are supported, and should raise an illegal instruction otherwise.
-An {\em x}\,RET instruction can be executed in privilege mode {\em x}
-or higher, where executing a lower-privilege {\em x}\,RET instruction
-will pop the relevant lower-privilege interrupt enable and privilege
-mode stack. In addition to manipulating the privilege stack as
-described in Section~\ref{privstack}, {\em x}\,RET sets the {\tt pc}
-to the value stored in the {\em x}\,{\tt epc} register.
-
-\begin{commentary}
-Previously, there was only a single ERET instruction (which was also
-earlier known as SRET). To support the addition of user-level
-interrupts, we needed to add a separate URET instruction to continue
-to allow classic virtualization of OS code using the ERET instruction.
-It then became more orthogonal to support a different {\em x}RET
-instruction per privilege level.
-\end{commentary}
-
-If the A extension is supported, the {\em x},RET instruction is
-allowed to clear any outstanding LR address reservation but is not
-required to. Trap handlers should explicitly clear the reservation if
-required (e.g., by using a dummy SC) before executing the {\em x}RET.
-
-\begin{commentary}
- If {\em x},RET instructions always cleared LR reservations, it would
- be impossible to single-step through LR/SC sequences using a
- debugger.
-\end{commentary}
-
-\subsection{Wait for Interrupt}
-\label{wfi}
-
-The Wait for Interrupt instruction (WFI) provides a hint to the
-implementation that the current hart can be stalled until an interrupt
-might need servicing. Execution of the WFI instruction can also be
-used to inform the hardware platform that suitable interrupts should
-preferentially be routed to this hart. WFI is available in all of the
-supported S and M privilege modes, and optionally available to
-U-mode for implementations that support U-mode interrupts. This instruction may
-raise an illegal instruction exception when TW=1 in {\tt mstatus}, as described
-in Section~\ref{virt-control}.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}S}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct12} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-WFI & 0 & PRIV & 0 & SYSTEM \\
-\end{tabular}
-\end{center}
-
-If an enabled interrupt is present or later becomes present while the
-hart is stalled, the interrupt exception will be taken on the
-following instruction, i.e., execution resumes in the trap handler and
-{\tt mepc} = {\tt pc} + 4.
-
-\begin{commentary}
-The following instruction takes the interrupt exception and trap, so
-that a simple return from the trap handler will execute code after the
-WFI instruction.
-\end{commentary}
-
-The purpose of the WFI instruction is to provide a hint to the implementation,
-and so a legal implementation is to simply implement WFI as a NOP.
-
-\begin{commentary}
-If the implementation does not stall the hart on execution of the
-instruction, then the interrupt will be taken on some instruction in
-the idle loop containing the WFI, and on a simple return from the
-handler, the idle loop will resume execution.
-\end{commentary}
-
-\begin{commentary}
-We have removed the earlier requirement that implementations ignore
-the {\em rs1} and {\em rd} fields, so non-zero values in these fields
-should now raise illegal instruction exceptions.
-\end{commentary}
-
-The WFI instruction can also be executed when interrupts are disabled. The
-operation of WFI must be unaffected by the global interrupt bits in {\tt
-mstatus} (MIE/SIE/UIE) and the delegation registers {\tt [m|s]ideleg}
-(i.e., the hart must resume if a locally enabled interrupt becomes pending,
-even if it has been delegated to a less-privileged mode), but should honor the
-individual interrupt enables (e.g, MTIE) (i.e., implementations should
-avoid resuming the hart if the interrupt is pending but not
-individually enabled). WFI is also required to resume execution for
-locally enabled interrupts pending at any privilege level, regardless
-of the global interrupt enable at each privilege level.
-
-If the event that causes the hart to resume execution does not cause
-an interrupt to be taken, execution will resume at {\tt pc} + 4, and
-software must determine what action to take, including looping back to
-repeat the WFI if there was no actionable event.
-
-\begin{commentary}
-By allowing wakeup when interrupts are disabled, an alternate entry
-point to an interrupt handler can be called that does not require
-saving the current context, as the current context can be saved or
-discarded before the WFI is executed.
-
-As implementations are free to implement WFI as a NOP, software must
-explicitly check for any relevant pending but disabled interrupts in
-the code following an WFI, and should loop back to the WFI if no
-suitable interrupt was detected. The {\tt mip}, {\tt sip},
-or {\tt uip} registers can be interrogated to determine the presence
-of any interrupt in machine, supervisor, or user mode
-respectively.
-
-The operation of WFI is unaffected by the delegation register settings.
-
-WFI is defined so that an implementation can trap into a higher
-privilege mode, either immediately on encountering the WFI or after
-some interval to initiate a machine-mode transition to a lower power
-state, for example.
-\end{commentary}
-
-\begin{commentary}
-The same ``wait-for-event'' template might be used for possible future
-extensions that wait on memory locations changing, or message
-arrival.
-\end{commentary}
-
-\section{Reset}
-\label{sec:reset}
-
-Upon reset, a hart's privilege mode is set to M. The {\tt mstatus} fields MIE
-and MPRV are reset to 0. The {\tt pc} is
-set to an implementation-defined reset vector. The {\tt mcause} register is
-set to a value indicating the cause of the reset. All other hart state is
-undefined.
-
-The {\tt mcause} values after reset have implementation-specific
-interpretation, but the value 0 should be returned on implementations
-that do not distinguish different reset conditions. Implementations
-that distinguish different reset conditions should only use 0 to
-indicate the most complete reset (e.g., hard reset).
-
-\begin{commentary}
-Some designs may have multiple causes of reset (e.g., power-on reset,
-external hard reset, brownout detected, watchdog timer elapse,
-sleep-mode wakeup), which machine-mode software and debuggers may wish
-to distinguish.
-
-{\tt mcause} reset values may alias {\tt mcause} values following synchronous
-exceptions. There should be no ambiguity in this overlap, since on reset the
-{\tt pc} is typically set to a different value than on other traps.
-\end{commentary}
-
-\section{Non-Maskable Interrupts}
-\label{sec:nmi}
-
-Non-maskable interrupts (NMIs) are only used for hardware error
-conditions, and cause an immediate jump to an implementation-defined
-NMI vector running in M-mode regardless of the state of a hart's
-interrupt enable bits. The {\tt mepc} register is written with the
-address of the next instruction to be executed at the time the NMI was
-taken, and {\tt mcause} is set to a value indicating the source of the
-NMI. The NMI can thus overwrite state in an active machine-mode
-interrupt handler.
-
-The values written to {\tt mcause} on an NMI are
-implementation-defined, but a value of 0 is reserved to mean ``unknown
-cause'' and implementations that do not distinguish sources of NMIs
-via the {\tt mcause} register should return 0.
-
-Unlike resets, NMIs do not reset processor state, enabling diagnosis,
-reporting, and possible containment of the hardware error.
-
-\section{Physical Memory Attributes}
-\label{sec:pma}
-
-The physical memory map for a complete system includes various address
-ranges, some corresponding to memory regions, some to memory-mapped
-control registers, and some to empty holes in the address space. Some
-memory regions might not support reads, writes, or execution; some
-might not support subword or subblock accesses; some might not support
-atomic operations; and some might not support cache coherence or might
-have different memory models. Similarly, memory-mapped control
-registers vary in their supported access widths, support for atomic
-operations, and whether read and write accesses have associated side
-effects. In RISC-V systems, these properties and capabilities of each
-region of the machine's physical address space are termed {\em
- physical memory attributes} (PMAs). This section describes RISC-V
-PMA terminology and how RISC-V systems implement and check PMAs.
-
-PMAs are inherent properties of the underlying hardware and rarely
-change during system operation. Unlike physical memory protection
-values described in Section~\ref{sec:pmp}, PMAs do not vary by
-execution context. The PMAs of some memory regions are fixed at chip
-design time---for example, for an on-chip ROM. Others are fixed at
-board design time, depending, for example, on which other chips are
-connected to off-chip buses. Off-chip buses might also support
-devices that could be changed on every power cycle (cold pluggable) or
-dynamically while the system is running (hot pluggable). Some devices
-might be configurable at run time to support different uses that imply
-different PMAs---for example, an on-chip scratchpad RAM might be
-cached privately by one core in one end-application, or accessed as a
-shared non-cached memory in another end-application.
-
-Most systems will require that at least some PMAs are dynamically
-checked in hardware later in the execution pipeline after the physical
-address is known, as some operations will not be supported at all
-physical memory addresses, and some operations require knowing the
-current setting of a configurable PMA attribute. While many other architectures
-specify some PMAs in the virtual memory page tables and use the TLB to
-inform the pipeline of these properties, this approach injects platform-specific
-information into a virtualized layer and can cause system errors
-unless attributes are correctly initialized in each page-table entry
-for each physical memory region. In addition, the available
-page sizes might not be optimal for specifying attributes in the
-physical memory space, leading to address-space fragmentation and
-inefficient use of expensive TLB entries.
-
-For RISC-V, we separate out specification and checking of PMAs into a
-separate hardware structure, the {\em PMA checker}. In many cases,
-the attributes are known at system design time for each physical
-address region, and can be hardwired into the PMA checker. Where the
-attributes are run-time configurable, platform-specific memory-mapped
-control registers can be provided to specify these attributes at a
-granularity appropriate to each region on the platform (e.g., for an
-on-chip SRAM that can be flexibly divided between cacheable and
-uncacheable uses). PMAs are checked for any access to physical
-memory, including accesses that have undergone virtual to physical
-memory translation. To aid in system debugging, we strongly recommend
-that, where possible, RISC-V processors precisely trap physical memory
-accesses that fail PMA checks. Precisely trapped PMA violations manifest
-as load, store, or instruction-fetch access exceptions, distinct from
-virtual-memory page-fault exceptions. Precise PMA traps might not always be
-possible, for example, when probing a legacy bus architecture that
-uses access failures as part of the discovery mechanism. In this
-case, error responses from slave devices will be reported as imprecise
-bus-error interrupts.
-
-PMAs must also be readable by software to correctly access certain
-devices or to correctly configure other hardware components that
-access memory, such as DMA engines. As PMAs are tightly tied to a
-given physical platform's organization, many details are inherently
-platform-specific, as is the means by which software can learn the PMA
-values for a platform. The configuration string
-(Chapter~\ref{cfgstr}) can encode PMAs for on-chip devices and might
-also describe on-chip controllers for off-chip buses that can be
-dynamically interrogated to discover attached device PMAs. Some
-devices, particularly legacy buses, do not support discovery of PMAs
-and so will give error responses or time out if an unsupported access
-is attempted. Typically, platform-specific machine-mode code will
-extract PMAs and ultimately present this information to higher-level
-less-privileged software using some standard representation.
-
-Where platforms support dynamic reconfiguration of PMAs, an interface
-will be provided to set the attributes by passing requests to a
-machine-mode driver that can correctly reconfigure the platform. For
-example, switching cacheability attributes on some memory regions
-might involve platform-specific operations, such as cache flushes,
-that are available only to machine-mode.
-
-\subsection{Main Memory versus I/O versus Empty Regions}
-
-The most important characterization of a given memory address range is
-whether it holds regular main memory, or I/O devices, or is empty.
-Regular main memory is required to have a number of properties,
-specified below, whereas I/O devices can have a much broader range of
-attributes. Memory regions that do not fit into regular main
-memory, for example, device scratchpad RAMs, are categorized as I/O
-regions. Empty regions are also classified as I/O regions but with
-attributes specifying that no accesses are supported.
-
-\subsection{Supported Access Type PMAs}
-
-Access types specify which access widths, from 8-bit byte to long
-multi-word burst, are supported, and also whether misaligned accesses
-are supported for each access width.
-
-\begin{commentary}
-Although software running on a RISC-V hart cannot directly generate
-bursts to memory, software might have to program DMA engines to access
-I/O devices and might therefore need to know which access sizes are
-supported.
-\end{commentary}
-
-Main memory regions always support read, write, and execute of all
-access widths required by the attached devices.
-
-\begin{commentary}
-In some cases, the design of a processor or device accessing main
-memory might support other widths, but must be able to function with
-the types supported by the main memory.
-\end{commentary}
-
-I/O regions can specify which combinations of read, write, or execute
-accesses to which data widths are supported.
-
-\subsection{Atomicity PMAs}
-
-Atomicity PMAs describes which atomic instructions are supported in
-this address region. Main memory regions must support the atomic
-operations required by the processors attached. I/O regions may only
-support a subset or none of the processor-supported atomic operations.
-
-Support for atomic instructions is divided into two categories: {\em
- LR/SC} and {\em AMOs}. Within AMOs, there are four levels of
-support: {\em AMONone}, {\em AMOSwap}, {\em AMOLogical}, and {\em
- AMOArithmetic}. AMONone indicates that no AMO operations are
-supported. AMOSwap indicates that only {\tt amoswap} instructions are
-supported in this address range. AMOLogical indicates that swap
-instructions plus all the logical AMOs ({\tt amoand}, {\tt amoor},
-{\tt amoxor}) are supported. AMOArithmetic indicates that all RISC-V
-AMOs are supported. For each level of support, naturally aligned AMOs
-of a given width are supported if the underlying memory region
-supports reads and writes of that width.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|l|l|}
- \hline
- AMO Class & Supported Operations \\
- \hline
- AMONone & {\em None} \\
- AMOSwap & {\tt amoswap} \\
- AMOLogical & above + {\tt amoand}, {\tt amoor}, {\tt amoxor} \\
- AMOArithmetic & above + {\tt amoadd}, {\tt amomin}, {\tt amomax}, {\tt amominu}, {\tt amomaxu} \\
- \hline
-\end{tabular}
-\end{center}
-\caption{Classes of AMOs supported by I/O regions. Main memory
- regions must always support all AMOs required by the processor.}
-\label{amoclasses}
-\end{table*}
-
-\begin{commentary}
-We recommend providing at least AMOLogical support for I/O regions
-where possible. Most I/O regions will not support LR/SC accesses, as
-these are most conveniently built on top of a cache-coherence scheme.
-\end{commentary}
-
-Memory regions that support LR/SC will define the conditions under which LR/SC
-sequences must succeed or must fail. Main memory must guarantee the eventual
-success of any LR/SC sequence that meets the requirements described in the
-user ISA specification.
-
-Memory regions that support aligned LR/SC or aligned AMOs might also support
-misaligned LR/SC or misaligned AMOs for some addresses and access widths. If,
-for a given address and access width, a misaligned LR/SC or AMO generates
-a misaligned address exception, then {\em all} loads, stores, LRs/SCs, and
-AMOs using that address and access width must generate misaligned address
-exceptions.
-\begin{commentary}
-The standard ``A'' extension does not support misaligned AMOs or LR/SC pairs.
-Support for misaligned AMOs is provided by the standard ``Zam'' extension.
-Support for misaligned LR/SC sequences is not currently standardized,
-so LR and SC to misaligned addresses must raise an exception.
-
-Mandating that misaligned loads and stores trap wherever misaligned AMOs trap
-permits the emulation of misaligned AMOs in an M-mode trap handler. The
-handler guarantees atomicity by acquiring a global mutex and emulating the
-access within the critical section. Provided that the handler for misaligned
-loads and stores uses the same mutex, all accesses to a given address that
-use the same word size will be mutually atomic.
-\end{commentary}
-
-\subsection{Memory-Ordering PMAs}
-
-Regions of the address space are classified as either {\em main
- memory} or {\em I/O} for the purposes of ordering by the FENCE
-instruction and atomic-instruction ordering bits.
-
-Accesses by one hart to main memory regions are observable not only by
-other harts but also by other devices with the capability to initiate
-requests in the main memory system (e.g., DMA engines). Main memory
-regions always have the standard RISC-V relaxed memory model.
-
-Accesses by one hart to the I/O space are observable not only by other
-harts and bus mastering devices, but also by targeted slave I/O
-devices. Within I/O, regions may further be classified as
-implementing either {\em relaxed} or {\em strong} ordering. A relaxed
-I/O region has no ordering guarantees on how memory accesses made by
-one hart are observable by different harts or I/O devices beyond those
-enforced by FENCE and AMO instructions. A strongly ordered I/O region
-ensures that all accesses made by a hart to that region are only
-observable in program order by all other harts or I/O devices.
-
-Each strongly ordered I/O region specifies a numbered ordering
-channel, which is a mechanism by which ordering guarantees can be
-provided between different I/O regions. Channel 0 is used to indicate
-point-to-point strong ordering only, where only accesses by the hart to the
-single associated I/O region are strongly ordered.
-
-Channel 1 is used to provide global strong ordering across all I/O
-regions. Any accesses by a hart to any I/O region associated with
-channel 1 can only be observed to have occurred in program order by all
-other harts and I/O devices, including relative to accesses made by
-that hart to relaxed I/O regions or strongly ordered I/O regions with
-different channel numbers. In other words, any access to a region in
-channel 1 is equivalent to executing a {\tt fence io,io}
-instruction before and after the instruction.
-
-Other larger channel numbers provide program ordering to accesses by
-that hart across any regions with the same channel number.
-
-Systems might support dynamic configuration of ordering properties on
-each memory region.
-
-\begin{commentary}
-Strong ordering can be used to improve compatibility with legacy
-device driver code, or to enable increased performance compared to
-insertion of explicit ordering instructions when the implementation is
-known to not reorder accesses.
-
-Local strong ordering (channel 0) is the default form of strong
-ordering as it is often straightforward to provide if there is only a
-single in-order communication path between the hart and the I/O
-device.
-
-Generally, different strongly ordered I/O regions can share the same
-ordering channel without additional ordering hardware if they share
-the same interconnect path and the path does not reorder requests.
-\end{commentary}
-
-\subsection{Coherence and Cacheability PMAs}
-
-Coherence is a property defined for a single physical address, and
-indicates that writes to that address by one agent will eventually be
-made visible to other agents in the system. Coherence is not to be
-confused with the memory consistency model of a system, which defines
-what values a memory read can return given the previous history of
-reads and writes to the entire memory system. In RISC-V platforms,
-the use of hardware-incoherent regions is discouraged due to software
-complexity, performance, and energy impacts.
-
-The cacheability of a memory region should not affect the software
-view of the region except for differences reflected in other PMAs,
-such as main memory versus I/O classification, memory ordering,
-supported accesses and atomic operations, and coherence. For this
-reason, we treat cacheability as a platform-level setting managed by
-machine-mode software only.
-
-Where a platform supports configurable cacheability settings for a
-memory region, a platform-specific machine-mode routine will change
-the settings and flush caches if necessary, so the system is only
-incoherent during the transition between cacheability settings. This
-transitory state should not be visible to lower privilege levels.
-
-\begin{commentary}
-We categorize RISC-V caches into three types: {\em master-private},
-{\em shared}, and {\em slave-private}. Master-private caches are
-attached to a single master agent, i.e., one that issues read/write
-requests to the memory system. Shared caches are located between
-masters and slaves and may be hierarchically organized. Slave-private
-caches do not impact coherence, as they are local to a single slave
-and do not affect other PMAs at a master, so are not considered
-further here. We use {\em private cache} to mean a master-private
-cache in the following section, unless explicitly stated otherwise.
-
-Coherence is straightforward to provide for a shared memory region
-that is not cached by any agent. The PMA for such a region would
-simply indicate it should not be cached in a private or shared cache.
-
-Coherence is also straightforward for read-only regions, which can be
-safely cached by multiple agents without requiring a cache-coherence
-scheme. The PMA for this region would indicate that it can be cached,
-but that writes are not supported.
-
-Some read-write regions might only be accessed by a single agent, in
-which case they can be cached privately by that agent without
-requiring a coherence scheme. The PMA for such regions would indicate
-they can be cached. The data can also be cached in a shared cache, as
-other agents should not access the region.
-
-If an agent can cache a read-write region that is accessible by other
-agents, whether caching or non-caching, a cache-coherence scheme is
-required to avoid use of stale values. In regions lacking hardware
-cache coherence (hardware-incoherent regions), cache coherence can be
-implemented entirely in software, but software coherence schemes are
-notoriously difficult to implement correctly and often have severe
-performance impacts due to the need for conservative software-directed
-cache-flushing. Hardware cache-coherence schemes require more complex
-hardware and can impact performance due to the cache-coherence probes,
-but are otherwise invisible to software.
-
-For each hardware cache-coherent region, the PMA would indicate that
-the region is coherent and which hardware coherence controller to use
-if the system has multiple coherence controllers. For some systems,
-the coherence controller might be an outer-level shared cache, which
-might itself access further outer-level cache-coherence controllers
-hierarchically.
-
-Most memory regions within a platform will be coherent to software,
-because they will be fixed as either uncached, read-only, hardware
-cache-coherent, or only accessed by one agent.
-\end{commentary}
-
-\subsection{Idempotency PMAs}
-
-Idempotency PMAs describe whether reads and writes to an address
-region are idempotent. Main memory regions are assumed to be
-idempotent. For I/O regions, idempotency on reads and writes can be
-specified separately (e.g., reads are idempotent but writes are not).
-If accesses are non-idempotent, i.e., there is potentially a side
-effect on any read or write access, then speculative or redundant
-accesses must be avoided.
-
-For the purposes of defining the idempotency PMAs, changes in observed
-memory ordering created by redundant accesses are not considered a
-side effect.
-
-\begin{commentary}
-While hardware should always be designed to avoid speculative or
-redundant accesses to memory regions marked as non-idempotent, it is
-also necessary to ensure software or compiler optimizations do not
-generate spurious accesses to non-idempotent memory regions.
-\end{commentary}
-
-\begin{commentary}
-Non-idempotent regions might not support misaligned accesses, in which case
-software might emulate misaligned accesses as a sequence of aligned accesses,
-each possibly causing side effects. Therefore, portable software should not
-issue misaligned accesses to non-idempotent regions.
-\end{commentary}
-
-\section{Physical Memory Protection}
-\label{sec:pmp}
-
-To support secure processing and contain faults, it is desirable to
-limit the physical addresses accessible by software running on a hart.
-An optional physical memory protection (PMP) unit provides
-per-hart machine-mode control registers to allow
-physical memory access privileges (read, write, execute) to be
-specified for each physical memory region. The PMP values are checked
-in parallel with the PMA checks described in Section~\ref{sec:pma}.
-
-The granularity of PMP access control settings are platform-specific and
-within a platform may vary by physical memory region, but the standard PMP
-encoding supports regions as small as four bytes. Certain regions' privileges
-can be hardwired---for example, some regions might only ever be visible in
-machine mode but in no lower-privilege layers.
-
-\begin{commentary}
-Platforms vary widely in demands for physical memory protection, and
-some platforms may provide other PMP structures in addition to or
-instead of the scheme described in this section.
-\end{commentary}
-
-PMP checks are applied to all accesses when the hart is running in
-S or U modes, and for loads and stores when the MPRV bit is set in
-the {\tt mstatus} register and the MPP field in the {\tt mstatus}
-register contains S or U. PMP checks are also applied to page-table
-accesses for virtual-address translation, for which the effective
-privilege mode is S. Optionally, PMP checks may additionally apply
-to M-mode accesses, in which case the PMP registers themselves are
-locked, so that even M-mode software cannot change them without
-a system reset. In effect, PMP can {\em grant} permissions to S and U
-modes, which by default have none, and can {\em revoke} permissions
-from M-mode, which by default has full permissions.
-
-PMP violations are always trapped precisely at the processor.
-
-\subsection{Physical Memory Protection CSRs}
-
-PMP entries are described by an 8-bit configuration register and one MXLEN-bit
-address register. Some PMP settings additionally use the address register
-associated with the preceding PMP entry. Up to 16 PMP entries are supported.
-If any PMP entries are implemented, then all PMP CSRs must be implemented,
-but all PMP CSR fields are \warl\ and may be hardwired to zero. PMP CSRs
-are only accessible to M-mode.
-
-The PMP configuration registers are densely packed into CSRs to minimize
-context-switch time. For RV32, four CSRs, {\tt pmpcfg0}--{\tt pmpcfg3}, hold
-the configurations {\tt pmp0cfg}--{\tt pmp15cfg} for the 16 PMP entries, as
-shown in Figure~\ref{pmpcfg-rv32}. For RV64, {\tt pmpcfg0} and {\tt pmpcfg2}
-hold the configurations for the 16 PMP entries, as shown in
-Figure~\ref{pmpcfg-rv64}; {\tt pmpcfg1} and {\tt pmpcfg3} are illegal.
-
-\begin{commentary}
-RV64 systems use {\tt pmpcfg2}, rather than {\tt pmpcfg1}, to hold
-configurations for PMP entries 8--15. This design reduces the cost of
-supporting multiple MXLEN values, since the configurations for PMP
-entries 8--11 appear in {\tt pmpcfg2}[31:0] for both RV32 and RV64.
-\end{commentary}
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}Y@{}Y@{}Y@{}Yl}
-\instbitrange{31}{24} &
-\instbitrange{23}{16} &
-\instbitrange{15}{8} &
-\instbitrange{7}{0} & \\
-\cline{1-4}
-\multicolumn{1}{|c|}{pmp3cfg} &
-\multicolumn{1}{c|}{pmp2cfg} &
-\multicolumn{1}{c|}{pmp1cfg} &
-\multicolumn{1}{c|}{pmp0cfg} &
-\tt pmpcfg0 \\
-\cline{1-4}
-8 & 8 & 8 & 8 & \\
-\instbitrange{31}{24} &
-\instbitrange{23}{16} &
-\instbitrange{15}{8} &
-\instbitrange{7}{0} & \\
-\cline{1-4}
-\multicolumn{1}{|c|}{pmp7cfg} &
-\multicolumn{1}{c|}{pmp6cfg} &
-\multicolumn{1}{c|}{pmp5cfg} &
-\multicolumn{1}{c|}{pmp4cfg} &
-\tt pmpcfg1 \\
-\cline{1-4}
-8 & 8 & 8 & 8 & \\
-\instbitrange{31}{24} &
-\instbitrange{23}{16} &
-\instbitrange{15}{8} &
-\instbitrange{7}{0} & \\
-\cline{1-4}
-\multicolumn{1}{|c|}{pmp11cfg} &
-\multicolumn{1}{c|}{pmp10cfg} &
-\multicolumn{1}{c|}{pmp9cfg} &
-\multicolumn{1}{c|}{pmp8cfg} &
-\tt pmpcfg2 \\
-\cline{1-4}
-8 & 8 & 8 & 8 & \\
-\instbitrange{31}{24} &
-\instbitrange{23}{16} &
-\instbitrange{15}{8} &
-\instbitrange{7}{0} & \\
-\cline{1-4}
-\multicolumn{1}{|c|}{pmp15cfg} &
-\multicolumn{1}{c|}{pmp14cfg} &
-\multicolumn{1}{c|}{pmp13cfg} &
-\multicolumn{1}{c|}{pmp12cfg} &
-\tt pmpcfg3 \\
-\cline{1-4}
-8 & 8 & 8 & 8 & \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{RV32 PMP configuration CSR layout.}
-\label{pmpcfg-rv32}
-\end{figure}
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}Y@{}Y@{}Y@{}Y@{}Y@{}Y@{}Y@{}Yl}
-\instbitrange{63}{56} &
-\instbitrange{55}{48} &
-\instbitrange{47}{40} &
-\instbitrange{39}{32} &
-\instbitrange{31}{24} &
-\instbitrange{23}{16} &
-\instbitrange{15}{8} &
-\instbitrange{7}{0} & \\
-\cline{1-8}
-\multicolumn{1}{|c|}{pmp7cfg} &
-\multicolumn{1}{c|}{pmp6cfg} &
-\multicolumn{1}{c|}{pmp5cfg} &
-\multicolumn{1}{c|}{pmp4cfg} &
-\multicolumn{1}{c|}{pmp3cfg} &
-\multicolumn{1}{c|}{pmp2cfg} &
-\multicolumn{1}{c|}{pmp1cfg} &
-\multicolumn{1}{c|}{pmp0cfg} &
-\tt pmpcfg0 \\
-\cline{1-8}
-8 & 8 & 8 & 8 & 8 & 8 & 8 & 8 & \\
-\instbitrange{63}{56} &
-\instbitrange{55}{48} &
-\instbitrange{47}{40} &
-\instbitrange{39}{32} &
-\instbitrange{31}{24} &
-\instbitrange{23}{16} &
-\instbitrange{15}{8} &
-\instbitrange{7}{0} & \\
-\cline{1-8}
-\multicolumn{1}{|c|}{pmp15cfg} &
-\multicolumn{1}{c|}{pmp14cfg} &
-\multicolumn{1}{c|}{pmp13cfg} &
-\multicolumn{1}{c|}{pmp12cfg} &
-\multicolumn{1}{c|}{pmp11cfg} &
-\multicolumn{1}{c|}{pmp10cfg} &
-\multicolumn{1}{c|}{pmp9cfg} &
-\multicolumn{1}{c|}{pmp8cfg} &
-\tt pmpcfg2 \\
-\cline{1-8}
-8 & 8 & 8 & 8 & 8 & 8 & 8 & 8 & \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{RV64 PMP configuration CSR layout.}
-\label{pmpcfg-rv64}
-\end{figure}
-
-The PMP address registers are CSRs named {\tt pmpaddr0}--{\tt pmpaddr15}.
-Each PMP address register encodes bits 33--2 of a 34-bit physical address for
-RV32, as shown in Figure~\ref{pmpaddr-rv32}. For RV64, each PMP address
-register encodes bits 55--2 of a 56-bit physical address, as shown in
-Figure~\ref{pmpaddr-rv64}. Not all physical address bits may be implemented,
-and so the {\tt pmpaddr} registers are \warl.
-
-\begin{commentary}
-The Sv32 page-based virtual-memory scheme described in Section~\ref{sec:sv32}
-supports 34-bit physical addresses for RV32, so the PMP scheme must support
-addresses wider than XLEN for RV32.
-The Sv39 and Sv48 page-based virtual-memory schemes described in
-Sections~\ref{sec:sv39} and~\ref{sec:sv48} support a 56-bit physical address
-space, so the RV64 PMP address registers impose the same limit.
-\end{commentary}
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{31}{0} \\
-\hline
-\multicolumn{1}{|c|}{address[33:2] (\warl)} \\
-\hline
-32 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{PMP address register format, RV32.}
-\label{pmpaddr-rv32}
-\end{figure}
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}F@{}J}
-\instbitrange{63}{54} &
-\instbitrange{53}{0} \\
-\hline
-\multicolumn{1}{|c|}{0 (\warl)} &
-\multicolumn{1}{c|}{address[55:2] (\warl)} \\
-\hline
-10 & 54 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{PMP address register format, RV64.}
-\label{pmpaddr-rv64}
-\end{figure}
-
-Figure~\ref{pmpcfg} shows the layout of a PMP configuration register. The R,
-W, and X bits, when set, indicate that the PMP entry permits read, write, and
-instruction execution, respectively. When one of these bits is clear, the
-corresponding access type is denied. The combination R=0 and W=1 is reserved
-for future use. The remaining two fields, A and L, are
-described in the following sections.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{YSSYYY}
-\instbit{7} &
-\instbitrange{6}{5} &
-\instbitrange{4}{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{L (\warl)} &
-\multicolumn{1}{c|}{0 (\warl)} &
-\multicolumn{1}{c|}{A (\warl)} &
-\multicolumn{1}{c|}{X (\warl)} &
-\multicolumn{1}{c|}{W (\warl)} &
-\multicolumn{1}{c|}{R (\warl)}
-\\
-\hline
-1 & 2 & 2 & 1 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{PMP configuration register format.}
-\label{pmpcfg}
-\end{figure}
-
-Attempting to fetch an instruction from a PMP region that does not have execute
-permissions raises a fetch access exception. Attempting to execute
-a load or load-reserved instruction whose effective address lies within
-a PMP region without read permissions raises a load access exception.
-Attempting to execute a store, store-conditional (regardless of success),
-or AMO instruction whose effective address lies within a PMP region without
-write permissions raises a store access exception.
-
-\subsubsection*{Address Matching}
-
-The A field in a PMP entry's configuration register encodes the
-address-matching mode of the associated PMP address register. The encoding of
-this field is shown in Table~\ref{pmpcfg-a}. When A=0, this PMP entry is
-disabled and matches no addresses. Two other address-matching modes are
-supported: naturally aligned power-of-2 regions (NAPOT), including the special
-case of naturally aligned four-byte regions (NA4); and the top boundary of an
-arbitrary range (TOR). These modes support four-byte granularity.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|r|c|l|}
-\hline
-A & Name & Description \\
-\hline
-0 & OFF & Null region (disabled) \\
-1 & TOR & Top of range \\
-2 & NA4 & Naturally aligned four-byte region \\
-3 & NAPOT & Naturally aligned power-of-two region, $\ge$8 bytes \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Encoding of A field in PMP configuration registers.}
-\label{pmpcfg-a}
-\end{table*}
-
-NAPOT ranges make use of the low-order bits of the associated address register
-to encode the size of the range, as shown in Table~\ref{pmpcfg-napot}.
-
-\begin{table*}[h!]
-\begin{center}
- \begin{tabular}{|c|c|l|}
- \hline
- \tt pmpaddr & {\tt pmpcfg}.A & Match type and size \\
- \hline
- \tt yyyy...yyyy & NA4 & 4-byte NAPOT range \\
- \tt yyyy...yyy0 & NAPOT & 8-byte NAPOT range \\
- \tt yyyy...yy01 & NAPOT & 16-byte NAPOT range \\
- \tt yyyy...y011 & NAPOT & 32-byte NAPOT range \\
- \multicolumn{1}{|c|}{\ldots} & \ldots & \multicolumn{1}{|c|}{\ldots} \\
- \tt yy01...1111 & NAPOT & $2^{XLEN}$-byte NAPOT range \\
- \tt y011...1111 & NAPOT & $2^{XLEN+1}$-byte NAPOT range \\
- \tt 0111...1111 & NAPOT & $2^{XLEN+2}$-byte NAPOT range \\
- \tt 1111...1111 & NAPOT & $2^{XLEN+3}$-byte NAPOT range \\
- \hline
- \end{tabular}
-\end{center}
-\caption{NAPOT range encoding in PMP address and configuration registers.}
-\label{pmpcfg-napot}
-\end{table*}
-
-If TOR is selected, the associated address register forms the top of the
-address range, and the preceding PMP address register forms the bottom of the
-address range. If PMP entry $i$'s A field is set to TOR, the entry matches
-any address $y$ such that ${\tt pmpaddr}_{i-1}\leq y < {\tt pmpaddr}_i$. If
-PMP entry 0's A field is set to TOR, zero is used for the lower bound, and so
-it matches any address $y < {\tt pmpaddr}_0$.
-
-Although the PMP mechanism supports regions as small as four bytes, platforms
-may specify coarser PMP regions. In general, the PMP grain is $2^{G+2}$ bytes
-and must be the same across all PMP regions. When $G \geq 1$, the NA4 mode
-may not be selected. When $G \geq 2$ and ${\tt pmpcfg}_i$.A[1] is set, i.e.
-the mode is NAPOT, then bits ${\tt pmpaddr}_i$[G-2:0] read as all ones. When
-$G \geq 1$ and ${\tt pmpcfg}_i$.A[1] is clear, i.e. the mode is OFF or TOR,
-then bits ${\tt pmpaddr}_i$[G-1:0] read as all zeros. Bits ${\tt
-pmpaddr}_i$[G-1:0] do not affect the TOR address-matching logic.
-
-\begin{commentary}
-Software may determine the PMP granularity by writing zero to {\tt pmp0cfg},
-then writing all ones to {\tt pmpaddr0}, then reading back {\tt pmpaddr0}.
-If $G$ is the index of the least-significant bit set,
-the PMP granularity is $2^{G+2}$ bytes.
-\end{commentary}
-
-\subsubsection*{Locking and Privilege Mode}
-
-The L bit indicates that the PMP entry is locked, i.e., writes to the
-configuration register and associated address registers are ignored. Locked
-PMP entries may only be unlocked with a system reset. If PMP entry $i$ is
-locked, writes to {\tt pmp}$i${\tt cfg} and {\tt pmpaddr}$i$ are ignored.
-Additionally, if {\tt pmp}$i${\tt cfg}.A is set to TOR, writes to {\tt
-pmpaddr}$i$-1 are ignored.
-
-In addition to locking the PMP entry, the L bit indicates whether the R/W/X
-permissions are enforced on M-mode accesses. When the L bit is set, these
-permissions are enforced for all privilege modes. When the L bit is clear,
-any M-mode access matching the PMP entry will succeed; the R/W/X
-permissions apply only to S and U modes.
-
-\subsubsection*{Priority and Matching Logic}
-
-PMP entries are statically prioritized. The lowest-numbered PMP entry that
-matches any byte of an access determines whether that access succeeds or
-fails. The matching PMP entry must match all bytes of an access, or the
-access fails, irrespective of the L, R, W, and X bits. For example, if a PMP
-entry is configured to match the four-byte range {\tt 0xC}--{\tt 0xF}, then an
-8-byte access to the range {\tt 0x8}--{\tt 0xF} will fail, assuming that
-PMP entry is the highest-priority entry that matches those addresses.
-
-If a PMP entry matches all bytes of an access, then the L, R, W, and X bits
-determine whether the access succeeds or fails. If the L bit is clear and the
-privilege mode of the access is M, the access succeeds. Otherwise, if the
-L bit is set or the privilege mode of the access is S or U, then the access
-succeeds only if the R, W, or X bit corresponding to the access type is set.
-
-If no PMP entry matches an M-mode access, the access succeeds. If no PMP
-entry matches an S-mode or U-mode access, but at least one PMP entry is
-implemented, the access fails.
-
-Failed accesses generate a load, store, or instruction access exception. Note
-that a single instruction may generate multiple accesses, which may not be
-mutually atomic. An access exception is generated if at least one access
-generated by an instruction fails, though other accesses generated by that
-instruction may succeed with visible side effects. Notably, instructions that
-reference virtual memory are decomposed into multiple accesses.
-
-On some implementations, misaligned loads, stores, and instruction fetches may
-also be decomposed into multiple accesses, some of which may succeed before an
-access exception occurs. In particular, a portion of a misaligned store
-that passes the PMP check may become visible, even if another portion fails
-the PMP check. The same behavior may manifest for floating-point stores wider
-than XLEN bits (e.g., the FSD instruction in RV32D), even when the store
-address is naturally aligned.
-
-\subsection{Physical Memory Protection and Paging}
-\label{pmp-vmem}
-
-The Physical Memory Protection mechanism is designed to compose with the
-page-based virtual memory systems described in Chapter~\ref{supervisor}. When
-paging is enabled, instructions that access virtual memory may result in
-multiple physical-memory accesses, including implicit references to the page
-tables. The PMP checks apply to all of these accesses. The effective
-privilege mode for implicit page-table accesses is S.
-
-Implementations with virtual memory are permitted to perform address
-translations speculatively and earlier than required by an explicit
-virtual-memory access. The PMP settings for the resulting physical address
-may be checked at any point between the address translation and the explicit
-virtual-memory access. Hence, when the PMP settings are modified in a manner
-that affects either the physical memory that holds the page tables or the
-physical memory to which the page tables point, M-mode software must
-synchronize the PMP settings with the virtual memory system. This is
-accomplished by executing an SFENCE.VMA instruction with {\em rs1}={\tt x0}
-and {\em rs2}={\tt x0}, after the PMP CSRs are written.
-
-If page-based virtual memory is not implemented, or when it is disabled,
-memory accesses check the PMP settings synchronously, so no fence is needed.
diff --git a/src/memory-model-operational.tex b/src/memory-model-operational.tex
deleted file mode 100644
index a94c8d4..0000000
--- a/src/memory-model-operational.tex
+++ /dev/null
@@ -1,659 +0,0 @@
-\section{An Operational Memory Model}
-\label{sec:operational}
-This is an alternative presentation of the RVWMO memory model in
-operational style.
-%
-It aims to admit exactly the same extensional behaviour as the
-axiomatic presentation: for any given program, admitting an execution
-if and only if the axiomatic presentation allows it.
-
-The axiomatic presentation is defined as a predicate on complete
-candidate executions. In contrast, this operational presentation has
-an abstract microarchitectural flavour: it is expressed as a state
-machine, with states that are an abstract representation of hardware
-machine states, and with explicit out-of-order and speculative
-execution
-(but abstracting from more implementation-specific microarchitectural
-details such as register renaming, store buffers, cache hierarchies, cache protocols, etc.).
-As such, it can provide useful intuition.
-It can also
-construct executions incrementally, making it possible to
-interactively and randomly explore the behaviour of larger examples,
-while the axiomatic model requires complete candidate executions
-over which the axioms can be checked.
-
-The operational presentation covers mixed-size execution, with
-potentially overlapping memory accesses of different power-of-two byte
-sizes. Misaligned accesses are broken up into single-byte accesses.
-
-An interactive version of the model, together with a library of litmus tests,
-is provided online: \url{http://www.cl.cam.ac.uk/~pes20/rmem}.
-This is integrated with a fragment of the RISC-V ISA semantics
-(RV64I and A) expressed explicitly in Sail
-(\url{https://github.com/rems-project/sail}).
-% TODO: compare with the herd and alloy versions
-
-
-Below is an informal introduction of the model states and transitions.
-The description of the formal model starts in the next subsection.
-
-
-Terminology: In contrast to the axiomatic presentation, here every memory operation is either a load or a store.
-Hence, AMOs give rise to two distinct memory operations, a load and a store.
-When used in conjunction with ``instruction'', the terms ``load'' and ``store'' refer to instructions that give rise to such memory operations.
-As such, both include AMO instructions.
-The term ``acquire'' refers to an instruction (or its memory operation) with the acquire-RCpc or acquire-RCsc annotation.
-The term ``release'' refers to an instruction (or its memory operation) with the release-RCpc or release-RCsc annotation.
-
-\paragraph{Model states}
-A model state consists of a shared memory and a tuple of hart states.
-\begin{center}
-\sffamily
-\begin{tabular}{ccc}
-\cline{1-1}\cline{3-3}
-\multicolumn{1}{|c|}{Hart 0} & \bf \dots & \multicolumn{1}{|c|}{Hart $n$} \\
-\cline{1-1}\cline{3-3}
-$\big\uparrow$ $\big\downarrow$ & & $\big\uparrow$ $\big\downarrow$ \\
-\hline
-\multicolumn{3}{|c|}{Shared Memory} \\
-\hline
-\end{tabular}
-\end{center}
-The shared memory state records all the memory store operations that have propagated so far, in the order they propagated (this can be made more efficient, but for simplicity of the presentation we keep it this way).
-
-Each hart state consists principally of a tree of instruction instances, some of which have been \emph{finished}, and some of which have not.
-Non-finished instruction instances can be subject to \emph{restart}, e.g.~if they depend on an out-of-order or speculative load that turns out to be unsound.
-
-Conditional branch and indirect jump instructions may have multiple successors in the instruction tree.
-When such instruction is finished, any un-taken alternative paths are discarded.
-
-Each instruction instance in the instruction tree has a state that
-includes an execution state of the intra-instruction semantics (the
-ISA pseudocode for this instruction).
-The model uses a formalisation of the intra-instruction semantics in Sail.
-One can think of the execution state of an instruction as a representation of the pseudocode control state, pseudocode call stack, and local variable values.
-An instruction instance state also includes information about the instance's memory and register footprints, its register reads and writes, its memory operations, whether it is finished, etc.
-
-\paragraph{Model transitions}
-The model defines, for any model state, the set of allowed transitions, each of which is a single atomic step to a new abstract machine state.
-Execution of a single instruction will typically involve many
-transitions, and they may be interleaved in operational-model
-execution with transitions arising from other instructions.
-Each transition arises from a single instruction instance; it will
-change the state of that instance, and it may depend on or change the
-rest of its hart state and the shared memory state, but it does not depend on other hart states, and it will not change them.
-% Instructions cannot be treated
-% as atomic units: complete execution of a single instruction instance may
-% involve many transitions, which can be interleaved with those of other
-% instances in the same or other harts, and some of this is programmer-visible.
-The transitions are introduced below and defined in Section~\ref{sec:omm:transitions}, with a precondition and a construction of the post-transition model state for each.
-
-\noindent Transitions for all instructions:
-\begin{itemize}
-\item \nameref{omm:fetch}: This transition represents a fetch and
- decode of a new instruction instance, as a program order successor
- of a previously fetched instruction instance (or the initial fetch
- address).
-
-The model assumes the instruction memory is fixed; it does not
-describe the behaviour of self-modifying code.
-In particular, the \nameref{omm:fetch} transition does not generate memory load operations, and the shared memory is not involved in the transition.
-Instead, the model depends on an external oracle that provides an opcode when given a memory location.
-%
-
-
-\item[$\circ$] \nameref{omm:reg_write}: This is a write of a register value.
-\item[$\circ$] \nameref{omm:reg_read}: This is a read of a register
- value from the most recent program-order-predecessor instruction instance that writes to that register.
-\item[$\circ$] \nameref{omm:sail_interp}: This covers pseudocode
- internal computation: arithmetic, function calls, etc.
-\item[$\circ$] \nameref{omm:finish}: At this point the instruction pseudocode is done, the instruction cannot be restarted, memory accesses cannot be discarded, and all memory effects have taken place.
-For conditional branch and indirect jump instructions, any program order successors that were fetched from an address that is not the one that was written to the {\em pc} register are discarded, together with the sub-tree of instruction instances below them.
-\end{itemize}
-
-\noindent Transitions specific to load instructions:
-\begin{itemize}
-\item[$\circ$] \nameref{omm:initiate_load}: At this point the memory
- footprint of the load instruction is provisionally known (it could change if
- earlier instructions are restarted) and its individual memory load operations can start being satisfied.
-\item \nameref{omm:sat_by_forwarding}: This partially or entirely
- satisfies a single memory load operation by forwarding, from
- program-order-previous memory store operations.
-\item \nameref{omm:sat_from_mem}: This entirely satisfies the outstanding slices of a single memory load operation, from memory.
-\item[$\circ$] \nameref{omm:complete_loads}: At this point all the memory load operations of the instruction have been entirely satisfied and the instruction pseudocode can continue executing.
-A load instruction can be subject to being restarted until the \nameref{omm:finish} transition.
-But, under some conditions, the model might treat a load instruction as non-restartable even before it is finished (e.g.~see \nameref{omm:prop_store}).
-\end{itemize}
-
-\noindent Transitions specific to store instructions:
-\begin{itemize}
-\item[$\circ$] \nameref{omm:initiate_store_footprint}: At this point the memory footprint of the store is provisionally known.
-\item[$\circ$] \nameref{omm:instantiate_store_value}: At this point the memory store operations have their values and program-order-successor memory load operations can be satisfied by forwarding from them.
-\item[$\circ$] \nameref{omm:commit_stores}: At this point the store operations are guaranteed to happen (the instruction can no longer be restarted or discarded), and they can start being propagated to memory.
-\item \nameref{omm:prop_store}: This propagates a single memory store operation to memory.
-\item[$\circ$] \nameref{omm:complete_stores}: At this point all the memory store operations of the instruction have been propagated to memory, and the instruction pseudocode can continue executing.
-\end{itemize}
-
-\noindent Transitions specific to {\tt sc} instructions:
-\begin{itemize}
-\item \nameref{omm:early_sc_fail}: This causes the {\tt sc} to fail, either a spontaneous fail or because it is not paired with a program-order-previous {\tt lr}.
-\item \nameref{omm:paired_sc}: This transition indicates the {\tt sc} is paired with an {\tt lr} and might succeed.
-\item \nameref{omm:commit_sc}: This is an atomic execution of the transitions \nameref{omm:commit_stores} and \nameref{omm:prop_store}, it is enabled only if the stores from which the {\tt lr} read from have not been overwritten.
-\item \nameref{omm:late_sc_fail}: This causes the {\tt sc} to fail, either a spontaneous fail or because the stores from which the {\tt lr} read from have been overwritten.
-\end{itemize}
-
-\noindent Transitions specific to AMO instructions:
-\begin{itemize}
-\item \nameref{omm:do_amo}: This is an atomic execution of all the transitions needed to satisfy the load operation, do the required arithmetic, and propagate the store operation.
-\end{itemize}
-
-\noindent Transitions specific to fence instructions:
-\begin{itemize}
-\item[$\circ$] \nameref{omm:commit_fence}
-\end{itemize}
-
-The transitions labelled~$\circ$ can always be taken eagerly, as soon as their precondition is satisfied, without excluding other behaviour; the $\bullet$ cannot.
-Although \nameref{omm:fetch} is marked with a $\bullet$, it can be taken eagerly as long as it is not taken infinitely many times.
-
-An instance of a non-AMO load instruction, after being fetched, will typically experience the following transitions in this order:
-\begin{enumerate}
-\item \nameref{omm:reg_read}
-\item \nameref{omm:initiate_load}
-\item \nameref{omm:sat_by_forwarding} and/or \nameref{omm:sat_from_mem} (as many as needed to satisfy all the load operations of the instance)
-\item \nameref{omm:complete_loads}
-\item \nameref{omm:reg_write}
-\item \nameref{omm:finish}
-\end{enumerate}
-Before, between and after the transitions above, any number of \nameref{omm:sail_interp} transitions may appear.
-In addition, a \nameref{omm:fetch} transition for fetching the instruction in the next program location will be available until it is taken.
-
-
-This concludes the informal description of the operational model.
-The following sections describe the formal operational model.
-
-\subsection{Intra-instruction Pseudocode Execution}\label{sec:omm:pseudocode_exec}
-The intra-instruction semantics for each instruction instance is expressed as a state machine, essentially running the instruction pseudocode.
-Given a pseudocode execution state, it computes the next state. Most
-states identify a pending memory or register operation, requested by
-the pseudocode, which the memory model has to do. The
-states are (this is a tagged union; tags in small-caps):
-
-\begin{center}
-\begin{tabular}{l@{ \quad-\quad }l}
-{\sc Load\_mem}({\it kind}, {\it address}, {\it size}, {\it load\_continuation})
- & memory load operation\\
-{\sc Early\_sc\_fail}({\it res\_continuation})
- & allow {\tt sc} to fail early\\
-{\sc Store\_ea}({\it kind}, {\it address}, {\it size}, {\it next\_state})
- & memory store effective address\\
-{\sc Store\_memv}({\it mem\_value}, {\it store\_continuation})
- & memory store value\\
-{\sc Fence}({\it kind}, {\it next\_state})
- & fence\\
-{\sc Read\_reg}({\it reg\_name}, {\it read\_continuation})
- & register read\\
-{\sc Write\_reg}({\it reg\_name}, {\it reg\_value}, {\it next\_state})
- & register write\\
-{\sc Internal}({\it next\_state})
- & pseudocode internal step\\
-{\sc Done}
- & end of pseudocode\\
-\end{tabular}
-\end{center}
-Here:
-\begin{tightlist}
-\item {\it mem\_value} and {\it reg\_value} are lists of bytes;
-\item {\it address} is an integer of XLEN bits;
-\item for load/store, {\it kind} identifies whether it is {\tt lr/sc}, acquire-RCpc/release-RCpc, acquire-RCsc/release-RCsc, acquire-release-RCsc;
-\item for fence, {\it kind} identifies whether it is a normal or TSO, and (for normal fences) the predecessor and successor ordering bits;
-\item {\it reg\_name} identifies a register and a slice thereof (start and
- end bit indices); and
-\item the continuations describe how the instruction instance will continue for each value that might be provided by the surrounding memory model (the {\it load\_continuation} and {\it read\_continuation} take the value loaded from memory and read from the previous register write, the {\it store\_continuation} takes {\it false} for an {\tt sc} that failed and {\it true} in all other cases, and {\it res\_continuation} takes {\it false} if the {\tt sc} fails and {\it true} otherwise).
-\end{tightlist}
-
-\begin{commentary}
-For example, given the load instruction \verb!lw x1,0(x2)!,
-an execution will typically go as follows.
-The initial execution state will be computed from the pseudocode for the given opcode.
-This can be expected to be {\sc Read\_reg}({\tt x2}, {\it read\_continuation}).
-Feeding the most recently written value of register {\tt x2} (the instruction semantics will be blocked if necessary until the register value is available), say {\tt 0x4000}, to {\it read\_continuation} returns {\sc Load\_mem}({\tt plain\_load}, {\tt 0x4000}, {\tt 4}, {\it load\_continuation}).
-Feeding the 4-byte value loaded from memory location {\tt 0x4000}, say {\tt 0x42}, to {\it load\_continuation} returns
-{\sc Write\_reg}({\tt x1}, {\tt 0x42}, {\sc Done}).
-Many {\sc Internal}({\it next\_state}) states may appear before and between the states above.
-\end{commentary}
-
-Notice that writing to memory is split into two steps, {\sc Store\_ea} and {\sc Store\_memv}: the first one makes the memory footprint of the store provisionally known, and the second one adds the value to be stored.
-We ensure these are paired in the pseudocode ({\sc Store\_ea} followed by {\sc Store\_memv}), but there may be other steps between them.
-\begin{commentary}
-It is observable that the {\sc Store\_ea} can occur before the value to be stored is determined.
-For example, for the litmus test LB+fence.r.rw+data-po to be allowed by the operational model (as it is by RVWMO), the first store in Hart 1 has to take the {\sc Store\_ea} step before its value is determined, so that the second store can see it is to a non-overlapping memory footprint, allowing the second store to be committed out of order without violating coherence.
-\end{commentary}
-
-The pseudocode of each instruction performs at most one store or one load, except for AMOs that perform exactly one load and one store.
-Those memory accesses are then split apart into the architecturally atomic units by the hart semantics (see \nameref{omm:initiate_load} and \nameref{omm:initiate_store_footprint} below).
-
-Informally, each bit of a register read should be satisfied from a register write by the most recent (in program order) instruction instance that can write that bit (or from the hart's initial register state if there is no such write).
-Hence, it is essential to know the register write footprint of each instruction instance, which we calculate when the instruction instance is created (see the action of \nameref{omm:fetch} below).
-We ensure in the pseudocode that each instruction does at most one register write to each register bit, and also that it does not try to read a register value it just wrote.
-
-Data-flow dependencies (address and data) in the model emerge from the
-fact that each register read has to wait for the appropriate register write to be executed (as described above).
-
-\subsection{Instruction Instance State}\label{sec:omm:inst_state}
-Each instruction instance $i$ has a state comprising:
-\begin{itemize}
-\item {\it program\_loc}, the memory address from which the instruction was fetched;
-\item {\it instruction\_kind}, identifying whether this is a load, store, AMO, fence, branch/jump or a `simple' instruction (this also includes a {\it kind} similar to the one described for the pseudocode execution states);
-\item {\it src\_regs}, the set of source {\it reg\_name}s (including system registers), as statically determined from the pseudocode of the instruction;
-\item {\it dst\_regs}, the destination {\it reg\_name}s (including system registers), as statically determined from the pseudocode of the instruction;
-\item {\it pseudocode\_state} (or sometimes just `state' for short), one of (this is a tagged union; tags in small-caps):
- \begin{center}
- \begin{tabular}{l@{ \quad-\quad }l}
- {\sc Plain}({\it isa\_state})
- & ready to make a pseudocode transition \\
- {\sc Pending\_mem\_loads}({\it load\_continuation})
- & requesting memory load operation(s) \\
- {\sc Pending\_mem\_stores}({\it store\_continuation})
- & requesting memory store operation(s) \\
-% {\sc Pending\_exception}({\it exception}) & performing an exception;
- \end{tabular}
- \end{center}
-
-\item {\it reg\_reads}, the register reads the instance has performed, including, for each one, the register write slices it read from;
-\item {\it reg\_writes}, the register writes the instance has performed;
-\item {\it mem\_loads}, a set of memory load operations, and for each one
- the as-yet-unsatisfied slices (the byte indices that have not been
- satisfied yet), and, for the satisfied slices, the store slices
- (each consisting of a memory store operation and subset of its byte indices) that satisfied it.
-\item {\it mem\_stores}, a set of memory store operations, and for each one a flag that indicates whether it has been propagated (passed to the shared memory) or not.
-\item information recording whether the instance is committed, finished, etc.
-\end{itemize}
-
-Each memory load operation includes a memory footprint (address and size).
-Each memory store operations includes a memory footprint, and, when available, a value.
-
-A load instruction instance with a non-empty {\it mem\_loads}, for which all the load operations are satisfied (i.e.~there are no unsatisfied load slices) is said to be {\it entirely satisfied}.
-
-Informally, an instruction instance is said to have {\it fully determined data} if the load (and {\tt sc}) instructions feeding its source registers are finished.
-Similarly, it is said to have a {\it fully determined memory footprint} if the load (and {\tt sc}) instructions feeding its memory operation address register are finished.
-%
-Formally, we first define the notion of {\it fully determined register write}: a register write $w$ from {\it reg\_writes} of instruction instance $i$ is said to be {\it fully determined} if one of the following conditions hold:
-\begin{enumerate}
-\item $i$ is finished; or
-\item the value written by $w$ is not affected by a memory operation that $i$ has made (i.e. a value loaded from memory or the result of {\tt sc}), and, for every register read that $i$ has made, that affects $w$, the register write from which $i$ read is fully determined (or $i$ read from the initial register state).
-\end{enumerate}
-Now, an instruction instance $i$ is said to have {\it fully determined data} if for every register read $r$ from {\it reg\_reads}, the register writes that $r$ reads from are fully determined.
-An instruction instance $i$ is said to have a {\it fully determined memory footprint} if for every register read $r$ from {\it reg\_reads} that feeds into $i$'s memory operation address, the register writes that $r$ reads from are fully determined.
-\begin{commentary}
-The {\tt rmem} tool records, for every register write, the set of register writes from other instructions that have been read by this instruction at the point of performing the write.
-By carefully arranging the pseudocode of the instructions covered by the tool we were able to make it so that this is exactly the set of register writes on which the write depends on.
-\end{commentary}
-
-
-\subsection{Hart State}
-The model state of a single hart comprises:
-\begin{itemize}
-\item {\it hart\_id}, a unique identifier of the hart;
-%\item {\it register\_data}, the name, bit width, and start bit index for each register;
-\item {\it initial\_register\_state}, the initial register value for each register;
-\item {\it initial\_fetch\_address}, the initial instruction fetch address;
-\item {\it instruction\_tree}, a tree of the instruction instances that have been fetched (and not discarded), in program order.
-\end{itemize}
-
-
-\subsection{Shared Memory State}
-The model state of the shared memory comprises a list of memory store operations, in the order they propagated to the shared memory.
-
-When a store operation is propagated to the shared memory it is simply added to the end of the list.
-When a load operation is satisfied from memory, for each byte of the load operation, the most recent corresponding store slice is returned.
-
-\begin{commentary}
-For most purposes, it is simpler to think of the shared memory as an array, i.e., a map from memory locations to memory store operation slices, where each memory location is mapped to a one-byte slice of the most recent memory store operation to that location.
-However, this abstraction is not detailed enough to properly handle the {\tt sc} instruction.
-The RVWMO \nameref{rvwmo:ax:atom} allows store operations from the same hart as the {\tt sc} to intervene between the store operation of the {\tt sc} and the store operations the paired {\tt lr} read from.
-To allow such store operations to intervene, and forbid others, the array abstraction must be extended to record more information.
-Here, we use a list as it is very simple, but a more efficient and scalable implementations should probably use something better.
-\end{commentary}
-
-
-\subsection{Transitions}\label{sec:omm:transitions}
-
-Each of the paragraphs below describes a single kind of system transition.
-The description starts with a condition over the current system state.
-The transition can be taken in the current state only if the condition is satisfied.
-The condition is followed by an action that is applied to that state when the transition is taken, in order to generate the new system state.
-
-\paragraph{Fetch instruction}\label{omm:fetch}
-A possible program-order-successor of instruction instance $i$ can be fetched from address {\it loc} if:
-\begin{enumerate}
-\item it has not already been fetched, i.e., none of the immediate successors of $i$ in the hart's {\it instruction\_tree} are from {\it loc}; and
-\item if $i$'s pseudocode has already written an address to {\em pc}, then {\it loc} must be that address, otherwise {\it loc} is:
- \begin{itemize}
- \item for a conditional branch, the successor address or the branch target address;
- \item for a (direct) jump and link instruction ({\tt jal}), the target address;
- \item for an indirect jump instruction ({\tt jalr}), any address; and
- \item for any other instruction, $i.\textit{program\_loc}+4$.
- \end{itemize}
-\end{enumerate}
-% \fixme{Does an instruction at the end of memory need special-case treatment?}
-
-Action: construct a freshly initialized instruction instance $i'$ for the instruction in the program memory at {\it loc}, with state {\sc Plain}({\it isa\_state}), computed from the instruction pseudocode, including the static information available from the pseudocode such as its {\it instruction\_kind}, {\it src\_regs}, and {\it dst\_regs}, and add $i'$ to the hart's {\it instruction\_tree} as a successor of $i$.
-% If the instruction fails to decode, set the state of $i'$ to ``{\sc Pending\_exception} {\it exception}'' with {\it exception} that describes the decoding error.
-
-\begin{commentary}
-The possible next fetch addresses ({\it loc}) are available immediately after fetching $i$ and the model does not need to wait for the pseudocode to write to {\em pc}; this allows out-of-order execution, and speculation past conditional branches and jumps.
-For most instructions these addresses are easily obtained from the instruction pseudocode.
-The only exception to that is the indirect jump instruction ({\tt jalr}), where the address depends on the value held in a register.
-%
-In principle the mathematical model should allow speculation to
-arbitrary addresses here.
-%
-The exhaustive search in the {\tt rmem} tool handles this by running the exhaustive search multiple times with a growing set of possible next fetch addresses for each indirect jump.
-The initial search uses empty sets, hence there is no fetch after indirect jump instruction until the pseudocode of the instruction writes to {\em pc}, and then we use that value for fetching the next instruction.
-Before starting the next iteration of exhaustive search, we collect for each indirect jump (grouped by code location) the set of values it wrote to {\em pc} in all the executions in the previous search iteration, and use that as possible next fetch addresses of the instruction.
-This process terminates when no new fetch addresses are detected.
-\end{commentary}
-
-\paragraph{Initiate memory load operations}\label{omm:initiate_load}
-An instruction instance $i$ in state {\sc Plain}({\sc Load\_mem}({\it kind}, {\it address}, {\it size}, {\it load\_continuation})) can always initiate the corresponding memory load operations.
-Action:
-\begin{enumerate}
-\item Construct the appropriate memory load operations $mlos$:
- \begin{itemize}
- \item if {\it address} is aligned to {\it size} then $mlos$ is a single memory load operation of {\it size} bytes from {\it address};
- \item otherwise, $mlos$ is a set of {\it size} memory load operations, each of one byte, from the addresses $\textit{address}\ldots\textit{address}+\textit{size}-1$.
- \end{itemize}
-\item set {\it mem\_loads} of $i$ to $mlos$; and
-\item update the state of $i$ to {\sc Pending\_mem\_loads}({\it load\_continuation}).
-\end{enumerate}
-
-\begin{commentary}
-In Section~\ref{sec:rvwmo:primitives} it is said that misaligned memory accesses may be decomposed at any granularity.
-Here we decompose them to one-byte accesses as this granularity subsumes all others.
-\end{commentary}
-
-\paragraph{Satisfy memory load operation by forwarding from unpropagated stores}\label{omm:sat_by_forwarding}
-For a non-AMO load instruction instance $i$ in state {\sc Pending\_mem\_loads}({\it load\_continuation}), and a memory load operation $mlo$ in $i.\textit{mem\_loads}$ that has unsatisfied slices, the memory load operation can be partially or entirely satisfied by forwarding from unpropagated memory store operations by store instruction instances that are program-order-before $i$ if:
-\begin{enumerate}
-\item all program-order-previous {\tt fence} instructions with {\tt .sr} and {\tt .pw} set are finished;
-\item for every program-order-previous {\tt fence} instruction, $f$, with {\tt .sr} and {\tt .pr} set, and {\tt .pw} not set, if $f$ is not finished then all load instructions that are program-order-before $f$ are entirely satisfied;
-\item for every program-order-previous {\tt fence.tso} instruction, $f$, that is not finished, all load instructions that are program-order-before $f$ are entirely satisfied;
-% \item all program-order-previous {\tt fence.i} instructions are finished;
-\item if $i$ is a load-acquire-RCsc, all program-order-previous store-releases-RCsc are finished;
-\item if $i$ is a load-acquire-release, all program-order-previous instructions are finished;
-\item all non-finished program-order-previous load-acquire instructions are entirely satisfied; and
-\item all program-order-previous store-acquire-release instructions are finished;
-\end{enumerate}
-
-Let $msoss$ be the set of all unpropagated memory store operation slices from non-{\tt sc} store instruction instances that are program-order-before $i$ and have already calculated the value to be stored, that overlap with the unsatisfied slices of $mlo$, and which are not superseded by intervening store operations or store operations that are read from by an intervening load.
-The last condition requires, for each memory store operation slice $msos$ in $msoss$ from instruction $i'$:
-\begin{tightlist}
-\item that there is no store instruction program-order-between $i$ and $i'$ with a memory store operation overlapping $msos$; and
-\item that there is no load instruction program-order-between $i$ and $i'$ that was satisfied from an overlapping memory store operation slice from a different hart.
-\end{tightlist}
-
-Action:
-\begin{enumerate}
-\item update $i.\textit{mem\_loads}$ to indicate that $mlo$ was satisfied by $msoss$; and
-\item restart any speculative instructions which have violated coherence as a result of this, i.e., for every non-finished instruction $i'$ that is a program-order-successor of $i$, and every memory load operation $mlo'$ of $i'$ that was satisfied from $msoss'$, if there exists a memory store operation slice $msos'$ in $msoss'$, and an overlapping memory store operation slice from a different memory store operation in $msoss$, and $msos'$ is not from an instruction that is a program-order-successor of $i$, restart $i'$ and its {\em restart-dependents}.
-\end{enumerate}
-Where, the {\em restart-dependents} of instruction $j$ are:
-\begin{tightlist}
-\item program-order-successors of $j$ that have data-flow dependency on a register write of $j$;
-\item program-order-successors of $j$ that have a memory load operation that reads from a memory store operation of $j$ (by forwarding);
-\item if $j$ is a load-acquire, all the program-order-successors of $j$;
-\item if $j$ is a load, for every {\tt fence}, $f$, with {\tt .sr} and {\tt .pr} set, and {\tt .pw} not set, that is a program-order-successor of $j$, all the load instructions that are program-order-successors of $f$;
-\item if $j$ is a load, for every {\tt fence.tso}, $f$, that is a program-order-successor of $j$, all the load instructions that are program-order-successors of $f$;
-and \item (recursively) all the restart-dependents of all the instruction instances above.
-\end{tightlist}
-
-\begin{commentary}
-Forwarding memory store operations to a memory load might satisfy only some slices of the load, leaving other slices unsatisfied.
-
-A program-order-previous store operation that was not available when taking the transition above might make $msoss$ provisionally unsound (violating coherence) when it becomes available.
-That store will prevent the load from being finished (see \nameref{omm:finish}), and will cause it to restart when that store operation is propagated (see \nameref{omm:prop_store}).
-
-A consequence of the transition condition above is that store-release-RCsc memory store operations cannot be forwarded to load-acquire-RCsc instructions:
-$msoss$ does not include memory store operations from finished stores (as those must be propagated memory store operations), and the condition above requires all program-order-previous store-releases-RCsc to be finished when the load is acquire-RCsc.
-\end{commentary}
-
-
-\paragraph{Satisfy memory load operation from memory}\label{omm:sat_from_mem}
-For an instruction instance $i$ of a non-AMO load instruction or an AMO instruction in the context of the ``\nameref{omm:do_amo}'' transition, any memory load operation $mlo$ in $i.\textit{mem\_loads}$ that has unsatisfied slices, can be satisfied from memory if all the conditions of \nameref{omm:sat_by_forwarding} are satisfied.
-Action: let $msoss$ be the memory store operation slices from memory covering the unsatisfied slices of $mlo$, and apply the action of \nameref{omm:sat_by_forwarding}.
-
-\begin{commentary}
-Note that \nameref{omm:sat_by_forwarding} might leave some slices of the memory load operation unsatisfied, those will have to be satisfied by taking the transition again, or taking \nameref{omm:sat_from_mem}.
-\nameref{omm:sat_from_mem}, on the other hand, will always satisfy all the unsatisfied slices of the memory load operation.
-\end{commentary}
-
-
-\paragraph{Complete load operations}\label{omm:complete_loads}
-A load instruction instance $i$ in state {\sc Pending\_mem\_loads}({\it load\_continuation}) can be completed (not to be confused with finished) if all the memory load operations $i.\textit{mem\_loads}$ are entirely satisfied (i.e.~there are no unsatisfied slices).
-Action: update the state of $i$ to {\sc Plain}({\it load\_continuation(mem\_value)}), where {\it mem\_value} is assembled from all the memory store operation slices that satisfied $i.\textit{mem\_loads}$.
-
-
-\paragraph{Early {\tt sc} fail}\label{omm:early_sc_fail}
-An {\tt sc} instruction instance $i$ in state {\sc Plain}({\sc Early\_sc\_fail}({\it res\_continuation})) can always be made to fail.
-Action: update the state of $i$ to {\sc Plain}({\it res\_continuation(false)}).
-
-
-\paragraph{Paired {\tt sc}}\label{omm:paired_sc}
-An {\tt sc} instruction instance $i$ in state {\sc Plain}({\sc Early\_sc\_fail}({\it res\_continuation})) can continue its (potentially successful) execution if $i$ is paired with an {\tt lr}.
-Action: update the state of $i$ to {\sc Plain}({\it res\_continuation(true)}).
-
-
-\paragraph{Initiate memory store operation footprints}\label{omm:initiate_store_footprint}
-An instruction instance $i$ in state {\sc Plain}({\sc Store\_ea}({\it kind}, {\it address}, {\it size}, {\it next\_state})) can always announce its pending memory store operation footprint.
-Action:
-\begin{enumerate}
-\item construct the appropriate memory store operations $msos$ (without the store value):
- \begin{itemize}
- \item if {\it address} is aligned to {\it size} then $msos$ is a single memory store operation of {\it size} bytes to {\it address};
- \item otherwise, $msos$ is a set of {\it size} memory store operations, each of one-byte size, to the addresses $\textit{address}\ldots\textit{address}+\textit{size}-1$.
- \end{itemize}
-\item set $i.\textit{mem\_stores}$ to $msos$; and
-\item update the state of $i$ to {\sc Plain}({\it next\_state}).
-\end{enumerate}
-
-\begin{commentary}
-Note that after taking the transition above the memory store operations do not yet have their values.
-The importance of splitting this transition from the transition below is that it allows other program-order-successor store instructions to observe the memory footprint of this instruction, and if they don't overlap, propagate out of order as early as possible (i.e.~before the data register value becomes available).
-\end{commentary}
-
-
-\paragraph{Instantiate memory store operation values}\label{omm:instantiate_store_value}
-An instruction instance $i$ in state {\sc Plain}({\sc Store\_memv}({\it mem\_value}, {\it store\_continuation})) can always instantiate the values of the memory store operations $i.\textit{mem\_stores}$.
-Action:
-\begin{enumerate}
-\item split {\it mem\_value} between the memory store operations $i.\textit{mem\_stores}$; and
-\item update the state of $i$ to {\sc Pending\_mem\_stores}({\it store\_continuation}).
-\end{enumerate}
-
-
-\paragraph{Commit store instruction}\label{omm:commit_stores}
-An uncommitted instruction instance $i$ of a non-{\tt sc} store instruction or an {\tt sc} instruction in the context of the ``\nameref{omm:commit_sc}'' transition, in state {\sc Pending\_mem\_stores}({\it store\_continuation}), can be committed (not to be confused with propagated) if:
-\begin{enumerate}
-\item $i$ has fully determined data;
-\item all program-order-previous conditional branch and indirect jump instructions are finished;
-\item all program-order-previous {\tt fence} instructions with {\tt .sw} set are finished;
-\item all program-order-previous {\tt fence.tso} instructions are finished;
-% \item all program-order-previous {\tt fence.i} instructions are finished;
-\item all program-order-previous load-acquire instructions are finished;
-\item all program-order-previous store-acquire-release instructions are finished;
-\item if $i$ is a store-release, all program-order-previous instructions are finished;
-\item\label{omm:commit_store:prev_addrs} all program-order-previous memory access instructions have a fully determined memory footprint;
-\item\label{omm:commit_store:prev_stores} all program-order-previous store instructions, except for {\tt sc} that failed, have initiated and so have non-empty {\it mem\_stores}; and
-\item\label{omm:commit_store:prev_loads} all program-order-previous load instructions have initiated and so have non-empty {\it mem\_loads}.
-\end{enumerate}
-Action: record that $i$ is committed.
-
-\begin{commentary}
-Notice that if condition \ref{omm:commit_store:prev_addrs} is satisfied the conditions \ref{omm:commit_store:prev_stores} and \ref{omm:commit_store:prev_loads} are also satisfied, or will be satisfied after taking some eager transitions.
-Hence, requiring them does not strengthen the model.
-By requiring them, we guarantee that previous memory access instructions have taken enough transitions to make their memory operations visible for the condition check of \nameref{omm:prop_store}, which is the next transition the instruction will take, making that condition simpler.
-\end{commentary}
-
-
-\paragraph{Propagate store operation}\label{omm:prop_store}
-For a committed instruction instance $i$ in state {\sc Pending\_mem\_stores}({\it store\_continuation}), and an unpropagated memory store operation $mso$ in $i.\textit{mem\_stores}$, $mso$ can be propagated if:
-\begin{enumerate}
-\item all memory store operations of program-order-previous store instructions that overlap with $mso$ have already propagated;
-\item all memory load operations of program-order-previous load instructions that overlap with $mso$ have already been satisfied, and (the load instructions) are {\em non-restartable} (see definition below); and
-\item all memory load operations that were satisfied by forwarding $mso$ are entirely satisfied.
-\end{enumerate}
-Where a non-finished instruction instance $j$ is {\em non-restartable} if:
-\begin{enumerate}
-\item there does not exist a store instruction $s$ and an unpropagated memory store operation $mso$ of $s$ such that applying the action of the ``\nameref{omm:prop_store}'' transition to $mso$ will result in the restart of $j$; and
-\item there does not exist a non-finished load instruction $l$ and a memory load operation $mlo$ of $l$ such that applying the action of the ``\nameref{omm:sat_by_forwarding}''/``\nameref{omm:sat_from_mem}'' transition (even if $mlo$ is already satisfied) to $mlo$ will result in the restart of $j$.
-\end{enumerate}
-Action:
-\begin{enumerate}
-\item update the shared memory state with $mso$;
-\item update $i.\textit{mem\_stores}$ to indicate that $mso$ was propagated; and
-\item restart any speculative instructions which have violated coherence as a result of this, i.e., for every non-finished instruction $i'$ program-order-after $i$ and every memory load operation $mlo'$ of $i'$ that was satisfied from $msoss'$, if there exists a memory store operation slice $msos'$ in $msoss'$ that overlaps with $mso$ and is not from $mso$, and $msos'$ is not from a program-order-successor of $i$, restart $i'$ and its {\em restart-dependents} (see \nameref{omm:sat_by_forwarding}).
-\end{enumerate}
-
-
-\paragraph{Commit and propagate store operation of an {\tt sc}}\label{omm:commit_sc}
-An uncommitted {\tt sc} instruction instance $i$, from hart $h$, in state {\sc Pending\_mem\_stores}({\it store\_continuation}), with a paired {\tt lr} $i'$ that has been satisfied by some store slices $msoss$, can be committed and propagated at the same time if:
-\begin{enumerate}
-\item $i'$ is finished;
-\item every memory store operation that has been forwarded to $i'$ is propagated;
-\item the conditions of \nameref{omm:commit_stores} is satisfied;
-\item the conditions of \nameref{omm:prop_store} is satisfied (notice that an {\tt sc} instruction can only have one memory store operation); and
-\item for every store slice $msos$ from $msoss$, $msos$ has not been overwritten, in the shared memory, by a store that is from a hart that is not $h$, at any point since $msos$ was propagated to memory.
-\end{enumerate}
-Action:
-\begin{enumerate}
-\item apply the actions of \nameref{omm:commit_stores}; and
-\item apply the action of \nameref{omm:prop_store}.
-\end{enumerate}
-
-
-\paragraph{Late {\tt sc} fail}\label{omm:late_sc_fail}
-An {\tt sc} instruction instance $i$ in state {\sc Pending\_mem\_stores}({\it store\_continuation}), that has not propagated its memory store operation, can always be made to fail.
-Action:
-\begin{enumerate}
-\item clear $i.\textit{mem\_stores}$; and
-\item update the state of $i$ to {\sc Plain}({\it store\_continuation(false)}).
-\end{enumerate}
-
-\begin{commentary}
-For efficiency, the {\tt rmem} tool allows this transition only when it is not possible to take the \nameref{omm:commit_sc} transition.
-This does not affect the set of allowed final states, but when explored interactively, if the {\tt sc} should fail one should use the \nameref{omm:early_sc_fail} transition instead of waiting for this transition.
-\end{commentary}
-
-\paragraph{Complete store operations}\label{omm:complete_stores}
-A store instruction instance $i$ in state {\sc Pending\_mem\_stores}({\it store\_continuation}), for which all the memory store operations in $i.\textit{mem\_stores}$ have been propagated, can always be completed (not to be confused with finished).
-Action: update the state of $i$ to {\sc Plain}({\it store\_continuation(true)}).
-
-
-\paragraph{Satisfy, commit and propagate operations of an AMO}\label{omm:do_amo}
-An AMO instruction instance $i$ in state {\sc Pending\_mem\_loads}({\it load\_continuation}) can perform its memory access if it is possible to perform the following sequence of transitions with no intervening transitions:
-\begin{enumerate}
-\item \nameref{omm:sat_from_mem}
-\item \nameref{omm:complete_loads}
-\item \nameref{omm:sail_interp} (zero or more times)
-\item \nameref{omm:instantiate_store_value}
-\item \nameref{omm:commit_stores}
-\item \nameref{omm:prop_store}
-\item \nameref{omm:complete_stores}
-\end{enumerate}
-and in addition, the condition of \nameref{omm:finish}, with the exception of not requiring $i$ to be in state {\sc Plain}({\sc Done}), holds after those transitions.
-Action: perform the above sequence of transitions (this does not include \nameref{omm:finish}), one after the other, with no intervening transitions.
-
-\begin{commentary}
-Notice that program-order-previous stores cannot be forwarded to the load of an AMO.
-This is simply because the sequence of transitions above does not include the forwarding transition.
-But even if it did include it, the sequence will fail when trying to do the \nameref{omm:prop_store} transition, as this transition requires all program-order-previous store operations to overlapping memory footprints to be propagated, and forwarding requires the store operation to be unpropagated.
-
-In addition, the store of an AMO cannot be forwarded to a program-order-successor load.
-Before taking the transition above, the store operation of the AMO does not have its value and therefore cannot be forwarded; after taking the transition above the store operation is propagated and therefore cannot be forwarded.
-\end{commentary}
-
-
-\paragraph{Commit fence}\label{omm:commit_fence}
-A fence instruction instance $i$ in state {\sc Plain}({\sc Fence}({\it kind}, {\it next\_state})) can be committed if:
-\begin{enumerate}
-\item if $i$ is a normal fence and it has {\tt .pr} set, all program-order-previous load instructions are finished;
-\item if $i$ is a normal fence and it has {\tt .pw} set, all program-order-previous store instructions are finished; and
-\item if $i$ is a {\tt fence.tso}, all program-order-previous load and store instructions are finished.
-% \item if $i$ is a {\tt fence.i} instruction, all program-order-previous memory access instructions have fully determined memory footprints.
-\end{enumerate}
-Action:
-\begin{enumerate}
-\item record that $i$ is committed; and
-\item update the state of $i$ to {\sc Plain}({\it next\_state}).
-\end{enumerate}
-
-
-\paragraph{Register read}\label{omm:reg_read}
-An instruction instance $i$ in state {\sc Plain}({\sc Read\_reg}({\it reg\_name}, {\it read\_cont})) can do a register read of {\it reg\_name} if every instruction instance that it needs to read from has already performed the expected {\it reg\_name} register write.
-
-Let {\it read\_sources} include, for each bit of {\it reg\_name}, the write to
-that bit by the most recent (in program order) instruction instance that can write to that bit, if any. If there is no such instruction, the source is the initial register value from {\it initial\_register\_state}.
-Let {\it reg\_value} be the value assembled from {\it read\_sources}.
-Action:
-\begin{enumerate}
-\item add {\it reg\_name} to $i.\textit{reg\_reads}$ with {\it read\_sources} and {\it reg\_value}; and
-\item update the state of $i$ to {\sc Plain}({\it read\_cont(reg\_value)}).
-\end{enumerate}
-
-
-\paragraph{Register write}\label{omm:reg_write}
-An instruction instance $i$ in state {\sc Plain}({\sc Write\_reg}({\it reg\_name}, {\it reg\_value}, {\it next\_state})) can always do a {\it reg\_name} register write.
-Action:
-\begin{enumerate}
-\item add {\it reg\_name} to $i.\textit{reg\_writes}$ with $deps$ and {\it reg\_value}; and
-\item update the state of $i$ to {\sc Plain}({\it next\_state}).
-\end{enumerate}
-where $deps$ is a pair of the set of all {\it read\_sources} from $i.\textit{reg\_reads}$, and a flag that is true iff $i$ is a load instruction instance that has already been entirely satisfied.
-
-
-\paragraph{Pseudocode internal step}\label{omm:sail_interp}
-An instruction instance $i$ in state {\sc Plain}({\sc Internal}({\it next\_state})) can always do that pseudocode-internal step.
-Action: update the state of $i$ to {\sc Plain}({\it next\_state}).
-
-
-\paragraph{Finish instruction}\label{omm:finish}
-A non-finished instruction instance $i$ in state {\sc Plain}({\sc Done}) can be finished if:
-\begin{enumerate}
-\item if $i$ is a load instruction:
- \begin{enumerate}
- \item all program-order-previous load-acquire instructions are finished;
- \item all program-order-previous {\tt fence} instructions with {\tt .sr} set are finished;
- \item for every program-order-previous {\tt fence.tso} instruction, $f$, that is not finished, all load instructions that are program-order-before $f$ are finished; and
- \item it is guaranteed that the values read by the memory load operations of $i$ will not cause coherence violations, i.e., for any program-order-previous instruction instance $i'$, let $\textit{cfp}$ be the combined footprint of propagated memory store operations from store instructions program-order-between $i$ and $i'$, and {\em fixed memory store operations} that were forwarded to $i$ from store instructions program-order-between $i$ and $i'$ including $i'$, and let $\overline{\textit{cfp}}$ be the complement of $\textit{cfp}$ in the memory footprint of $i$.
- If $\overline{\textit{cfp}}$ is not empty:
- \begin{enumerate}
- \item $i'$ has a fully determined memory footprint;
- \item $i'$ has no unpropagated memory store operations that overlap with $\overline{\textit{cfp}}$; and
- \item if $i'$ is a load with a memory footprint that overlaps with $\overline{\textit{cfp}}$, then all the memory load operations of $i'$ that overlap with $\overline{\textit{cfp}}$ are satisfied and $i'$ is {\em non-restartable} (see the \nameref{omm:prop_store} transition for how to determined if an instruction is non-restartable).
- \end{enumerate}
- Here, a memory store operation is called fixed if the store instruction has fully determined data.
- \end{enumerate}
-\item $i$ has a fully determined data; and
-\item if $i$ is not a fence, all program-order-previous conditional branch and indirect jump instructions are finished.
-\end{enumerate}
-Action:
-\begin{enumerate}
-\item if $i$ is a conditional branch or indirect jump instruction, discard any untaken paths of execution, i.e., remove all instruction instances that are not reachable by the branch/jump taken in {\it instruction\_tree}; and
-\item record the instruction as finished, i.e., set {\it finished} to {\it true}.
-\end{enumerate}
-
-
-\subsection{Limitations}\label{sec:omm:limitations}
-\begin{itemize}
-\item The model covers user-level RV64I and RV64A.
-In particular, it does not support the misaligned atomics extension ``Zam'' or the total store ordering extension ``Ztso''.
-It should be trivial to adapt the model to RV32I/A and to the G, Q and C extensions, but we have never tried it. This will involve, mostly, writing Sail code for the instructions, with minimal, if any, changes to the concurrency model.
-% unsupported (system) instructions: ecall, ebreak, csrrw, csrrs, csrrc, csrrwi, csrrsi, csrrci
-\item The model covers only normal memory accesses (it does not handle I/O accesses).
-\item The model does not cover TLB-related effects.
-\item The model assumes the instruction memory is fixed.
-In particular, the \nameref{omm:fetch} transition does not generate memory load operations, and the shared memory is not involved in the transition.
-Instead, the model depends on an external oracle that provides an opcode when given a memory location.
-\item The model does not cover exceptions, traps and interrupts.
-\end{itemize}
-
diff --git a/src/memory.tex b/src/memory.tex
deleted file mode 100644
index 936df17..0000000
--- a/src/memory.tex
+++ /dev/null
@@ -1,1422 +0,0 @@
-%%%%Nice fonts in diagrams
-%%Images
-\makeatletter
-% for the fig2dev version on P desktop
-\gdef\SetFigFont#1#2#3#4#5{%
- \reset@font\fontsize{12}{#2pt}%
-% \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
- \fontfamily{\sfdefault}\fontseries{#4}\fontshape{#5}%
- \selectfont}
-\makeatother
-
-\chapter{RVWMO Explanatory Material, Version 0.1}
-\label{sec:memorymodelexplanation}
-This section provides more explanation for RVWMO (Chapter~\ref{ch:memorymodel}), using more informal language and concrete examples.
-These are intended to clarify the meaning and intent of the axioms and preserved program order rules.
-This appendix should be treated as commentary; all normative material is provided in Chapter~\ref{ch:memorymodel} and in the rest of the main body of the ISA specification.
-All currently known discrepancies are listed in Section~\ref{sec:memory:discrepancies}.
-Any other discrepancies are unintentional.
-
-\section{Why RVWMO?}
-\label{sec:whyrvwmo}
-
-Memory consistency models fall along a loose spectrum from weak to strong.
-Weak memory models allow more hardware implementation flexibility and deliver arguably better performance, performance per watt, power, scalability, and hardware verification overheads than strong models, at the expense of a more complex programming model.
-Strong models provide simpler programming models, but at the cost of imposing more restrictions on the kinds of (non-speculative) hardware optimizations that can be performed in the pipeline and in the memory system, and in turn imposing some cost in terms of power, area overhead, and verification burden.
-
-RISC-V has chosen the RVWMO memory model, a variant of release consistency.
-This places it in between the two extremes of the memory model spectrum.
-The RVWMO memory model enables architects to build simple implementations, aggressive implementations, implementations embedded deeply inside a much larger system and subject to complex memory system interactions, or any number of other possibilities, all while simultaneously being strong enough to support programming language memory models at high performance.
-
-To facilitate the porting of code from other architectures, some hardware implementations may choose to implement the Ztso extension, which provides stricter RVTSO ordering semantics by default.
-Code written for RVWMO is automatically and inherently compatible with RVTSO, but code written assuming RVTSO is not guaranteed to run correctly on RVWMO implementations.
-In fact, most RVWMO implementations will (and should) simply refuse to run RVTSO-only binaries.
-Each implementation must therefore choose whether to prioritize compatibility with RVTSO code (e.g., to facilitate porting from x86) or whether to instead prioritize compatibility with other RISC-V cores implementing RVWMO.
-
-Some fences and/or memory ordering annotations in code written for RVWMO may become redundant under RVTSO; the cost that the default of RVWMO imposes on Ztso implementations is the incremental overhead of fetching those fences (e.g., FENCE~R,RW and FENCE~RW,W) which become no-ops on that implementation.
-However, these fences must remain present in the code if compatibility with non-Ztso implementations is desired.
-
-\section{Litmus Tests}
-The explanations in this chapter make use of {\em litmus tests}, or small programs designed to test or highlight one particular aspect of a memory model.
-Figure~\ref{fig:litmus:sample} shows an example of a litmus test with two harts.
-As a convention for this figure and for all figures that follow in this chapter, we assume that {\tt s0}--{\tt s2} are pre-set to the same value in all harts and that {\tt s0} holds the address labeled {\tt x}, {\tt s1} holds {\tt y}, and {\tt s2} holds {\tt z}, where {\tt x}, {\tt y}, and {\tt z} are disjoint memory locations aligned to 8 byte boundaries.
-Each figure shows the litmus test code on the left, and a visualization of one particular valid or invalid execution on the right.
-
-\begin{figure}[h!]
- \centering
- \begin{tabular}{m{.4\linewidth}m{.05\linewidth}m{.4\linewidth}}
- \tt\small
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & $\vdots$ & & $\vdots$ \\
- & li t1,1 & & li t4,4 \\
- (a) & sw t1,0(s0) & (e) & sw t4,0(s0) \\
- & $\vdots$ & & $\vdots$ \\
- & li t2,2 & & \\
- (b) & sw t2,0(s0) & & \\
- & $\vdots$ & & $\vdots$ \\
- (c) & lw a0,0(s0) & & \\
- & $\vdots$ & & $\vdots$ \\
- & li t3,3 & & li t5,5 \\
- (d) & sw t3,0(s0) & (f) & sw t5,0(s0) \\
- & $\vdots$ & & $\vdots$ \\
- \end{tabular}
- & &
- \input{figs/litmus_sample.pdf_t}
-\end{tabular}
- \caption{A sample litmus test and one forbidden execution ({\tt a0=1}).}
- \label{fig:litmus:sample}
-\end{figure}
-
-Litmus tests are used to understand the implications of the memory model in specific concrete situations.
-For example, in the litmus test of Figure~\ref{fig:litmus:sample}, the final value of {\tt a0} in the first hart can be either 2, 4, or 5, depending on the dynamic interleaving of the instruction stream from each hart at runtime.
-However, in this example, the final value of {\tt a0} in Hart 0 will never be 1 or 3; intuitively, the value 1 will no longer be visible at the time the load executes, and the value 3 will not yet be visible by the time the load executes.
-We analyze this test and many others below.
-
-\begin{table}[h]
- \centering\small
- \begin{tabular}{|c|l|}
- \hline
- Edge & Full Name (and explanation) \\
- \hline
- \sf rf & Reads From (from each store to the loads that return a value written by that store) \\
- \hline
- \sf co & Coherence (a total order on the stores to each address) \\
- \hline
- \sf fr & From-Reads (from each load to co-successors of the store from which the load returned a value) \\
- \hline
- \sf ppo & Preserved Program Order \\
- \hline
- \sf fence & Orderings enforced by a FENCE instruction \\
- \hline
- \sf addr & Address Dependency \\
- \hline
- \sf ctrl & Control Dependency \\
- \hline
- \sf data & Data Dependency \\
- \hline
- \end{tabular}
- \caption{A key for the litmus test diagrams drawn in this appendix}
- \label{tab:litmus:key}
-\end{table}
-
-The diagram shown to the right of each litmus test shows a visual representation of the particular execution candidate being considered.
-These diagrams use a notation that is common in the memory model literature for constraining the set of possible global memory orders that could produce the execution in question.
-It is also the basis for the \textsf{herd} models presented in Appendix~\ref{sec:herd}.
-This notation is explained in Table~\ref{tab:litmus:key}.
-Of the listed relations, {\sf rf} edges between harts, {\sf co} edges, {\sf fr} edges, and {\sf ppo} edges directly constrain the global memory order (as do {\sf fence}, {\sf addr}, {\sf data}, and some {\sf ctrl} edges, via {\sf ppo}).
-Other edges (such as intra-hart {\sf rf} edges) are informative but do not constrain the global memory order.
-
-For example, in Figure~\ref{fig:litmus:sample}, {\tt a0=1} could occur only if one of the following were true:
-\begin{itemize}
- \item (b) appears before (a) in global memory order (and in the coherence order {\sf co}). However, this violates RVWMO PPO rule~\ref{ppo:->st}. The {\sf co} edge from (b) to (a) highlights this contradiction.
- \item (a) appears before (b) in global memory order (and in the coherence order {\sf co}). However, in this case, the Load Value Axiom would be violated, because (a) is not the latest matching store prior to (c) in program order. The {\sf fr} edge from (c) to (b) highlights this contradiction.
-\end{itemize}
-Since neither of these scenarios satisfies the RVWMO axioms, the outcome {\tt a0=1} is forbidden.
-
-Beyond what is described in this appendix, a suite of more than seven thousand litmus tests is available at \url{http://diy.inria.fr/cats7/riscv/}.
-
-\begin{commentary}
- In the future, we expect to adapt these memory model litmus tests for use as part of the RISC-V compliance test suite as well.
-\end{commentary}
-
-\section{Explaining the RVWMO Rules}
-In this section, we provide explanation and examples for all of the RVWMO rules and axioms.
-
-\subsection{Preserved Program Order and Global Memory Order}
-Preserved program order represents the subset of program order that must be respected within the global memory order.
-Conceptually, events from the same hart that are ordered by preserved program order must appear in that order from the perspective of other harts and/or observers.
-Events from the same hart that are not ordered by preserved program order, on the other hand, may appear reordered from the perspective of other harts and/or observers.
-
-Informally, the global memory order represents the order in which loads and stores perform.
-The formal memory model literature has moved away from specifications built around the concept of performing, but the idea is still useful for building up informal intuition.
-A load is said to have performed when its return value is determined.
-A store is said to have performed not when it has executed inside the pipeline, but rather only when its value has been propagated to globally visible memory.
-In this sense, the global memory order also represents the contribution of the coherence protocol and/or the rest of the memory system to interleave the (possibly reordered) memory accesses being issued by each hart into a single total order agreed upon by all harts.
-
-The order in which loads perform does not always directly correspond to the relative age of the values those two loads return.
-In particular, a load $b$ may perform before another load $a$ to the same address (i.e., $b$ may execute before $a$, and $b$ may appear before $a$ in the global memory order), but $a$ may nevertheless return an older value than $b$.
-This discrepancy captures (among other things) the reordering effects of buffering placed between the core and memory.
-For example, $b$ may have returned a value from a store in the store buffer, while $a$ may have ignored that younger store and read an older value from memory instead.
-To account for this, at the time each load performs, the value it returns is determined by the load value axiom, not just strictly by determining the most recent store to the same address in the global memory order, as described below.
-
-\subsection{\nameref*{rvwmo:ax:load}}
-\label{sec:memory:loadvalueaxiom}
-\begin{tabular}{p{1cm}|p{12cm}} &
-\nameref{rvwmo:ax:load}: \loadvalueaxiom
-\end{tabular}
-
-Preserved program order is {\em not} required to respect the ordering of a store followed by a load to an overlapping address.
-This complexity arises due to the ubiquity of store buffers in nearly all implementations.
-Informally, the load may perform (return a value) by forwarding from the store while the store is still in the store buffer, and hence before the store itself performs (writes back to globally visible memory).
-Any other hart will therefore observe the load as performing before the store.
-
-\begin{figure}[h!]
- \centering
- \begin{tabular}{m{.4\linewidth}@{\qquad}m{.45\linewidth}}
- {
- \tt\small
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & li t1, 1 & & li t1, 1 \\
- (a) & sw t1,0(s0) & (e) & sw t1,0(s1) \\
- (b) & lw a0,0(s0) & (f) & lw a2,0(s1) \\
- (c) & fence r,r & (g) & fence r,r \\
- (d) & lw a1,0(s1) & (h) & lw a3,0(s0) \\
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=1}, {\tt a1=0}, {\tt a2=1}, {\tt a3=0}}
- \end{tabular}
- }
- &
- \input{figs/litmus_sb_fwd.pdf_t}
- \end{tabular}
- \caption{A store buffer forwarding litmus test (outcome permitted)}
- \label{fig:litmus:storebuffer}
-\end{figure}
-
-Consider the litmus test of Figure~\ref{fig:litmus:storebuffer}.
-When running this program on an implementation with store buffers, it is possible to arrive at the final outcome
-{\tt a0=1}, {\tt a1=0}, {\tt a2=1}, {\tt a3=0}
-as follows:
-\begin{itemize}
- \item (a) executes and enters the first hart's private store buffer
- \item (b) executes and forwards its return value 1 from (a) in the store buffer
- \item (c) executes since all previous loads (i.e., (b)) have completed
- \item (d) executes and reads the value 0 from memory
- \item (e) executes and enters the second hart's private store buffer
- \item (f) executes and forwards its return value 1 from (e) in the store buffer
- \item (g) executes since all previous loads (i.e., (f)) have completed
- \item (h) executes and reads the value 0 from memory
- \item (a) drains from the first hart's store buffer to memory
- \item (e) drains from the second hart's store buffer to memory
-\end{itemize}
-Therefore, the memory model must be able to account for this behavior.
-
-To put it another way, suppose the definition of preserved program order did include the following hypothetical rule:
-memory access $a$ precedes memory access $b$ in preserved program order (and hence also in the global memory order) if $a$ precedes $b$ in program order and $a$ and $b$ are accesses to the same memory location, $a$ is a write, and $b$ is a read. Call this ``Rule X''. Then we get the following:
-
-\begin{itemize}
- \item (a) precedes (b): by rule X
- \item (b) precedes (d): by rule \ref{ppo:fence}
- \item (d) precedes (e): by the load value axiom. Otherwise, if (e) preceded (d), then (d) would be required to return the value 1. (This is a perfectly legal execution; it's just not the one in question)
- \item (e) precedes (f): by rule X
- \item (f) precedes (h): by rule \ref{ppo:fence}
- \item (h) precedes (a): by the load value axiom, as above.
-\end{itemize}
-The global memory order must be a total order and cannot be cyclic, because a cycle would imply that every event in the cycle happens before itself, which is impossible.
-Therefore, the execution proposed above would be forbidden, and hence the addition of rule X would forbid implementations with store buffer forwarding, which would clearly be undesirable.
-
-Nevertheless, even if (b) precedes (a) and/or (f) precedes (e) in the global memory order, the only sensible possibility in this example is for (b) to return the value written by (a), and likewise for (f) and (e). This combination of circumstances is what leads to the second option in the definition of the load value axiom.
-Even though (b) precedes (a) in the global memory order, (a) will still be visible to (b) by virtue of sitting in the store buffer at the time (b) executes.
-Therefore, even if (b) precedes (a) in the global memory order, (b) should return the value written by (a) because (a) precedes (b) in program order.
-Likewise for (e) and (f).
-
-\begin{figure}[h!]
- \centering
- \begin{tabular}{m{.4\linewidth}@{\qquad}m{.4\linewidth}}
- {
- \tt\small
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & li t1, 1 & & li t1, 1 \\
- (a) & sw t1,0(s0) & & LOOP: \\
- (b) & fence w,w & (d) & lw a0,0(s1) \\
- (c) & sw t1,0(s1) & & beqz a0, LOOP \\
- & & (e) & sw t1,0(s2) \\
- & & (f) & lw a1,0(s2) \\
- & & & xor a2,a1,a1 \\
- & & & add s0,s0,a2 \\
- & & (g) & lw a2,0(s0) \\
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=1}, {\tt a1=1}, {\tt a2=0}}
- \end{tabular}
- }
- &
- \input{figs/litmus_ppoca.pdf_t}
- \end{tabular}
- \caption{The ``PPOCA'' store buffer forwarding litmus test (outcome permitted)}
- \label{fig:litmus:ppoca}
-\end{figure}
-
-Another test that highlights the behavior of store buffers is shown in Figure~\ref{fig:litmus:ppoca}.
-In this example, (d) is ordered before (e) because of the control dependency, and (f) is ordered before (g) because of the address dependency.
-However, (e) is {\em not} necessarily ordered before (f), even though (f) returns the value written by (e).
-This could correspond to the following sequence of events:
-\begin{itemize}
- \item (e) executes speculatively and enters the second hart's private store buffer (but does not drain to memory)
- \item (f) executes speculatively and forwards its return value 1 from (e) in the store buffer
- \item (g) executes speculatively and reads the value 0 from memory
- \item (a) executes, enters the first hart's private store buffer, and drains to memory
- \item (b) executes and retires
- \item (c) executes, enters the first hart's private store buffer, and drains to memory
- \item (d) executes and reads the value 1 from memory
- \item (e), (f), and (g) commit, since the speculation turned out to be correct
- \item (e) drains from the store buffer to memory
-\end{itemize}
-
-\subsection{\nameref*{rvwmo:ax:atom}}
-\label{sec:memory:atomicityaxiom}
-\begin{tabular}{p{1cm}|p{12cm}} &
-\nameref{rvwmo:ax:atom} (for Aligned Atomics): \atomicityaxiom
-\end{tabular}
-
-The RISC-V architecture decouples the notion of atomicity from the notion of ordering. Unlike architectures such as TSO, RISC-V atomics under RVWMO do not impose any ordering requirements by default. Ordering semantics are only guaranteed by the PPO rules that otherwise apply.
-
-RISC-V contains two types of atomics: AMOs and LR/SC pairs.
-These conceptually behave differently, in the following way.
-LR/SC behave as if the old value is brought up to the core, modified, and written back to memory, all while a reservation is held on that memory location.
-AMOs on the other hand conceptually behave as if they are performed directly in memory.
-AMOs are therefore inherently atomic, while LR/SC pairs are atomic in the slightly different sense that the memory location in question will not be modified by another hart during the time the original hart holds the reservation.
-
-\begin{figure}[h!]
- \centering\small
- \begin{verbbox}
- (a) lr.d a0, 0(s0)
- (b) sd t1, 0(s0)
- (c) sc.d t2, 0(s0)
- \end{verbbox}
- \theverbbox
- ~~~~~~
- \begin{verbbox}
- (a) lr.d a0, 0(s0)
- (b) sw t1, 4(s0)
- (c) sc.d t2, 0(s0)
- \end{verbbox}
- \theverbbox
- ~~~~~~
- \begin{verbbox}
- (a) lr.w a0, 0(s0)
- (b) sw t1, 4(s0)
- (c) sc.w t2, 0(s0)
- \end{verbbox}
- \theverbbox
- ~~~~~~
- \begin{verbbox}
- (a) lr.w a0, 0(s0)
- (b) sw t1, 4(s0)
- (c) sc.w t2, 8(s0)
- \end{verbbox}
- \theverbbox
- \caption{In all four (independent) code snippets, the store-conditional (c) is permitted but not guaranteed to succeed}
- \label{fig:litmus:lrsdsc}
-\end{figure}
-
-The atomicity axiom forbids stores from other harts from being interleaved in global memory order between an LR and the SC paired with that LR.
-The atomicity axiom does not forbid loads from being interleaved between the paired operations in program order or in the global memory order, nor does it forbid stores from the same hart or stores to non-overlapping locations from appearing between the paired operations in either program order or in the global memory order.
-For example, the SC instructions in Figure~\ref{fig:litmus:lrsdsc} may (but are not guaranteed to) succeed.
-None of those successes would violate the atomicity axiom, because the intervening non-conditional stores are from the same hart as the paired load-reserved and store-conditional instructions.
-This way, a memory system that tracks memory accesses at cache line granularity (and which therefore will see the four snippets of Figure~\ref{fig:litmus:lrsdsc} as identical) will not be forced to fail a store-conditional instruction that happens to (falsely) share another portion of the same cache line as the memory location being held by the reservation.
-
-The atomicity axiom also technically supports cases in which the LR and SC touch different addresses and/or use different access sizes; however, use cases for such behaviors are expected to be rare in practice.
-Likewise, scenarios in which stores from the same hart between an LR/SC pair actually overlap the memory location(s) referenced by the LR or SC are expected to be rare compared to scenarios where the intervening store may simply fall onto the same cache line.
-
-\subsection{\nameref*{rvwmo:ax:prog}}
-\label{sec:memory:progress}
-\begin{tabular}{p{1cm}|p{12cm}} &
-\nameref{rvwmo:ax:prog}: \progressaxiom
-\end{tabular}
-
-The progress axiom ensures a minimal forward progress guarantee.
-It ensures that stores from one hart will eventually be made visible to other harts in the system in a finite amount of time, and that loads from other harts will eventually be able to read those values (or successors thereof).
-Without this rule, it would be legal, for example, for a spinlock to spin infinitely on a value, even with a store from another hart waiting to unlock the spinlock.
-
-The progress axiom is intended not to impose any other notion of fairness, latency, or quality of service onto the harts in a RISC-V implementation.
-Any stronger notions of fairness are up to the rest of the ISA and/or up to the platform and/or device to define and implement.
-
-The forward progress axiom will in almost all cases be naturally satisfied by any standard cache coherence protocol.
-Implementations with non-coherent caches may have to provide some other mechanism to ensure the eventual visibility of all stores (or successors thereof) to all harts.
-
-\subsection{Overlapping-Address Orderings (Rules~\ref{ppo:->st}--\ref{ppo:amoforward})}
-\label{sec:memory:overlap}
-\begin{tabular}{p{1cm}|p{12cm}}
- & Rule \ref{ppo:->st}: \ppost \\
- & Rule \ref{ppo:rdw}: \ppordw \\
- & Rule \ref{ppo:amoforward}: \ppoamoforward \\
-\end{tabular}
-
-Same-address orderings where the latter is a store are straightforward: a load or store can never be reordered with a later store to an overlapping memory location. From a microarchitecture perspective, generally speaking, it is difficult or impossible to undo a speculatively reordered store if the speculation turns out to be invalid, so such behavior is simply disallowed by the model.
-Same-address orderings from a store to a later load, on the other hand, do not need to be enforced.
-As discussed in Section~\ref{sec:memory:loadvalueaxiom}, this reflects the observable behavior of implementations that forward values from buffered stores to later loads.
-
-Same-address load-load ordering requirements are far more subtle.
-The basic requirement is that a younger load must not return a value that is older than a value returned by an older load in the same hart to the same address. This is often known as ``CoRR'' (Coherence for Read-Read pairs), or as part of a broader ``coherence'' or ``sequential consistency per location'' requirement.
-Some architectures in the past have relaxed same-address load-load ordering, but in hindsight this is generally considered to complicate the programming model too much, and so RVWMO requires CoRR ordering to be enforced.
-However, because the global memory order corresponds to the order in which loads perform rather than the ordering of the values being returned, capturing CoRR requirements in terms of the global memory order requires a bit of indirection.
-
-\begin{figure}[h!]
- \center
- \begin{tabular}{m{.4\linewidth}@{\qquad}m{.4\linewidth}}
- {\tt\small
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & li t1, 1 & & li~ t2, 2 \\
- (a) & sw t1,0(s0) & (d) & lw~ a0,0(s1) \\
- (b) & fence w, w & (e) & sw~ t2,0(s1) \\
- (c) & sw t1,0(s1) & (f) & lw~ a1,0(s1) \\
- & & (g) & xor t3,a1,a1 \\
- & & (h) & add s0,s0,t3 \\
- & & (i) & lw~ a2,0(s0) \\
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=1}, {\tt a1=2}, {\tt a2=0}}
- \end{tabular}
- }
- &
- \input{figs/litmus_mp_fenceww_fri_rfi_addr.pdf_t}
- \end{tabular}
- \caption{Litmus test MP+fence.w.w+fri-rfi-addr (outcome permitted)}
- \label{fig:litmus:frirfi}
-\end{figure}
-
-Consider the litmus test of Figure~\ref{fig:litmus:frirfi}, which is one particular instance of the more general ``fri-rfi'' pattern.
-The term ``fri-rfi'' refers to the sequence (d), (e), (f): (d) ``from-reads'' (i.e., reads from an earlier write than) (e) which is the same hart, and (f) reads from (e) which is in the same hart.
-
-From a microarchitectural perspective, outcome {\tt a0=1}, {\tt a1=2}, {\tt a2=0} is legal (as are various other less subtle outcomes). Intuitively, the following would produce the outcome in question:
-\begin{itemize}
- \item (d) stalls (for whatever reason; perhaps it's stalled waiting for some other preceding instruction)
- \item (e) executes and enters the store buffer (but does not yet drain to memory)
- \item (f) executes and forwards from (e) in the store buffer
- \item (g), (h), and (i) execute
- \item (a) executes and drains to memory, (b) executes, and (c) executes and drains to memory
- \item (d) unstalls and executes
- \item (e) drains from the store buffer to memory
-\end{itemize}
-This corresponds to a global memory order of (f), (i), (a), (c), (d), (e).
-Note that even though (f) performs before (d), the value returned by (f) is newer than the value returned by (d).
-Therefore, this execution is legal and does not violate the CoRR requirements.
-
-Likewise, if two back-to-back loads return the values written by the same store, then they may also appear out-of-order in the global memory order without violating CoRR. Note that this is not the same as saying that the two loads return the same value, since two different stores may write the same value.
-
-\begin{figure}[h!]
- \centering
- \begin{tabular}{m{.4\linewidth}@{\qquad\quad}m{.6\linewidth}}
- {
- \tt\small
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & li t1, 1 & (d) & lw~ a0,0(s1) \\
- (a) & sw t1,0(s0) & (e) & xor t2,a0,a0 \\
- (b) & fence w, w & (f) & add s4,s2,t2 \\
- (c) & sw t1,0(s1) & (g) & lw~ a1,0(s4) \\
- & & (h) & lw~ a2,0(s2) \\
- & & (i) & xor t3,a2,a2 \\
- & & (j) & add s0,s0,t3 \\
- & & (k) & lw~ a3,0(s0) \\
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=1}, {\tt a1=$v$}, {\tt a2=$v$}, {\tt a3=0}}
- \end{tabular}
- }
- &
- \input{figs/litmus_rsw.pdf_t}
- \end{tabular}
- \caption{Litmus test RSW (outcome permitted)}
- \label{fig:litmus:rsw}
-\end{figure}
-
-Consider the litmus test of Figure~\ref{fig:litmus:rsw}.
-The outcome {\tt a0=1}, {\tt a1=$v$}, {\tt a2=$v$}, {\tt a3=0} (where $v$ is some value written by another hart) can be observed by allowing (g) and (h) to be reordered. This might be done speculatively, and the speculation can be justified by the microarchitecture (e.g., by snooping for cache invalidations and finding none) because replaying (h) after (g) would return the value written by the same store anyway.
-Hence assuming {\tt a1} and {\tt a2} would end up with the same value written by the same store anyway, (g) and (h) can be legally reordered.
-The global memory order corresponding to this execution would be (h),(k),(a),(c),(d),(g).
-
-Executions of the test in Figure~\ref{fig:litmus:rsw} in which {\tt a1} does not equal {\tt a2} do in fact require that (g) appears before (h) in the global memory order.
-Allowing (h) to appear before (g) in the global memory order would in that case result in a violation of CoRR, because then (h) would return an older value than that returned by (g).
-Therefore, PPO rule~\ref{ppo:rdw} forbids this CoRR violation from occurring.
-As such, PPO rule~\ref{ppo:rdw} strikes a careful balance between enforcing CoRR in all cases while simultaneously being weak enough to permit ``RSW'' and ``fri-rfi'' patterns that commonly appear in real microarchitectures.
-
-There is one more overlapping-address rule: PPO rule~\ref{ppo:amoforward} simply states that a value cannot be returned from an AMO or SC to a subsequent load until the AMO or SC has (in the case of the SC, successfully) performed globally.
-This follows somewhat naturally from the conceptual view that both AMOs and SC instructions are meant to be performed atomically in memory.
-However, notably, PPO rule~\ref{ppo:amoforward} states that hardware may not even non-speculatively forward the value being stored by an AMOSWAP to a subsequent load, even though for AMOSWAP that store value is not actually semantically dependent on the previous value in memory, as is the case for the other AMOs.
-The same holds true even when forwarding from SC store values that are not semantically dependent on the value returned by the paired LR.
-
-The three PPO rules above also apply when the memory accesses in question only overlap partially.
-This can occur, for example, when accesses of different sizes are used to access the same object.
-Note also that the base addresses of two overlapping memory operations need not necessarily be the same for two memory accesses to overlap.
-When misaligned memory accesses are being used, the overlapping-address PPO rules apply to each of the component memory accesses independently.
-
-\begin{comment}
-The formal model captures this as follows:
-\begin{itemize}
- \item (a) precedes (b) in preserved program order because both are stores to the same address, and (b) is a store (Rule~\ref{ppo:->st}). Therefore, (c) cannot return the value written by (a), because (b) is a later store to the same address in both program order and the global memory order, and so returning the value written by (a) would violate the load value axiom.
- \item (c) precedes (d) in preserved program order because both are accesses to the same address, and (d) is a store. (c) also precedes (d) in program order. Therefore, (c) is not able to return the value written by (d), because neither option in the load value axiom applies.
-\end{itemize}
-\end{comment}
-
-\subsection{Fences (Rule~\ref{ppo:fence})}
-\label{sec:mm:fence}
-\begin{tabular}{p{1cm}|p{12cm}} &
-Rule \ref{ppo:fence}: \ppofence
-\end{tabular}
-
-By default, the FENCE instruction ensures that all memory accesses from instructions preceding the fence in program order (the ``predecessor set'') appear earlier in the global memory order than memory accesses from instructions appearing after the fence in program order (the ``successor set'').
-However, fences can optionally further restrict the predecessor set and/or the successor set to a smaller set of memory accesses in order to provide some speedup.
-Specifically, fences have PR, PW, SR, and SW bits which restrict the predecessor and/or successor sets.
-The predecessor set includes loads (resp.\@ stores) if and only if PR (resp.\@ PW) is set.
-Similarly, the successor set includes loads (resp.\@ stores) if and only if SR (resp.\@ SW) is set.
-
-The FENCE encoding currently has nine non-trivial combinations of the four bits PR, PW, SR, and SW, plus one extra encoding FENCE.TSO which facilitates mapping of ``acquire+release'' or RVTSO semantics.
-The remaining seven combinations have empty predecessor and/or successor sets and hence are no-ops.
-Of the ten non-trivial options, only six are commonly used in practice:
-{
-\begin{itemize}
- \item FENCE RW,RW
- \item FENCE.TSO
- \item FENCE RW,W
- \item FENCE R,RW
- \item FENCE R,R
- \item FENCE W,W
-\end{itemize}
-}
-FENCE instructions using any other combination of PR, PW, SR, and SW are reserved. We strongly recommend that programmers stick to these six.
-Other combinations may have unknown or unexpected interactions with the memory model.
-
-Finally, we note that since RISC-V uses a multi-copy atomic memory model, programmers can reason about fences bits in a thread-local manner. There is no complex notion of ``fence cumulativity'' as found in memory models that are not multi-copy atomic.
-
-\subsection{Explicit Synchronization (Rules~\ref{ppo:acquire}--\ref{ppo:pair})}
-\label{sec:memory:acqrel}
-\begin{tabular}{p{1cm}|p{12cm}}
- & Rule \ref{ppo:acquire}: \ppoacquire \\
- & Rule \ref{ppo:release}: \pporelease \\
- & Rule \ref{ppo:rcsc}: \pporcsc \\
- & Rule \ref{ppo:pair}: \ppopair \\
-\end{tabular}
-
-An {\em acquire} operation, as would be used at the start of a critical section, requires all memory operations following the acquire in program order to also follow the acquire in the global memory order.
-This ensures, for example, that all loads and stores inside the critical section are up to date with respect to the synchronization variable being used to protect it.
-Acquire ordering can be enforced in one of two ways: with an acquire annotation, which enforces ordering with respect to just the synchronization variable itself, or with a FENCE~R,RW, which enforces ordering with respect to all previous loads.
-
-\begin{figure}[h!]
- \centering\small
- \begin{verbatim}
- sd x1, (a1) # Arbitrary unrelated store
- ld x2, (a2) # Arbitrary unrelated load
- li t0, 1 # Initialize swap value.
- again:
- amoswap.w.aq t0, t0, (a0) # Attempt to acquire lock.
- bnez t0, again # Retry if held.
- # ...
- # Critical section.
- # ...
- amoswap.w.rl x0, x0, (a0) # Release lock by storing 0.
- sd x3, (a3) # Arbitrary unrelated store
- ld x4, (a4) # Arbitrary unrelated load
- \end{verbatim}
- \caption{A spinlock with atomics}
- \label{fig:litmus:spinlock_atomics}
-\end{figure}
-
-Consider Figure~\ref{fig:litmus:spinlock_atomics}.
-Because this example uses {\em aq}, the loads and stores in the critical section are guaranteed to appear in the global memory order after the AMOSWAP used to acquire the lock. However, assuming {\tt a0}, {\tt a1}, and {\tt a2} point to different memory locations, the loads and stores in the critical section may or may not appear after the ``Arbitrary unrelated load'' at the beginning of the example in the global memory order.
-
-\begin{figure}[h!]
- \centering\small
- \begin{verbatim}
- sd x1, (a1) # Arbitrary unrelated store
- ld x2, (a2) # Arbitrary unrelated load
- li t0, 1 # Initialize swap value.
- again:
- amoswap.w t0, t0, (a0) # Attempt to acquire lock.
- fence r, rw # Enforce "acquire" memory ordering
- bnez t0, again # Retry if held.
- # ...
- # Critical section.
- # ...
- fence rw, w # Enforce "release" memory ordering
- amoswap.w x0, x0, (a0) # Release lock by storing 0.
- sd x3, (a3) # Arbitrary unrelated store
- ld x4, (a4) # Arbitrary unrelated load
- \end{verbatim}
- \caption{A spinlock with fences}
- \label{fig:litmus:spinlock_fences}
-\end{figure}
-
-Now, consider the alternative in Figure~\ref{fig:litmus:spinlock_fences}.
-In this case, even though the AMOSWAP does not enforce ordering with an {\em aq} bit, the fence nevertheless enforces that the acquire AMOSWAP appears earlier in the global memory order than all loads and stores in the critical section.
-Note, however, that in this case, the fence also enforces additional orderings: it also requires that the ``Arbitrary unrelated load'' at the start of the program appears earlier in the global memory order than the loads and stores of the critical section. (This particular fence does not, however, enforce any ordering with respect to the ``Arbitrary unrelated store'' at the start of the snippet.)
-In this way, fence-enforced orderings are slightly coarser than orderings enforced by {\em .aq}.
-
-Release orderings work exactly the same as acquire orderings, just in the opposite direction. Release semantics require all loads and stores preceding the release operation in program order to also precede the release operation in the global memory order.
-This ensures, for example, that memory accesses in a critical section appear before the lock-releasing store in the global memory order. Just as for acquire semantics, release semantics can be enforced using release annotations or with a FENCE~RW,W operation. Using the same examples, the ordering between the loads and stores in the critical section and the ``Arbitrary unrelated store'' at the end of the code snippet is enforced only by the FENCE~RW,W in Figure~\ref{fig:litmus:spinlock_fences}, not by the {\em rl} in Figure~\ref{fig:litmus:spinlock_atomics}.
-
-With RCpc annotations alone, store-release-to-load-acquire ordering is not enforced. This facilitates the porting of code written under the TSO and/or RCpc memory models.
-To enforce store-release-to-load-acquire ordering, the code must use store-release-RCsc and load-acquire-RCsc operations so that PPO rule \ref{ppo:rcsc} applies.
-RCpc alone is sufficient for many use cases in C/C++ but is insufficient for many other use cases in C/C++, Java, and Linux, to name just a few examples; see Section~\ref{sec:memory:porting} for details.
-
-PPO rule~\ref{ppo:pair} indicates that an SC must appear after its paired LR in the global memory order.
-This will follow naturally from the common use of LR/SC to perform an atomic read-modify-write operation due to the inherent data dependency.
-However, PPO rule~\ref{ppo:pair} also applies even when the value being stored does not syntactically depend on the value returned by the paired LR.
-
-Lastly, we note that just as with fences, programmers need not worry about ``cumulativity'' when analyzing ordering annotations.
-
-\subsection{Syntactic Dependencies (Rules~\ref{ppo:addr}--\ref{ppo:ctrl})}
-\label{sec:memory:dependencies}
-\begin{tabular}{p{1cm}|p{12cm}}
- & Rule \ref{ppo:addr}: \ppoaddr \\
- & Rule \ref{ppo:data}: \ppodata \\
- & Rule \ref{ppo:ctrl}: \ppoctrl \\
-\end{tabular}
-
-Dependencies from a load to a later memory operation in the same hart are respected by the RVWMO memory model.
-The Alpha memory model was notable for choosing {\em not} to enforce the ordering of such dependencies, but most modern hardware and software memory models consider allowing dependent instructions to be reordered too confusing and counterintuitive.
-Furthermore, modern code sometimes intentionally uses such dependencies as a particularly lightweight ordering enforcement mechanism.
-
-The terms in Section~\ref{sec:memorymodel:dependencies} work as follows.
-Instructions are said to carry dependencies from their source register(s) to their destination register(s) whenever the value written into each destination register is a function of the source register(s).
-For most instructions, this means that the destination register(s) carry a dependency from all source register(s).
-However, there are a few notable exceptions.
-In the case of memory instructions, the value written into the destination register ultimately comes from the memory system rather than from the source register(s) directly, and so this breaks the chain of dependencies carried from the source register(s).
-In the case of unconditional jumps, the value written into the destination register comes from the current {\tt pc} (which is never considered a source register by the memory model), and so likewise, JALR (the only jump with a source register) does not carry a dependency from {\em rs1} to {\em rd}.
-
-\begin{verbbox}
-(a) fadd f3,f1,f2
-(b) fadd f6,f4,f5
-(c) csrrs a0,fflags,x0
-\end{verbbox}
-\begin{figure}[h!]
- \centering\small
- \theverbbox
- \caption{(c) has a syntactic dependency on both (a) and (b) via {\tt fflags}, a destination register that both (a) and (b) implicitly accumulate into}
- \label{fig:litmus:fflags}
-\end{figure}
-
-The notion of accumulating into a destination register rather than writing into it reflects the behavior of CSRs such as {\tt fflags}.
-In particular, an accumulation into a register does not clobber any previous writes or accumulations into the same register.
-For example, in Figure~\ref{fig:litmus:fflags}, (c) has a syntactic dependency on both (a) and (b).
-
-Like other modern memory models, the RVWMO memory model uses syntactic rather than semantic dependencies.
-In other words, this definition depends on the identities of the
-registers being accessed by different instructions, not the actual
-contents of those registers. This means that an address, control, or
-data dependency must be enforced even if the calculation could seemingly
-be ``optimized away''.
-This choice ensures that RVWMO remains compatible with code that uses these false syntactic dependencies as a lightweight ordering mechanism.
-
-\begin{verbbox}
-ld a1,0(s0)
-xor a2,a1,a1
-add s1,s1,a2
-ld a5,0(s1)
-\end{verbbox}
-\begin{figure}[h!]
- \centering\small
- \theverbbox
- \caption{A syntactic address dependency}
- \label{fig:litmus:address}
-\end{figure}
-
-For example, there is a syntactic address
-dependency from the memory operation generated by the first instruction to the memory operation generated by the last instruction in
-Figure~\ref{fig:litmus:address}, even though {\tt a1} XOR {\tt a1} is zero and
-hence has no effect on the address accessed by the second load.
-
-The benefit of using dependencies as a lightweight synchronization mechanism is that the ordering enforcement requirement is limited only to the specific two instructions in question.
-Other non-dependent instructions may be freely-reordered by aggressive implementations.
-One alternative would be to use a load-acquire, but this would enforce ordering for the first load with respect to {\em all} subsequent instructions.
-Another would be to use a FENCE~R,R, but this would include all previous and all subsequent loads, making this option more expensive.
-
-\begin{verbbox}
- lw x1,0(x2)
- bne x1,x0,next
- sw x3,0(x4)
-next: sw x5,0(x6)
-\end{verbbox}
-\begin{figure}[h!]
- \centering\small
- \theverbbox
- \caption{A syntactic control dependency}
- \label{fig:litmus:control1}
-\end{figure}
-
-Control dependencies behave differently from address and data dependencies in the sense that a control dependency always extends to all instructions following the original target in program order.
-Consider Figure~\ref{fig:litmus:control1}: the instruction at {\tt next} will always execute, but the memory operation generated by that last instruction nevertheless still has a control dependency from the memory operation generated by the first instruction.
-
-\begin{verbbox}
- lw x1,0(x2)
- bne x1,x0,next
- next: sw x3,0(x4)
-\end{verbbox}
-\begin{figure}[h!]
- \centering\small
- \theverbbox
- \caption{Another syntactic control dependency}
- \label{fig:litmus:control2}
-\end{figure}
-
-Likewise, consider Figure~\ref{fig:litmus:control2}.
-Even though both branch outcomes have the same target, there is still a control dependency from the memory operation generated by the first instruction in this snippet to the memory operation generated by the last instruction.
-This definition of control dependency is subtly stronger than what might be seen in other contexts (e.g., C++), but it conforms with standard definitions of control dependencies in the literature.
-
-Notably, PPO rules \ref{ppo:addr}--\ref{ppo:ctrl} are also intentionally designed to respect dependencies that originate from the output of a successful store-conditional instruction.
-Typically, an SC instruction will be followed by a conditional branch checking whether the outcome was successful; this implies that there will be a control dependency from the store operation generated by the SC instruction to any memory operations following the branch.
-PPO rule~\ref{ppo:ctrl} in turn implies that any subsequent store operations will appear later in the global memory order than the store operation generated by the SC.
-However, since control, address, and data dependencies are defined over memory operations, and since an unsuccessful SC does not generate a memory operation, no order is enforced between unsuccessful SC and its dependent instructions.
-Moreover, since SC is defined to carry dependencies from its source registers to {\em rd} only when the SC is successful, an unsuccessful SC has no effect on the global memory order.
-
-
-\begin{figure}[h!]
- \centering
- \begin{tabular}{m{.4\linewidth}m{0.05\linewidth}m{.4\linewidth}}
- {
- \tt\small
- \begin{tabular}{cl||cl}
- \multicolumn{4}{c}{Initial values: 0(s0)=1; 0(s1)=1} \\
- \\
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- (a) & ld a0,0(s0) & (e) & ld a3,0(s2) \\
- (b) & lr a1,0(s1) & (f) & sd a3,0(s0) \\
- (c) & sc a2,a0,0(s1) & \\
- (d) & sd a2,0(s2) & \\
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=0}, {\tt a3=0}}
- \end{tabular}
- }
- & &
- \input{figs/litmus_lb_lrsc.pdf_t}
- \end{tabular}
- \caption{A variant of the LB litmus test (outcome forbidden)}
- \label{fig:litmus:successdeps}
-\end{figure}
-
-In addition, the choice to respect dependencies originating at store-conditional instructions ensures that certain out-of-thin-air-like behaviors will be prevented.
-Consider Figure~\ref{fig:litmus:successdeps}.
-Suppose a hypothetical implementation could occasionally make some early guarantee that a store-conditional operation will succeed.
-In this case, (c) could return 0 to {\tt a2} early (before actually executing), allowing the sequence (d), (e), (f), (a), and then (b) to execute, and then (c) might execute (successfully) only at that point.
-This would imply that (c) writes its own success value to {\tt 0(s1)}!
-Fortunately, this situation and others like it are prevented by the fact that RVWMO respects dependencies originating at the stores generated by successful SC instructions.
-
-We also note that syntactic dependencies between instructions only have any force when they take the form of a syntactic address, control, and/or data dependency.
-For example: a syntactic dependency between two ``F'' instructions via one of the ``accumulating CSRs'' in Section~\ref{sec:source-dest-regs} does {\em not} imply that the two ``F'' instructions must be executed in order.
-Such a dependency would only serve to ultimately set up later a dependency from both ``F'' instructions to a later CSR instruction accessing the CSR flag in question.
-
-\subsection{Pipeline Dependencies (Rules~\ref{ppo:addrdatarfi}--\ref{ppo:addrpo})}
-\label{sec:memory:ppopipeline}
-\begin{tabular}{p{1cm}|p{12cm}}
- & Rule \ref{ppo:addrdatarfi}: \ppoaddrdatarfi \\
- & Rule \ref{ppo:addrpo}: \ppoaddrpo \\
-% & Rule \ref{ppo:ctrlcfence}: \ppoctrlcfence \\
-% & Rule \ref{ppo:addrpocfence}: \ppoaddrpocfence \\
-\end{tabular}
-
-\begin{figure}[h!]
- \centering
- \begin{tabular}{m{.4\linewidth}m{.05\linewidth}m{.4\linewidth}}
- {
- \tt\small
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & li t1, 1 & (d) & lw a0, 0(s1) \\
- (a) & sw t1,0(s0) & (e) & sw a0, 0(s2) \\
- (b) & fence w, w & (f) & lw a1, 0(s2) \\
- (c) & sw t1,0(s1) & & xor a2,a1,a1 \\
- & & & add s0,s0,a2 \\
- & & (g) & lw a3,0(s0) \\
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=1}, {\tt a3=0}}
- \end{tabular}
- } & &
- \input{figs/litmus_datarfi.pdf_t}
- \end{tabular}
-
- \caption{Because of PPO rule~\ref{ppo:addrdatarfi} and the data dependency from (d) to (e), (d) must also precede (f) in the global memory order (outcome forbidden)}
- \label{fig:litmus:addrdatarfi}
-\end{figure}
-
-PPO rules~\ref{ppo:addrdatarfi} and \ref{ppo:addrpo} reflect behaviors of almost all real processor pipeline implementations.
-Rule~\ref{ppo:addrdatarfi} states that a load cannot forward from a store until the address and data for that store are known.
-Consider Figure~\ref{fig:litmus:addrdatarfi}:
-(f) cannot be executed until the data for (e) has been resolved, because (f) must return the value written by (e) (or by something even later in the global memory order), and the old value must not be clobbered by the writeback of (e) before (d) has had a chance to perform.
-Therefore, (f) will never perform before (d) has performed.
-
-\begin{figure}[h!]
- \centering
- \begin{tabular}{m{.4\linewidth}m{.05\linewidth}m{.4\linewidth}}
- {
- \tt\small
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & li t1, 1 & & li t1, 1 \\
- (a) & sw t1,0(s0) & (d) & lw a0, 0(s1) \\
- (b) & fence w, w & (e) & sw a0, 0(s2) \\
- (c) & sw t1,0(s1) & (f) & sw t1, 0(s2) \\
- & & (g) & lw a1, 0(s2) \\
- & & & xor a2,a1,a1 \\
- & & & add s0,s0,a2 \\
- & & (h) & lw a3,0(s0) \\
-
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=1}, {\tt a1=0}}
- \end{tabular}
- } & &
- \input{figs/litmus_datacoirfi.pdf_t}
- \end{tabular}
-
- \caption{Because of the extra store between (e) and (g), (d) no longer necessarily precedes (g) (outcome permitted)}
- \label{fig:litmus:addrdatarfi_no}
-\end{figure}
-
-If there were another store to the same address in between (e) and (f), as in Figure~\ref{fig:litmus:addrdatarfi_no}, then (f) would no longer be dependent on the data of (e) being resolved, and hence the dependency of (f) on (d), which produces the data for (e), would be broken.
-
-Rule~\ref{ppo:addrpo} makes a similar observation to the previous rule: a store cannot be performed at memory until all previous loads that might access the same address have themselves been performed.
-Such a load must appear to execute before the store, but it cannot do so if the store were to overwrite the value in memory before the load had a chance to read the old value.
-Likewise, a store generally cannot be performed until it is known that preceding instructions will not cause an exception due to failed address resolution, and in this sense, rule~\ref{ppo:addrpo} can be seen as somewhat of a special case of rule~\ref{ppo:ctrl}.
-
-\begin{figure}[h!]
- \centering
- \begin{tabular}{m{.4\linewidth}m{.05\linewidth}m{.4\linewidth}}
- \tt\small
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & & & li t1, 1 \\
- (a) & lw a0,0(s0) & (d) & lw a1, 0(s1) \\
- (b) & fence rw,rw & (e) & lw a2, 0(a1) \\
- (c) & sw s2,0(s1) & (f) & sw t1, 0(s0) \\
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=1}, {\tt a1=t}}
- \end{tabular}
- & &
- \input{figs/litmus_addrpo.pdf_t}
- \end{tabular}
- \caption{Because of the address dependency from (d) to (e), (d) also precedes (f) (outcome forbidden)}
- \label{fig:litmus:addrpo}
-\end{figure}
-
-Consider Figure~\ref{fig:litmus:addrpo}:
-(f) cannot be executed until the address for (e) is resolved, because it may turn out that the addresses match; i.e., that {\tt a1=s0}. Therefore, (f) cannot be sent to memory before (d) has executed and confirmed whether the addresses do indeed overlap.
-
-
-\section{Beyond Main Memory}
-
-RVWMO does not currently attempt to formally describe how FENCE.I, SFENCE.VMA, I/O fences, and PMAs behave.
-All of these behaviors will be described by future formalizations.
-In the meantime, the behavior of FENCE.I is described in Section~\ref{sec:fence}, the behavior of SFENCE.VMA is described in the RISC-V Instruction Set Privileged Architecture Manual, and the behavior of I/O fences and the effects of PMAs are described below.
-
-\subsection{Coherence and Cacheability}
-
-The RISC-V Privileged ISA defines Physical Memory Attributes (PMAs) which specify, among other things, whether portions of the address space are coherent and/or cacheable.
-See the RISC-V Privileged ISA Specification for the complete details.
-Here, we simply discuss how the various details in each PMA relate to the memory model:
-
-\begin{itemize}
- \item Main memory vs.\@ I/O, and I/O memory ordering PMAs: the memory model as defined applies to main memory regions. I/O ordering is discussed below.
- \item Supported access types and atomicity PMAs: the memory model is simply applied on top of whatever primitives each region supports.
- \item Cacheability PMAs: the cacheability PMAs in general do not affect the memory model. Non-cacheable regions may have more restrictive behavior than cacheable regions, but the set of allowed behaviors does not change regardless. However, some platform-specific and/or device-specific cacheability settings may differ.
- \item Coherence PMAs: The memory consistency model for memory regions marked as non-coherent in PMAs is currently platform-specific and/or device-specific: the load-value axiom, the atomicity axiom, and the progress axiom all may be violated with non-coherent memory. Note however that coherent memory does not require a hardware cache coherence protocol. The RISC-V Privileged ISA Specification suggests that hardware-incoherent regions of main memory are discouraged, but the memory model is compatible with hardware coherence, software coherence, implicit coherence due to read-only memory, implicit coherence due to only one agent having access, or otherwise.
- \item Idempotency PMAs: Idempotency PMAs are used to specify memory regions for which loads and/or stores may have side effects, and this in turn is used by the microarchitecture to determine, e.g., whether prefetches are legal. This distinction does not affect the memory model.
-\end{itemize}
-
-
-\subsection{I/O Ordering}
-
-For I/O, the load value axiom and atomicity axiom in general do not apply, as both reads and writes might have device-specific side effects and may return values other than the value ``written'' by the most recent store to the same address.
-Nevertheless, the following preserved program order rules still generally apply for accesses to I/O memory:
-memory access $a$ precedes memory access $b$ in global memory order if $a$ precedes $b$ in program order and one or more of the following holds:
-\begin{enumerate}
- \item $a$ precedes $b$ in preserved program order as defined in Chapter~\ref{ch:memorymodel}, with the exception that acquire and release ordering annotations apply only from one memory operation to another memory operation and from one I/O operation to another I/O operation, but not from a memory operation to an I/O nor vice versa
- \item $a$ and $b$ are accesses to overlapping addresses in an I/O region
- \item $a$ and $b$ are accesses to the same strongly-ordered I/O region
- \item $a$ and $b$ are accesses to I/O regions, and the channel associated with the I/O region accessed by either $a$ or $b$ is channel 1
- \item $a$ and $b$ are accesses to I/O regions associated with the same channel (except for channel 0)
-\end{enumerate}
-
-Note that the FENCE instruction distinguishes between main memory operations and I/O operations in its predecessor and successor sets.
-To enforce ordering between I/O operations and main memory operations, code must use a FENCE with PI, PO, SI, and/or SO, plus PR, PW, SR, and/or SW.
-For example, to enforce ordering between a write to main memory and an I/O write to a device register, a FENCE~W,O or stronger is needed.
-
-\begin{verbbox}
- sd t0, 0(a0)
- fence w,o
- sd a0, 0(a1)
-\end{verbbox}
-\begin{figure}[h!]
- \centering\small
- \theverbbox
- \caption{Ordering memory and I/O accesses}
- \label{fig:litmus:wo}
-\end{figure}
-
-When a fence is in fact used, implementations must assume that the device may attempt to access memory immediately after receiving the MMIO signal, and subsequent memory accesses from that device to memory must observe the effects of all accesses ordered prior to that MMIO operation.
-In other words, in Figure~\ref{fig:litmus:wo}, suppose {\tt 0(a0)} is in main memory and {\tt 0(a1)} is the address of a device register in I/O memory.
-If the device accesses {\tt 0(a0)} upon receiving the MMIO write, then that load must conceptually appear after the first store to {\tt 0(a0)} according to the rules of the RVWMO memory model.
-In some implementations, the only way to ensure this will be to require that the first store does in fact complete before the MMIO write is issued.
-Other implementations may find ways to be more aggressive, while others still may not need to do anything different at all for I/O and main memory accesses.
-Nevertheless, the RVWMO memory model does not distinguish between these options; it simply provides an implementation-agnostic mechanism to specify the orderings that must be enforced.
-
-Many architectures include separate notions of ``ordering'' and ``completion'' fences, especially as it relates to I/O (as opposed to regular main memory).
-Ordering fences simply ensure that memory operations stay in order, while completion fences ensure that predecessor accesses have all completed before any successors are made visible.
-RISC-V does not explicitly distinguish between ordering and completion fences.
-Instead, this distinction is simply inferred from different uses of the FENCE bits.
-
-For implementations that conform to the RISC-V Unix Platform Specification, I/O devices and DMA operations are required to access memory coherently and via strongly-ordered I/O channels.
-Therefore, accesses to regular main memory regions that are concurrently accessed by external devices can also use the standard synchronization mechanisms.
-Implementations that do not conform to the Unix Platform Specification and/or in which devices do not access memory coherently will need to use mechanisms (which are currently platform-specific or device-specific) to enforce coherency.
-
-I/O regions in the address space should be considered non-cacheable regions in the PMAs for those regions. Such regions can be considered coherent by the PMA if they are not cached by any agent.
-
-The ordering guarantees in this section may not apply beyond a platform-specific boundary between the RISC-V cores and the device. In particular, I/O accesses sent across an external bus (e.g., PCIe) may be reordered before they reach their ultimate destination. Ordering must be enforced in such situations according to the platform-specific rules of those external devices and buses.
-
-\section{Code Porting and Mapping Guidelines}
-\label{sec:memory:porting}
-
-\begin{table}[h!]
- \centering
- \begin{tabular}{|l|l|}
- \hline
- x86/TSO Operation & RVWMO Mapping \\
- \hline
- \hline
- Load & \tt l\{b|h|w|d\}; fence r,rw \\
- \hline
- Store & \tt fence rw,w; s\{b|h|w|d\} \\
- \hline
- \multirow{2}{*}{Atomic RMW}
- & \tt amo<op>.\{w|d\}.aqrl \textrm{OR} \\
- & \tt loop:\@ lr.\{w|d\}.aq; <op>; sc.\{w|d\}.aqrl; bnez loop \\
- \hline
- Fence & \tt fence rw,rw \\
- \hline
- \end{tabular}
- \caption{Mappings from TSO operations to RISC-V operations}
- \label{tab:tsomappings}
-\end{table}
-
-Table~\ref{tab:tsomappings} provides a mapping from TSO memory operations onto RISC-V memory instructions.
-Normal x86 loads and stores are all inherently acquire-RCpc and release-RCpc operations: TSO enforces all load-load, load-store, and store-store ordering by default.
-Therefore, under RVWMO, all TSO loads must be mapped onto a load followed by FENCE~R,RW, and all TSO stores must be mapped onto FENCE~RW,W followed by a store.
-TSO atomic read-modify-writes and x86 instructions using the LOCK prefix are fully-ordered and can be implemented either via an AMO with both {\em aq} and {\em rl} set, or via an LR with {\em aq} set, the arithmetic operation in question, an SC with both {\em aq} and {\em rl} set, and a conditional branch checking the success condition.
-In the latter case, the {\em rl} annotation on the LR turns out (for non-obvious reasons) to be redundant and can be omitted.
-
-Alternatives to Table~\ref{tab:tsomappings} are also possible.
-A TSO store can be mapped onto AMOSWAP with {\em rl} set.
-However, since RVWMO PPO Rule~\ref{ppo:amoforward} forbids forwarding of values from AMOs to subsequent loads, the use of AMOSWAP for stores may negatively affect performance.
-A TSO load can be mapped using LR with {\em aq} set: all such LR instructions will be unpaired, but that fact in and of itself does not preclude the use of LR for loads.
-However, again, this mapping may also negatively affect performance if it puts more pressure on the reservation mechanism than was originally intended.
-
-\begin{table}[h!]
- \centering
- \begin{tabular}{|l|l|}
- \hline
- Power Operation & RVWMO Mapping \\
- \hline
- \hline
- Load & \tt l\{b|h|w|d\} \\
- \hline
- Load-Reserve & \tt lr.\{w|d\} \\
- \hline
- Store & \tt s\{b|h|w|d\} \\
- \hline
- Store-Conditional & \tt sc.\{w|d\} \\
- \hline
- \tt lwsync & \tt fence.tso \\
- \hline
- \tt sync & \tt fence rw,rw \\
- \hline
- \tt isync & \tt fence.i; fence r,r \\
- \hline
- \end{tabular}
- \caption{Mappings from Power operations to RISC-V operations}
- \label{tab:powermappings}
-\end{table}
-
-Table~\ref{tab:powermappings} provides a mapping from Power memory operations onto RISC-V memory instructions.
-Power ISYNC maps on RISC-V to a FENCE.I followed by a FENCE~R,R; the latter fence is needed because ISYNC is used to define a ``control+control fence'' dependency that is not present in RVWMO.
-
-\begin{table}[h!]
- \centering
- \begin{tabular}{|l|l|}
- \hline
- ARM Operation & RVWMO Mapping \\
- \hline
- \hline
- Load & \tt l\{b|h|w|d\} \\
- \hline
- Load-Acquire & \tt fence rw, rw; l\{b|h|w|d\}; fence r,rw \\
- \hline
- Load-Exclusive & \tt lr.\{w|d\} \\
- \hline
- Load-Acquire-Exclusive & \tt lr.\{w|d\}.aqrl \\
- \hline
- Store & \tt s\{b|h|w|d\} \\
- \hline
- Store-Release & \tt fence rw,w; s\{b|h|w|d\} \\
- \hline
- Store-Exclusive & \tt sc.\{w|d\} \\
- \hline
- Store-Release-Exclusive & \tt sc.\{w|d\}.rl \\
- \hline
- \tt dmb & \tt fence rw,rw \\
- \hline
- \tt dmb.ld & \tt fence r,rw \\
- \hline
- \tt dmb.st & \tt fence w,w \\
- \hline
- \tt isb & \tt fence.i; fence r,r \\
- \hline
- \end{tabular}
- \caption{Mappings from ARM operations to RISC-V operations}
- \label{tab:armmappings}
-\end{table}
-
-Table~\ref{tab:armmappings} provides a mapping from ARM memory operations onto RISC-V memory instructions.
-Since RISC-V does not currently have plain load and store opcodes with {\em aq} or {\em rl} annotations, ARM load-acquire and store-release operations should be mapped using fences instead.
-Furthermore, in order to enforce store-release-to-load-acquire ordering, there must be a FENCE~RW,RW between the store-release and load-acquire; Table~\ref{tab:armmappings} enforces this by always placing the fence in front of each acquire operation.
-ARM load-exclusive and store-exclusive instructions can likewise map onto their RISC-V LR and SC equivalents, but instead of placing a FENCE~RW,RW in front of an LR with {\em aq} set, we simply also set {\em rl} instead.
-ARM ISB maps on RISC-V to FENCE.I followed by FENCE~R,R similarly to how ISYNC maps for Power.
-
-\begin{table}[h!]
- \centering
- \begin{tabular}{|l|l|}
- \hline
- Linux Operation & RVWMO Mapping \\
- \hline
- \hline
- \tt smp\_mb() & \tt fence rw,rw \\
- \hline
- \tt smp\_rmb() & \tt fence r,r \\
- \hline
- \tt smp\_wmb() & \tt fence w,w \\
- \hline
- \tt dma\_rmb() & \tt fence r,r \\
- \hline
- \tt dma\_wmb() & \tt fence w,w \\
- \hline
- \tt mb() & \tt fence iorw,iorw \\
- \hline
- \tt rmb() & \tt fence ri,ri \\
- \hline
- \tt wmb() & \tt fence wo,wo \\
- \hline
- \tt smp\_load\_acquire() & \tt l\{b|h|w|d\}; fence r,rw \\
- \hline
- \tt smp\_store\_release() & \tt fence.tso; s\{b|h|w|d\} \\
- \hline
- \hline
- Linux Construct & RVWMO AMO Mapping \\
- \hline
- \tt atomic\_<op>\_relaxed & \tt amo<op>.\{w|d\} \\
- \hline
- \tt atomic\_<op>\_acquire & \tt amo<op>.\{w|d\}.aq \\
- \hline
- \tt atomic\_<op>\_release & \tt amo<op>.\{w|d\}.rl \\
- \hline
- \tt atomic\_<op> & \tt amo<op>.\{w|d\}.aqrl \\
- \hline
- \hline
- Linux Construct & RVWMO LR/SC Mapping\\
- \hline
- \tt atomic\_<op>\_relaxed & \tt loop:\@ lr.\{w|d\}; <op>; sc.\{w|d\}; bnez loop \\
- \hline
- \tt atomic\_<op>\_acquire & \tt loop:\@ lr.\{w|d\}.aq; <op>; sc.\{w|d\}; bnez loop \\
- \hline
- \multirow{2}{*}{\tt atomic\_<op>\_release}
- & \tt loop:\@ lr.\{w|d\}; <op>; sc.\{w|d\}.aqrl$^*$; bnez loop \textrm{OR} \\
- & \tt fence.tso; loop:\@ lr.\{w|d\}; <op>; sc.\{w|d\}$^*$; bnez loop \\
- \hline
- \tt atomic\_<op> & \tt loop:\@ lr.\{w|d\}.aq; <op>; sc.\{w|d\}.aqrl; bnez loop \\
- \hline
- \end{tabular}
- \caption{Mappings from Linux memory primitives to RISC-V primitives. Other constructs (such as spinlocks) should follow accordingly. Platforms or devices with non-coherent DMA may need additional synchronization (such as cache flush or invalidate mechanisms); currently any such extra synchronization will be device-specific.}
- \label{tab:linuxmappings}
-\end{table}
-
-Table~\ref{tab:linuxmappings} provides a mapping of Linux memory ordering macros onto RISC-V memory instructions.
-%The now-deprecated fence {\tt smp\_read\_barrier\_depends()} map to a no-op due to preserved program order rules \ref{ppo:addr}--\ref{ppo:ctrl}.
-The Linux fences {\tt dma\_rmb()} and {\tt dma\_wmb()} map onto FENCE~R,R and FENCE~W,W, respectively, since the RISC-V Unix Platform requires coherent DMA, but would be mapped onto FENCE~RI,RI and FENCE~WO,WO, respectively, on a platform with non-coherent DMA.
-Platforms with non-coherent DMA may also require a mechanism by which cache lines can be flushed and/or invalidated.
-Such mechanisms will be device-specific and/or standardized in a future extension to the ISA.
-
-The Linux mappings for release operations may seem stronger than necessary, but these mappings are needed to cover some cases in which Linux requires stronger orderings than the more intuitive mappings would provide.
-In particular, as of the time this text is being written, Linux is actively debating whether to require load-load, load-store, and store-store orderings between accesses in one critical section and accesses in a subsequent critical section in the same hart and protected by the same synchronization object.
-Not all combinations of FENCE~RW,W/FENCE~R,RW mappings with {\em aq}/{\em rl} mappings combine to provide such orderings.
-There are a few ways around this problem, including:
-\begin{enumerate}
- \item Always use FENCE~RW,W/FENCE~R,RW, and never use {\em aq}/{\em rl}. This suffices but is undesirable, as it defeats the purpose of the {\em aq}/{\em rl} modifiers.
- \item Always use {\em aq}/{\em rl}, and never use FENCE~RW,W/FENCE~R,RW. This does not currently work due to the lack of load and store opcodes with {\em aq} and {\em rl} modifiers.
- \item Strengthen the mappings of release operations such that they would enforce sufficient orderings in the presence of either type of acquire mapping. This is the currently-recommended solution, and the one shown in Table~\ref{tab:linuxmappings}.
-\end{enumerate}
-
-\begin{figure}[h!]
- \centering\small
- \begin{verbbox}
-Linux code:
-(a) int r0 = *x;
-(bc) spin_unlock(y, 0);
- ...
- ...
-(d) spin_lock(y);
-(e) int r1 = *z;
- \end{verbbox}
- \theverbbox
- ~~~~~~~~~~
- \begin{verbbox}
-RVWMO Mapping:
-(a) lw a0, 0(s0)
-(b) fence.tso // vs. fence rw,w
-(c) sd x0,0(s1)
- ...
- loop:
-(d) amoswap.d.aq a1,t1,0(s1)
- bnez a1,loop
-(e) lw a2,0(s2)
- \end{verbbox}
- \theverbbox
- \caption{Orderings between critical sections in Linux}
- \label{fig:litmus:lkmm_ll}
-\end{figure}
-
-For example, the critical section ordering rule currently being debated by the Linux community would require (a) to be ordered before (e) in Figure~\ref{fig:litmus:lkmm_ll}.
-If that will indeed be required, then it would be insufficient for (b) to map as FENCE~RW,W.
-That said, these mappings are subject to change as the Linux Kernel Memory Model evolves.
-
-\begin{table}[h!]
- \centering
- \begin{tabular}{|l|l|}
- \hline
- C/C++ Construct & RVWMO Mapping \\
- \hline
- \hline
- Non-atomic load & \tt l\{b|h|w|d\} \\
- \hline
- \tt atomic\_load(memory\_order\_relaxed) & \tt l\{b|h|w|d\} \\
- \hline
- %\tt atomic\_load(memory\_order\_consume) & \multicolumn{2}{l|}{\tt l\{b|h|w|d\}; fence r,rw} \\
- %\hline
- \tt atomic\_load(memory\_order\_acquire) & \tt l\{b|h|w|d\}; fence r,rw \\
- \hline
- \tt atomic\_load(memory\_order\_seq\_cst) & \tt fence rw,rw; l\{b|h|w|d\}; fence r,rw \\
- \hline
- \hline
- Non-atomic store & \tt s\{b|h|w|d\} \\
- \hline
- \tt atomic\_store(memory\_order\_relaxed) & \tt s\{b|h|w|d\} \\
- \hline
- \tt atomic\_store(memory\_order\_release) & \tt fence rw,w; s\{b|h|w|d\} \\
- \hline
- \tt atomic\_store(memory\_order\_seq\_cst) & \tt fence rw,w; s\{b|h|w|d\} \\
- \hline
- \hline
- \tt atomic\_thread\_fence(memory\_order\_acquire) & \tt fence r,rw \\
- \hline
- \tt atomic\_thread\_fence(memory\_order\_release) & \tt fence rw,w \\
- \hline
- \tt atomic\_thread\_fence(memory\_order\_acq\_rel) & {\tt fence.tso} \\
- \hline
- \tt atomic\_thread\_fence(memory\_order\_seq\_cst) & \tt fence rw,rw \\
- \hline
- \hline
- C/C++ Construct & RVWMO AMO Mapping \\
- \hline
- \tt atomic\_<op>(memory\_order\_relaxed) & \tt amo<op>.\{w|d\} \\
- \hline
- \tt atomic\_<op>(memory\_order\_acquire) & \tt amo<op>.\{w|d\}.aq \\
- \hline
- \tt atomic\_<op>(memory\_order\_release) & \tt amo<op>.\{w|d\}.rl \\
- \hline
- \tt atomic\_<op>(memory\_order\_acq\_rel) & \tt amo<op>.\{w|d\}.aqrl \\
- \hline
- \tt atomic\_<op>(memory\_order\_seq\_cst) & \tt amo<op>.\{w|d\}.aqrl \\
- \hline
- \hline
- C/C++ Construct & RVWMO LR/SC Mapping\\
- \hline
- \multirow{2}{*}{\tt atomic\_<op>(memory\_order\_relaxed)}
- & \tt loop:\@ lr.\{w|d\}; <op>; sc.\{w|d\}; \\
- & \tt bnez loop \\
- \hline
- \multirow{2}{*}{\tt atomic\_<op>(memory\_order\_acquire)}
- & \tt loop:\@ lr.\{w|d\}.aq; <op>; sc.\{w|d\}; \\
- & \tt bnez loop \\
- \hline
- \multirow{2}{*}{\tt atomic\_<op>(memory\_order\_release)}
- & \tt loop:\@ lr.\{w|d\}; <op>; sc.\{w|d\}.rl; \\
- & \tt bnez loop \\
- \hline
- \multirow{2}{*}{\tt atomic\_<op>(memory\_order\_acq\_rel)}
- & \tt loop:\@ lr.\{w|d\}.aq; <op>; sc.\{w|d\}.rl; \\
- & \tt bnez loop \\
- \hline
- \multirow{2}{*}{\tt atomic\_<op>(memory\_order\_seq\_cst)}
- & \tt loop:\@ lr.\{w|d\}.aqrl; <op>; \\
- & \tt sc.\{w|d\}.rl; bnez loop \\
- \hline
- \end{tabular}
- \caption{Mappings from C/C++ primitives to RISC-V primitives.}
- \label{tab:c11mappings}
-\end{table}
-
-\begin{table}[h!]
- \centering
- \begin{tabular}{|l|l|}
- \hline
- C/C++ Construct & RVWMO Mapping \\
- \hline
- \hline
- Non-atomic load & \tt l\{b|h|w|d\} \\
- \hline
- \tt atomic\_load(memory\_order\_relaxed) & \tt l\{b|h|w|d\} \\
- \hline
- \tt atomic\_load(memory\_order\_acquire) & \tt l\{b|h|w|d\}.aq \\
- \hline
- \tt atomic\_load(memory\_order\_seq\_cst) & \tt l\{b|h|w|d\}.aq \\
- \hline
- \hline
- Non-atomic store & \tt s\{b|h|w|d\} \\
- \hline
- \tt atomic\_store(memory\_order\_relaxed) & \tt s\{b|h|w|d\} \\
- \hline
- \tt atomic\_store(memory\_order\_release) & \tt s\{b|h|w|d\}.rl \\
- \hline
- \tt atomic\_store(memory\_order\_seq\_cst) & \tt s\{b|h|w|d\}.rl \\
- \hline
- \hline
- \tt atomic\_thread\_fence(memory\_order\_acquire) & \tt fence r,rw \\
- \hline
- \tt atomic\_thread\_fence(memory\_order\_release) & \tt fence rw,w \\
- \hline
- \tt atomic\_thread\_fence(memory\_order\_acq\_rel) & {\tt fence.tso} \\
- \hline
- \tt atomic\_thread\_fence(memory\_order\_seq\_cst) & \tt fence rw,rw \\
- \hline
- \hline
- C/C++ Construct & RVWMO AMO Mapping \\
- \hline
- \tt atomic\_<op>(memory\_order\_relaxed) & \tt amo<op>.\{w|d\} \\
- \hline
- \tt atomic\_<op>(memory\_order\_acquire) & \tt amo<op>.\{w|d\}.aq \\
- \hline
- \tt atomic\_<op>(memory\_order\_release) & \tt amo<op>.\{w|d\}.rl \\
- \hline
- \tt atomic\_<op>(memory\_order\_acq\_rel) & \tt amo<op>.\{w|d\}.aqrl \\
- \hline
- \tt atomic\_<op>(memory\_order\_seq\_cst) & \tt amo<op>.\{w|d\}.aqrl \\
- \hline
- \hline
- C/C++ Construct & RVWMO LR/SC Mapping\\
- \hline
- \tt atomic\_<op>(memory\_order\_relaxed) & \tt lr.\{w|d\}; <op>; sc.\{w|d\} \\
- \hline
- \tt atomic\_<op>(memory\_order\_acquire) & \tt lr.\{w|d\}.aq; <op>; sc.\{w|d\} \\
- \hline
- \tt atomic\_<op>(memory\_order\_release) & \tt lr.\{w|d\}; <op>; sc.\{w|d\}.rl \\
- \hline
- \tt atomic\_<op>(memory\_order\_acq\_rel) & \tt lr.\{w|d\}.aq; <op>; sc.\{w|d\}.rl \\
- \hline
- \tt atomic\_<op>(memory\_order\_seq\_cst) & \tt lr.\{w|d\}.aq$^*$; <op>; sc.\{w|d\}.rl \\
- \hline
- \multicolumn{2}{l}{$^*$must be {\tt lr.\{w|d\}.aqrl} in order to interoperate with code mapped per Table~\ref{tab:c11mappings}}
- \end{tabular}
- \caption{Hypothetical mappings from C/C++ primitives to RISC-V primitives, if native load-acquire and store-release opcodes are introduced.}
- \label{tab:c11mappings_hypothetical}
-\end{table}
-
-Table~\ref{tab:c11mappings} provides a mapping of C11/C++11 atomic operations onto RISC-V memory instructions.
-If load and store opcodes with {\em aq} and {\em rl} modifiers are introduced, then the mappings in Table~\ref{tab:c11mappings_hypothetical} will suffice.
-Note however that the two mappings only interoperate correctly if {\tt atomic\_<op>(memory\_order\_seq\_cst)} is mapped using an LR that has both {\em aq} and {\em rl} set.
-
-Any AMO can be emulated by an LR/SC pair, but care must be taken to ensure that any PPO orderings that originate from the LR are also made to originate from the SC, and that any PPO orderings that terminate at the SC are also made to terminate at the LR.
-For example, the LR must also be made to respect any data dependencies that the AMO has, given that load operations do not otherwise have any notion of a data dependency.
-Likewise, the effect a FENCE~R,R elsewhere in the same hart must also be made to apply to the SC, which would not otherwise respect that fence.
-The emulator may achieve this effect by simply mapping AMOs onto {\tt lr.aq;~<op>;~sc.aqrl}, matching the mapping used elsewhere for fully-ordered atomics.
-
-\section{Implementation Guidelines}
-
-The RVWMO and RVTSO memory models by no means preclude microarchitectures from employing sophisticated speculation techniques or other forms of optimization in order to deliver higher performance.
-The models also do not impose any requirement to use any one particular cache hierarchy, nor even to use a cache coherence protocol at all.
-Instead, these models only specify the behaviors that can be exposed to software.
-Microarchitectures are free to use any pipeline design, any coherent or non-coherent cache hierarchy, any on-chip interconnect, etc., as long as the design only admits executions that satisfy the memory model rules.
-That said, to help people understand the actual implementations of the memory model, in this section we provide some guidelines on how architects and programmers should interpret the models' rules.
-
-Both RVWMO and RVTSO are multi-copy atomic (or ``other-multi-copy-atomic''): any store value that is visible to a hart other than the one that originally issued it must also be conceptually visible to all other harts in the system.
-In other words, harts may forward from their own previous stores before those stores have become globally visible to all harts, but no early inter-hart forwarding is permitted.
-Multi-copy atomicity may be enforced in a number of ways.
-It might hold inherently due to the physical design of the caches and store buffers, it may be enforced via a single-writer/multiple-reader cache coherence protocol, or it might hold due to some other mechanism.
-
-Although multi-copy atomicity does impose some restrictions on the microarchitecture, it is one of the key properties keeping the memory model from becoming extremely complicated.
-For example, a hart may not legally forward a value from a neighbor hart's private store buffer (unless of course it is done in such a way that no new illegal behaviors become architecturally visible).
-Nor may a cache coherence protocol forward a value from one hart to another until the coherence protocol has invalidated all older copies from other caches.
-Of course, microarchitectures may (and high-performance implementations likely will) violate these rules under the covers through speculation or other optimizations, as long as any non-compliant behaviors are not exposed to the programmer.
-
-As a rough guideline for interpreting the PPO rules in RVWMO, we expect the following from the software perspective:
-\begin{itemize}
- \item programmers will use PPO rules \ref{ppo:->st} and \ref{ppo:fence}--\ref{ppo:pair} regularly and actively.
- \item expert programmers will use PPO rules \ref{ppo:addr}--\ref{ppo:ctrl} to speed up critical paths of important data structures.
- \item even expert programmers will rarely if ever use PPO rules \ref{ppo:rdw}--\ref{ppo:amoforward} and \ref{ppo:addrdatarfi}--\ref{ppo:addrpo} directly. These are included to facilitate common microarchitectural optimizations (rule~\ref{ppo:rdw}) and the operational formal modeling approach (rules \ref{ppo:amoforward} and \ref{ppo:addrdatarfi}--\ref{ppo:addrpo}) described in Section~\ref{sec:operational}. They also facilitate the process of porting code from other architectures that have similar rules.
-\end{itemize}
-
-We also expect the following from the hardware perspective:
-\begin{itemize}
- \item PPO rules \ref{ppo:->st} and \ref{ppo:amoforward}--\ref{ppo:release} reflect well-understood rules that should pose few surprises to architects.
- \item PPO rule \ref{ppo:rdw} reflects a natural and common hardware optimization, but one that is very subtle and hence is worth double checking carefully.
- \item PPO rule \ref{ppo:rcsc} may not be immediately obvious to architects, but it is a standard memory model requirement
- \item The load value axiom, the atomicity axiom, and PPO rules \ref{ppo:pair}--\ref{ppo:addrpo} reflect rules that most hardware implementations will enforce naturally, unless they contain extreme optimizations. Of course, implementations should make sure to double check these rules nevertheless. Hardware must also ensure that syntactic dependencies are not ``optimized away''.
-\end{itemize}
-
-Architectures are free to implement any of the memory model rules as conservatively as they choose. For example, a hardware implementation may choose to do any or all of the following:
- \begin{itemize}
- \item interpret all fences as if they were FENCE~RW,RW (or FENCE~IORW,IORW, if I/O is involved), regardless of the bits actually set
- \item implement all fences with PW and SR as if they were FENCE~RW,RW (or FENCE~IORW,IORW, if I/O is involved), as PW with SR is the most expensive of the four possible main memory ordering components anyway
- \item emulate {\em aq} and {\em rl} as described in Section~\ref{sec:memory:porting}
- \item enforcing all same-address load-load ordering, even in the presence of patterns such as ``fri-rfi'' and ``RSW''
- \item forbid any forwarding of a value from a store in the store buffer to a subsequent AMO or LR to the same address
- \item forbid any forwarding of a value from an AMO or SC in the store buffer to a subsequent load to the same address
- \item implement TSO on all memory accesses, and ignore any main memory fences that do not include PW and SR ordering (e.g., as Ztso implementations will do)
- \item implement all atomics to be RCsc or even fully-ordered, regardless of annotation
- \end{itemize}
-
-Architectures that implement RVTSO can safely do the following:
-\begin{itemize}
- \item Ignore all fences that do not have both PW and SR (unless the fence also orders I/O)
- \item Ignore all PPO rules except for rules \ref{ppo:fence} through \ref{ppo:rcsc}, since the rest are redundant with other PPO rules under RVTSO assumptions
-\end{itemize}
-
-Other general notes:
-
-\begin{itemize}
- \item Silent stores (i.e., stores that write the same value that already exists at a memory location) behave like any other store from a memory model point of view. Likewise, AMOs which do not actually change the value in memory (e.g., an AMOMAX for which the value in {\em rs2} is smaller than the value currently in memory) are still semantically considered store operations. Microarchitectures that attempt to implement silent stores must take care to ensure that the memory model is still obeyed, particularly in cases such as RSW (Section~\ref{sec:memory:overlap}) which tend to be incompatible with silent stores.
- \item Writes may be merged (i.e., two consecutive writes to the same address may be merged) or subsumed (i.e., the earlier of two back-to-back writes to the same address may be elided) as long as the resulting behavior does not otherwise violate the memory model semantics.
-\end{itemize}
-
-The question of write subsumption can be understood from the following example:
-\begin{figure}[h!]
- \centering
- \begin{tabular}{m{.4\linewidth}m{.1\linewidth}m{.4\linewidth}}
- \tt\small
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & li t1, 3 & & li t3, 2 \\
- & li t2, 1 & & \\
- (a) & sw t1,0(s0) & (d) & lw a0,0(s1) \\
- (b) & fence w, w & (e) & sw a0,0(s0) \\
- (c) & sw t2,0(s1) & (f) & sw t3,0(s0) \\
- \end{tabular}
- & &
- \input{figs/litmus_subsumption.pdf_t}
- \end{tabular}
- \caption{Write subsumption litmus test, allowed execution.}
- \label{fig:litmus:subsumption}
-\end{figure}
-
-As written, if the load ~(d) reads value~$1$, then (a) must precede (f) in the global memory order:
-\begin{itemize}
- \item (a) precedes (c) in the global memory order because of rule 2
- \item (c) precedes (d) in the global memory order because of the Load Value axiom
- \item (d) precedes (e) in the global memory order because of rule 7
- \item (e) precedes (f) in the global memory order because of rule 1
-\end{itemize}
-In other words the final value of the memory location whose address is in {\tt s0} must be~$2$ (the value written by the store~(f)) and cannot be~$3$ (the value written by the store~(a)).
-
-A very aggressive microarchitecture might erroneously decide to discard (e), as (f) supersedes it, and this may in turn lead the microarchitecture to break the now-eliminated dependency between (d) and (f) (and hence also between (a) and (f)).
-This would violate the memory model rules, and hence it is forbidden.
-Write subsumption may in other cases be legal, if for example there were no data dependency between (d) and (e).
-
-\subsection{Possible Future Extensions}
-
-We expect that any or all of the following possible future extensions would be compatible with the RVWMO memory model:
-
-\begin{itemize}
- \item `V' vector ISA extensions
- \item A transactional memory subset of the `T' ISA extension
- \item `J' JIT extension
- \item Native encodings for load and store opcodes with {\em aq} and {\em rl} set
- \item Fences limited to certain addresses
- \item Cache writeback/flush/invalidate/etc.\@ instructions
-\end{itemize}
-
-\section{Known Issues}
-\label{sec:memory:discrepancies}
-
-\subsection{Mixed-size RSW}
-\label{sec:memory:discrepancies:mixedrsw}
-
-\begin{figure}[h!]
- \centering\small
- {\tt
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & li t1, 1 & & li t1, 1 \\
- (a) & lw a0,0(s0) & (d) & lw a1,0(s1) \\
- (b) & fence rw,rw & (e) & amoswap.w.rl a2,t1,0(s2) \\
- (c) & sw t1,0(s1) & (f) & ld a3,0(s2) \\
- & & (g) & lw a4,4(s2) \\
- & & & xor a5,a4,a4 \\
- & & & add s0,s0,a5 \\
- & & (h) & sw a2,0(s0) \\
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=1}, {\tt a1=1}, {\tt a2=0}, {\tt a3=1}, {\tt a4=0}}
- \end{tabular}
- }
- \caption{Mixed-size discrepancy (permitted by axiomatic models, forbidden by operational model)}
- \label{fig:litmus:discrepancy:rsw1}
-\end{figure}
-
-\begin{figure}[h!]
- \centering\small
- {\tt
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & li t1, 1 & & li t1, 1 \\
- (a) & lw a0,0(s0) & (d) & ld a1,0(s1) \\
- (b) & fence rw,rw & (e) & lw a2,4(s1) \\
- (c) & sw t1,0(s1) & & xor a3,a2,a2 \\
- & & & add s0,s0,a3 \\
- & & (f) & sw a2,0(s0) \\
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=0}, {\tt a1=1}, {\tt a2=0}}
- \end{tabular}
- }
- \caption{Mixed-size discrepancy (permitted by axiomatic models, forbidden by operational model)}
- \label{fig:litmus:discrepancy:rsw2}
-\end{figure}
-
-\begin{figure}[h!]
- \centering\small
- {\tt
- \begin{tabular}{cl||cl}
- \multicolumn{2}{c}{Hart 0} & \multicolumn{2}{c}{Hart 1} \\
- \hline
- & li t1, 1 & & li t1, 1 \\
- (a) & lw a0,0(s0) & (d) & sw t1,4(s1) \\
- (b) & fence rw,rw & (e) & ld a1,0(s1) \\
- (c) & sw t1,0(s1) & (f) & lw a2,4(s1) \\
- & & & xor a3,a2,a2 \\
- & & & add s0,s0,a3 \\
- & & (g) & sw a2,0(s0) \\
- \hline
- \multicolumn{4}{c}{Outcome: {\tt a0=1}, {\tt a1=0x100000001}, {\tt a1=1}}
- \end{tabular}
- }
- \caption{Mixed-size discrepancy (permitted by axiomatic models, forbidden by operational model)}
- \label{fig:litmus:discrepancy:rsw3}
-\end{figure}
-
-There is a known discrepancy between the operational and axiomatic specifications within the family of mixed-size RSW variants shown in Figures~\ref{fig:litmus:discrepancy:rsw1}--\ref{fig:litmus:discrepancy:rsw3}.
-To address this, we may choose to add something like the following new PPO rule:
-Memory operation $a$ precedes memory operation $b$ in preserved program order (and hence also in the global memory order) if $a$ precedes $b$ in program order, $a$ and $b$ both access regular main memory (rather than I/O regions), $a$ is a load, $b$ is a store, there is a load $m$ between $a$ and $b$, there is a byte $x$ that both $a$ and $m$ read, there is no store between $a$ and $m$ that writes to $x$, and $m$ precedes $b$ in PPO.
-In other words, in {\sf herd} syntax, we may choose to add ``{\tt (po-loc \& rsw);ppo;[W]}'' to PPO.
-Many implementations will already enforce this ordering naturally.
-As such, even though this rule is not official, we recommend that implementers enforce it nevertheless in order to ensure forwards compatibility with the possible future addition of this rule to RVWMO.
-
-\chapter{Formal Memory Model Specifications, Version 0.1}
-To facilitate formal analysis of RVWMO, this chapter presents a set of formalizations using different tools and modeling approaches. Any discrepancies are unintended; the expectation is that the models describe exactly the same sets of legal behaviors.
-
-This appendix should be treated as commentary; all normative material is provided in Chapter~\ref{ch:memorymodel} and in the rest of the main body of the ISA specification.
-All currently known discrepancies are listed in Section~\ref{sec:memory:discrepancies}.
-Any other discrepancies are unintentional.
-
-\clearpage
-\input{memory-model-alloy.tex}
-
-\clearpage
-\input{memory-model-herd.tex}
-
-\clearpage
-\input{memory-model-operational.tex}
diff --git a/src/memory-model-alloy.tex b/src/mm-alloy.adoc
index c584931..1352fad 100644
--- a/src/memory-model-alloy.tex
+++ b/src/mm-alloy.adoc
@@ -1,28 +1,17 @@
-\section{Formal Axiomatic Specification in Alloy}
-\label{sec:alloy}
-
-\lstdefinelanguage{alloy}{
- morekeywords={abstract, sig, extends, pred, fun, fact, no, set, one, lone, let, not, all, iden, some, run, for},
- morecomment=[l]{//},
- morecomment=[s]{/*}{*/},
- commentstyle=\color{green!40!black},
- keywordstyle=\color{blue!40!black},
- moredelim=**[is][\color{red}]{@}{@},
- escapeinside={!}{!},
-}
-\lstset{language=alloy}
-\lstset{aboveskip=0pt}
-\lstset{belowskip=0pt}
+[[sec:alloy]]
+== Formal Axiomatic Specification in Alloy
+
+We present a formal specification of the RVWMO memory model in Alloy
+(https://alloytools.org/). This model is available online at
+https://github.com/daniellustig/riscv-memory-model.
-We present a formal specification of the RVWMO memory model in Alloy (\url{http://alloy.mit.edu}).
-This model is available online at \url{https://github.com/daniellustig/riscv-memory-model}.
+The online material also contains some litmus tests and some examples of
+how Alloy can be used to model check some of the mappings in
+Section #sec:memory:porting[[sec:memory:porting]].
-The online material also contains some litmus tests and some examples of how Alloy can be used to model check some of the mappings in Section~\ref{sec:memory:porting}.
+` `
-\begin{figure}[h!]
- {
- \tt\bfseries\centering\footnotesize
- \begin{lstlisting}
+....
////////////////////////////////////////////////////////////////////////////////
// =RVWMO PPO=
@@ -52,14 +41,11 @@ fun ppo : Event->Event {
// the global memory order respects preserved program order
fact { ppo in ^gmo }
-\end{lstlisting}}
- \caption{The RVWMO memory model formalized in Alloy (1/5: PPO)}
- \label{fig:alloy1}
-\end{figure}
-\begin{figure}[h!]
- {
- \tt\bfseries\centering\footnotesize
- \begin{lstlisting}
+....
+
+` `
+
+....
////////////////////////////////////////////////////////////////////////////////
// =RVWMO axioms=
@@ -88,15 +74,11 @@ pred Atomicity {
// Progress Axiom implicit: Alloy only considers finite executions
pred RISCV_mm { LoadValue and Atomicity /* and Progress */ }
+....
+
+` `
-\end{lstlisting}}
- \caption{The RVWMO memory model formalized in Alloy (2/5: Axioms)}
- \label{fig:alloy2}
-\end{figure}
-\begin{figure}[h!]
- {
- \tt\bfseries\centering\footnotesize
- \begin{lstlisting}
+....
////////////////////////////////////////////////////////////////////////////////
// Basic model of memory
@@ -149,15 +131,11 @@ fact { pr + pw + sr + sw in iden }
fact { acquireRCpc + acquireRCsc + releaseRCpc + releaseRCsc in iden }
// don't try to encode FenceTSO via pr/pw/sr/sw; just use it as-is
fact { no FenceTSO.(pr + pw + sr + sw) }
-\end{lstlisting}}
- \caption{The RVWMO memory model formalized in Alloy (3/5: model of memory)}
- \label{fig:alloy3}
-\end{figure}
-
-\begin{figure}[h!]
- {
- \tt\bfseries\centering\footnotesize
- \begin{lstlisting}
+....
+
+` `
+
+....
////////////////////////////////////////////////////////////////////////////////
// =Basic model rules=
@@ -199,15 +177,11 @@ fact { Init->(MemoryEvent & NonInit) in ^gmo }
fact { all e: NonInit | one e.*~po.~start } // each event is in exactly one hart
fact { all a: Address | one Init & a.~address } // one init store per address
fact { no Init <: po and no po :> Init }
-\end{lstlisting}}
- \caption{The RVWMO memory model formalized in Alloy (4/5: Basic model rules)}
- \label{fig:alloy4}
-\end{figure}
-
-\begin{figure}[h!]
- {
- \tt\bfseries\centering\footnotesize
- \begin{lstlisting}
+....
+
+` `
+
+....
// po
fact { acyclic[po] }
@@ -262,8 +236,4 @@ pred total[rel: Event->Event, bag: Event] {
all disj e, e': bag | e->e' in rel + ~rel
acyclic[rel]
}
-\end{lstlisting}}
- \caption{The RVWMO memory model formalized in Alloy (5/5: Auxiliaries)}
- \label{fig:alloy5}
-\end{figure}
-
+....
diff --git a/src/mm-eplan.adoc b/src/mm-eplan.adoc
new file mode 100644
index 0000000..798e73f
--- /dev/null
+++ b/src/mm-eplan.adoc
@@ -0,0 +1,1851 @@
+[appendix]
+== RVWMO Explanatory Material, Version 0.1
+[[mm-explain]]
+
+This section provides more explanation for RVWMO
+<<memorymodel>>, using more informal
+language and concrete examples. These are intended to clarify the
+meaning and intent of the axioms and preserved program order rules. This
+appendix should be treated as commentary; all normative material is
+provided in <<memorymodel>> and in the rest of
+the main body of the ISA specification. All currently known
+discrepancies are listed in <<discrepancies>>. Any
+other discrepancies are unintentional.
+
+[[whyrvwmo]]
+=== Why RVWMO?
+
+Memory consistency models fall along a loose spectrum from weak to
+strong. Weak memory models allow more hardware implementation
+flexibility and deliver arguably better performance, performance per
+watt, power, scalability, and hardware verification overheads than
+strong models, at the expense of a more complex programming model.
+Strong models provide simpler programming models, but at the cost of
+imposing more restrictions on the kinds of (non-speculative) hardware
+optimizations that can be performed in the pipeline and in the memory
+system, and in turn imposing some cost in terms of power, area overhead,
+and verification burden.
+
+RISC-V has chosen the RVWMO memory model, a variant of release
+consistency. This places it in between the two extremes of the memory
+model spectrum. The RVWMO memory model enables architects to build
+simple implementations, aggressive implementations, implementations
+embedded deeply inside a much larger system and subject to complex
+memory system interactions, or any number of other possibilities, all
+while simultaneously being strong enough to support programming language
+memory models at high performance.
+
+To facilitate the porting of code from other architectures, some
+hardware implementations may choose to implement the Ztso extension,
+which provides stricter RVTSO ordering semantics by default. Code
+written for RVWMO is automatically and inherently compatible with RVTSO,
+but code written assuming RVTSO is not guaranteed to run correctly on
+RVWMO implementations. In fact, most RVWMO implementations will (and
+should) simply refuse to run RVTSO-only binaries. Each implementation
+must therefore choose whether to prioritize compatibility with RVTSO
+code (e.g., to facilitate porting from x86) or whether to instead
+prioritize compatibility with other RISC-V cores implementing RVWMO.
+
+Some fences and/or memory ordering annotations in code written for RVWMO
+may become redundant under RVTSO; the cost that the default of RVWMO
+imposes on Ztso implementations is the incremental overhead of fetching
+those fences (e.g., FENCE R,RW and FENCE RW,W) which become no-ops on
+that implementation. However, these fences must remain present in the
+code if compatibility with non-Ztso implementations is desired.
+
+[[litmustests]]
+=== Litmus Tests
+
+The explanations in this chapter make use of _litmus tests_, or small
+programs designed to test or highlight one particular aspect of a memory
+model. <<litmus-sample>> shows an example
+of a litmus test with two harts. As a convention for this figure and for
+all figures that follow in this chapter, we assume that `s0-s2` are
+pre-set to the same value in all harts and that `s0` holds the address
+labeled `x`, `s1` holds `y`, and `s2` holds `z`, where `x`, `y`, and `z`
+are disjoint memory locations aligned to 8 byte boundaries. All other registers and all referenced memory locations are presumed to be initialized to zero. Each figure
+shows the litmus test code on the left, and a visualization of one
+particular valid or invalid execution on the right.
+
+[[litmus-sample, Litmus sample]]
+[float="center",align="center",cols="1a,.^1a",frame="none",grid="none",options="noheader"]
+.A sample litmus test and one forbidden execution (`a0=1`).
+|===
+|
+[.left]
+[%autowidth,float="center",align="center",cols="^,<,^,<",options="header"]
+!===
+2+!Hart 0 2+!Hart 1
+! !&#8942; ! !&#8942;
+! !li t1,1 ! !li t4,4
+!(a) !sw t1,0(s0) !(e) !sw t4,0(s0)
+! !&#8942; ! !&#8942;
+! !li t2,2 ! !
+!(b) !sw t2,0(s0) ! !
+! !&#8942; ! !&#8942;
+!(c) !lw a0,0(s0) ! !
+! !&#8942; ! !&#8942;
+! !li t3,3 ! !li t5,5
+!(d) !sw t3,0(s0) !(f) !sw t5,0(s0)
+! !&#8942; ! !&#8942;
+!===
+|
+!===
+//a! graphviz::images/graphviz/litmus_sample.txt[]
+a! image::graphviz/litmus_sample.png[]
+!===
+|===
+
+Litmus tests are used to understand the implications of the memory model
+in specific concrete situations. For example, in the litmus test of
+<<litmus-sample>>, the final value of `a0`
+in the first hart can be either 2, 4, or 5, depending on the dynamic
+interleaving of the instruction stream from each hart at runtime.
+However, in this example, the final value of `a0` in Hart 0 will never
+be 1 or 3; intuitively, the value 1 will no longer be visible at the
+time the load executes, and the value 3 will not yet be visible by the
+time the load executes. We analyze this test and many others below.
+
+<<<
+[[litmus-key]]
+.A key for the litmus test diagrams drawn in this appendix
+[%autowidth,cols="<,<",align="center",float="center",options="header",]
+|===
+|Edge |Full Name (and explanation)
+|rf |Reads From (from each store to the loads that return a value
+written by that store)
+
+|co |Coherence (a total order on the stores to each address)
+
+|fr |From-Reads (from each load to co-successors of the store from which
+the load returned a value)
+
+|ppo |Preserved Program Order
+
+|fence |Orderings enforced by a FENCE instruction
+
+|addr |Address Dependency
+
+|ctrl |Control Dependency
+
+|data |Data Dependency
+|===
+
+The diagram shown to the right of each litmus test shows a visual
+representation of the particular execution candidate being considered.
+These diagrams use a notation that is common in the memory model
+literature for constraining the set of possible global memory orders
+that could produce the execution in question. It is also the basis for
+the _herd_ models presented in
+<<sec:herd>>. This notation is explained in
+<<litmus-key>>. Of the listed relations, rf edges between
+harts, co edges, fr edges, and ppo edges directly constrain the global
+memory order (as do fence, addr, data, and some ctrl edges, via ppo).
+Other edges (such as intra-hart rf edges) are informative but do not
+constrain the global memory order.
+
+For example, in <<litmus-sample>>, `a0=1`
+could occur only if one of the following were true:
+
+* (b) appears before (a) in global memory order (and in the
+coherence order co). However, this violates RVWMO PPO
+rule `ppo:->st`. The co edge from (b) to (a) highlights this
+contradiction.
+* (a) appears before (b) in global memory order (and in the
+coherence order co). However, in this case, the Load Value Axiom would
+be violated, because (a) is not the latest matching store prior to (c)
+in program order. The fr edge from (c) to (b) highlights this
+contradiction.
+
+Since neither of these scenarios satisfies the RVWMO axioms, the outcome
+`a0=1` is forbidden.
+
+Beyond what is described in this appendix, a suite of more than seven
+thousand litmus tests is available at
+https://github.com/litmus-tests/litmus-tests-riscv.
+[NOTE]
+====
+The litmus tests repository also provides instructions on how to run the
+litmus tests on RISC-V hardware and how to compare the results with the
+operational and axiomatic models.
+
+In the future, we expect to adapt these memory model litmus tests for
+use as part of the RISC-V compliance test suite as well.
+====
+=== Explaining the RVWMO Rules
+
+In this section, we provide explanation and examples for all of the
+RVWMO rules and axioms.
+
+==== Preserved Program Order and Global Memory Order
+
+Preserved program order represents the subset of program order that must
+be respected within the global memory order. Conceptually, events from
+the same hart that are ordered by preserved program order must appear in
+that order from the perspective of other harts and/or observers. Events
+from the same hart that are not ordered by preserved program order, on
+the other hand, may appear reordered from the perspective of other harts
+and/or observers.
+
+Informally, the global memory order represents the order in which loads
+and stores perform. The formal memory model literature has moved away
+from specifications built around the concept of performing, but the idea
+is still useful for building up informal intuition. A load is said to
+have performed when its return value is determined. A store is said to
+have performed not when it has executed inside the pipeline, but rather
+only when its value has been propagated to globally visible memory. In
+this sense, the global memory order also represents the contribution of
+the coherence protocol and/or the rest of the memory system to
+interleave the (possibly reordered) memory accesses being issued by each
+hart into a single total order agreed upon by all harts.
+
+The order in which loads perform does not always directly correspond to
+the relative age of the values those two loads return. In particular, a
+load _b_ may perform before another load _a_ to
+the same address (i.e., _b_ may execute before
+_a_, and _b_ may appear before _a_
+in the global memory order), but _a_ may nevertheless return
+an older value than _b_. This discrepancy captures (among
+other things) the reordering effects of buffering placed between the
+core and memory. For example, _b_ may have returned a value
+from a store in the store buffer, while _a_ may have ignored
+that younger store and read an older value from memory instead. To
+account for this, at the time each load performs, the value it returns
+is determined by the load value axiom, not just strictly by determining
+the most recent store to the same address in the global memory order, as
+described below.
+
+[[loadvalueaxiom, Load value axiom]]
+==== Load value axiom
+
+[IMPORTANT]
+====
+<<ax-load>>: Each byte of each load _i_ returns the value written
+to that byte by the store that is the latest in global memory order among
+the following stores:
+
+. Stores that write that byte and that precede i in the global memory
+order
+. Stores that write that byte and that precede i in program order
+====
+
+Preserved program order is _not_ required to respect the ordering of a
+store followed by a load to an overlapping address. This complexity
+arises due to the ubiquity of store buffers in nearly all
+implementations. Informally, the load may perform (return a value) by
+forwarding from the store while the store is still in the store buffer,
+and hence before the store itself performs (writes back to globally
+visible memory). Any other hart will therefore observe the load as
+performing before the store.
+
+Consider the <<litms_sb_forward>>. When running this program on an implementation with
+store buffers, it is possible to arrive at the final outcome `a0=1, a1=0, a2=1, a3=0` as follows:
+
+[[litms_sb_forward]]
+.A store buffer forwarding litmus test (outcome permitted)
+[float="center",align="center",cols=".^1a,.^1a",frame="none",grid="none",options="noheader"]
+|===
+|
+[%autowidth,float="center",align="center",cols="^,<,^,<",options="header",align="center"]
+!===
+2+^!Hart 0 2+^!Hart 1
+2+^!li t1, 1 2+^!li t1, 1
+2+<!(a) sw t1,0(s0) 2+!(e) sw t1,0(s1)
+2+<!(b) lw a0,0(s0) 2+!(f) lw a2,0(s1)
+2+<!(c) fence r,r 2+!(g) fence r,r
+2+<!(d) lw a1,0(s1) 2+!(h) lw a3,0(s0)
+4+^!Outcome: `a0=1`, `a1=0`, `a2=1`, `a3=0`
+!===
+|
+!===
+//a! graphviz::images/graphviz/litmus_sb_fwd.txt[]
+a! image::graphviz/litmus_sb_fwd.png[]
+!===
+|===
+
+* (a) executes and enters the first hart's private store buffer
+* (b) executes and forwards its return value 1 from (a) in the
+store buffer
+* (c) executes since all previous loads (i.e., (b)) have
+completed
+* (d) executes and reads the value 0 from memory
+* (e) executes and enters the second hart's private store buffer
+* (f) executes and forwards its return value 1 from (e) in the
+store buffer
+* (g) executes since all previous loads (i.e., (f)) have
+completed
+* (h) executes and reads the value 0 from memory
+* (a) drains from the first hart's store buffer to memory
+* (e) drains from the second hart's store buffer to memory
+
+Therefore, the memory model must be able to account for this behavior.
+
+To put it another way, suppose the definition of preserved program order
+did include the following hypothetical rule: memory access
+_a_ precedes memory access _b_ in preserved
+program order (and hence also in the global memory order) if
+_a_ precedes _b_ in program order and
+_a_ and _b_ are accesses to the same memory
+location, _a_ is a write, and _b_ is a read.
+Call this "Rule X". Then we get the following:
+
+* (a) precedes (b): by rule X
+* (b) precedes (d): by rule <<overlapping-ordering, 4>>
+* (d) precedes (e): by the load value axiom. Otherwise, if (e)
+preceded (d), then (d) would be required to return the value 1. (This is
+a perfectly legal execution; it's just not the one in question)
+* (e) precedes (f): by rule X
+* (f) precedes (h): by rule <<overlapping-ordering, 4>>
+* (h) precedes (a): by the load value axiom, as above.
+
+The global memory order must be a total order and cannot be cyclic,
+because a cycle would imply that every event in the cycle happens before
+itself, which is impossible. Therefore, the execution proposed above
+would be forbidden, and hence the addition of rule X would forbid
+implementations with store buffer forwarding, which would clearly be
+undesirable.
+
+Nevertheless, even if (b) precedes (a) and/or (f) precedes (e) in the
+global memory order, the only sensible possibility in this example is
+for (b) to return the value written by (a), and likewise for (f) and
+(e). This combination of circumstances is what leads to the second
+option in the definition of the load value axiom. Even though (b)
+precedes (a) in the global memory order, (a) will still be visible to
+(b) by virtue of sitting in the store buffer at the time (b) executes.
+Therefore, even if (b) precedes (a) in the global memory order, (b)
+should return the value written by (a) because (a) precedes (b) in
+program order. Likewise for (e) and (f).
+
+[[litmus_ppoca]]
+.Key for test that highlights the behavior of store buffers
+[float="center",align="center",cols=".^1a,.^1a",frame="none",grid="none",options="noheader"]
+.The "PPOCA" store buffer forwarding litmus test (outcome permitted)
+|===
+|
+[%autowidth,cols="^,<,^,<",options="header",float="center",align="center"]
+!===
+2+^!Hart 0 2+^!Hart 1
+! !li t1, 1 !!li t1, 1
+!(a) !sw t1,0(s0) !!LOOP:
+!(b) !fence w,w !(d) !lw a0,0(s1)
+!(c) !sw t1,0(s1) !!beqz a0, LOOP
+2+! !(e) !sw t1,0(s2)
+2+! !(f) !lw a1,0(s2)
+2+! ! !xor a2,a1,a1
+2+! ! !add s0,s0,a2
+2+! !(g) !lw a2,0(s0)
+4+!Outcome: `a0=1`, `a1=1`, `a2=0`
+!===
+|
+!===
+//a! graphviz::images/graphviz/litmus_ppoca.txt[]
+a! image::graphviz/litmus_ppoca.png[]
+!===
+|===
+
+Another test that highlights the behavior of store buffers is shown in
+<<litmus_ppoca>>. In this example, (d) is
+ordered before (e) because of the control dependency, and (f) is ordered
+before (g) because of the address dependency. However, (e) is _not_
+necessarily ordered before (f), even though (f) returns the value
+written by (e). This could correspond to the following sequence of
+events:
+
+* (e) executes speculatively and enters the second hart's private
+store buffer (but does not drain to memory)
+* (f) executes speculatively and forwards its return value 1 from
+(e) in the store buffer
+* (g) executes speculatively and reads the value 0 from memory
+* (a) executes, enters the first hart's private store buffer, and
+drains to memory
+* (b) executes and retires
+* (c) executes, enters the first hart's private store buffer, and
+drains to memory
+* (d) executes and reads the value 1 from memory
+* (e), (f), and (g) commit, since the speculation turned out to be
+correct
+* (e) drains from the store buffer to memory
+
+[[atomicityaxiom]]
+==== Atomicity axiom
+
+[IMPORTANT]
+====
+<<ax-atom, Atomicity Axiom>> (for Aligned Atomics): If r and w are paired load and
+store operations generated by aligned LR and SC instructions in a hart
+h, s is a store to byte x, and r returns a value written by s, then s must
+precede w in the global memory order, and there can be no store from
+a hart other than h to byte x following s and preceding w in the global
+memory order.
+====
+
+The RISC-V architecture decouples the notion of atomicity from the
+notion of ordering. Unlike architectures such as TSO, RISC-V atomics
+under RVWMO do not impose any ordering requirements by default. Ordering
+semantics are only guaranteed by the PPO rules that otherwise apply.
+
+RISC-V contains two types of atomics: AMOs and LR/SC pairs. These
+conceptually behave differently, in the following way. LR/SC behave as
+if the old value is brought up to the core, modified, and written back
+to memory, all while a reservation is held on that memory location. AMOs
+on the other hand conceptually behave as if they are performed directly
+in memory. AMOs are therefore inherently atomic, while LR/SC pairs are
+atomic in the slightly different sense that the memory location in
+question will not be modified by another hart during the time the
+original hart holds the reservation.
+
+[[litmus_lrsdsc]]
+
+[frame=none]
+.In all four (independent) instances, the final store-conditional instruction is permitted but not guaranteed to succeed.
+|====
+|(a) lr.d a0, 0(s0) |(a) lr.d a0, 0(s0) |(a) lr.w a0, 0(s0) |(a) lr.w a0, 0(s0)
+
+|(b) sd t1, 0(s0) |(b) sw t1, 4(s0) |(b) sw t1, 4(s0) |(b) sw t1, 4(s0)
+
+|(c) sc.d t3, t2, 0(s0) |(c) sc.d t3, t2, 0(s0) |(c) sc.w t3, t2, 0(s0) |(c) addi s0, s0, 8
+
+||||(d) sc.w t3, t2, 0(s0)
+|====
+
+The atomicity axiom forbids stores from other harts from being
+interleaved in global memory order between an LR and the SC paired with
+that LR. The atomicity axiom does not forbid loads from being
+interleaved between the paired operations in program order or in the
+global memory order, nor does it forbid stores from the same hart or
+stores to non-overlapping locations from appearing between the paired
+operations in either program order or in the global memory order. For
+example, the SC instructions in <<litmus_lrsdsc>> may (but are not
+guaranteed to) succeed. None of those successes would violate the
+atomicity axiom, because the intervening non-conditional stores are from
+the same hart as the paired load-reserved and store-conditional
+instructions. This way, a memory system that tracks memory accesses at
+cache line granularity (and which therefore will see the four snippets
+of <<litmus_lrsdsc>> as identical) will not
+be forced to fail a store-conditional instruction that happens to
+(falsely) share another portion of the same cache line as the memory
+location being held by the reservation.
+
+The atomicity axiom also technically supports cases in which the LR and
+SC touch different addresses and/or use different access sizes; however,
+use cases for such behaviors are expected to be rare in practice.
+Likewise, scenarios in which stores from the same hart between an LR/SC
+pair actually overlap the memory location(s) referenced by the LR or SC
+are expected to be rare compared to scenarios where the intervening
+store may simply fall onto the same cache line.
+
+[[mm-progress]]
+==== Progress axiom
+
+[IMPORTANT]
+====
+<<ax-prog, Progress Axiom>>: No memory operation may be preceded in the global
+memory order by an infinite sequence of other memory operations.
+====
+
+The progress axiom ensures a minimal forward progress guarantee. It
+ensures that stores from one hart will eventually be made visible to
+other harts in the system in a finite amount of time, and that loads
+from other harts will eventually be able to read those values (or
+successors thereof). Without this rule, it would be legal, for example,
+for a spinlock to spin infinitely on a value, even with a store from
+another hart unlocking the spinlock.
+
+The progress axiom is intended not to impose any other notion of
+fairness, latency, or quality of service onto the harts in a RISC-V
+implementation. Any stronger notions of fairness are up to the rest of
+the ISA and/or up to the platform and/or device to define and implement.
+
+The forward progress axiom will in almost all cases be naturally
+satisfied by any standard cache coherence protocol. Implementations with
+non-coherent caches may have to provide some other mechanism to ensure
+the eventual visibility of all stores (or successors thereof) to all
+harts.
+
+[[mm-overlap]]
+==== Overlapping-Address Orderings (<<overlapping-ordering, Rules 1-3>>)
+
+[NOTE]
+====
+<<overlapping-ordering, Rule 1>>: b is a store, and a and b access overlapping memory addresses
+
+<<overlapping-ordering, Rule 2>>: a and b are loads, x is a byte read by both a and b, there is no
+store to x between a and b in program order, and a and b return values
+for x written by different memory operations
+
+<<overlapping-ordering, Rule 3>>: a is generated by an AMO or SC instruction, b is a load, and b
+returns a value written by a
+====
+
+Same-address orderings where the latter is a store are straightforward:
+a load or store can never be reordered with a later store to an
+overlapping memory location. From a microarchitecture perspective,
+generally speaking, it is difficult or impossible to undo a
+speculatively reordered store if the speculation turns out to be
+invalid, so such behavior is simply disallowed by the model.
+Same-address orderings from a store to a later load, on the other hand,
+do not need to be enforced. As discussed in
+<<loadvalueaxiom>>, this reflects the observable
+behavior of implementations that forward values from buffered stores to
+later loads.
+
+Same-address load-load ordering requirements are far more subtle. The
+basic requirement is that a younger load must not return a value that is
+older than a value returned by an older load in the same hart to the
+same address. This is often known as "CoRR" (Coherence for Read-Read
+pairs), or as part of a broader "coherence" or "sequential
+consistency per location" requirement. Some architectures in the past
+have relaxed same-address load-load ordering, but in hindsight this is
+generally considered to complicate the programming model too much, and
+so RVWMO requires CoRR ordering to be enforced. However, because the
+global memory order corresponds to the order in which loads perform
+rather than the ordering of the values being returned, capturing CoRR
+requirements in terms of the global memory order requires a bit of
+indirection.
+
+[[frirfi]]
+.A litmus test MP+fence.w.w+fri-rfi-addr (outcome permitted)
+
+[float="center",align="center",cols=".^1a,.^1a",frame="none",grid="none",options="noheader"]
+.Litmus test MP+fence.w.w+fre-rfi-addr (outcome permitted)
+|===
+|
+[%autowidth,cols="^,<,^,<",options="header",float="center",align="center"]
+!===
+2+!Hart 0 2+^!Hart 1
+!!li t1, 1 !!li t2, 2
+>!(a) !sw t1,0(s0) >!(d) !lw a0,0(s1)
+>!(b) !fence w, w >!(e) !sw t2,0(s1)
+>!(c) !sw t1,0(s1) >!(f) !lw a1,0(s1)
+! ! >!(g) !xor t3,a1,a1
+! ! >!(h) !add s0,s0,t3
+! ! >!(i) !lw a2,0(s0)
+4+^!Outcome: `a0=1`, `a1=2`, `a2=0`
+!===
+|
+!===
+//a! graphviz::images/graphviz/litmus_mp_fenceww_fri_rfi_addr.txt[]
+a! image::graphviz/litmus_mp_fenceww_fri_rfi_addr.png[]
+!===
+|===
+Consider the litmus test of <<frirfi>>, which is one particular
+instance of the more general "fri-rfi" pattern. The term "fri-rfi"
+refers to the sequence (d), (e), (f): (d) "from-reads" (i.e., reads
+from an earlier write than) (e) which is the same hart, and (f) reads
+from (e) which is in the same hart.
+
+From a microarchitectural perspective, outcome `a0=1`, `a1=2`, `a2=0` is
+legal (as are various other less subtle outcomes). Intuitively, the
+following would produce the outcome in question:
+
+* (d) stalls (for whatever reason; perhaps it's stalled waiting
+for some other preceding instruction)
+* (e) executes and enters the store buffer (but does not yet
+drain to memory)
+* (f) executes and forwards from (e) in the store buffer
+* (g), (h), and (i) execute
+* (a) executes and drains to memory, (b) executes, and (c)
+executes and drains to memory
+* (d) unstalls and executes
+* (e) drains from the store buffer to memory
+
+This corresponds to a global memory order of (f), (i), (a), (c), (d),
+(e). Note that even though (f) performs before (d), the value returned
+by (f) is newer than the value returned by (d). Therefore, this
+execution is legal and does not violate the CoRR requirements.
+
+Likewise, if two back-to-back loads return the values written by the
+same store, then they may also appear out-of-order in the global memory
+order without violating CoRR. Note that this is not the same as saying
+that the two loads return the same value, since two different stores may
+write the same value.
+
+[[litmus-rsw]]
+.Litmus test RSW (outcome permitted)
+
+[float="center",align="center",cols=".^1a,.^1a",frame="none",grid="none",options="noheader"]
+|===
+|
+[%autowidth,cols="^,<,^,<",options="header",float="center",align="center"]
+!===
+2+!Hart 0 2+^!Hart 1
+2+!li t1, 1 >!(d) <!lw a0,0(s1)
+>!(a) <!sw t1,0(s0) >!(e) !xor t2,a0,a0
+>!(b) <!fence w, w >!(f) !add s4,s2,t2
+>!(c) <!sw t1,0(s1) >!(g) !lw a1,0(s4)
+! ! >!(h) !lw a2,0(s2)
+! ! >!(i) !xor t3,a2,a2
+! ! >!(j) !add s0,s0,t3
+! ! >!(k) !lw a3,0(s0)
+4+!Outcome: `a0=1`, `a1=v`, `a2=v`, `a3=0`
+!===
+|
+!===
+//a! graphviz::images/graphviz/litmus_rsw.txt[]
+a! image::graphviz/litmus_rsw.png[]
+!===
+|===
+
+Consider the litmus test of <<litmus-rsw>>.
+The outcome `a0=1`, `a1=v`, `a2=v`, `a3=0` (where _v_ is
+some value written by another hart) can be observed by allowing (g) and
+(h) to be reordered. This might be done speculatively, and the
+speculation can be justified by the microarchitecture (e.g., by snooping
+for cache invalidations and finding none) because replaying (h) after
+(g) would return the value written by the same store anyway. Hence
+assuming `a1` and `a2` would end up with the same value written by the
+same store anyway, (g) and (h) can be legally reordered. The global
+memory order corresponding to this execution would be
+(h),(k),(a),(c),(d),(g).
+
+Executions of the test in <<litmus-rsw>> in
+which `a1` does not equal `a2` do in fact require that (g) appears
+before (h) in the global memory order. Allowing (h) to appear before (g)
+in the global memory order would in that case result in a violation of
+CoRR, because then (h) would return an older value than that returned by
+(g). Therefore, <<overlapping-ordering, rule 2>> forbids this CoRR violation
+from occurring. As such, <<overlapping-ordering, rule 2>> strikes a careful
+balance between enforcing CoRR in all cases while simultaneously being
+weak enough to permit "RSW" and "fri-rfi" patterns that commonly
+appear in real microarchitectures.
+
+There is one more overlapping-address rule: <<overlapping-ordering,
+rule 3>> simply states that a value cannot
+be returned from an AMO or SC to a subsequent load until the AMO or SC
+has (in the case of the SC, successfully) performed globally. This
+follows somewhat naturally from the conceptual view that both AMOs and
+SC instructions are meant to be performed atomically in memory. However,
+notably, <<overlapping-ordering, rule 3>> states that hardware
+may not even non-speculatively forward the value being stored by an
+AMOSWAP to a subsequent load, even though for AMOSWAP that store value
+is not actually semantically dependent on the previous value in memory,
+as is the case for the other AMOs. The same holds true even when
+forwarding from SC store values that are not semantically dependent on
+the value returned by the paired LR.
+
+The three PPO rules above also apply when the memory accesses in
+question only overlap partially. This can occur, for example, when
+accesses of different sizes are used to access the same object. Note
+also that the base addresses of two overlapping memory operations need
+not necessarily be the same for two memory accesses to overlap. When
+misaligned memory accesses are being used, the overlapping-address PPO
+rules apply to each of the component memory accesses independently.
+
+[[mm-fence]]
+==== Fences (<<overlapping-ordering, Rule 4>>)
+
+[IMPORTANT]
+====
+Rule <<overlapping-ordering, 4>>: There is a FENCE instruction that orders a before b
+====
+
+By default, the FENCE instruction ensures that all memory accesses from
+instructions preceding the fence in program order (the "predecessor
+set") appear earlier in the global memory order than memory accesses
+from instructions appearing after the fence in program order (the
+"successor set"). However, fences can optionally further restrict the
+predecessor set and/or the successor set to a smaller set of memory
+accesses in order to provide some speedup. Specifically, fences have PR,
+PW, SR, and SW bits which restrict the predecessor and/or successor
+sets. The predecessor set includes loads (resp.stores) if and only if PR
+(resp.PW) is set. Similarly, the successor set includes loads
+(resp.stores) if and only if SR (resp.SW) is set.
+
+The FENCE encoding currently has nine non-trivial combinations of the
+four bits PR, PW, SR, and SW, plus one extra encoding FENCE.TSO which
+facilitates mapping of "acquire+release" or RVTSO semantics. The
+remaining seven combinations have empty predecessor and/or successor
+sets and hence are no-ops. Of the ten non-trivial options, only six are
+commonly used in practice:
+
+* FENCE RW,RW
+* FENCE.TSO
+* FENCE RW,W
+* FENCE R,RW
+* FENCE R,R
+* FENCE W,W
+
+FENCE instructions using any other combination of PR, PW, SR, and SW are
+reserved. We strongly recommend that programmers stick to these six.
+Other combinations may have unknown or unexpected interactions with the
+memory model.
+
+Finally, we note that since RISC-V uses a multi-copy atomic memory
+model, programmers can reason about fences bits in a thread-local
+manner. Fences in RISC-V are not cumulative, as they are in some
+non-multi-copy-atomic memory models.
+
+[[sec:memory:acqrel]]
+==== Explicit Synchronization (<<overlapping-ordering, Rules 5-8>>)
+
+[IMPORTANT]
+====
+<<overlapping-ordering, Rule 5>>: a has an acquire annotation
+
+<<overlapping-ordering, Rule 6>>: b has a release annotation
+
+<<overlapping-ordering, Rule 7>>: a and b both have RCsc annotations
+
+<<overlapping-ordering, Rule 8>>: a is paired with b
+====
+
+An _acquire_ operation, as would be used at the start of a critical
+section, requires all memory operations following the acquire in program
+order to also follow the acquire in the global memory order. This
+ensures, for example, that all loads and stores inside the critical
+section are up to date with respect to the synchronization variable
+being used to protect it. Acquire ordering can be enforced in one of two
+ways: with an acquire annotation, which enforces ordering with respect
+to just the synchronization variable itself, or with a FENCE R,RW, which
+enforces ordering with respect to all previous loads.
+
+[[spinlock_atomics]]
+.A spinlock with atomics
+[source%linenums,asm]
+....
+ sd x1, (a1) # Arbitrary unrelated store
+ ld x2, (a2) # Arbitrary unrelated load
+ li t0, 1 # Initialize swap value.
+ again:
+ amoswap.w.aq t0, t0, (a0) # Attempt to acquire lock.
+ bnez t0, again # Retry if held.
+ # ...
+ # Critical section.
+ # ...
+ amoswap.w.rl x0, x0, (a0) # Release lock by storing 0.
+ sd x3, (a3) # Arbitrary unrelated store
+ ld x4, (a4) # Arbitrary unrelated load
+....
+
+Consider <<spinlock_atomics, Example 1>>.
+Because this example uses _aq_, the loads and stores in the critical
+section are guaranteed to appear in the global memory order after the
+AMOSWAP used to acquire the lock. However, assuming `a0`, `a1`, and `a2`
+point to different memory locations, the loads and stores in the
+critical section may or may not appear after the "Arbitrary unrelated
+load" at the beginning of the example in the global memory order.
+
+[[spinlock_fences]]
+.A spinlock with fences
+[source%linenums,asm]
+....
+ sd x1, (a1) # Arbitrary unrelated store
+ ld x2, (a2) # Arbitrary unrelated load
+ li t0, 1 # Initialize swap value.
+ again:
+ amoswap.w t0, t0, (a0) # Attempt to acquire lock.
+ fence r, rw # Enforce "acquire" memory ordering
+ bnez t0, again # Retry if held.
+ # ...
+ # Critical section.
+ # ...
+ fence rw, w # Enforce "release" memory ordering
+ amoswap.w x0, x0, (a0) # Release lock by storing 0.
+ sd x3, (a3) # Arbitrary unrelated store
+ ld x4, (a4) # Arbitrary unrelated load
+....
+
+Now, consider the alternative in <<spinlock_fences, Example 2>>. In
+this case, even though the AMOSWAP does not enforce ordering with an
+_aq_ bit, the fence nevertheless enforces that the acquire AMOSWAP
+appears earlier in the global memory order than all loads and stores in
+the critical section. Note, however, that in this case, the fence also
+enforces additional orderings: it also requires that the "Arbitrary
+unrelated load" at the start of the program appears earlier in the
+global memory order than the loads and stores of the critical section.
+(This particular fence does not, however, enforce any ordering with
+respect to the "Arbitrary unrelated store" at the start of the
+snippet.) In this way, fence-enforced orderings are slightly coarser
+than orderings enforced by _.aq_.
+
+Release orderings work exactly the same as acquire orderings, just in
+the opposite direction. Release semantics require all loads and stores
+preceding the release operation in program order to also precede the
+release operation in the global memory order. This ensures, for example,
+that memory accesses in a critical section appear before the
+lock-releasing store in the global memory order. Just as for acquire
+semantics, release semantics can be enforced using release annotations
+or with a FENCE RW,W operation. Using the same examples, the ordering
+between the loads and stores in the critical section and the "Arbitrary
+unrelated store" at the end of the code snippet is enforced only by the
+FENCE RW,W in <<spinlock_fences, Example 2>>, not by
+the _rl_ in <<spinlock_atomics, Example 1>>.
+
+With RCpc annotations alone, store-release-to-load-acquire ordering is
+not enforced. This facilitates the porting of code written under the TSO
+and/or RCpc memory models. To enforce store-release-to-load-acquire
+ordering, the code must use store-release-RCsc and load-acquire-RCsc
+operations so that PPO rule 7 applies. RCpc alone is
+sufficient for many use cases in C/C\++ but is insufficient for many
+other use cases in C/C++, Java, and Linux, to name just a few examples;
+see <<memory_porting, Memory Porting>> for details.
+
+PPO rule 8 indicates that an SC must appear after
+its paired LR in the global memory order. This will follow naturally
+from the common use of LR/SC to perform an atomic read-modify-write
+operation due to the inherent data dependency. However, PPO
+rule 8 also applies even when the value being stored
+does not syntactically depend on the value returned by the paired LR.
+
+Lastly, we note that, as with fences, ordering annotations are
+not cumulative.
+
+[[sec:memory:dependencies]]
+==== Syntactic Dependencies (<<overlapping-ordering, Rules 9-11>>)
+
+[[ppo-addr]]
+[IMPORTANT]
+====
+<<overlapping-ordering, Rule 9>>: b has a syntactic address dependency on a
+
+<<overlapping-ordering, Rule 10>>: b has a syntactic data dependency on a
+
+<<overlapping-ordering, Rule 11>>: b is a store, and b has a syntactic control dependency on a
+====
+
+Dependencies from a load to a later memory operation in the same hart
+are respected by the RVWMO memory model. The Alpha memory model was
+notable for choosing _not_ to enforce the ordering of such dependencies,
+but most modern hardware and software memory models consider allowing
+dependent instructions to be reordered too confusing and
+counterintuitive. Furthermore, modern code sometimes intentionally uses
+such dependencies as a particularly lightweight ordering enforcement
+mechanism.
+
+The terms in <<mem-dependencies>> work as follows. Instructions
+are said to carry dependencies from their
+source register(s) to their destination register(s) whenever the value
+written into each destination register is a function of the source
+register(s). For most instructions, this means that the destination
+register(s) carry a dependency from all source register(s). However,
+there are a few notable exceptions. In the case of memory instructions,
+the value written into the destination register ultimately comes from
+the memory system rather than from the source register(s) directly, and
+so this breaks the chain of dependencies carried from the source
+register(s). In the case of unconditional jumps, the value written into
+the destination register comes from the current `pc` (which is never
+considered a source register by the memory model), and so likewise, JALR
+(the only jump with a source register) does not carry a dependency from
+_rs1_ to _rd_.
+
+
+[[fflags]]
+.(c) has a syntactic dependency on both (a) and (b) via fflags, a destination register that both (a) and (b) implicitly accumulate into
+[.text-center,source%linenums,asm]
+----
+(a) fadd f3,f1,f2
+(b) fadd f6,f4,f5
+(c) csrrs a0,fflags,x0
+----
+
+The notion of accumulating into a destination register rather than
+writing into it reflects the behavior of CSRs such as `fflags`. In
+particular, an accumulation into a register does not clobber any
+previous writes or accumulations into the same register. For example, in
+<<fflags>>, (c) has a syntactic dependency on both (a) and (b).
+
+Like other modern memory models, the RVWMO memory model uses syntactic
+rather than semantic dependencies. In other words, this definition
+depends on the identities of the registers being accessed by different
+instructions, not the actual contents of those registers. This means
+that an address, control, or data dependency must be enforced even if
+the calculation could seemingly be `optimized away`. This choice
+ensures that RVWMO remains compatible with code that uses these false
+syntactic dependencies as a lightweight ordering mechanism.
+
+[[address]]
+.A syntactic address dependency
+[.text-center, source%linenums, asm]
+----
+ld a1,0(s0)
+xor a2,a1,a1
+add s1,s1,a2
+ld a5,0(s1)
+----
+
+For example, there is a syntactic address dependency from the memory
+operation generated by the first instruction to the memory operation
+generated by the last instruction in
+<<address>>, even though `a1` XOR
+`a1` is zero and hence has no effect on the address accessed by the
+second load.
+
+The benefit of using dependencies as a lightweight synchronization
+mechanism is that the ordering enforcement requirement is limited only
+to the specific two instructions in question. Other non-dependent
+instructions may be freely reordered by aggressive implementations. One
+alternative would be to use a load-acquire, but this would enforce
+ordering for the first load with respect to _all_ subsequent
+instructions. Another would be to use a FENCE R,R, but this would
+include all previous and all subsequent loads, making this option more
+expensive.
+
+[[control1]]
+.A syntactic control dependency
+[.text-center, source%linenums, asm]
+----
+lw x1,0(x2)
+bne x1,x0,next
+sw x3,0(x4)
+next: sw x5,0(x6)
+----
+
+Control dependencies behave differently from address and data
+dependencies in the sense that a control dependency always extends to
+all instructions following the original target in program order.
+Consider <<control1>> the
+instruction at `next` will always execute, but the memory operation
+generated by that last instruction nevertheless still has a control
+dependency from the memory operation generated by the first instruction.
+
+[[control2]]
+.Another syntactic control dependency
+[.text-center,source%linenums,asm]
+----
+lw x1,0(x2)
+bne x1,x0,next
+next: sw x3,0(x4)
+----
+
+Likewise, consider <<control2>>.
+Even though both branch outcomes have the same target, there is still a
+control dependency from the memory operation generated by the first
+instruction in this snippet to the memory operation generated by the
+last instruction. This definition of control dependency is subtly
+stronger than what might be seen in other contexts (e.g., C++), but it
+conforms with standard definitions of control dependencies in the
+literature.
+
+Notably, PPO rules <<overlapping-ordering, 9-11>> are also
+intentionally designed to respect dependencies that originate from the
+output of a successful store-conditional instruction. Typically, an SC
+instruction will be followed by a conditional branch checking whether
+the outcome was successful; this implies that there will be a control
+dependency from the store operation generated by the SC instruction to
+any memory operations following the branch. PPO
+rule <<ppo, 11>> in turn implies that any subsequent store
+operations will appear later in the global memory order than the store
+operation generated by the SC. However, since control, address, and data
+dependencies are defined over memory operations, and since an
+unsuccessful SC does not generate a memory operation, no order is
+enforced between unsuccessful SC and its dependent instructions.
+Moreover, since SC is defined to carry dependencies from its source
+registers to _rd_ only when the SC is successful, an unsuccessful SC has
+no effect on the global memory order.
+
+[[litmus_lb_lrsc]]
+.A variant of the LB litmus test (outcome forbidden)
+[float="center",align="center",cols=".^1a,.^1a",frame="none",grid="none",options="noheader"]
+|===
+|
+[%autowidth,cols="^,<,^,<",float="center",align="center"]
+!===
+4+!Initial values: 0(s0)=1; 0(s2)=1
+4+!
+2+^!Hart 0 2+^!Hart 1
+!(a) !ld a0,0(s0) !(e) !ld a3,0(s2)
+!(b) !lr a1,0(s1) !(f) !sd a3,0(s0)
+!(c) !sc a2,a0,0(s1) ! !
+!(d) !sd a2,0(s2) ! !
+4+!Outcome: `a0=0`, `a3=0`
+!===
+|
+!===
+//a! graphviz::images/graphviz/litmus_lb_lrsc.txt[]
+a! image::graphviz/litmus_lb_lrsc.png[]
+!===
+|===
+
+In addition, the choice to respect dependencies originating at
+store-conditional instructions ensures that certain out-of-thin-air-like
+behaviors will be prevented. Consider
+<<litmus_lb_lrsc>>. Suppose a
+hypothetical implementation could occasionally make some early guarantee
+that a store-conditional operation will succeed. In this case, (c) could
+return 0 to `a2` early (before actually executing), allowing the
+sequence (d), (e), (f), (a), and then (b) to execute, and then (c) might
+execute (successfully) only at that point. This would imply that (c)
+writes its own success value to `0(s1)`! Fortunately, this situation and
+others like it are prevented by the fact that RVWMO respects
+dependencies originating at the stores generated by successful SC
+instructions.
+
+We also note that syntactic dependencies between instructions only have
+any force when they take the form of a syntactic address, control,
+and/or data dependency. For example: a syntactic dependency between two
+`F` instructions via one of the `accumulating CSRs` in
+<<source-dest-regs>> does _not_ imply
+that the two `F` instructions must be executed in order. Such a
+dependency would only serve to ultimately set up later a dependency from
+both `F` instructions to a later CSR instruction accessing the CSR
+flag in question.
+
+[[memory-ppopipeline]]
+==== Pipeline Dependencies (<<overlapping-ordering, Rules 12-13>>)
+
+[[addrdatarfi]]
+[IMPORTANT]
+====
+<<overlapping-ordering, Rule 12>>: b is a load, and there exists some store m between a and b in
+program order such that m has an address or data dependency on a,
+and b returns a value written by m
+
+<<overlapping-ordering, Rule 13>>: b is a store, and there exists some instruction m between a and
+b in program order such that m has an address dependency on a
+====
+
+[[litmus_datarfi]]
+.Because of PPO <<overlapping-ordering, rule 12>> and the data dependency from (d) to (e), (d) must also precede (f) in the global memory order (outcome forbidden)
+[float="center",align="center",cols=".^1a,.^1a",frame="none",grid="none",options="noheader"]
+|===
+|
+[%autowidth,float="center",align="center",cols="^,<,^,<",options="header",]
+!===
+2+!Hart 0 2+! Hart 1
+! !li t1, 1 !(d) !lw a0, 0(s1)
+!(a) !sw t1,0(s0) !(e) !sw a0, 0(s2)
+!(b) !fence w, w !(f) !lw a1, 0(s2)
+!(c) !sw t1,0(s1) ! !xor a2,a1,a1
+! ! ! !add s0,s0,a2
+! ! !(g) !lw a3,0(s0)
+4+!Outcome: `a0=1`, `a3=0`
+!===
+|
+!===
+//a! graphviz::images/graphviz/litmus_datarfi.txt[]
+a! image::graphviz/litmus_datarfi.png[]
+!===
+|===
+
+PPO rules <<overlapping-ordering, 12>> and <<overlapping-ordering, 13>> reflect behaviors of almost all real processor
+pipeline implementations. Rule <<overlapping-ordering, 12>>
+states that a load cannot forward from a store until the address and
+data for that store are known. Consider <<litmus_datarfi>> (f) cannot be
+executed until the data for (e) has been resolved, because (f) must
+return the value written by (e) (or by something even later in the
+global memory order), and the old value must not be clobbered by the
+write-back of (e) before (d) has had a chance to perform. Therefore, (f)
+will never perform before (d) has performed.
+
+
+.Because of the extra store between (e) and (g), (d) no longer necessarily precedes (g) (outcome permitted)
+
+[float="center",align="center",cols=".^1a,.^1a",frame="none",grid="none",options="noheader"]
+|===
+|
+[%autowidth,cols="^,<,^,<",float="center",align="center",options="header",]
+!===
+2+!Hart 0 2+!Hart 1
+2+!li t1, 1 2+^!li t1, 1
+!(a) !sw t1,0(s0) !(d) !lw a0, 0(s1)
+!(b) !fence w, w !(e) !sw a0, 0(s2)
+!(c) !sw t1,0(s1) !(f) !sw t1, 0(s2)
+! ! !(g) !lw a1, 0(s2)
+! ! ! !xor a2,a1,a1
+! ! ! !add s0,s0,a2
+! ! !(h) !lw a3,0(s0)
+4+!Outcome: `a0=1`, `a3=0`
+!===
+|
+!===
+//a! graphviz::images/graphviz/litmus_datacoirfi.txt[]
+a! image::graphviz/litmus_datacoirfi.png[]
+!===
+|===
+
+If there were another store to the same address in between (e) and (f),
+as in <<litmus:addrdatarfi_no>>,
+then (f) would no longer be dependent on the data of (e) being resolved,
+and hence the dependency of (f) on (d), which produces the data for (e),
+would be broken.
+
+Rule <<overlapping-ordering, 13>> makes a similar observation to the
+previous rule: a store cannot be performed at memory until all previous
+loads that might access the same address have themselves been performed.
+Such a load must appear to execute before the store, but it cannot do so
+if the store were to overwrite the value in memory before the load had a
+chance to read the old value. Likewise, a store generally cannot be
+performed until it is known that preceding instructions will not cause
+an exception due to failed address resolution, and in this sense,
+rule 13 can be seen as somewhat of a special case
+of rule <<overlapping-ordering, 11>>.
+
+[[litmus:addrdatarfi_no]]
+.Because of the address dependency from (d) to (e), (d) also precedes (f) (outcome forbidden)
+[float="center",align="center",cols=".^1a,.^1a",frame="none",grid="none",options="noheader"]
+|===
+|
+[%autowidth,cols="^,<,^,<"float="center",align="center",options="header"]
+!===
+2+!Hart 0 2+^!Hart 1
+2+! 2+^!li t1, 1
+!(a) !lw a0,0(s0) !(d) !lw a1, 0(s1)
+!(b) !fence rw,rw !(e) !lw a2, 0(a1)
+!(c) !sw s2,0(s1) !(f) !sw t1, 0(s0)
+4+!Outcome: `a0=1`, `a1=t`
+!===
+|
+!===
+//a! graphviz::images/graphviz/litmus_addrpo.txt[]
+a! image:graphviz/litmus_addrpo.png[]
+!===
+|===
+
+Consider <<litmus:addrdatarfi_no>> (f) cannot be
+executed until the address for (e) is resolved, because it may turn out
+that the addresses match; i.e., that `a1=s0`. Therefore, (f) cannot be
+sent to memory before (d) has executed and confirmed whether the
+addresses do indeed overlap.
+
+=== Beyond Main Memory
+
+RVWMO does not currently attempt to formally describe how FENCE.I,
+SFENCE.VMA, I/O fences, and PMAs behave. All of these behaviors will be
+described by future formalizations. In the meantime, the behavior of
+FENCE.I is described in <<zifencei>>, the
+behavior of SFENCE.VMA is described in the RISC-V Instruction Set
+Privileged Architecture Manual, and the behavior of I/O fences and the
+effects of PMAs are described below.
+
+==== Coherence and Cacheability
+
+The RISC-V Privileged ISA defines Physical Memory Attributes (PMAs)
+which specify, among other things, whether portions of the address space
+are coherent and/or cacheable. See the RISC-V Privileged ISA
+Specification for the complete details. Here, we simply discuss how the
+various details in each PMA relate to the memory model:
+
+* Main memory vs.I/O, and I/O memory ordering PMAs: the memory model as
+defined applies to main memory regions. I/O ordering is discussed below.
+* Supported access types and atomicity PMAs: the memory model is simply
+applied on top of whatever primitives each region supports.
+* Cacheability PMAs: the cacheability PMAs in general do not affect the
+memory model. Non-cacheable regions may have more restrictive behavior
+than cacheable regions, but the set of allowed behaviors does not change
+regardless. However, some platform-specific and/or device-specific
+cacheability settings may differ.
+* Coherence PMAs: The memory consistency model for memory regions marked
+as non-coherent in PMAs is currently platform-specific and/or
+device-specific: the load-value axiom, the atomicity axiom, and the
+progress axiom all may be violated with non-coherent memory. Note
+however that coherent memory does not require a hardware cache coherence
+protocol. The RISC-V Privileged ISA Specification suggests that
+hardware-incoherent regions of main memory are discouraged, but the
+memory model is compatible with hardware coherence, software coherence,
+implicit coherence due to read-only memory, implicit coherence due to
+only one agent having access, or otherwise.
+* Idempotency PMAs: Idempotency PMAs are used to specify memory regions
+for which loads and/or stores may have side effects, and this in turn is
+used by the microarchitecture to determine, e.g., whether prefetches are
+legal. This distinction does not affect the memory model.
+
+==== I/O Ordering
+
+For I/O, the load value axiom and atomicity axiom in general do not
+apply, as both reads and writes might have device-specific side effects
+and may return values other than the value "written" by the most
+recent store to the same address. Nevertheless, the following preserved
+program order rules still generally apply for accesses to I/O memory:
+memory access _a_ precedes memory access _b_ in
+global memory order if _a_ precedes _b_ in
+program order and one or more of the following holds:
+
+. _a_ precedes _b_ in preserved program order as
+defined in <<memorymodel>>, with the exception
+that acquire and release ordering annotations apply only from one memory
+operation to another memory operation and from one I/O operation to
+another I/O operation, but not from a memory operation to an I/O nor
+vice versa
+. _a_ and _b_ are accesses to overlapping
+addresses in an I/O region
+. _a_ and _b_ are accesses to the same strongly
+ordered I/O region
+. _a_ and _b_ are accesses to I/O regions, and
+the channel associated with the I/O region accessed by either
+_a_ or _b_ is channel 1
+. _a_ and _b_ are accesses to I/O regions
+associated with the same channel (except for channel 0)
+
+Note that the FENCE instruction distinguishes between main memory
+operations and I/O operations in its predecessor and successor sets. To
+enforce ordering between I/O operations and main memory operations, code
+must use a FENCE with PI, PO, SI, and/or SO, plus PR, PW, SR, and/or SW.
+For example, to enforce ordering between a write to main memory and an
+I/O write to a device register, a FENCE W,O or stronger is needed.
+[[wo]]
+.Ordering memory and I/O accesses
+[.text-center,source%linenums,asm]
+----
+sd t0, 0(a0)
+fence w,o
+sd a0, 0(a1)
+----
+
+When a fence is in fact used, implementations must assume that the
+device may attempt to access memory immediately after receiving the MMIO
+signal, and subsequent memory accesses from that device to memory must
+observe the effects of all accesses ordered prior to that MMIO
+operation. In other words, in <<wo>>,
+suppose `0(a0)` is in main memory and `0(a1)` is the address of a device
+register in I/O memory. If the device accesses `0(a0)` upon receiving
+the MMIO write, then that load must conceptually appear after the first
+store to `0(a0)` according to the rules of the RVWMO memory model. In
+some implementations, the only way to ensure this will be to require
+that the first store does in fact complete before the MMIO write is
+issued. Other implementations may find ways to be more aggressive, while
+others still may not need to do anything different at all for I/O and
+main memory accesses. Nevertheless, the RVWMO memory model does not
+distinguish between these options; it simply provides an
+implementation-agnostic mechanism to specify the orderings that must be
+enforced.
+
+Many architectures include separate notions of "ordering" and
+`completion" fences, especially as it relates to I/O (as opposed to
+regular main memory). Ordering fences simply ensure that memory
+operations stay in order, while completion fences ensure that
+predecessor accesses have all completed before any successors are made
+visible. RISC-V does not explicitly distinguish between ordering and
+completion fences. Instead, this distinction is simply inferred from
+different uses of the FENCE bits.
+
+For implementations that conform to the RISC-V Unix Platform
+Specification, I/O devices and DMA operations are required to access
+memory coherently and via strongly ordered I/O channels. Therefore,
+accesses to regular main memory regions that are concurrently accessed
+by external devices can also use the standard synchronization
+mechanisms. Implementations that do not conform to the Unix Platform
+Specification and/or in which devices do not access memory coherently
+will need to use mechanisms (which are currently platform-specific or
+device-specific) to enforce coherency.
+
+I/O regions in the address space should be considered non-cacheable
+regions in the PMAs for those regions. Such regions can be considered
+coherent by the PMA if they are not cached by any agent.
+
+The ordering guarantees in this section may not apply beyond a
+platform-specific boundary between the RISC-V cores and the device. In
+particular, I/O accesses sent across an external bus (e.g., PCIe) may be
+reordered before they reach their ultimate destination. Ordering must be
+enforced in such situations according to the platform-specific rules of
+those external devices and buses.
+
+[[memory_porting]]
+=== Code Porting and Mapping Guidelines
+
+[[tsomappings]]
+.Mappings from TSO operations to RISC-V operations
+[%autowidth,float="center", align="center",cols="<,<",options="header",separator=!]
+|===
+!x86/TSO Operation !RVWMO Mapping
+!Load ! `l{b|h|w|d}; fence r,rw`
+!Store !`fence rw,w; s{b|h|w|d}`
+!Atomic RMW !`amo<op>.{w|d}.aqrl OR` +
+`loop:lr.{w|d}.aq; <op>; sc.{w|d}.aqrl; bnez loop`
+!Fence !`fence rw,rw`
+|===
+
+<<tsomappings>> provides a mapping from TSO memory
+operations onto RISC-V memory instructions. Normal x86 loads and stores
+are all inherently acquire-RCpc and release-RCpc operations: TSO
+enforces all load-load, load-store, and store-store ordering by default.
+Therefore, under RVWMO, all TSO loads must be mapped onto a load
+followed by FENCE R,RW, and all TSO stores must be mapped onto
+FENCE RW,W followed by a store. TSO atomic read-modify-writes and x86
+instructions using the LOCK prefix are fully ordered and can be
+implemented either via an AMO with both _aq_ and _rl_ set, or via an LR
+with _aq_ set, the arithmetic operation in question, an SC with both
+_aq_ and _rl_ set, and a conditional branch checking the success
+condition. In the latter case, the _rl_ annotation on the LR turns out
+(for non-obvious reasons) to be redundant and can be omitted.
+
+Alternatives to <<tsomappings>> are also possible. A TSO
+store can be mapped onto AMOSWAP with _rl_ set. However, since RVWMO PPO
+Rule <<overlapping-ordering, 3>> forbids forwarding of values from
+AMOs to subsequent loads, the use of AMOSWAP for stores may negatively
+affect performance. A TSO load can be mapped using LR with _aq_ set: all
+such LR instructions will be unpaired, but that fact in and of itself
+does not preclude the use of LR for loads. However, again, this mapping
+may also negatively affect performance if it puts more pressure on the
+reservation mechanism than was originally intended.
+
+[[powermappings]]
+.Mappings from Power operations to RISC-V operations
+[%autowidth,float="center",align="center",cols="<,<",options="header",separator=!]
+|===
+!Power Operation !RVWMO Mapping
+!Load !`l{b|h|w|d}`
+!Load-Reserve !`lr.{w|d}`
+!Store !`s{b|h|w|d}`
+!Store-Conditional !`sc.{w|d}`
+!`lwsync` !`fence.tso`
+!`sync` !`fence rw,rw`
+!`isync` !`fence.i; fence r,r`
+|===
+
+<<powermappings>> provides a mapping from Power memory
+operations onto RISC-V memory instructions. Power ISYNC maps on RISC-V
+to a FENCE.I followed by a FENCE R,R; the latter fence is needed because
+ISYNC is used to define a "control+control fence" dependency that is
+not present in RVWMO.
+
+[[armmappings]]
+.Mappings from ARM operations to RISC-V operations
+[%autowidth,float="center",align="center",cols="<,<",options="header",separator=!]
+|===
+!ARM Operation !RVWMO Mapping
+!Load !`l{b|h|w|d}`
+!Load-Acquire !`fence rw, rw; l{b|h|w|d}; fence r,rw`
+!Load-Exclusive !`lr.{w|d}`
+!Load-Acquire-Exclusive !`lr.{w|d}.aqrl`
+!Store !`s{b|h|w|d}`
+!Store-Release !`fence rw,w; s{b|h|w|d}`
+!Store-Exclusive !`sc.{w|d}`
+!Store-Release-Exclusive !`sc.{w|d}.rl`
+!`dmb` !`fence rw,rw`
+!`dmb.ld` !`fence r,rw`
+!`dmb.st` !`fence w,w`
+!`isb` !`fence.i; fence r,r`
+|===
+
+<<armmappings>> provides a mapping from ARM memory
+operations onto RISC-V memory instructions. Since RISC-V does not
+currently have plain load and store opcodes with _aq_ or _rl_
+annotations, ARM load-acquire and store-release operations should be
+mapped using fences instead. Furthermore, in order to enforce
+store-release-to-load-acquire ordering, there must be a FENCE RW,RW
+between the store-release and load-acquire; <<armmappings>>
+enforces this by always placing the fence in front of each acquire
+operation. ARM load-exclusive and store-exclusive instructions can
+likewise map onto their RISC-V LR and SC equivalents, but instead of
+placing a FENCE RW,RW in front of an LR with _aq_ set, we simply also
+set _rl_ instead. ARM ISB maps on RISC-V to FENCE.I followed by
+FENCE R,R similarly to how ISYNC maps for Power.
+
+[[linuxmappings]]
+.Mappings from Linux memory primitives to RISC-V primitives.
+[%autowidth,float="center",align="center",cols="<,<",options="header",separator=!]
+|===
+!Linux Operation !RVWMO Mapping
+
+!`smp_mb()` !`fence rw,rw`
+
+!`smp_rmb()` !`fence r,r`
+
+!`smp_wmb()` !`fence w,w`
+
+!`dma_rmb()` !`fence r,r`
+
+!`dma_wmb()` !`fence w,w`
+
+!`mb()` !`fence iorw,iorw`
+
+!`rmb()` !`fence ri,ri`
+
+!`wmb()` !`fence wo,wo`
+
+!`smp_load_acquire()` !`l{b|h|w|d}; fence r,rw`
+
+!`smp_store_release()` !`fence.tso; s{b|h|w|d}`
+
+!Linux Construct !RVWMO AMO Mapping
+
+!`atomic &#60;op&#62; relaxed` !`amo &#60;op&#62;.{w|d}`
+
+!`atomic &#60;op&#62; acquire` !`amo &#60;op&#62;.{w|d}.aq`
+
+!`atomic &#60;op&#62; release` !`amo &#60;op&#62;.{w|d}.rl`
+
+!`atomic &#60;op&#62;` !`amo &#60;op&#62;.{w|d}.aqrl`
+
+!Linux Construct !RVWMO LR/SC Mapping
+
+!`atomic &#60;op&#62; relaxed` !`loop:lr.{w|d}; &#60;op&#62;; sc.{w|d}; bnez loop`
+
+!`atomic &#60;op&#62; acquire` !`loop:lr.{w|d}.aq; &#60;op&#62;; sc.{w|d}; bnez loop`
+
+!`atomic &#60;op&#62; release` !`loop:lr.{w|d}; &#60;op&#62;; sc.{w|d}.aqrl^&#42;; bnez loop OR`
+
+! !`fence.tso; loop:lr.{w|d}; &#60;op &#62;; sc.{w|d}^&#42;; bnez loop`
+
+!`atomic &#60;op&#62;` !`loop:lr.{w|d}.aq;` `&#60;op&#62;; sc.{w|d}.aqrl; bnez loop`
+
+|===
+
+With regards to <<linuxmappings>>, other
+constructs (such as spinlocks) should follow accordingly. Platforms or
+devices with non-coherent DMA may need additional synchronization (such
+as cache flush or invalidate mechanisms); currently any such extra
+synchronization will be device-specific.
+
+<<linuxmappings>> provides a mapping of Linux memory
+ordering macros onto RISC-V memory instructions. The Linux fences
+`dma_rmb()` and `dma_wmb()` map onto FENCE R,R and FENCE W,W,
+respectively, since the RISC-V Unix Platform requires coherent DMA, but
+would be mapped onto FENCE RI,RI and FENCE WO,WO, respectively, on a
+platform with non-coherent DMA. Platforms with non-coherent DMA may also
+require a mechanism by which cache lines can be flushed and/or
+invalidated. Such mechanisms will be device-specific and/or standardized
+in a future extension to the ISA.
+
+The Linux mappings for release operations may seem stronger than
+necessary, but these mappings are needed to cover some cases in which
+Linux requires stronger orderings than the more intuitive mappings would
+provide. In particular, as of the time this text is being written, Linux
+is actively debating whether to require load-load, load-store, and
+store-store orderings between accesses in one critical section and
+accesses in a subsequent critical section in the same hart and protected
+by the same synchronization object. Not all combinations of
+FENCE RW,W/FENCE R,RW mappings with _aq_/_rl_ mappings combine to
+provide such orderings. There are a few ways around this problem,
+including:
+
+. Always use FENCE RW,W/FENCE R,RW, and never use _aq_/_rl_. This
+suffices but is undesirable, as it defeats the purpose of the _aq_/_rl_
+modifiers.
+. Always use _aq_/_rl_, and never use FENCE RW,W/FENCE R,RW. This does
+not currently work due to the lack of load and store opcodes with _aq_
+and _rl_ modifiers.
+. Strengthen the mappings of release operations such that they would
+enforce sufficient orderings in the presence of either type of acquire
+mapping. This is the currently recommended solution, and the one shown
+in <<linuxmappings>>.
+
+RVWMO Mapping: (a) lw a0, 0(s0) (b) fence.tso // vs. fence rw,w (c) sd
+x0,0(s1) ... loop: (d) amoswap.d.aq a1,t1,0(s1) bnez a1,loop (e) lw
+a2,0(s2)
+
+For example, the critical section ordering rule currently being debated
+by the Linux community would require (a) to be ordered before (e) in
+<<lkmm_ll>>. If that will indeed be
+required, then it would be insufficient for (b) to map as FENCE RW,W.
+That said, these mappings are subject to change as the Linux Kernel
+Memory Model evolves.
+
+[[lkmm_ll]]
+.Orderings between critical sections in Linux
+[source%linenums,asm]
+----
+Linux Code:
+(a) int r0 = *x;
+ (bc) spin_unlock(y, 0);
+....
+....
+(d) spin_lock(y);
+(e) int r1 = *z;
+
+RVWMO Mapping:
+(a) lw a0, 0(s0)
+(b) fence.tso // vs. fence rw,w
+(c) sd x0,0(s1)
+....
+loop:
+(d) lr.d.aq a1,(s1)
+bnez a1,loop
+sc.d a1,t1,(s1)
+bnez a1,loop
+(e) lw a2,0(s2)
+----
+
+<<c11mappings>> provides a mapping of C11/C++11 atomic
+operations onto RISC-V memory instructions. If load and store opcodes
+with _aq_ and _rl_ modifiers are introduced, then the mappings in
+<<c11mappings_hypothetical>> will suffice. Note however that
+the two mappings only interoperate correctly if
+`atomic_<op>(memory_order_seq_cst)` is mapped using an LR that has both
+_aq_ and _rl_ set.
+Even more importantly, a <<c11mappings>> sequentially consistent store,
+followed by a <<c11mappings_hypothetical>> sequentially consistent load
+can be reordered unless the <<c11mappings>> mapping of stores is
+strengthened by either adding a second fence or mapping the store
+to `amoswap.rl` instead.
+
+[[c11mappings]]
+.Mappings from C/C++ primitives to RISC-V primitives.
+[%autowidth,float="center",align="center",cols="<,<",options="header",separator=!]
+|===
+
+!C/C++ Construct ! RVWMO Mapping
+
+!Non-atomic load ! `l{b|h|w|d}`
+
+!`atomic_load(memory_order_relaxed)` !`l{b|h|w|d}`
+
+!`atomic_load(memory_order_acquire)` !`l{b|h|w|d}; fence r,rw`
+
+!`atomic_load(memory_order_seq_cst)` !`fence rw,rw; l{b|h|w|d}; fence r,rw`
+
+!Non-atomic store !`s{b|h|w|d}`
+
+!`atomic_store(memory_order_relaxed)` !`s{b|h|w|d}`
+
+!`atomic_store(memory_order_release)` !`fence rw,w; s{b|h|w|d}`
+
+!`atomic_store(memory_order_seq_cst)` !`fence rw,w; s{b|h|w|d}`
+
+!`atomic_thread_fence(memory_order_acquire)` !`fence r,rw`
+
+!`atomic_thread_fence(memory_order_release)` !`fence rw,w`
+
+!`atomic_thread_fence(memory_order_acq_rel)` !`fence.tso`
+
+!`atomic_thread_fence(memory_order_seq_cst)` !`fence rw,rw`
+
+!C/C++ Construct !RVWMO AMO Mapping
+
+!`atomic_<op>(memory_order_relaxed)` !`amo<op>.{w|d}`
+
+!`atomic_<op>(memory_order_acquire)` !`amo<op>.{w|d}.aq`
+
+!`atomic_<op>(memory_order_release)` !`amo<op>.{w|d}.rl`
+
+!`atomic_<op>(memory_order_acq_rel)` !`amo<op>.{w|d}.aqrl`
+
+!`atomic_<op>(memory_order_seq_cst)` !`amo<op>.{w|d}.aqrl`
+
+!C/C++ Construct !RVWMO LR/SC Mapping
+
+!`atomic_<op>(memory_order_relaxed)` !`loop:lr.{w|d}; <op>; sc.{w|d};`
+
+! !`bnez loop`
+
+!`atomic_<op>(memory_order_acquire)` !`loop:lr.{w|d}.aq; <op>; sc.{w|d};`
+
+! !`bnez loop`
+
+!`atomic_<op>(memory_order_release)` !`loop:lr.{w|d}; <op>; sc.{w|d}.rl;`
+
+! !`bnez loop`
+
+!`atomic_<op>(memory_order_acq_rel)` !`loop:lr.{w|d}.aq; <op>; sc.{w|d}.rl;`
+
+! !`bnez loop`
+
+!`atomic_<op>(memory_order_seq_cst)` !`loop:lr.{w|d}.aqrl; <op>;`
+
+! !`sc.{w|d}.rl; bnez loop`
+
+|===
+
+[[c11mappings_hypothetical]]
+.Hypothetical mappings from C/C++ primitives to RISC-V primitives, if native load-acquire and store-release opcodes are introduced.
+[%autowidth,float="center",align="center",cols="<,<",options="header",separator=!]
+|===
+!C/C++ Construct !RVWMO Mapping
+
+!Non-atomic load !`l{b|h|w|d}`
+
+!`atomic_load(memory_order_relaxed)` !`l{b|h|w|d}`
+
+!`atomic_load(memory_order_acquire)` !`l{b|h|w|d}.aq`
+
+!`atomic_load(memory_order_seq_cst)` !`l{b|h|w|d}.aq`
+
+!Non-atomic store !`s{b|h|w|d}`
+
+!`atomic_store(memory_order_relaxed)` !`s{b|h|w|d}`
+
+!`atomic_store(memory_order_release)` !`s{b|h|w|d}.rl`
+
+!`atomic_store(memory_order_seq_cst)` !`s{b|h|w|d}.rl`
+
+!`atomic_thread_fence(memory_order_acquire)` !`fence r,rw`
+
+!`atomic_thread_fence(memory_order_release)` !`fence rw,w`
+
+!`atomic_thread_fence(memory_order_acq_rel)` !`fence.tso`
+
+!`atomic_thread_fence(memory_order_seq_cst)` !`fence rw,rw`
+
+!C/C++ Construct !RVWMO AMO Mapping
+
+!`atomic_<op>(memory_order_relaxed)` !`amo<op>.{w|d}`
+
+!`atomic_<op>(memory_order_acquire)` !`amo<op>.{w|d}.aq`
+
+!`atomic_<op>(memory_order_release)` !`amo<op>.{w|d}.rl`
+
+!`atomic_<op>(memory_order_acq_rel)` !`amo<op>.{w|d}.aqrl`
+
+!`atomic_<op>(memory_order_seq_cst)` !`amo<op>.{w|d}.aqrl`
+
+!C/C++ Construct !RVWMO LR/SC Mapping
+
+!`atomic_<op>(memory_order_relaxed)` !`lr.{w|d}; <op>; sc.{w|d}`
+
+!`atomic_<op>(memory_order_acquire)` !`lr.{w|d}.aq; <op>; sc.{w|d}`
+
+!`atomic_<op>(memory_order_release)` !`lr.{w|d}; <op>; sc.{w|d}.rl`
+
+!`atomic_<op>(memory_order_acq_rel)` !`lr.{w|d}.aq; <op>; sc.{w|d}.rl`
+
+!`atomic_<op>(memory_order_seq_cst)` !`lr.{w|d}.aq* <op>; sc.{w|d}.rl`
+
+2+!`*` must be `lr.{w|d}.aqrl` in order to interoperate with code mapped per <<c11mappings>>
+|===
+
+Any AMO can be emulated by an LR/SC pair, but care must be taken to
+ensure that any PPO orderings that originate from the LR are also made
+to originate from the SC, and that any PPO orderings that terminate at
+the SC are also made to terminate at the LR. For example, the LR must
+also be made to respect any data dependencies that the AMO has, given
+that load operations do not otherwise have any notion of a data
+dependency. Likewise, the effect a FENCE R,R elsewhere in the same hart
+must also be made to apply to the SC, which would not otherwise respect
+that fence. The emulator may achieve this effect by simply mapping AMOs
+onto `lr.aq; <op>; sc.aqrl`, matching the mapping used elsewhere for
+fully ordered atomics.
+
+These C11/C++11 mappings require the platform to provide the following
+Physical Memory Attributes (as defined in the RISC-V Privileged ISA) for
+all memory:
+
+* main memory
+* coherent
+* AMOArithmetic
+* RsrvEventual
+
+Platforms with different attributes may require different mappings, or
+require platform-specific SW (e.g., memory-mapped I/O).
+
+=== Implementation Guidelines
+
+The RVWMO and RVTSO memory models by no means preclude
+microarchitectures from employing sophisticated speculation techniques
+or other forms of optimization in order to deliver higher performance.
+The models also do not impose any requirement to use any one particular
+cache hierarchy, nor even to use a cache coherence protocol at all.
+Instead, these models only specify the behaviors that can be exposed to
+software. Microarchitectures are free to use any pipeline design, any
+coherent or non-coherent cache hierarchy, any on-chip interconnect,
+etc., as long as the design only admits executions that satisfy the
+memory model rules. That said, to help people understand the actual
+implementations of the memory model, in this section we provide some
+guidelines on how architects and programmers should interpret the
+models' rules.
+
+Both RVWMO and RVTSO are multi-copy atomic (or
+_other-multi-copy-atomic_): any store value that is visible to a hart
+other than the one that originally issued it must also be conceptually
+visible to all other harts in the system. In other words, harts may
+forward from their own previous stores before those stores have become
+globally visible to all harts, but no early inter-hart forwarding is
+permitted. Multi-copy atomicity may be enforced in a number of ways. It
+might hold inherently due to the physical design of the caches and store
+buffers, it may be enforced via a single-writer/multiple-reader cache
+coherence protocol, or it might hold due to some other mechanism.
+
+Although multi-copy atomicity does impose some restrictions on the
+microarchitecture, it is one of the key properties keeping the memory
+model from becoming extremely complicated. For example, a hart may not
+legally forward a value from a neighbor hart's private store buffer
+(unless of course it is done in such a way that no new illegal behaviors
+become architecturally visible). Nor may a cache coherence protocol
+forward a value from one hart to another until the coherence protocol
+has invalidated all older copies from other caches. Of course,
+microarchitectures may (and high-performance implementations likely
+will) violate these rules under the covers through speculation or other
+optimizations, as long as any non-compliant behaviors are not exposed to
+the programmer.
+
+As a rough guideline for interpreting the PPO rules in RVWMO, we expect
+the following from the software perspective:
+
+* programmers will use PPO rules <<overlapping-ordering, 1>> and <<overlapping-ordering, 4-8>> regularly and actively.
+* expert programmers will use PPO rules <<overlapping-ordering, 9-11>> to speed up critical paths
+of important data structures.
+* even expert programmers will rarely if ever use PPO rules <<overlapping-ordering, 2-3>> and
+<<overlapping-ordering, 12-13>> directly.
+These are included to facilitate common microarchitectural optimizations
+(rule <<overlapping-ordering, 2>>) and the operational formal modeling approach (rules <<overlapping-ordering, 3>> and
+<<overlapping-ordering, 12-13>>) described
+in <<operational>>. They also facilitate the
+process of porting code from other architectures that have similar
+rules.
+
+We also expect the following from the hardware perspective:
+
+* PPO rules <<overlapping-ordering, 1>> and <<overlapping-ordering, 3-6>> reflect
+well-understood rules that should pose few surprises to architects.
+* PPO rule <<overlapping-ordering, 2>> reflects a natural and common hardware
+optimization, but one that is very subtle and hence is worth double
+checking carefully.
+* PPO rule <<overlapping-ordering, 7>> may not be immediately obvious to
+architects, but it is a standard memory model requirement
+* The load value axiom, the atomicity axiom, and PPO rules
+<<overlapping-ordering, 8-13>> reflect rules that most
+hardware implementations will enforce naturally, unless they contain
+extreme optimizations. Of course, implementations should make sure to
+double check these rules nevertheless. Hardware must also ensure that
+syntactic dependencies are not `optimized away`.
+
+Architectures are free to implement any of the memory model rules as
+conservatively as they choose. For example, a hardware implementation
+may choose to do any or all of the following:
+
+* interpret all fences as if they were FENCE RW,RW (or FENCE IORW,IORW,
+if I/O is involved), regardless of the bits actually set
+* implement all fences with PW and SR as if they were FENCE RW,RW (or
+FENCE IORW,IORW, if I/O is involved), as PW with SR is the most
+expensive of the four possible main memory ordering components anyway
+* emulate _aq_ and _rl_ as described in <<memory_porting>>
+* enforcing all same-address load-load ordering, even in the presence of
+patterns such as `fri-rfi` and `RSW`
+* forbid any forwarding of a value from a store in the store buffer to a
+subsequent AMO or LR to the same address
+* forbid any forwarding of a value from an AMO or SC in the store buffer
+to a subsequent load to the same address
+* implement TSO on all memory accesses, and ignore any main memory
+fences that do not include PW and SR ordering (e.g., as Ztso
+implementations will do)
+* implement all atomics to be RCsc or even fully ordered, regardless of
+annotation
+
+Architectures that implement RVTSO can safely do the following:
+
+* Ignore all fences that do not have both PW and SR (unless the fence
+also orders I/O)
+* Ignore all PPO rules except for rules <<overlapping-ordering, 4>> through <<overlapping-ordering, 7>>, since the rest
+are redundant with other PPO rules under RVTSO assumptions
+
+Other general notes:
+
+* Silent stores (i.e., stores that write the same value that already
+exists at a memory location) behave like any other store from a memory
+model point of view. Likewise, AMOs which do not actually change the
+value in memory (e.g., an AMOMAX for which the value in _rs2_ is smaller
+than the value currently in memory) are still semantically considered
+store operations. Microarchitectures that attempt to implement silent
+stores must take care to ensure that the memory model is still obeyed,
+particularly in cases such as RSW <<mm-overlap>>
+which tend to be incompatible with silent stores.
+* Writes may be merged (i.e., two consecutive writes to the same address
+may be merged) or subsumed (i.e., the earlier of two back-to-back writes
+to the same address may be elided) as long as the resulting behavior
+does not otherwise violate the memory model semantics.
+
+The question of write subsumption can be understood from the following
+example:
+
+.Write subsumption litmus test, allowed execution
+[float="center",align="center",cols=".^1a,.^1a",frame="none",grid="none",options="noheader"]
+|===
+|
+[%autowidth,float="center",align="center",cols="^,<,^,<",options="header",]
+!===
+2+!Hart 0 2+^!Hart 1
+2+!li t1, 3 2+^!li t3, 2
+! !li t2, 1 ! !
+!(a) !sw t1,0(s0) !(d) !lw a0,0(s1)
+!(b) !fence w, w !(e) !sw a0,0(s0)
+!(c) !sw t2,0(s1) !(f) !sw t3,0(s0)
+!===
+|
+!===
+//a! graphviz::images/graphviz/litmus_subsumption.txt[]
+a! image::graphviz/litmus_subsumption.png[]
+!===
+|===
+
+As written, if the load (d) reads value _1_, then (a) must
+precede (f) in the global memory order:
+
+* (a) precedes (c) in the global memory order because of rule 4
+* (c) precedes (d) in the global memory order because of the Load
+Value axiom
+* (d) precedes (e) in the global memory order because of rule 10
+* (e) precedes (f) in the global memory order because of rule 1
+
+In other words the final value of the memory location whose address is
+in `s0` must be _2_ (the value written by the store (f)) and
+cannot be _3_ (the value written by the store (a)).
+
+A very aggressive microarchitecture might erroneously decide to discard
+(e), as (f) supersedes it, and this may in turn lead the
+microarchitecture to break the now-eliminated dependency between (d) and
+(f) (and hence also between (a) and (f)). This would violate the memory
+model rules, and hence it is forbidden. Write subsumption may in other
+cases be legal, if for example there were no data dependency between (d)
+and (e).
+
+==== Possible Future Extensions
+
+We expect that any or all of the following possible future extensions
+would be compatible with the RVWMO memory model:
+
+* "V" vector ISA extensions
+* "J" JIT extension
+* Native encodings for load and store opcodes with _aq_ and _rl_ set
+* Fences limited to certain addresses
+* Cache write-back/flush/invalidate/etc.instructions
+
+[[discrepancies]]
+=== Known Issues
+
+[[mixedrsw]]
+==== Mixed-size RSW
+
+[[rsw1]]
+.Mixed-size discrepancy (permitted by axiomatic models, forbidden by operational model)
+[%autowidth,float="center",align="center",cols="^,<,^,<",options="header",]
+|===
+2+|Hart 0 2+^|Hart 1
+2+|li t1, 1 2+^|li t1, 1
+|(a) |lw a0,0(s0) |(d) |lw a1,0(s1)
+|(b) |fence rw,rw |(e) |amoswap.w.rl a2,t1,0(s2)
+|(c) |sw t1,0(s1) |(f) |ld a3,0(s2)
+| | |(g) |lw a4,4(s2)
+| | | |xor a5,a4,a4
+| | | |add s0,s0,a5
+| | |(h) |sw t1,0(s0)
+4+|Outcome: `a0=1`, `a1=1`, `a2=0`, `a3=1`, `a4=0`
+|===
+
+[[rsw2]]
+.Mixed-size discrepancy (permitted by axiomatic models, forbidden by operational model)
+[%autowidth,float="center",align="center",cols="^,<,^,<",options="header"]
+|===
+2+|Hart 0 2+^|Hart 1
+2+|li t1, 1 2+^|li t1, 1
+|(a) |lw a0,0(s0) |(d) |ld a1,0(s1)
+|(b) |fence rw,rw |(e) |lw a2,4(s1)
+|(c) |sw t1,0(s1) | |xor a3,a2,a2
+| | | |add s0,s0,a3
+| | |(f) |sw t1,0(s0)
+4+|Outcome: `a0=1`, `a1=1`, `a2=0`
+|===
+
+[[rsw3]]
+.Mixed-size discrepancy (permitted by axiomatic models, forbidden by operational model)
+[%autowidth,float="center",align="center",cols="^,<,^,<",options="header",]
+|===
+2+|Hart 0 2+^|Hart 1
+2+|li t1, 1 2+^|li t1, 1
+|(a) |lw a0,0(s0) |(d) |sw t1,4(s1)
+|(b) |fence rw,rw |(e) |ld a1,0(s1)
+|(c) |sw t1,0(s1) |(f) |lw a2,4(s1)
+| | | |xor a3,a2,a2
+| | | |add s0,s0,a3
+| | |(g) |sw t1,0(s0)
+4+|Outcome: `a0=1`, `a1=0x100000001`, `a2=1`
+|===
+
+There is a known discrepancy between the operational and axiomatic
+specifications within the family of mixed-size RSW variants shown in
+<<rsw1>>-<<rsw3>>.
+To address this, we may choose to add something like the following new
+PPO rule: Memory operation _a_ precedes memory operation
+_b_ in preserved program order (and hence also in the global
+memory order) if _a_ precedes _b_ in program
+order, _a_ and _b_ both access regular main
+memory (rather than I/O regions), _a_ is a load,
+_b_ is a store, there is a load _m_ between
+_a_ and _b_, there is a byte _x_
+that both _a_ and _m_ read, there is no store
+between _a_ and _m_ that writes to
+_x_, and _m_ precedes _b_ in PPO. In
+other words, in herd syntax, we may choose to add
+`(po-loc & rsw);ppo;[W]` to PPO. Many implementations will already
+enforce this ordering naturally. As such, even though this rule is not
+official, we recommend that implementers enforce it nevertheless in
+order to ensure forwards compatibility with the possible future addition
+of this rule to RVWMO.
diff --git a/src/mm-formal.adoc b/src/mm-formal.adoc
new file mode 100644
index 0000000..39c36fe
--- /dev/null
+++ b/src/mm-formal.adoc
@@ -0,0 +1,1425 @@
+[appendix]
+== Formal Memory Model Specifications, Version 0.1
+[[mm-formal]]
+
+To facilitate formal analysis of RVWMO, this chapter presents a set of
+formalizations using different tools and modeling approaches. Any
+discrepancies are unintended; the expectation is that the models
+describe exactly the same sets of legal behaviors.
+
+This appendix should be treated as commentary; all normative material is
+provided in <<memorymodel>> and in the rest of
+the main body of the ISA specification.
+All currently known discrepancies are listed in <<discrepancies>>.
+Any other discrepancies are unintentional.
+
+[[alloy]]
+=== Formal Axiomatic Specification in Alloy
+
+We present a formal specification of the RVWMO memory model in Alloy
+(http://alloy.mit.edu). This model is available online at
+https://github.com/daniellustig/riscv-memory-model.
+
+The online material also contains some litmus tests and some examples of
+how Alloy can be used to model check some of the mappings in <<memory_porting>>.
+
+.The RVWMO memory model formalized in Alloy (1/5: PPO)
+[source,c]
+----
+// =RVWMO PPO=
+
+// Preserved Program Order
+fun ppo : Event->Event {
+ // same-address ordering
+ po_loc :> Store
+ + rdw
+ + (AMO + StoreConditional) <: rfi
+
+ // explicit synchronization
+ + ppo_fence
+ + Acquire <: ^po :> MemoryEvent
+ + MemoryEvent <: ^po :> Release
+ + RCsc <: ^po :> RCsc
+ + pair
+
+ // syntactic dependencies
+ + addrdep
+ + datadep
+ + ctrldep :> Store
+
+ // pipeline dependencies
+ + (addrdep+datadep).rfi
+ + addrdep.^po :> Store
+}
+
+// the global memory order respects preserved program order
+fact { ppo in ^gmo }
+----
+
+.The RVWMO memory model formalized in Alloy (2/5: Axioms)
+[,io]
+....
+// =RVWMO axioms=
+
+// Load Value Axiom
+fun candidates[r: MemoryEvent] : set MemoryEvent {
+ (r.~^gmo & Store & same_addr[r]) // writes preceding r in gmo
+ + (r.^~po & Store & same_addr[r]) // writes preceding r in po
+}
+
+fun latest_among[s: set Event] : Event { s - s.~^gmo }
+
+pred LoadValue {
+ all w: Store | all r: Load |
+ w->r in rf <=> w = latest_among[candidates[r]]
+}
+
+// Atomicity Axiom
+pred Atomicity {
+ all r: Store.~pair | // starting from the lr,
+ no x: Store & same_addr[r] | // there is no store x to the same addr
+ x not in same_hart[r] // such that x is from a different hart,
+ and x in r.~rf.^gmo // x follows (the store r reads from) in gmo,
+ and r.pair in x.^gmo // and r follows x in gmo
+}
+
+// Progress Axiom implicit: Alloy only considers finite executions
+
+pred RISCV_mm { LoadValue and Atomicity /* and Progress */ }
+....
+
+
+.The RVWMO memory model formalized in Alloy (3/5: model of memory)
+[source,sml]
+....
+//Basic model of memory
+
+sig Hart { // hardware thread
+ start : one Event
+}
+sig Address {}
+abstract sig Event {
+ po: lone Event // program order
+}
+
+abstract sig MemoryEvent extends Event {
+ address: one Address,
+ acquireRCpc: lone MemoryEvent,
+ acquireRCsc: lone MemoryEvent,
+ releaseRCpc: lone MemoryEvent,
+ releaseRCsc: lone MemoryEvent,
+ addrdep: set MemoryEvent,
+ ctrldep: set Event,
+ datadep: set MemoryEvent,
+ gmo: set MemoryEvent, // global memory order
+ rf: set MemoryEvent
+}
+sig LoadNormal extends MemoryEvent {} // l{b|h|w|d}
+sig LoadReserve extends MemoryEvent { // lr
+ pair: lone StoreConditional
+}
+sig StoreNormal extends MemoryEvent {} // s{b|h|w|d}
+// all StoreConditionals in the model are assumed to be successful
+sig StoreConditional extends MemoryEvent {} // sc
+sig AMO extends MemoryEvent {} // amo
+sig NOP extends Event {}
+
+fun Load : Event { LoadNormal + LoadReserve + AMO }
+fun Store : Event { StoreNormal + StoreConditional + AMO }
+
+sig Fence extends Event {
+ pr: lone Fence, // opcode bit
+ pw: lone Fence, // opcode bit
+ sr: lone Fence, // opcode bit
+ sw: lone Fence // opcode bit
+}
+sig FenceTSO extends Fence {}
+
+/* Alloy encoding detail: opcode bits are either set (encoded, e.g.,
+ * as f.pr in iden) or unset (f.pr not in iden). The bits cannot be used for
+ * anything else */
+fact { pr + pw + sr + sw in iden }
+// likewise for ordering annotations
+fact { acquireRCpc + acquireRCsc + releaseRCpc + releaseRCsc in iden }
+// don't try to encode FenceTSO via pr/pw/sr/sw; just use it as-is
+fact { no FenceTSO.(pr + pw + sr + sw) }
+....
+
+.The RVWMO memory model formalized in Alloy (4/5: Basic model rules)
+[source,scala]
+....
+// =Basic model rules=
+
+// Ordering annotation groups
+fun Acquire : MemoryEvent { MemoryEvent.acquireRCpc + MemoryEvent.acquireRCsc }
+fun Release : MemoryEvent { MemoryEvent.releaseRCpc + MemoryEvent.releaseRCsc }
+fun RCpc : MemoryEvent { MemoryEvent.acquireRCpc + MemoryEvent.releaseRCpc }
+fun RCsc : MemoryEvent { MemoryEvent.acquireRCsc + MemoryEvent.releaseRCsc }
+
+// There is no such thing as store-acquire or load-release, unless it's both
+fact { Load & Release in Acquire }
+fact { Store & Acquire in Release }
+
+// FENCE PPO
+fun FencePRSR : Fence { Fence.(pr & sr) }
+fun FencePRSW : Fence { Fence.(pr & sw) }
+fun FencePWSR : Fence { Fence.(pw & sr) }
+fun FencePWSW : Fence { Fence.(pw & sw) }
+
+fun ppo_fence : MemoryEvent->MemoryEvent {
+ (Load <: ^po :> FencePRSR).(^po :> Load)
+ + (Load <: ^po :> FencePRSW).(^po :> Store)
+ + (Store <: ^po :> FencePWSR).(^po :> Load)
+ + (Store <: ^po :> FencePWSW).(^po :> Store)
+ + (Load <: ^po :> FenceTSO) .(^po :> MemoryEvent)
+ + (Store <: ^po :> FenceTSO) .(^po :> Store)
+}
+
+// auxiliary definitions
+fun po_loc : Event->Event { ^po & address.~address }
+fun same_hart[e: Event] : set Event { e + e.^~po + e.^po }
+fun same_addr[e: Event] : set Event { e.address.~address }
+
+// initial stores
+fun NonInit : set Event { Hart.start.*po }
+fun Init : set Event { Event - NonInit }
+fact { Init in StoreNormal }
+fact { Init->(MemoryEvent & NonInit) in ^gmo }
+fact { all e: NonInit | one e.*~po.~start } // each event is in exactly one hart
+fact { all a: Address | one Init & a.~address } // one init store per address
+fact { no Init <: po and no po :> Init }
+....
+
+.The RVWMO memory model formalized in Alloy (5/5: Auxiliaries)
+[source,asm]
+....
+// po
+fact { acyclic[po] }
+
+// gmo
+fact { total[^gmo, MemoryEvent] } // gmo is a total order over all MemoryEvents
+
+//rf
+fact { rf.~rf in iden } // each read returns the value of only one write
+fact { rf in Store <: address.~address :> Load }
+fun rfi : MemoryEvent->MemoryEvent { rf & (*po + *~po) }
+
+//dep
+fact { no StoreNormal <: (addrdep + ctrldep + datadep) }
+fact { addrdep + ctrldep + datadep + pair in ^po }
+fact { datadep in datadep :> Store }
+fact { ctrldep.*po in ctrldep }
+fact { no pair & (^po :> (LoadReserve + StoreConditional)).^po }
+fact { StoreConditional in LoadReserve.pair } // assume all SCs succeed
+
+// rdw
+fun rdw : Event->Event {
+ (Load <: po_loc :> Load) // start with all same_address load-load pairs,
+ - (~rf.rf) // subtract pairs that read from the same store,
+ - (po_loc.rfi) // and subtract out "fri-rfi" patterns
+}
+
+// filter out redundant instances and/or visualizations
+fact { no gmo & gmo.gmo } // keep the visualization uncluttered
+fact { all a: Address | some a.~address }
+
+// =Optional: opcode encoding restrictions=
+
+// the list of blessed fences
+fact { Fence in
+ Fence.pr.sr
+ + Fence.pw.sw
+ + Fence.pr.pw.sw
+ + Fence.pr.sr.sw
+ + FenceTSO
+ + Fence.pr.pw.sr.sw
+}
+
+pred restrict_to_current_encodings {
+ no (LoadNormal + StoreNormal) & (Acquire + Release)
+}
+
+// =Alloy shortcuts=
+pred acyclic[rel: Event->Event] { no iden & ^rel }
+pred total[rel: Event->Event, bag: Event] {
+ all disj e, f: bag | e->f in rel + ~rel
+ acyclic[rel]
+}
+....
+
+[[sec:herd]]
+=== Formal Axiomatic Specification in Herd
+
+The tool [.sans-serif]#herd# takes a memory model and a litmus test as
+input and simulates the execution of the test on top of the memory
+model. Memory models are written in the domain specific language Cat.
+This section provides two Cat memory model of RVWMO. The first model,
+<<herd2>>, follows the _global memory order_,
+<<memorymodel>>, definition of RVWMO, as much
+as is possible for a Cat model. The second model,
+<<herd3>>, is an equivalent, more efficient,
+partial order based RVWMO model.
+
+The simulator `herd` is part of the `diy` tool
+suite — see http://diy.inria.fr for software and documentation. The
+models and more are available online at http://diy.inria.fr/cats7/riscv/.
+[[herd1]]
+.riscv-defs.cat, a herd definition of preserved program order (1/3)
+[source,asm]
+....
+(*************)
+(* Utilities *)
+(*************)
+
+(* All fence relations *)
+let fence.r.r = [R];fencerel(Fence.r.r);[R]
+let fence.r.w = [R];fencerel(Fence.r.w);[W]
+let fence.r.rw = [R];fencerel(Fence.r.rw);[M]
+let fence.w.r = [W];fencerel(Fence.w.r);[R]
+let fence.w.w = [W];fencerel(Fence.w.w);[W]
+let fence.w.rw = [W];fencerel(Fence.w.rw);[M]
+let fence.rw.r = [M];fencerel(Fence.rw.r);[R]
+let fence.rw.w = [M];fencerel(Fence.rw.w);[W]
+let fence.rw.rw = [M];fencerel(Fence.rw.rw);[M]
+let fence.tso =
+ let f = fencerel(Fence.tso) in
+ ([W];f;[W]) | ([R];f;[M])
+
+let fence =
+ fence.r.r | fence.r.w | fence.r.rw |
+ fence.w.r | fence.w.w | fence.w.rw |
+ fence.rw.r | fence.rw.w | fence.rw.rw |
+ fence.tso
+
+(* Same address, no W to the same address in-between *)
+let po-loc-no-w = po-loc \ (po-loc?;[W];po-loc)
+(* Read same write *)
+let rsw = rf^-1;rf
+(* Acquire, or stronger *)
+let AQ = Acq|AcqRel
+(* Release or stronger *)
+and RL = RelAcqRel
+(* All RCsc *)
+let RCsc = Acq|Rel|AcqRel
+(* Amo events are both R and W, relation rmw relates paired lr/sc *)
+let AMO = R & W
+let StCond = range(rmw)
+
+(*************)
+(* ppo rules *)
+(*************)
+
+(* Overlapping-Address Orderings *)
+let r1 = [M];po-loc;[W]
+and r2 = ([R];po-loc-no-w;[R]) \ rsw
+and r3 = [AMO|StCond];rfi;[R]
+(* Explicit Synchronization *)
+and r4 = fence
+and r5 = [AQ];po;[M]
+and r6 = [M];po;[RL]
+and r7 = [RCsc];po;[RCsc]
+and r8 = rmw
+(* Syntactic Dependencies *)
+and r9 = [M];addr;[M]
+and r10 = [M];data;[W]
+and r11 = [M];ctrl;[W]
+(* Pipeline Dependencies *)
+and r12 = [R];(addr|data);[W];rfi;[R]
+and r13 = [R];addr;[M];po;[W]
+
+let ppo = r1 | r2 | r3 | r4 | r5 | r6 | r7 | r8 | r9 | r10 | r11 | r12 | r13
+....
+[[herd2]]
+.riscv.cat, a herd version of the RVWMO memory model (2/3)
+[source,asm]
+....
+Total
+
+(* Notice that herd has defined its own rf relation *)
+
+(* Define ppo *)
+include "riscv-defs.cat"
+
+(********************************)
+(* Generate global memory order *)
+(********************************)
+
+let gmo0 = (* precursor: ie build gmo as an total order that include gmo0 *)
+ loc & (W\FW) * FW | # Final write after any write to the same location
+ ppo | # ppo compatible
+ rfe # includes herd external rf (optimization)
+
+(* Walk over all linear extensions of gmo0 *)
+with gmo from linearizations(M\IW,gmo0)
+
+(* Add initial writes upfront -- convenient for computing rfGMO *)
+let gmo = gmo | loc & IW * (M\IW)
+
+(**********)
+(* Axioms *)
+(**********)
+
+(* Compute rf according to the load value axiom, aka rfGMO *)
+let WR = loc & ([W];(gmo|po);[R])
+let rfGMO = WR \ (loc&([W];gmo);WR)
+
+(* Check equality of herd rf and of rfGMO *)
+empty (rf\rfGMO)|(rfGMO\rf) as RfCons
+
+(* Atomicity axiom *)
+let infloc = (gmo & loc)^-1
+let inflocext = infloc & ext
+let winside = (infloc;rmw;inflocext) & (infloc;rf;rmw;inflocext) & [W]
+empty winside as Atomic
+....
+[[herd3]]
+.`riscv.cat`, an alternative herd presentation of the RVWMO memory model (3/3)
+[source,asm]
+....
+Partial
+
+(***************)
+(* Definitions *)
+(***************)
+
+(* Define ppo *)
+include "riscv-defs.cat"
+
+(* Compute coherence relation *)
+include "cos-opt.cat"
+
+(**********)
+(* Axioms *)
+(**********)
+
+(* Sc per location *)
+acyclic co|rf|fr|po-loc as Coherence
+
+(* Main model axiom *)
+acyclic co|rfe|fr|ppo as Model
+
+(* Atomicity axiom *)
+empty rmw & (fre;coe) as Atomic
+....
+
+[[operational]]
+=== An Operational Memory Model
+
+This is an alternative presentation of the RVWMO memory model in
+operational style. It aims to admit exactly the same extensional
+behavior as the axiomatic presentation: for any given program, admitting
+an execution if and only if the axiomatic presentation allows it.
+
+The axiomatic presentation is defined as a predicate on complete
+candidate executions. In contrast, this operational presentation has an
+abstract microarchitectural flavor: it is expressed as a state machine,
+with states that are an abstract representation of hardware machine
+states, and with explicit out-of-order and speculative execution (but
+abstracting from more implementation-specific microarchitectural details
+such as register renaming, store buffers, cache hierarchies, cache
+protocols, etc.). As such, it can provide useful intuition. It can also
+construct executions incrementally, making it possible to interactively
+and randomly explore the behavior of larger examples, while the
+axiomatic model requires complete candidate executions over which the
+axioms can be checked.
+
+The operational presentation covers mixed-size execution, with
+potentially overlapping memory accesses of different power-of-two byte
+sizes. Misaligned accesses are broken up into single-byte accesses.
+
+The operational model, together with a fragment of the RISC-V ISA
+semantics (RV64I and A), are integrated into the `rmem` exploration tool
+(https://github.com/rems-project/rmem). `rmem` can explore litmus tests
+(see <<litmustests>>) and small ELF binaries
+exhaustively, pseudorandomly and interactively. In `rmem`, the ISA
+semantics is expressed explicitly in Sail (see
+https://github.com/rems-project/sail for the Sail language, and
+https://github.com/rems-project/sail-riscv for the RISC-V ISA model),
+and the concurrency semantics is expressed in Lem (see
+https://github.com/rems-project/lem for the Lem language).
+
+`rmem` has a command-line interface and a web-interface. The
+web-interface runs entirely on the client side, and is provided online
+together with a library of litmus tests:
+http://www.cl.cam.ac.uk/. The command-line interface is
+faster than the web-interface, specially in exhaustive mode.
+
+Below is an informal introduction of the model states and transitions.
+The description of the formal model starts in the next subsection.
+
+Terminology: In contrast to the axiomatic presentation, here every
+memory operation is either a load or a store. Hence, AMOs give rise to
+two distinct memory operations, a load and a store. When used in
+conjunction with `instruction`, the terms `load` and `store` refer
+to instructions that give rise to such memory operations. As such, both
+include AMO instructions. The term `acquire` refers to an instruction
+(or its memory operation) with the acquire-RCpc or acquire-RCsc
+annotation. The term `release` refers to an instruction (or its memory
+operation) with the release-RCpc or release-RCsc annotation.
+
+*Model states*
+
+Model states: A model state consists of a shared memory and a tuple of hart states.
+
+
+["ditaa",shadows=false, separation=false, fontsize: 14,float="center"]
+....
++----------+ +---------+
+| Hart 0 | ... | Trace |
++----------+ +---------+
+ ↑ ↓ ↑ ↓
++--------------------------+
+| Shared memory |
++--------------------------+
+....
+
+The shared memory state records all the memory store operations that
+have propagated so far, in the order they propagated (this can be made
+more efficient, but for simplicity of the presentation we keep it this
+way).
+
+Each hart state consists principally of a tree of instruction instances,
+some of which have been _finished_, and some of which have not.
+Non-finished instruction instances can be subject to _restart_, e.g. if
+they depend on an out-of-order or speculative load that turns out to be
+unsound.
+
+Conditional branch and indirect jump instructions may have multiple
+successors in the instruction tree. When such instruction is finished,
+any un-taken alternative paths are discarded.
+
+Each instruction instance in the instruction tree has a state that
+includes an execution state of the intra-instruction semantics (the ISA
+pseudocode for this instruction). The model uses a formalization of the
+intra-instruction semantics in Sail. One can think of the execution
+state of an instruction as a representation of the pseudocode control
+state, pseudocode call stack, and local variable values. An instruction
+instance state also includes information about the instance's memory and
+register footprints, its register reads and writes, its memory
+operations, whether it is finished, etc.
+
+*Model transitions*
+
+The model defines, for any model state, the set of allowed transitions,
+each of which is a single atomic step to a new abstract machine state.
+Execution of a single instruction will typically involve many
+transitions, and they may be interleaved in operational-model execution
+with transitions arising from other instructions. Each transition arises
+from a single instruction instance; it will change the state of that
+instance, and it may depend on or change the rest of its hart state and
+the shared memory state, but it does not depend on other hart states,
+and it will not change them. The transitions are introduced below and
+defined in <<transitions>>, with a precondition and
+a construction of the post-transition model state for each.
+
+Transitions for all instructions:
+
+* <<fetch, Fetch instruction>>: This transition represents a fetch and decode of a new instruction instance, as a program order successor of a previously fetched
+instruction instance (or the initial fetch address).
+
+The model assumes the instruction memory is fixed; it does not describe
+the behavior of self-modifying code. In particular, the <<fetch, Fetch instruction>> transition does
+not generate memory load operations, and the shared memory is not
+involved in the transition. Instead, the model depends on an external
+oracle that provides an opcode when given a memory location.
+
+[circle]
+* <<reg_write, Register write>>: This is a write of a register value.
+
+* <<reg_read, Register read>>: This is a read of a register value from the most recent
+program-order-predecessor instruction instance that writes to that
+register.
+
+* <<sail_interp, Pseudocode internal step>>: This covers pseudocode internal computation: arithmetic, function
+calls, etc.
+
+* <<finish, Finish instruction>>: At this point the instruction pseudocode is done, the instruction cannot be restarted, memory accesses cannot be discarded, and all memory
+effects have taken place. For conditional branch and indirect jump
+instructions, any program order successors that were fetched from an
+address that is not the one that was written to the _pc_ register are
+discarded, together with the sub-tree of instruction instances below
+them.
+
+Transitions specific to load instructions:
+
+[circle]
+* <<initiate_load, Initiate memory load operations>>: At this point the memory footprint of the load instruction is
+provisionally known (it could change if earlier instructions are
+restarted) and its individual memory load operations can start being
+satisfied.
+
+[disc]
+* <<sat_by_forwarding, Satisfy memory load operation by forwarding from unpropogated stores>>: This partially or entirely satisfies a single memory load operation by forwarding, from program-order-previous memory store operations.
+
+* <<sat_from_mem, Satisfy memory load operation from memory>>: This entirely satisfies the outstanding slices of a single memory
+load operation, from memory.
+
+[circle]
+* <<complete_loads, Complete load operations>>: At this point all the memory load operations of the instruction have
+been entirely satisfied and the instruction pseudocode can continue
+executing. A load instruction can be subject to being restarted until
+the transition. But, under some conditions, the model might treat a load
+instruction as non-restartable even before it is finished (e.g. see ).
+
+Transitions specific to store instructions:
+
+[circle]
+* <<initiate_store_footprint, Initiate memory store operation footprints>>: At this point the memory footprint of the store is provisionally
+known.
+
+* <<instantiate_store_value, Instantiate memory store operation values>>: At this point the memory store operations have their values and
+program-order-successor memory load operations can be satisfied by
+forwarding from them.
+
+* <<commit_stores, Commit store instruction>>: At this point the store operations are guaranteed to happen (the
+instruction can no longer be restarted or discarded), and they can start
+being propagated to memory.
+
+[disc]
+* <<prop_store, Propagate store operation>>: This propagates a single memory store operation to memory.
+
+[circle]
+* <<complete_stores, Complete store operations>>: At this point all the memory store operations of the instruction
+have been propagated to memory, and the instruction pseudocode can
+continue executing.
+
+Transitions specific to `sc` instructions:
+
+[disc]
+* <<early_sc_fail, Early sc fail>>: This causes the `sc` to fail, either a spontaneous fail or because it is not paired with a program-order-previous `lr`.
+
+* <<paired_sc, Paired sc>>: This transition indicates the `sc` is paired with an `lr` and might
+succeed.
+
+* <<commit_sc, Commit and propagate store operation of an sc>>: This is an atomic execution of the transitions <<commit_stores, Commit store instruction>> and <<prop_store, Propagate store operation>>, it is enabled
+only if the stores from which the `lr` read from have not been
+overwritten.
+
+* <<late_sc_fail, Late sc fail>>: This causes the `sc` to fail, either a spontaneous fail or because
+the stores from which the `lr` read from have been overwritten.
+
+Transitions specific to AMO instructions:
+
+[disc]
+* <<do_amo, Satisfy, commit and propagate operations of an AMO>>: This is an atomic execution of all the transitions needed to satisfy
+the load operation, do the required arithmetic, and propagate the store
+operation.
+
+Transitions specific to fence instructions:
+
+[circle]
+* <<commit_fence, Commit fence>>
+
+The transitions labeled {circ} can always be taken eagerly,
+as soon as their precondition is satisfied, without excluding other
+behavior; the {bullet} cannot. Although <<fetch, Fetch instruction>> is marked with a
+{bullet}, it can be taken eagerly as long as it is not
+taken infinitely many times.
+
+An instance of a non-AMO load instruction, after being fetched, will
+typically experience the following transitions in this order:
+
+. <<reg_read, Register read>>
+. <<initiate_load, Initiate memory load operations>>
+. <<sat_by_forwarding, Satisfy memory load operation by forwarding from unpropagated stores>> and/or <<sat_from_mem, Satisfy memory load operation from memory>> (as many as needed to satisfy all the load operations of the
+instance)
+. <<complete_loads, Complete load operations>>
+. <<reg_write, Register write>>
+. <<finish, Finish instruction>>
+
+Before, between, and after the transitions above, any number of
+<<sail_interp, Pseudocode internal step>> transitions may appear. In addition, a <<fetch, Fetch instruction>> transition for fetching the
+instruction in the next program location will be available until it is
+taken.
+
+This concludes the informal description of the operational model. The
+following sections describe the formal operational model.
+
+[[pseudocode_exec]]
+==== Intra-instruction Pseudocode Execution
+
+The intra-instruction semantics for each instruction instance is
+expressed as a state machine, essentially running the instruction
+pseudocode. Given a pseudocode execution state, it computes the next
+state. Most states identify a pending memory or register operation,
+requested by the pseudocode, which the memory model has to do. The
+states are (this is a tagged union; tags in small-caps):
+
+[cols="<,<",grid="none"]
+|===
+|Load_mem(_kind_, _address_, _size_, _load_continuation_) |- memory load
+operation
+
+|Early_sc_fail(_res_continuation_) |- allow `sc` to fail early
+
+|Store_ea(_kind_, _address_, _size_, _next_state_) |- memory store
+effective address
+
+|Store_memv(_mem_value_, _store_continuation_) |- memory store value
+
+|Fence(_kind_, _next_state_) |- fence
+
+|Read_reg(_reg_name_, _read_continuation_) |- register read
+
+|Write_reg(_reg_name_, _reg_value_, _next_state_) |- register write
+
+|Internal(_next_state_) |- pseudocode internal step
+
+|Done |- end of pseudocode
+|===
+
+Here:
+
+* _mem_value_ and _reg_value_ are lists of bytes;
+* _address_ is an integer of XLEN bits;
+
+for load/store, _kind_ identifies whether it is `lr/sc`,
+acquire-RCpc/release-RCpc, acquire-RCsc/release-RCsc,
+acquire-release-RCsc;
+* for fence, _kind_ identifies whether it is a normal or TSO, and (for
+normal fences) the predecessor and successor ordering bits;
+* _reg_name_ identifies a register and a slice thereof (start and end bit
+indices); and the continuations describe how the instruction instance will continue
+for each value that might be provided by the surrounding memory model
+(the _load_continuation_ and _read_continuation_ take the value loaded
+from memory and read from the previous register write, the
+_store_continuation_ takes _false_ for an `sc` that failed and _true_ in
+all other cases, and _res_continuation_ takes _false_ if the `sc` fails
+and _true_ otherwise).
+[NOTE]
+====
+For example, given the load instruction `lw x1,0(x2)`, an execution will
+typically go as follows. The initial execution state will be computed
+from the pseudocode for the given opcode. This can be expected to be
+Read_reg(`x2`, _read_continuation_). Feeding the most recently written
+value of register `x2` (the instruction semantics will be blocked if
+necessary until the register value is available), say `0x4000`, to
+_read_continuation_ returns Load_mem(`plain_load`, `0x4000`, `4`,
+_load_continuation_). Feeding the 4-byte value loaded from memory
+location `0x4000`, say `0x42`, to _load_continuation_ returns
+Write_reg(`x1`, `0x42`, Done). Many Internal(_next_state_) states may
+appear before and between the states above.
+====
+Notice that writing to memory is split into two steps, Store_ea and
+Store_memv: the first one makes the memory footprint of the store
+provisionally known, and the second one adds the value to be stored. We
+ensure these are paired in the pseudocode (Store_ea followed by
+Store_memv), but there may be other steps between them.
+[NOTE]
+====
+It is observable that the Store_ea can occur before the value to be
+stored is determined. For example, for the litmus test
+LB+fence.r.rw+data-po to be allowed by the operational model (as it is
+by RVWMO), the first store in Hart 1 has to take the Store_ea step
+before its value is determined, so that the second store can see it is
+to a non-overlapping memory footprint, allowing the second store to be
+committed out of order without violating coherence.
+====
+The pseudocode of each instruction performs at most one store or one
+load, except for AMOs that perform exactly one load and one store. Those
+memory accesses are then split apart into the architecturally atomic
+units by the hart semantics (see <<initiate_load, Initiate memory load operations>> and <<initiate_store_footprint, Initiate memory store operation footprints>> below).
+
+Informally, each bit of a register read should be satisfied from a
+register write by the most recent (in program order) instruction
+instance that can write that bit (or from the hart’s initial register
+state if there is no such write). Hence, it is essential to know the
+register write footprint of each instruction instance, which we
+calculate when the instruction instance is created (see the <<fetch, Fetch instruction>> action of
+below). We ensure in the pseudocode that each instruction does at most
+one register write to each register bit, and also that it does not try
+to read a register value it just wrote.
+
+Data-flow dependencies (address and data) in the model emerge from the
+fact that each register read has to wait for the appropriate register
+write to be executed (as described above).
+
+[[inst_state]]
+==== Instruction Instance State
+
+Each instruction instance __i_ has a state comprising:
+
+* _program_loc_, the memory address from which the instruction was
+fetched;
+* _instruction_kind_, identifying whether this is a load, store, AMO,
+fence, branch/jump or a `simple` instruction (this also includes a
+_kind_ similar to the one described for the pseudocode execution
+states);
+* _src_regs_, the set of source _reg_name_s (including system
+registers), as statically determined from the pseudocode of the
+instruction;
+* _dst_regs_, the destination _reg_name_s (including system registers),
+as statically determined from the pseudocode of the instruction;
+* _pseudocode_state_ (or sometimes just `state` for short), one of (this
+is a tagged union; tags in small-caps): +
+
+
+[cols="<,<",grid="none"]
+|===
+|Plain(_isa_state_) |- ready to make a pseudocode transition
+
+|Pending_mem_loads(_load_continuation_) |- requesting memory load
+operation(s)
+
+|Pending_mem_stores(_store_continuation_) |- requesting memory store
+operation(s)
+|===
+* _reg_reads_, the register reads the instance has performed, including,
+for each one, the register write slices it read from;
+* _reg_writes_, the register writes the instance has performed;
+* _mem_loads_, a set of memory load operations, and for each one the
+as-yet-unsatisfied slices (the byte indices that have not been satisfied
+yet), and, for the satisfied slices, the store slices (each consisting
+of a memory store operation and subset of its byte indices) that
+satisfied it.
+* _mem_stores_, a set of memory store operations, and for each one a
+flag that indicates whether it has been propagated (passed to the shared
+memory) or not.
+* information recording whether the instance is committed, finished,
+etc.
+
+Each memory load operation includes a memory footprint (address and
+size). Each memory store operations includes a memory footprint, and,
+when available, a value.
+
+A load instruction instance with a non-empty _mem_loads_, for which all
+the load operations are satisfied (i.e. there are no unsatisfied load
+slices) is said to be _entirely satisfied_.
+
+Informally, an instruction instance is said to have _fully determined
+data_ if the load (and `sc`) instructions feeding its source registers
+are finished. Similarly, it is said to have a _fully determined memory
+footprint_ if the load (and `sc`) instructions feeding its memory
+operation address register are finished. Formally, we first define the
+notion of _fully determined register write_: a register write
+_w_ from _reg_writes_ of instruction instance
+_i_ is said to be _fully determined_ if one of the following
+conditions hold:
+
+. _i_ is finished; or
+. the value written by _w_ is not affected by a memory
+operation that _i_ has made (i.e. a value loaded from memory
+or the result of `sc`), and, for every register read that
+_i_ has made, that affects _w_, the register
+write from which _i_ read is fully determined (or
+_i_ read from the initial register state).
+
+Now, an instruction instance _i_ is said to have _fully
+determined data_ if for every register read _r_ from
+_reg_reads_, the register writes that _r_ reads from are
+fully determined. An instruction instance _i_ is said to
+have a _fully determined memory footprint_ if for every register read
+_r_ from _reg_reads_ that feeds into _i_’s
+memory operation address, the register writes that _r_ reads
+from are fully determined.
+[NOTE]
+====
+The `rmem` tool records, for every register write, the set of register
+writes from other instructions that have been read by this instruction
+at the point of performing the write. By carefully arranging the
+pseudocode of the instructions covered by the tool we were able to make
+it so that this is exactly the set of register writes on which the write
+depends on.
+====
+
+==== Hart State
+
+The model state of a single hart comprises:
+
+* _hart_id_, a unique identifier of the hart;
+* _initial_register_state_, the initial register value for each
+register;
+* _initial_fetch_address_, the initial instruction fetch address;
+* _instruction_tree_, a tree of the instruction instances that have been
+fetched (and not discarded), in program order.
+
+==== Shared Memory State
+
+The model state of the shared memory comprises a list of memory store
+operations, in the order they propagated to the shared memory.
+
+When a store operation is propagated to the shared memory it is simply
+added to the end of the list. When a load operation is satisfied from
+memory, for each byte of the load operation, the most recent
+corresponding store slice is returned.
+[NOTE]
+====
+For most purposes, it is simpler to think of the shared memory as an
+array, i.e., a map from memory locations to memory store operation
+slices, where each memory location is mapped to a one-byte slice of the
+most recent memory store operation to that location. However, this
+abstraction is not detailed enough to properly handle the `sc`
+instruction. The RVWMO allows store operations from the same hart as the
+`sc` to intervene between the store operation of the `sc` and the store
+operations the paired `lr` read from. To allow such store operations to
+intervene, and forbid others, the array abstraction must be extended to
+record more information. Here, we use a list as it is very simple, but a
+more efficient and scalable implementations should probably use
+something better.
+====
+
+[[transitions]]
+==== Transitions
+
+Each of the paragraphs below describes a single kind of system
+transition. The description starts with a condition over the current
+system state. The transition can be taken in the current state only if
+the condition is satisfied. The condition is followed by an action that
+is applied to that state when the transition is taken, in order to
+generate the new system state.
+
+[[fetch]]
+===== Fetch instruction
+
+A possible program-order-successor of instruction instance
+_i_ can be fetched from address _loc_ if:
+
+. it has not already been fetched, i.e., none of the immediate
+successors of _i_ in the hart’s _instruction_tree_ are from
+_loc_; and
+. if _i_’s pseudocode has already written an address to
+_pc_, then _loc_ must be that address, otherwise _loc_ is:
+* for a conditional branch, the successor address or the branch target
+address;
+* for a (direct) jump and link instruction (`jal`), the target address;
+* for an indirect jump instruction (`jalr`), any address; and
+* for any other instruction, _i.program_loc_+4.
+
+Action: construct a freshly initialized instruction instance
+_i'_ for the instruction in the program memory at _loc_,
+with state Plain(_isa_state_), computed from the instruction pseudocode,
+including the static information available from the pseudocode such as
+its _instruction_kind_, _src_regs_, and _dst_regs_, and add
+_i'_ to the hart’s _instruction_tree_ as a successor of
+_i_.
+
+The possible next fetch addresses (_loc_) are available immediately
+after fetching _i_ and the model does not need to wait for
+the pseudocode to write to _pc_; this allows out-of-order execution, and
+speculation past conditional branches and jumps. For most instructions
+these addresses are easily obtained from the instruction pseudocode. The
+only exception to that is the indirect jump instruction (`jalr`), where
+the address depends on the value held in a register. In principle the
+mathematical model should allow speculation to arbitrary addresses here.
+The exhaustive search in the `rmem` tool handles this by running the
+exhaustive search multiple times with a growing set of possible next
+fetch addresses for each indirect jump. The initial search uses empty
+sets, hence there is no fetch after indirect jump instruction until the
+pseudocode of the instruction writes to _pc_, and then we use that value
+for fetching the next instruction. Before starting the next iteration of
+exhaustive search, we collect for each indirect jump (grouped by code
+location) the set of values it wrote to _pc_ in all the executions in
+the previous search iteration, and use that as possible next fetch
+addresses of the instruction. This process terminates when no new fetch
+addresses are detected.
+
+[[initiate_load]]
+===== Initiate memory load operations
+
+An instruction instance _i_ in state Plain(Load_mem(_kind_,
+_address_, _size_, _load_continuation_)) can always initiate the
+corresponding memory load operations. Action:
+
+. Construct the appropriate memory load operations _mlos_:
+* if _address_ is aligned to _size_ then _mlos_ is a single
+memory load operation of _size_ bytes from _address_;
+* otherwise, _mlos_ is a set of _size_ memory load
+operations, each of one byte, from the addresses
+_address_..._address_+_size_−1.
+. set _mem_loads_ of _i_ to _mlos_; and
+. update the state of _i_ to
+Pending_mem_loads(_load_continuation_).
+[NOTE]
+====
+In <<rvwmo-primitives>> it is said that
+misaligned memory accesses may be decomposed at any granularity. Here we
+decompose them to one-byte accesses as this granularity subsumes all
+others.
+====
+[[sat_by_forwarding]]
+===== Satisfy memory load operation by forwarding from unpropagated stores
+
+For a non-AMO load instruction instance _i_ in state
+Pending_mem_loads(_load_continuation_), and a memory load operation
+_mlo_ in _i.mem_loads_ that has
+unsatisfied slices, the memory load operation can be partially or
+entirely satisfied by forwarding from unpropagated memory store
+operations by store instruction instances that are program-order-before
+_i_ if:
+
+. all program-order-previous `fence` instructions with `.sr` and `.pw`
+set are finished;
+. for every program-order-previous `fence` instruction, _f_,
+with `.sr` and `.pr` set, and `.pw` not set, if _f_ is not
+finished then all load instructions that are program-order-before
+_f_ are entirely satisfied;
+. for every program-order-previous `fence.tso` instruction,
+_f_, that is not finished, all load instructions that are
+program-order-before _f_ are entirely satisfied;
+. if _i_ is a load-acquire-RCsc, all program-order-previous
+store-releases-RCsc are finished;
+. if _i_ is a load-acquire-release, all
+program-order-previous instructions are finished;
+. all non-finished program-order-previous load-acquire instructions are
+entirely satisfied; and
+. all program-order-previous store-acquire-release instructions are
+finished;
+
+Let _msoss_ be the set of all unpropagated memory store
+operation slices from non-`sc` store instruction instances that are
+program-order-before _i_ and have already calculated the
+value to be stored, that overlap with the unsatisfied slices of
+_mlo_, and which are not superseded by intervening store
+operations or store operations that are read from by an intervening
+load. The last condition requires, for each memory store operation slice
+_msos_ in _msoss_ from instruction
+_i'_:
+
+* that there is no store instruction program-order-between _i_
+and _i'_ with a memory store operation overlapping
+_msos_; and
+* that there is no load instruction program-order-between _i_
+and _i'_ that was satisfied from an overlapping memory store
+operation slice from a different hart.
+
+Action:
+
+. update _i.mem_loads_ to indicate that
+_mlo_ was satisfied by _msoss_; and
+. restart any speculative instructions which have violated coherence as
+a result of this, i.e., for every non-finished instruction
+_i'_ that is a program-order-successor of _i_,
+and every memory load operation _mlo'_ of _i'_
+that was satisfied from _msoss'_, if there exists a memory
+store operation slice _msos'_ in _msoss'_, and
+an overlapping memory store operation slice from a different memory
+store operation in _msoss_, and _msos'_ is not
+from an instruction that is a program-order-successor of
+_i_, restart _i'_ and its _restart-dependents_.
+
+Where, the _restart-dependents_ of instruction _j_ are:
+
+* program-order-successors of _j_ that have data-flow
+dependency on a register write of _j_;
+* program-order-successors of _j_ that have a memory load
+operation that reads from a memory store operation of _j_
+(by forwarding);
+* if _j_ is a load-acquire, all the program-order-successors
+of _j_;
+* if _j_ is a load, for every `fence`, _f_, with
+`.sr` and `.pr` set, and `.pw` not set, that is a
+program-order-successor of _j_, all the load instructions
+that are program-order-successors of _f_;
+* if _j_ is a load, for every `fence.tso`, _f_,
+that is a program-order-successor of _j_, all the load
+instructions that are program-order-successors of _f_; and
+* (recursively) all the restart-dependents of all the instruction
+instances above.
+[NOTE]
+====
+Forwarding memory store operations to a memory load might satisfy only
+some slices of the load, leaving other slices unsatisfied.
+
+A program-order-previous store operation that was not available when
+taking the transition above might make _msoss_ provisionally
+unsound (violating coherence) when it becomes available. That store will
+prevent the load from being finished (see <<finish, Finish instruction>>), and will cause it to
+restart when that store operation is propagated (see <<prop_store, Propagate store operation>>).
+
+A consequence of the transition condition above is that
+store-release-RCsc memory store operations cannot be forwarded to
+load-acquire-RCsc instructions: _msoss_ does not include
+memory store operations from finished stores (as those must be
+propagated memory store operations), and the condition above requires
+all program-order-previous store-releases-RCsc to be finished when the
+load is acquire-RCsc.
+====
+[[sat_from_mem]]
+===== Satisfy memory load operation from memory
+
+For an instruction instance _i_ of a non-AMO load
+instruction or an AMO instruction in the context of the <<do_amo, Satisfy, commit and propagate operations of an AMO>> transition,
+any memory load operation _mlo_ in
+_i.mem_loads_ that has unsatisfied slices, can be
+satisfied from memory if all the conditions of <sat_by_forwarding, Satisfy memory load operation by forwarding from unpropagated stores>> are satisfied. Action:
+let _msoss_ be the memory store operation slices from memory
+covering the unsatisfied slices of _mlo_, and apply the
+action of <<do_amo, Satisfy memory operation by forwarding from unpropagates stores>>.
+[NOTE]
+====
+Note that <<do_amo, Satisfy memory operation by forwarding from unpropagates stores>> might leave some slices of the memory load operation
+unsatisfied, those will have to be satisfied by taking the transition
+again, or taking <<sat_from_mem, Satisfy memory load operation from memory>>. <<sat_from_mem, Satisfy memory load operation from memory>>, on the other hand, will always satisfy all the
+unsatisfied slices of the memory load operation.
+====
+[[complete_loads]]
+===== Complete load operations
+
+A load instruction instance _i_ in state
+Pending_mem_loads(_load_continuation_) can be completed (not to be
+confused with finished) if all the memory load operations
+_i.mem_loads_ are entirely satisfied (i.e. there
+are no unsatisfied slices). Action: update the state of _i_
+to Plain(_load_continuation(mem_value)_), where _mem_value_ is assembled
+from all the memory store operation slices that satisfied
+_i.mem_loads_.
+
+[[early_sc_fail]]
+===== Early `sc` fail
+
+An `sc` instruction instance _i_ in state
+Plain(Early_sc_fail(_res_continuation_)) can always be made to fail.
+Action: update the state of _i_ to
+Plain(_res_continuation(false)_).
+
+[[paired_sc]]
+===== Paired `sc`
+
+An `sc` instruction instance _i_ in state
+Plain(Early_sc_fail(_res_continuation_)) can continue its (potentially
+successful) execution if _i_ is paired with an `lr`. Action:
+update the state of _i_ to Plain(_res_continuation(true)_).
+
+[[initiate_store_footprint]]
+===== Initiate memory store operation footprints
+
+An instruction instance _i_ in state Plain(Store_ea(_kind_,
+_address_, _size_, _next_state_)) can always announce its pending memory
+store operation footprint. Action:
+
+. construct the appropriate memory store operations _msos_
+(without the store value):
+* if _address_ is aligned to _size_ then _msos_ is a single
+memory store operation of _size_ bytes to _address_;
+* otherwise, _msos_ is a set of _size_ memory store
+operations, each of one-byte size, to the addresses
+_address_..._address_+_size_−1.
+. set _i.mem_stores_ to _msos_; and
+. update the state of _i_ to Plain(_next_state_).
+[NOTE]
+====
+Note that after taking the transition above the memory store operations
+do not yet have their values. The importance of splitting this
+transition from the transition below is that it allows other
+program-order-successor store instructions to observe the memory
+footprint of this instruction, and if they don’t overlap, propagate out
+of order as early as possible (i.e. before the data register value
+becomes available).
+====
+[[instantiate_store_value]]
+===== Instantiate memory store operation values
+
+An instruction instance _i_ in state
+Plain(Store_memv(_mem_value_, _store_continuation_)) can always
+instantiate the values of the memory store operations
+_i.mem_stores_. Action:
+
+. split _mem_value_ between the memory store operations
+_i.mem_stores_; and
+. update the state of _i_ to
+Pending_mem_stores(_store_continuation_).
+
+[[commit_stores]]
+===== Commit store instruction
+
+An uncommitted instruction instance _i_ of a non-`sc` store
+instruction or an `sc` instruction in the context of the <<commit_sc, Commit and propagate store operation of an `sc`>>
+transition, in state Pending_mem_stores(_store_continuation_), can be
+committed (not to be confused with propagated) if:
+
+. _i_ has fully determined data;
+. all program-order-previous conditional branch and indirect jump
+instructions are finished;
+. all program-order-previous `fence` instructions with `.sw` set are
+finished;
+. all program-order-previous `fence.tso` instructions are finished;
+. all program-order-previous load-acquire instructions are finished;
+. all program-order-previous store-acquire-release instructions are
+finished;
+. if _i_ is a store-release, all program-order-previous
+instructions are finished;
+. all program-order-previous memory access instructions have a fully
+determined memory footprint;
+. all program-order-previous store instructions, except for `sc` that failed,
+have initiated and so have non-empty _mem_stores_; and
+. all program-order-previous load instructions have initiated and so have
+non-empty _mem_loads_.
+
+Action: record that _i_ is committed.
+[NOTE]
+====
+Notice that if condition
+<<commit_stores, 8>> is satisfied
+the conditions
+<<commit_stores, 9>> and
+<<commit_stores, 10>> are also
+satisfied, or will be satisfied after taking some eager transitions.
+Hence, requiring them does not strengthen the model. By requiring them,
+we guarantee that previous memory access instructions have taken enough
+transitions to make their memory operations visible for the condition
+check of , which is the next transition the instruction will take,
+making that condition simpler.
+====
+[[prop_store]]
+===== Propagate store operation
+
+For a committed instruction instance _i_ in state
+Pending_mem_stores(_store_continuation_), and an unpropagated memory
+store operation _mso_ in
+_i.mem_stores_, _mso_ can be
+propagated if:
+
+. all memory store operations of program-order-previous store
+instructions that overlap with _mso_ have already
+propagated;
+. all memory load operations of program-order-previous load instructions
+that overlap with _mso_ have already been satisfied, and
+(the load instructions) are _non-restartable_ (see definition below);
+and
+. all memory load operations that were satisfied by forwarding
+_mso_ are entirely satisfied.
+
+Where a non-finished instruction instance _j_ is
+_non-restartable_ if:
+
+. there does not exist a store instruction _s_ and an
+unpropagated memory store operation _mso_ of _s_
+such that applying the action of the <<prop_store, Propagate store operation>> transition to
+_mso_ will result in the restart of _j_; and
+. there does not exist a non-finished load instruction _l_
+and a memory load operation _mlo_ of _l_ such
+that applying the action of the <<sat_by_forwarding, Satisfy memory load operation by forwarding from unpropagated stores>>/<<sat_from_mem, Satisfy memory load operation from memory>> transition (even if
+_mlo_ is already satisfied) to _mlo_ will result
+in the restart of _j_.
+
+Action:
+
+. update the shared memory state with _mso_;
+. update _i.mem_stores_ to indicate that
+_mso_ was propagated; and
+. restart any speculative instructions which have violated coherence as
+a result of this, i.e., for every non-finished instruction
+_i'_ program-order-after _i_ and every memory
+load operation _mlo'_ of _i'_ that was satisfied
+from _msoss'_, if there exists a memory store operation
+slice _msos'_ in _msoss'_ that overlaps with
+_mso_ and is not from _mso_, and
+_msos'_ is not from a program-order-successor of
+_i_, restart _i'_ and its _restart-dependents_
+(see <<sat_by_forwarding, Satisfy memory load operation by forwarding from unpropagated stores>>).
+
+[[commit_sc]]
+===== Commit and propagate store operation of an `sc`
+
+An uncommitted `sc` instruction instance _i_, from hart
+_h_, in state Pending_mem_stores(_store_continuation_), with
+a paired `lr` _i'_ that has been satisfied by some store
+slices _msoss_, can be committed and propagated at the same
+time if:
+
+. _i'_ is finished;
+. every memory store operation that has been forwarded to
+_i'_ is propagated;
+. the conditions of <<commit_stores, Commit store instruction>> is satisfied;
+. the conditions of <<prop_store, Propagate store instruction>> is satisfied (notice that an `sc` instruction can
+only have one memory store operation); and
+. for every store slice _msos_ from _msoss_,
+_msos_ has not been overwritten, in the shared memory, by a
+store that is from a hart that is not _h_, at any point
+since _msos_ was propagated to memory.
+
+Action:
+
+. apply the actions of <<commit_stores, Commit store instruction>>; and
+. apply the action of <<prop_store, Propagate store instruction>>.
+
+[[late_sc_fail]]
+===== Late `sc` fail
+
+An `sc` instruction instance _i_ in state
+Pending_mem_stores(_store_continuation_), that has not propagated its
+memory store operation, can always be made to fail. Action:
+
+. clear _i.mem_stores_; and
+. update the state of _i_ to
+Plain(_store_continuation(false)_).
+[NOTE]
+====
+For efficiency, the `rmem` tool allows this transition only when it is
+not possible to take the <<commit_sc, Commit and propagate store operation of an sc>> transition. This does not affect the set of
+allowed final states, but when explored interactively, if the `sc`
+should fail one should use the <<early_sc_fail, Early sc fail>> transition instead of waiting for this transition.
+====
+[[complete_stores]]
+===== Complete store operations
+
+A store instruction instance _i_ in state
+Pending_mem_stores(_store_continuation_), for which all the memory store
+operations in _i.mem_stores_ have been propagated,
+can always be completed (not to be confused with finished). Action:
+update the state of _i_ to
+Plain(_store_continuation(true)_).
+
+[[do_amo]]
+===== Satisfy, commit and propagate operations of an AMO
+
+An AMO instruction instance _i_ in state
+Pending_mem_loads(_load_continuation_) can perform its memory access if
+it is possible to perform the following sequence of transitions with no
+intervening transitions:
+
+. <<sat_from_mem, Satisfy memory load operation from memory>>
+. <<complete_loads, Complere load operations>>
+. <<sail_interp, Pseudocode internal step>> (zero or more times)
+. <<instantiate_store_value, Instantiate memory store operation values>>
+. <<commit_stores, Commit store instruction>>
+. <<prop_store, Propagate store operation>>
+. <<complete_stores, Complete store operations>>
+
+and in addition, the condition of <<finish, Finish instruction>>, with the exception of not requiring
+_i_ to be in state Plain(Done), holds after those
+transitions. Action: perform the above sequence of transitions (this
+does not include <<finish, Finish instruction>>), one after the other, with no intervening
+transitions.
+[NOTE]
+====
+Notice that program-order-previous stores cannot be forwarded to the
+load of an AMO. This is simply because the sequence of transitions above
+does not include the forwarding transition. But even if it did include
+it, the sequence will fail when trying to do the <<prop_store, Propagate store operation>> transition, as this
+transition requires all program-order-previous store operations to
+overlapping memory footprints to be propagated, and forwarding requires
+the store operation to be unpropagated.
+
+In addition, the store of an AMO cannot be forwarded to a
+program-order-successor load. Before taking the transition above, the
+store operation of the AMO does not have its value and therefore cannot
+be forwarded; after taking the transition above the store operation is
+propagated and therefore cannot be forwarded.
+====
+[[commit_fence]]
+===== Commit fence
+
+A fence instruction instance _i_ in state
+Plain(Fence(_kind_, _next_state_)) can be committed if:
+
+. if _i_ is a normal fence and it has `.pr` set, all
+program-order-previous load instructions are finished;
+. if _i_ is a normal fence and it has `.pw` set, all
+program-order-previous store instructions are finished; and
+. if _i_ is a `fence.tso`, all program-order-previous load
+and store instructions are finished.
+
+Action:
+
+. record that _i_ is committed; and
+. update the state of _i_ to Plain(_next_state_).
+
+[[reg_read]]
+===== Register read
+
+An instruction instance _i_ in state
+Plain(Read_reg(_reg_name_, _read_cont_)) can do a register read of
+_reg_name_ if every instruction instance that it needs to read from has
+already performed the expected _reg_name_ register write.
+
+Let _read_sources_ include, for each bit of _reg_name_, the write to
+that bit by the most recent (in program order) instruction instance that
+can write to that bit, if any. If there is no such instruction, the
+source is the initial register value from _initial_register_state_. Let
+_reg_value_ be the value assembled from _read_sources_. Action:
+
+. add _reg_name_ to _i.reg_reads_ with
+_read_sources_ and _reg_value_; and
+. update the state of _i_ to Plain(_read_cont(reg_value)_).
+
+[[reg_write]]
+===== Register write
+
+An instruction instance _i_ in state
+Plain(Write_reg(_reg_name_, _reg_value_, _next_state_)) can always do a
+_reg_name_ register write. Action:
+
+. add _reg_name_ to _i.reg_writes_ with
+_deps_ and _reg_value_; and
+. update the state of _i_ to Plain(_next_state_).
+
+where _deps_ is a pair of the set of all _read_sources_ from
+_i.reg_reads_, and a flag that is true iff
+_i_ is a load instruction instance that has already been
+entirely satisfied.
+
+[[sail_interp]]
+===== Pseudocode internal step
+
+An instruction instance _i_ in state
+Plain(Internal(_next_state_)) can always do that pseudocode-internal
+step. Action: update the state of _i_ to
+Plain(_next_state_).
+
+[[finish]]
+===== Finish instruction
+
+A non-finished instruction instance _i_ in state Plain(Done)
+can be finished if:
+
+. if _i_ is a load instruction:
+.. all program-order-previous load-acquire instructions are finished;
+.. all program-order-previous `fence` instructions with `.sr` set are
+finished;
+.. for every program-order-previous `fence.tso` instruction,
+_f_, that is not finished, all load instructions that are
+program-order-before _f_ are finished; and
+.. it is guaranteed that the values read by the memory load operations
+of _i_ will not cause coherence violations, i.e., for any
+program-order-previous instruction instance _i'_, let
+_cfp_ be the combined footprint of propagated
+memory store operations from store instructions program-order-between
+_i_ and _i'_, and _fixed memory store
+operations_ that were forwarded to _i_ from store
+instructions program-order-between _i_ and _i'_
+including _i'_, and let
+_/cfp_ be the complement of
+_cfp_ in the memory footprint of _i_.
+If _/cfp_ is not empty:
+... _i'_ has a fully determined memory footprint;
+... _i'_ has no unpropagated memory store operations that
+overlap with _/cfp_; and
+... if _i'_ is a load with a memory footprint that overlaps
+with _/cfp_, then all the memory load
+operations of _i'_ that overlap with
+_/cfp_ are satisfied and _i'_
+is _non-restartable_ (see the <<prop_store, Propagate store operation>> transition for how to determined if an
+instruction is non-restartable).
++
+Here, a memory store operation is called fixed if the store instruction
+has fully determined data.
+. _i_ has a fully determined data; and
+. if _i_ is not a fence, all program-order-previous
+conditional branch and indirect jump instructions are finished.
+
+Action:
+
+. if _i_ is a conditional branch or indirect jump
+instruction, discard any untaken paths of execution, i.e., remove all
+instruction instances that are not reachable by the branch/jump taken in
+_instruction_tree_; and
+. record the instruction as finished, i.e., set _finished_ to _true_.
+
+[[limitations]]
+==== Limitations
+
+* The model covers user-level RV64I and RV64A. In particular, it does
+not support the misaligned atomicity granule PMA or the total store
+ordering extension "Ztso". It should be trivial to adapt the model to
+RV32I/A and to the G, Q and C extensions, but we have never tried it.
+This will involve, mostly, writing Sail code for the instructions, with
+minimal, if any, changes to the concurrency model.
+* The model covers only normal memory accesses (it does not handle I/O
+accesses).
+* The model does not cover TLB-related effects.
+* The model assumes the instruction memory is fixed. In particular, the
+<<fetch, Fetch instruction>> transition does not generate memory load operations, and the shared
+memory is not involved in the transition. Instead, the model depends on
+an external oracle that provides an opcode when given a memory location.
+* The model does not cover exceptions, traps and interrupts.
diff --git a/src/memory-model-herd.tex b/src/mm-herd.adoc
index d01af38..6eeffcd 100644
--- a/src/memory-model-herd.tex
+++ b/src/mm-herd.adoc
@@ -1,14 +1,24 @@
-\section{Formal Axiomatic Specification in Herd}
-\label{sec:herd}
-
-The tool \textsf{herd} takes a memory model and a litmus test as input and simulates the execution of the test on top of the memory model. Memory models are written in the domain specific language \textsc{Cat}. This section provides two \textsc{Cat} memory model of RVWMO. The first model, Figure~\ref{fig:herd2}, follows the \emph{global memory order}, Chapter~\ref{ch:memorymodel}, definition of~RVWMO, as much as is possible for a \textsc{Cat} model. The second model, Figure~\ref{fig:herd3}, is an equivalent, more efficient, partial order based RVWMO model.
-
-The simulator~\textsf{herd} is part of the \textsf{diy} tool suite --- see \url{http://diy.inria.fr} for software and documentation. The models and more are available online at~\url{http://diy.inria.fr/cats7/riscv/}.
-
-\begin{figure}[h!]
- {
- \tt\bfseries\centering\footnotesize
- \begin{lstlisting}
+[[sec:herd]]
+== Formal Axiomatic Specification in Herd
+
+The tool [.sans-serif]#herd# takes a memory model and a litmus test as
+input and simulates the execution of the test on top of the memory
+model. Memory models are written in the domain specific language Cat.
+This section provides two Cat memory model of RVWMO. The first model,
+Figure #fig:herd2[[fig:herd2]], follows the _global memory order_,
+Chapter #ch:memorymodel[[ch:memorymodel]], definition of RVWMO, as much
+as is possible for a Cat model. The second model,
+Figure #fig:herd3[[fig:herd3]], is an equivalent, more efficient,
+partial order based RVWMO model.
+
+The simulator [.sans-serif]#herd# is part of the [.sans-serif]#diy# tool
+suite — see http://diy.inria.fr for software and documentation. The
+models and more are available online
+at http://diy.inria.fr/cats7/riscv/.
+
+` `
+
+....
(*************)
(* Utilities *)
(*************)
@@ -27,7 +37,7 @@ let fence.tso =
let f = fencerel(Fence.tso) in
([W];f;[W]) | ([R];f;[M])
-let fence =
+let fence =
fence.r.r | fence.r.w | fence.r.rw |
fence.w.r | fence.w.w | fence.w.rw |
fence.rw.r | fence.rw.w | fence.rw.rw |
@@ -70,16 +80,11 @@ and r12 = [R];(addr|data);[W];rfi;[R]
and r13 = [R];addr;[M];po;[W]
let ppo = r1 | r2 | r3 | r4 | r5 | r6 | r7 | r8 | r9 | r10 | r11 | r12 | r13
-\end{lstlisting}
- }
- \caption{{\tt riscv-defs.cat}, a herd definition of preserved program order (1/3)}
- \label{fig:herd1}
-\end{figure}
-
-\begin{figure}[ht!]
- {
- \tt\bfseries\centering\footnotesize
- \begin{lstlisting}
+....
+
+` `
+
+....
Total
(* Notice that herd has defined its own rf relation *)
@@ -94,10 +99,10 @@ include "riscv-defs.cat"
let gmo0 = (* precursor: ie build gmo as an total order that include gmo0 *)
loc & (W\FW) * FW | # Final write after any write to the same location
ppo | # ppo compatible
- rfe # includes herd external rf (optimisation)
+ rfe # includes herd external rf (optimization)
(* Walk over all linear extensions of gmo0 *)
-with gmo from linearisations(M\IW,gmo0)
+with gmo from linearizations(M\IW,gmo0)
(* Add initial writes upfront -- convenient for computing rfGMO *)
let gmo = gmo | loc & IW * (M\IW)
@@ -118,16 +123,11 @@ let infloc = (gmo & loc)^-1
let inflocext = infloc & ext
let winside = (infloc;rmw;inflocext) & (infloc;rf;rmw;inflocext) & [W]
empty winside as Atomic
-\end{lstlisting}
- }
- \caption{{\tt riscv.cat}, a herd version of the RVWMO memory model (2/3)}
- \label{fig:herd2}
-\end{figure}
-
-\begin{figure}[h!]
- {
- \tt\bfseries\centering\footnotesize
- \begin{lstlisting}
+....
+
+` `
+
+....
Partial
(***************)
@@ -152,9 +152,4 @@ acyclic co|rfe|fr|ppo as Model
(* Atomicity axiom *)
empty rmw & (fre;coe) as Atomic
-\end{lstlisting}
- }
- \caption{{\tt riscv.cat}, an alternative herd presentation of the RVWMO memory model (3/3)}
- \label{fig:herd3}
-\end{figure}
-
+....
diff --git a/src/n.tex b/src/n.tex
deleted file mode 100644
index 00812a7..0000000
--- a/src/n.tex
+++ /dev/null
@@ -1,124 +0,0 @@
-\chapter{``N'' Standard Extension for User-Level Interrupts, Version 1.1}
-\label{chap:n}
-
-\begin{commentary}
- This is a placeholder for a more complete writeup of the N
- extension, and to form a basis for discussion.
-\end{commentary}
-
-This chapter presents a proposal for adding RISC-V user-level
-interrupt and exception handling. When the N extension is present,
-and the outer execution environment has delegated designated
-interrupts and exceptions to user-level, then hardware can transfer
-control directly to a user-level trap handler without invoking the
-outer execution environment.
-
-\begin{commentary}
-User-level interrupts are primarily intended to support secure
-embedded systems with only M-mode and U-mode present, but can also be
-supported in systems running Unix-like operating systems to support
-user-level trap handling.
-
-When used in an Unix environment, the user-level interrupts would
-likely not replace conventional signal handling, but could be used as
-a building block for further extensions that generate user-level
-events such as garbage collection barriers, integer overflow,
-floating-point traps.
-\end{commentary}
-
-\section{Additional CSRs}
-
-The user-visible CSRs added to support the N extension are listed in
-Table~\ref{tab:ncsrs}.
-
-\begin{table}[hbt]
- \centering
- \begin{tabular}{|l|l|l|}
- \hline
- Number & Name & Description \\
- \hline
- \tt 0x000 & \tt ustatus & User status register. \\
- \tt 0x004 & \tt uie & User interrupt-enable register. \\
- \tt 0x005 & \tt utvec & User trap handler base address. \\
- \tt 0x040 & \tt uscratch & Scratch register for user trap handlers. \\
- \tt 0x041 & \tt uepc & User exception program counter. \\
- \tt 0x042 & \tt ucause & User trap cause. \\
- \tt 0x043 & \tt utval & User bad address or instruction. \\
- \tt 0x044 & \tt uip & User interrupt pending. \\
- \hline
- \end{tabular}
- \caption{CSRs for N extension.}
- \label{tab:ncsrs}
-\end{table}
-
-\section{User Status Register ({\tt ustatus})}
-
-The {\tt ustatus} register is an XLEN-bit read/write register
-formatted as shown in Figure~\ref{ustatusreg}. The {\tt ustatus}
-register keeps track of and controls the hart's current operating
-state.
-
-\begin{figure*}[h!]
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{KccFc}
-\\
-\instbitrange{XLEN}{5} &
-\instbit{4} &
-\instbitrange{3}{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{\wpri} &
-\multicolumn{1}{c|}{UPIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{UIE} \\
-\hline
-XLEN-5 & 1 & 3 & 1 \\
-\end{tabular}
-\end{center}
-\vspace{-0.1in}
-\caption{User-mode status register ({\tt ustatus}).}
-\label{ustatusreg}
-\end{figure*}
-
-The user interrupt-enable bit UIE disables user-level interrupts when
-clear. The value of UIE is copied into UPIE when a user-level trap is
-taken, and the value of UIE is set to zero to provide atomicity for
-the user-level trap handler.
-
-\begin{commentary}
- There is no UPP bit to hold the previous privilege mode as it can
- only be user mode.
-\end{commentary}
-
-The URET instructions is used to return from traps in U-mode, and URET
-copies UPIE into UIE, then sets UPIE.
-\begin{commentary}
- UPIE is set after the UPIE/UIE stack is popped to enable interrupts
- and help catch coding errors.
-\end{commentary}
-
-\section{Other CSRs}
-The remaining CSRs function in an analogous way to the trap handling
-registers defined for M-mode and S-mode.
-
-\begin{commentary}
- A more complete writeup to follow.
-\end{commentary}
-
-\section{N Extension Instructions}
-
-The URET instruction is added to perform the analogous function to
-MRET and SRET.
-
-\section{Reducing Context-Swap Overhead}
-
-The user-level interrupt-handling registers add considerable state to
-the user-level context, yet will usually rarely be active in normal
-use. In particular, {\tt uepc}, {\tt ucause}, and {\tt utval} are
-only valid during execution of a trap handler.
-
-An NS field can be added to {\tt mstatus} and {\tt sstatus} following
-the format of the FS and XS fields to reduce context-switch overhead
-when the values are not live. Execution of URET will place the {\tt
- uepc}, {\tt ucause}, and {\tt utval} back into initial state.
diff --git a/src/naming.adoc b/src/naming.adoc
new file mode 100644
index 0000000..9b3f62d
--- /dev/null
+++ b/src/naming.adoc
@@ -0,0 +1,222 @@
+[[naming]]
+== ISA Extension Naming Conventions
+
+This chapter describes the RISC-V ISA extension naming scheme that is
+used to concisely describe the set of instructions present in a hardware
+implementation, or the set of instructions used by an application binary
+interface (ABI).
+[NOTE]
+====
+The RISC-V ISA is designed to support a wide variety of implementations
+with various experimental instruction-set extensions. We have found that
+an organized naming scheme simplifies software tools and documentation.
+====
+=== Case Sensitivity
+
+The ISA naming strings are case insensitive.
+
+=== Base Integer ISA
+
+RISC-V ISA strings begin with either RV32I, RV32E, RV64I, or RV64E,
+indicating the supported address space size in bits for the base integer
+ISA.
+
+=== Instruction-Set Extension Names
+
+Standard ISA extensions are given a name consisting of a single letter.
+For example, the first four standard extensions to the integer bases
+are: "M" for integer multiplication and division, "A" for atomic
+memory instructions, "F" for single-precision floating-point
+instructions, and "D" for double-precision floating-point
+instructions. Any RISC-V instruction-set variant can be succinctly
+described by concatenating the base integer prefix with the names of the
+included extensions, e.g., "RV64IMAFD".
+
+We have also defined an abbreviation "G" to represent the
+"IMAFDZicsr_Zifencei" base and extensions, as this is intended to
+represent our standard general-purpose ISA.
+
+Standard extensions to the RISC-V ISA are given other reserved letters,
+e.g., "Q" for quad-precision floating-point, or "C" for the 16-bit
+compressed instruction format.
+
+Some ISA extensions depend on the presence of other extensions, e.g.,
+"D" depends on "F" and "F" depends on "Zicsr". These dependencies
+may be implicit in the ISA name: for example, RV32IF is equivalent to
+RV32IFZicsr, and RV32ID is equivalent to RV32IFD and RV32IFDZicsr.
+
+=== Underscores
+
+Underscores "_" may be used to separate ISA extensions to improve
+readability and to provide disambiguation, e.g., "RV32I2_M2_A2".
+
+=== Additional Standard Unprivileged Extension Names
+
+Standard unprivileged extensions can also be named by using a single "Z" followed by an
+alphanumeric name. The name must end with an alphabetical character.
+The second letter from the end cannot be numeric if the
+last letter is "p". For example, "Zifencei" names the instruction-fetch fence extension
+described in <<zifencei>>.
+
+The first letter following the "Z" conventionally indicates the most
+closely related alphabetical extension category, IMAFDQLCBKJTPVH. For the
+"Zfa" extension for additional floating-point instructions, for example, the letter "f"
+indicates the extension is related to the "F" standard extension. If
+multiple "Z" extensions are named, they should be ordered first by
+category, then alphabetically within a category—for example,
+"Zicsr_Zifencei_Ztso".
+
+All multi-letter extensions, including those with the "Z" prefix, must be
+separated from other multi-letter extensions by an underscore, e.g.,
+"RV32IMACZicsr_Zifencei".
+
+=== Supervisor-level Instruction-Set Extension Names
+
+Standard extensions that extend the supervisor-level virtual-memory
+architecture are prefixed with the letters "Sv", followed by an alphanumeric
+name. Other standard extensions that extend the supervisor-level architecture are
+prefixed with the letters "Ss", followed by an alphanumeric name. The name
+must end with an alphabetical character. The second letter from the end cannot
+be numeric if the last letter is "p". These extensions are further defined in
+Volume II.
+
+The extensions "sv32", "sv39", "sv48", and "sv59" were defined before the rule
+against extension names ending in numbers was established.
+
+Standard supervisor-level extensions should be listed after standard
+unprivileged extensions, and like other multi-letter extensions, must be
+separated from other multi-letter extensions by an underscore. If multiple
+supervisor-level extensions are listed, they should be ordered alphabetically.
+
+=== Hypervisor-level Instruction-Set Extension Names
+
+Standard extensions that extend the hypervisor-level architecture are prefixed
+with the letters "Sh".
+If multiple hypervisor-level extensions are listed, they should be ordered
+alphabetically.
+
+NOTE: Many augmentations to the hypervisor-level architecture are more
+naturally defined as supervisor-level extensions, following the scheme
+described in the previous section.
+The "Sh" prefix is used by the few hypervisor-level extensions that have no
+supervisor-visible effects.
+
+=== Machine-level Instruction-Set Extension Names
+
+Standard machine-level instruction-set extensions are prefixed with the
+letters "Sm".
+
+Standard machine-level extensions should be listed after standard
+lesser-privileged extensions, and like other multi-letter extensions, must be
+separated from other multi-letter extensions by an underscore. If multiple
+machine-level extensions are listed, they should be ordered alphabetically.
+
+=== Non-Standard Extension Names
+
+Non-standard extensions are named by using a single "X" followed by the alphanumeric
+name. The name must end with an alphabetic character. The
+second letter from the end cannot be numeric if the last letter is
+"p". For example, "Xhwacha" names the Hwacha vector-fetch ISA
+extension.
+
+Non-standard extensions must be listed after all standard extensions, and,
+like other multi-letter extensions, must be separated from other multi-letter
+extensions by an underscore.
+For example, an ISA with non-standard extensions Argle and
+Bargle may be named "RV64IZifencei_Xargle_Xbargle".
+
+If multiple non-standard extensions are listed, they should be ordered
+alphabetically. Like other multi-letter extensions, they should be
+separated from other multi-letter extensions by an underscore.
+
+=== Version Numbers
+
+Recognizing that instruction sets may expand or alter over time, we
+encode extension version numbers following the extension name. Version
+numbers are divided into major and minor version numbers, separated by a
+"p". If the minor version is "0", then "p0" can be omitted from
+the version string. To avoid ambiguity, no extension name may end with a number
+or a "p" preceded by a number.
+
+Because the "P" extension for Packed SIMD can be confused for the
+decimal point in a version number, it must be preceded by an underscore
+if it follows another extension with a version number. For example, "rv32i2p2"
+means version 2.2 of RV32I, whereas "rv32i2_p2" means version 2.0 of RV32I with
+version 2.0 of the P extension.
+
+Changes in major version numbers imply a loss of
+backwards compatibility, whereas changes in only the minor version
+number must be backwards-compatible. For example, the original 64-bit
+standard ISA defined in release 1.0 of this manual can be written in
+full as "RV64I1p0M1p0A1p0F1p0D1p0", more concisely as
+"RV64I1M1A1F1D1".
+
+We introduced the version numbering scheme with the second release.
+Hence, we define the default version of a standard extension to be the
+version present at that time, e.g., "RV32I" is equivalent to
+"RV32I2".
+
+=== Subset Naming Convention
+
+<<isanametable>> summarizes the standardized extension
+names. The table also defines the canonical
+order in which extension names must appear in the name string, with
+top-to-bottom in table indicating first-to-last in the name string,
+e.g., RV32IMACV is legal, whereas RV32IMAVC is not.
+
+[[isanametable]]
+.Standard ISA extension names.
+[%autowidth,float="center",align="center",cols="<,^,^",options="header",]
+|===
+|Subset |Name |Implies
+
+|Base ISA | |
+
+|Integer |I |
+
+|Reduced Integer |E |
+
+3+|*Standard Unprivileged Extensions*
+
+|Integer Multiplication and Division |M |Zmmul
+
+|Atomics |A |
+
+|Single-Precision Floating-Point |F |Zicsr
+
+|Double-Precision Floating-Point |D |F
+
+|General |G |IMAFDZicsr_Zifencei
+
+|Quad-Precision Floating-Point |Q |D
+
+|16-bit Compressed Instructions |C |
+
+|B Extension |B |
+
+|Packed-SIMD Extensions |P |
+
+|Vector Extension |V |D
+
+|Hypervisor Extension |H |
+
+3+|*Additional Standard Unprivileged Extensions*
+
+|Additional Standard unprivileged extensions "abc" |Zabc |
+
+3+|*Standard Supervisor-Level Extensions*
+
+|Supervisor-level extension "def" |Ssdef |
+
+3+|*Standard Hypervisor-Level Extensions*
+
+|Hypervisor-level extension "ghi" |Shghi |
+
+3+|*Standard Machine-Level Extensions*
+
+|Machine-level extension "jkl" |Smjkl |
+
+3+|*Non-Standard Extensions*
+
+|Non-standard extension "mno" |Xmno |
+|===
diff --git a/src/naming.tex b/src/naming.tex
deleted file mode 100644
index 97e24c1..0000000
--- a/src/naming.tex
+++ /dev/null
@@ -1,161 +0,0 @@
-\chapter{ISA Subset Naming Conventions}
-\label{naming}
-
-This chapter describes the RISC-V ISA subset naming scheme that is
-used to concisely describe the set of instructions present in a
-hardware implementation, or the set of instructions used by an
-application binary interface (ABI).
-
-\begin{commentary}
-The RISC-V ISA is designed to support a wide variety of
-implementations with various experimental instruction-set extensions.
-We have found that an organized naming scheme simplifies software
-tools and documentation.
-\end{commentary}
-
-\section{Case Sensitivity}
-
-The ISA naming strings are case insensitive.
-
-\section{Base Integer ISA}
-RISC-V ISA strings begin with either RV32I, RV32E, RV64I, or RV128I
-indicating the supported address space size in bits for the base
-integer ISA.
-
-\section{Instruction-Set Extension Names}
-
-Standard ISA extensions are given a name consisting of a single
-letter. For example, the first four standard
-extensions to the integer bases are:
-``M'' for integer multiplication and division,
-``A'' for atomic memory instructions,
-``F'' for single-precision floating-point instructions, and
-``D'' for double-precision floating-point instructions.
-Any RISC-V instruction-set variant can be succinctly described by
-concatenating the base integer prefix with the names of the included
-extensions. For example, ``RV64IMAFD''.
-
-We have also defined an abbreviation ``G'' to represent the ``IMAFD''
-base and extensions, as this is intended to represent our standard
-general-purpose ISA.
-
-Standard extensions to the RISC-V ISA are given other reserved
-letters, e.g., ``Q'' for quad-precision floating-point, or
-``C'' for the 16-bit compressed instruction format.
-
-\section{Version Numbers}
-Recognizing that instruction sets may expand or alter over time, we
-encode subset version numbers following the subset name. Version
-numbers are divided into major and minor version numbers, separated by
-a ``p''. If the minor version is ``0'', then ``p0'' can be omitted
-from the version string. Changes in major version numbers imply a
-loss of backwards compatibility, whereas changes in only the minor
-version number must be backwards-compatible. For example, the
-original 64-bit standard ISA defined in release 1.0 of this manual can
-be written in full as ``RV64I1p0M1p0A1p0F1p0D1p0'', more concisely as
-``RV64I1M1A1F1D1'', or even more concisely as ``RV64G1''. The G ISA
-subset can be written as ``RV64I2p0M2p0A2p0F2p0D2p0'', or more
-concisely ``RV64G2''.
-
-We introduced the version numbering scheme with the second release,
-which we also intend to become a permanent standard. Hence, we define
-the default version of a standard subset to be that present at the
-time of this document, e.g., ``RV32G'' is equivalent to
-``RV32I2M2A2F2D2''.
-
-\section{Underscores}
-
-Underscores ``\_'' may be used to separate ISA subset components to
-improve readability and to provide disambiguation. For example, ``RV32I2\_M2\_A2\_F2\_D2''.
-
-\section{Additional Standard Extension Names}
-
-Standard extensions can also be named using a single ``Z'' followed by a name
-beginning with a letter and an optional version number. For example,
-``Zifencei'' names the instruction-fetch fence extension described in
-Chapter~\ref{chap:zifencei}; ``Zifencei2'' and ``Zifencei2p0'' name version
-2.0 of same.
-
-Extensions with the ``Z'' prefix must be separated
-from other multi-letter extensions by an underscore, e.g.,
-``RV32IMACZifencei\_Zicsr''.
-
-\section{Non-Standard Extension Names}
-
-Non-standard subsets are named using a single ``X'' followed by a name
-beginning with a letter and an optional version number.
-For example, ``Xhwacha'' names the Hwacha vector-fetch ISA extension;
-``Xhwacha2'' and ``Xhwacha2p0'' name version 2.0 of same.
-
-Non-standard extensions must be separated from other multi-letter extensions
-by an underscore. For example, an ISA with non-standard extensions
-Argle and Bargle may be named ``RV64IZifencei\_Xargle\_Xbargle''.
-
-\section{Supervisor-level Instruction-Set Extensions}
-Standard supervisor instruction-set extensions are defined in Volume II, but
-are named using ``S'' as a prefix, followed by a supervisor subset name
-beginning with a letter and an optional version number.
-
-Supervisor extensions must be separated from other multi-letter extensions
-by an underscore.
-
-\section{Supervisor-level Extensions}
-Non-standard extensions to the supervisor-level ISA are defined using
-the ``SX'' prefix.
-
-\section{Subset Naming Convention}
-Table~\ref{isanametable} summarizes the standardized subset names.
-~\\
-\begin{table}[h]
-\center
-\begin{tabular}{|l|c|}
-\hline
-Subset & Name \\
-\hline
-\hline
-\multicolumn{2}{|c|}{Standard General-Purpose ISA}\\
-\hline
-Integer & I \\
-Integer Multiplication and Division & M \\
-Atomics & A \\
-Single-Precision Floating-Point & F \\
-Double-Precision Floating-Point & D \\
-\hline
-General & G = IMAFD \\
-\hline
-\multicolumn{2}{|c|}{Standard Unprivileged Extensions}\\
-\hline
-Quad-Precision Floating-Point & Q \\
-Decimal Floating-Point & L \\
-16-bit Compressed Instructions & C \\
-Bit Manipulation & B \\
-Dynamic Languages & J \\
-Transactional Memory & T \\
-Packed-SIMD Extensions & P \\
-Vector Extensions & V \\
-User-Level Interrupts & N \\
-\hline
-\hline
-\multicolumn{2}{|c|}{Non-Standard Unprivileged Extensions}\\
-\hline
-Non-standard extension ``abc'' & Xabc \\
-\hline
-\hline
-\multicolumn{2}{|c|}{Standard Supervisor-Level ISA}\\
-\hline
-Supervisor extension ``def'' & Sdef \\
-\hline
-\hline
-\multicolumn{2}{|c|}{Non-Standard Supervisor-Level Extensions}\\
-\hline
-Supervisor extension ``ghi'' & SXghi \\
-\hline
-\end{tabular}
-\caption{Standard ISA subset names. The table also defines the
- canonical order in which subset names must appear in the name
- string, with top-to-bottom in table indicating first-to-last in the
- name string, e.g., RV32IMAFDQC is legal, whereas RV32IMAFDCQ is not.}
-\label{isanametable}
-\end{table}
-
-
diff --git a/src/opcode-map.tex b/src/opcode-map.tex
deleted file mode 100644
index a3224c1..0000000
--- a/src/opcode-map.tex
+++ /dev/null
@@ -1,22 +0,0 @@
-\vspace{0.1in}
-\definecolor{gray}{RGB}{180,180,180}
-\begin{table*}[htbp]
-\begin{center}
-{\footnotesize
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{|r|c|c|c|c|c|c|c|c|}
- \hline
- inst[4:2] & 000 & 001 & 010 & 011 & 100 & 101 & 110 & \cellcolor{gray}111 \\ \cline{1-1}
- inst[6:5] & & & & & & & & \cellcolor{gray}($>32b$) \\ \hline
- 00 & LOAD & LOAD-FP & {\em custom-0} & MISC-MEM & OP-IMM & AUIPC & OP-IMM-32 & \cellcolor{gray} $48b$\\ \hline
- 01 & STORE & STORE-FP & {\em custom-1} & AMO & OP & LUI & OP-32 & \cellcolor{gray} $64b$ \\ \hline
- 10 & MADD & MSUB & NMSUB & NMADD & OP-FP & {\em reserved} & {\em custom-2/rv128} & \cellcolor{gray} $48b$\\ \hline
- 11 & BRANCH & JALR & {\em reserved} & JAL & SYSTEM & {\em reserved} & {\em custom-3/rv128} & \cellcolor{gray} $\geq80b$\\ \hline
-
- \end{tabular}
-}
-\end{center}
-\vspace{-0.15in}
-\caption{RISC-V base opcode map, inst[1:0]=11}
-\label{opcodemap}
-\end{table*}
diff --git a/src/p.tex b/src/p.tex
deleted file mode 100644
index b360294..0000000
--- a/src/p.tex
+++ /dev/null
@@ -1,101 +0,0 @@
-\chapter{``P'' Standard Extension for Packed-SIMD Instructions,
- Version 0.1}
-\label{sec:packedsimd}
-
-\begin{commentary}
- Discussions at the 5th RISC-V workshop indicated a desire to drop
- this packed-SIMD proposal for floating-point registers in favor of
- standardizing on the V extension for large floating-point SIMD
- operations. However, there was interest in packed-SIMD fixed-point
- operations for use in the integer registers of small RISC-V
- implementations.
-\end{commentary}
-
-In this chapter, we outline a standard packed-SIMD extension for
-RISC-V. We've reserved the instruction subset name ``P'' for a future
-standard set of packed-SIMD extensions. Many other extensions can
-build upon a packed-SIMD extension, taking advantage of the wide data
-registers and datapaths separate from the integer unit.
-
-\begin{commentary}
-Packed-SIMD extensions, first introduced with the Lincoln Labs TX-2~\cite{tx2},
-have become a popular way to provide higher throughput on data-parallel
-codes. Earlier commercial microprocessor implementations include the
-Intel i860, HP PA-RISC MAX~\cite{lee-max-ieeemicro1996}, SPARC
-VIS~\cite{tremblay-vis-ieeemicro1996}, MIPS
-MDMX~\cite{gwennap-mdmx-mpr1996}, PowerPC
-AltiVec~\cite{diefendorff-altivec-ieeemicro2000}, Intel x86
-MMX/SSE~\cite{peleg-mmx-ieeemicro1996, raman-sse-ieeemicro2000}, while
-recent designs include Intel x86 AVX~\cite{lomont-avx-irm2011} and ARM
-Neon~\cite{goodacre-armisa-computer2005}. We describe a standard
-framework for adding packed-SIMD in this chapter, but are not actively
-working on such a design. In our opinion, packed-SIMD designs represent
-a reasonable design point when reusing existing wide datapath resources,
-but if significant additional resources are to be devoted to
-data-parallel execution then designs based on traditional vector
-architectures are a better choice and should use the V extension.
-
-\end{commentary}
-
-A RISC-V packed-SIMD extension reuses the floating-point registers
-({\tt f0}-{\tt f31}). These registers can be defined to have widths
-of FLEN=32 to FLEN=1024. The standard floating-point instruction
-subsets require registers of width 32 bits (``F''), 64 bits (``D''),
-or 128 bits (``Q'').
-
-\begin{commentary}
-It is natural to use the floating-point registers for packed-SIMD
-values rather than the integer registers (PA-RISC and Alpha
-packed-SIMD extensions) as this frees the integer registers for
-control and address values, simplifies reuse of scalar floating-point
-units for SIMD floating-point execution, and leads naturally to a
-decoupled integer/floating-point hardware design. The floating-point
-load and store instruction encodings also have space to handle wider
-packed-SIMD registers. However, reusing the floating-point registers
-for packed-SIMD values does make it more difficult to use a recoded
-internal format for floating-point values.
-\end{commentary}
-
-The existing floating-point load and store instructions are used to
-load and store various-sized words from memory to the {\tt f}
-registers. The base ISA supports 32-bit and 64-bit loads and stores,
-but the LOAD-FP and STORE-FP instruction encodings allows 8 different
-widths to be encoded as shown in Table~\ref{psimdwidth}. When used
-with packed-SIMD operations, it is desirable to support non-naturally
-aligned loads and stores in hardware.
-
-\begin{table}[htp]
-\begin{center}
-\begin{tabular}{|c|l|r|}
-\hline
-{\em width} field &
-Code &
-Size in bits\\
-\hline
-000 & B & 8 \\
-001 & H & 16 \\
-010 & W & 32 \\
-011 & D & 64 \\
-100 & Q & 128 \\
-101 & Q2 & 256 \\
-110 & Q4 & 512 \\
-111 & Q8 & 1024 \\
-\hline
-\end{tabular}
-\end{center}
-\caption{LOAD-FP and STORE-FP width encoding.}
-\label{psimdwidth}
-\end{table}
-
-Packed-SIMD computational instructions operate on packed values in
-{\tt f} registers. Each value can be 8-bit, 16-bit, 32-bit, 64-bit,
-or 128-bit, and both integer and floating-point representations can be
-supported. For example, a 64-bit packed-SIMD extension can treat each
-register as 1$\times$64-bit, 2$\times$32-bit, 4$\times$16-bit, or
-8$\times$8-bit packed values.
-
-\begin{commentary}
-Simple packed-SIMD extensions might fit in unused 32-bit instruction
-opcodes, but more extensive packed-SIMD extensions will likely require
-a dedicated 30-bit instruction space.
-\end{commentary}
diff --git a/src/plic.tex b/src/plic.tex
deleted file mode 100644
index f976e49..0000000
--- a/src/plic.tex
+++ /dev/null
@@ -1,427 +0,0 @@
-\chapter{Platform-Level Interrupt Controller (PLIC)}
-\label{plic}
-
-This chapter describes the general architecture for the RISC-V
-platform-level interrupt controller (PLIC), which prioritizes and
-distributes global interrupts in a RISC-V system.
-
-\section{PLIC Overview}
-
-Figure~\ref{fig:plic} provides a quick overview of PLIC operation.
-The PLIC connects global {\em interrupt sources}, which are usually
-I/O devices, to {\em interrupt targets}, which are usually {\em hart
- contexts}. The PLIC contains multiple {\em interrupt gateways}, one
-per interrupt source, together with a {\em PLIC core} that performs
-interrupt prioritization and routing. Global interrupts are sent from
-their source to an {\em interrupt gateway} that processes the
-interrupt signal from each source and sends a single {\em interrupt
- request} to the PLIC core, which latches these in the core interrupt
-pending bits (IP). Each interrupt source is assigned a separate
-priority. The PLIC core contains a matrix of interrupt enable (IE)
-bits to select the interrupts that are enabled for each target. The
-PLIC core forwards an {\em interrupt notification} to one or more
-targets if the targets have any pending interrupts enabled, and the
-priority of the pending interrupts exceeds a per-target threshold.
-When the target takes the external interrupt, it sends an {\em
- interrupt claim} request to retrieve the identifier of the
-highest-priority global interrupt source pending for that target from
-the PLIC core, which then clears the corresponding interrupt source
-pending bit. After the target has serviced the interrupt, it sends
-the associated interrupt gateway an {\em interrupt completion} message
-and the interrupt gateway can now forward another interrupt request
-for the same source to the PLIC. The rest of this chapter describes
-each of these components in detail, though many details are
-necessarily platform specific.
-
-\begin{figure}[tb]
-\centering
-\includegraphics[width=\textwidth]{figs/PLIC-block-diagram.pdf}
-\caption{Platform-Level Interrupt Controller (PLIC) conceptual block
- diagram. The figure shows the first two of potentially many
- interrupt sources, and the first two of potentially many interrupt
- targets. The figure is just intended to show the logic of the
- PLIC's operation, not to represent a realistic implementation
- strategy.}
-\label{fig:plic}
-\end{figure}
-
-\section{Interrupt Sources}
-
-RISC-V harts can have both local and global interrupt sources. Only
-global interrupt sources are handled by the PLIC.
-
-\subsection{Local Interrupt Sources}
-
-Each hart has a number of {\em local interrupt sources} that do not
-pass through the PLIC, including the standard software interrupts and
-timer interrupts for each privilege level. Local interrupts can be
-serviced quickly since there will be minimal latency between the
-source and the servicing hart, no arbitration is required to determine
-which hart will service the request, and the servicing hart can
-quickly determine the interrupt source using the {\tt mcause}
-register.
-
-All local interrupts follow a level-based model, where an interrupt is
-pending if the corresponding bit in {\tt mip} is set. The interrupt
-handler must clear the hardware condition that is causing the {\tt
- mip} bit to be set to avoid retaking the interrupt after re-enabling
-interrupts on exit from the interrupt handler.
-
-Additional non-standard local interrupt sources can be made visible to
-machine-mode by adding them to the high bits of the {\tt mip}/{\tt
- mie} registers, with corresponding additional cause values returned
-in the {\tt mcause} register. These additional non-standard local
-interrupts may also be made visible to lower privilege levels, using
-the corresponding bits in the {\tt mideleg} register. The priority of
-non-standard local interrupt sources relative to external, timer, and
-software interrupts is platform-specific.
-
-\subsection{Global Interrupt Sources}
-
-{\em Global interrupt sources} are those that are prioritized and
-distributed by the PLIC. Depending on the platform-specific PLIC
-implementation, any global interrupt source could be routed to any
-hart context.
-
-Global interrupt sources can take many forms, including
-level-triggered, edge-triggered, and message-signalled. Some sources
-might queue up a number of interrupt requests. All global interrupt
-sources are converted to a common interrupt request format for the
-PLIC.
-
-\section{Interrupt Targets and Hart Contexts}
-
-Interrupt targets are usually hart contexts, where a hart context is a
-given privilege mode on a given hart (though there are other possible
-interrupt targets, such as DMA engines). Not all hart contexts need
-be interrupt targets, in particular, if a processor core does not
-support delegating external interrupts to lower-privilege modes, then
-the lower-privilege hart contexts will not be interrupt targets.
-Interrupt notifications generated by the PLIC appear in the {\tt
- meip}/{\tt seip}/{\tt ueip} bits of the {\tt mip}/{\tt sip}/{\tt
- uip} registers for M/S/U modes, respectively. For the notifications
-to appear in lower-privilege {\em x}{\tt ip} registers, the corresponding
-external interrupts must have been delegated in the higher-privilege
-{\em y}{\tt ideleg} registers.
-
-Each processor core must define a policy on how simultaneous active
-interrupts are taken by multiple hart contexts on the core. For the
-simple case of a single stack of hart contexts, one for each supported
-privileged mode, interrupts for higher-privilege contexts can preempt
-execution of interrupt handlers for lower-privilege contexts. A
-multithreaded processor core could run multiple independent interrupt
-handlers on different hart contexts at the same time. A processor
-core could also provide hart contexts that are only used for interrupt
-handling to reduce interrupt service latency, and these might preempt
-interrupt handlers for other harts on the same core.
-
-The PLIC treats each interrupt target independently and does not take
-into account any interrupt prioritization scheme used by a component
-that contains multiple interrupt targets. As a result, the PLIC
-provides no concept of interrupt preemption or nesting so this must be
-handled by the cores hosting multiple interrupt target contexts.
-
-\section{Interrupt Gateways}
-
-The interrupt gateways are responsible for converting global interrupt
-signals into a common interrupt request format, and for controlling
-the flow of interrupt requests to the PLIC core. At most one
-interrupt request per interrupt source can be pending in the PLIC core
-at any time, indicated by setting the source's IP bit. The gateway
-only forwards a new interrupt request to the PLIC core after receiving
-notification that the interrupt handler servicing the previous
-interrupt request from the same source has completed.
-
-If the global interrupt source uses level-sensitive interrupts, the
-gateway will convert the first assertion of the interrupt level into
-an interrupt request, but thereafter the gateway will not forward an
-additional interrupt request until it receives an interrupt completion
-message. On receiving an interrupt completion message, if the
-interrupt is level-triggered and the interrupt is still asserted, a
-new interrupt request will be forwarded to the PLIC core. The gateway
-does not have the facility to retract an interrupt request once
-forwarded to the PLIC core. If a level-sensitive interrupt source
-deasserts the interrupt after the PLIC core accepts the request and
-before the interrupt is serviced, the interrupt request remains
-present in the IP bit of the PLIC core and will be serviced by a
-handler, which will then have to determine that the interrupt device
-no longer requires service.
-
-If the global interrupt source was edge-triggered, the gateway will
-convert the first matching signal edge into an interrupt request.
-Depending on the design of the device and the interrupt handler,
-between sending an interrupt request and receiving notice of its
-handler's completion, the gateway might either ignore additional
-matching edges or increment a counter of pending interrupts. In
-either case, the next interrupt request will not be forwarded to the
-PLIC core until the previous completion message has been received. If
-the gateway has a pending interrupt counter, the counter will be
-decremented when the interrupt request is accepted by the PLIC core.
-
-Unlike dedicated-wire interrupt signals, message-signalled interrupts
-(MSIs) are sent over the system interconnect via a message packet that
-describes which interrupt is being asserted. The message is decoded
-to select an interrupt gateway, and the relevant gateway then handles
-the MSI similar to an edge-triggered interrupt.
-
-\section{Interrupt Identifiers (IDs)}
-
-Global interrupt sources are assigned small unsigned integer
-identifiers, beginning at the value 1. An interrupt ID of 0 is
-reserved to mean ``no interrupt''.
-
-Interrupt identifiers are also used to break ties when two or more
-interrupt sources have the same assigned priority. Smaller values of
-interrupt ID take precedence over larger values of interrupt ID.
-
-\section{Interrupt Priorities}
-
-Interrupt priorities are small unsigned integers, with a
-platform-specific maximum number of supported levels. The priority
-value 0 is reserved to mean ``never interrupt'', and interrupt
-priority increases with increasing integer values.
-
-Each global interrupt source has an associated interrupt priority held
-in a platform-specific memory-mapped register. Different interrupt
-sources need not support the same set of priority values. A valid
-implementation can hardwire all input priority levels. Interrupt
-source priority registers should be \warl\ fields to allow software to
-determine the number and position of read-write bits in each priority
-specification, if any. To simplify discovery of supported priority
-values, each priority register must support any combination of values
-in the bits that are variable within the register, i.e., if there are
-two variable bits in the register, all four combinations of values in
-those bits must operate as valid priority levels.
-
-\begin{commentary}
- In the degenerate case, all priorities can be hardwired to the value
- 1, in which case input priorities are effectively determined by
- interrupt ID.
-
- The supported priority values can be determined as follows: 1) write
- all zeros to the priority register then 2) read back the value. Any
- set bits are hardwired to 1. Next, 3) write all ones to the
- register, and 4) read back the value. Any clear bits are hardwired
- to 0. Any set bits that were not found to be hardwired in step 2 are
- variable. The supported priority levels are the set of values
- obtained by substituting all combinations of ones and zeros in the
- variable bits within the priority field.
-\end{commentary}
-
-\section{Interrupt Enables}
-
-Each target has a vector of interrupt enable (IE) bits, one per
-interrupt source. The target will not receive interrupts from sources
-that are disabled. The IE bits for a single target should be packed
-together as a bit vector in platform-specific memory-mapped control
-registers to support rapid context switching of the IE bits for a
-target. IE bits are \warl\ fields that can be hardwired to either 0
-or 1.
-
-\begin{commentary}
-A large number of potential IE bits might be hardwired to zero in
-cases where some interrupt sources can only be routed to
-a subset of targets.
-
-A larger number of bits might be wired to 1 for an embedded device
-with fixed interrupt routing. Interrupt priorities, thresholds, and
-hart-internal interrupt masking provide considerable flexibility in
-ignoring external interrupts even if a global interrupt source is
-always enabled.
-\end{commentary}
-
-\section{Interrupt Priority Thresholds}
-
-Each interrupt target has an associated priority threshold, held in a
-platform-specific memory-mapped register. Only active interrupts that
-have a priority strictly greater than the threshold will cause a
-interrupt notification to be sent to the target. Different interrupt
-targets need not support the same set of priority threshold values.
-Interrupt target threshold registers should be \warl\ fields to allow
-software to determine the supported thresholds. A threshold register
-should always be able to hold the value zero, in which case, no
-interrupts are masked. If implemented, the threshold register will
-usually also be able to hold the maximum priority level, in which case
-all interrupts are masked.
-
-\begin{commentary}
-A simple valid implementation is to hardwire the threshold to zero, in
-which case it has no effect, and the individual enable bits will have
-to be saved and restored to attain the same effect. While the
-function of the threshold can be achieved by changing the
-interrupt-enable bits, manipulating a single threshold value avoids
-the target having to consider the individual priority levels of each
-interrupt source, and saving and restoring all the interrupt enables.
-Changing the threshold quickly might be especially important for
-systems that move frequently between power states.
-\end{commentary}
-
-\section{Interrupt Notifications}
-
-Each interrupt target has an {\em external interrupt pending} (EIP)
-bit in the PLIC core that indicates that the corresponding target has
-a pending interrupt waiting for service. The value in EIP can change
-as a result of changes to state in the PLIC core, brought on by
-interrupt sources, interrupt targets, or other agents manipulating
-register values in the PLIC. The value in EIP is communicated to the
-destination target as an interrupt notification. If the target is a
-RISC-V hart context, the interrupt notifications arrive on the {\tt
- meip}/{\tt seip}/{\tt ueip} bits depending on the
-privilege level of the hart context.
-
-\begin{commentary}
-In simple systems, the interrupt notifications will be simple wires
-connected to the processor implementing a hart. In more complex
-platforms, the notifications might be routed as messages across a
-system interconnect.
-\end{commentary}
-
-The PLIC hardware only supports multicasting of interrupts, such that
-all enabled targets will receive interrupt notifications for a given
-active interrupt.
-
-\begin{commentary}
-Multicasting provides rapid response since the fastest responder
-claims the interrupt, but can be wasteful in high-interrupt-rate
-scenarios if multiple harts take a trap for an interrupt that only one
-can successfully claim. Software can modulate the PLIC IE bits as
-part of each interrupt handler to provide alternate policies, such as
-interrupt affinity or round-robin unicasting.
-\end{commentary}
-
-Depending on the platform architecture and the method used to
-transport interrupt notifications, these might take some time to be
-received at the targets. The PLIC is guaranteed to eventually deliver
-all state changes in EIP to all targets, provided there is no
-intervening activity in the PLIC core.
-
-\begin{commentary}
-The value in an interrupt notification is only guaranteed to hold an
-EIP value that was valid at some point in the past. In particular, a
-second target can respond and claim an interrupt while a notification
-to the first target is still in flight, such that when the first
-target tries to claim the interrupt it finds it has no active
-interrupts in the PLIC core.
-\end{commentary}
-
-\section{Interrupt Claims}
-
-Sometime after a target receives an interrupt notification, it might
-decide to service the interrupt. The target sends an {\em interrupt
- claim} message to the PLIC core, which will usually be implemented
-as a non-idempotent memory-mapped I/O control register read. On
-receiving a claim message, the PLIC core will atomically determine the
-ID of the highest-priority pending interrupt for the target and then
-clear down the corresponding source's IP bit. The PLIC core will then
-return the ID to the target. The PLIC core will return an ID of zero,
-if there were no pending interrupts for the target when the claim was
-serviced.
-
-After the highest-priority pending interrupt is claimed by a target
-and the corresponding IP bit is cleared, other lower-priority pending
-interrupts might then become visible to the target, and so the PLIC
-EIP bit might not be cleared after a claim. The interrupt handler
-can check the local {\tt meip}/{\tt seip}/{\tt ueip} bits
-before exiting the handler, to allow more efficient service of other
-interrupts without first restoring the interrupted context and taking
-another interrupt trap.
-
-It is always legal for a hart to perform a claim even if the EIP is
-not set. In particular, a hart could set the threshold value to maximum
-to disable interrupt notifications and instead poll for active
-interrupts using periodic claim requests, though a simpler approach to
-implement polling would be to clear the external interrupt enable in
-the corresponding {\em x}{\tt ie} register for privilege mode {\em x}.
-
-\section{Interrupt Completion}
-
-After a handler has completed service of an interrupt, the associated
-gateway must be sent an interrupt completion message, usually as a
-write to a non-idempotent memory-mapped I/O control register. The
-gateway will only forward additional interrupts to the PLIC core after
-receiving the completion message.
-
-\section{Interrupt Flow}
-
-Figure~\ref{fig:intflow} shows the messages flowing between agents
-when handling interrupts via the PLIC.
-
-\begin{figure}[hb!]
-\centering
-\includegraphics[width=4.0in]{figs/PLIC-interrupt-flow.pdf}
-\caption{ Flow of interrupt processing via the PLIC.}
-\label{fig:intflow}
-\end{figure}
-
-The gateway will only forward a single interrupt request at a time to
-the PLIC, and not forward subsequent interrupts requests until an
-interrupt completion is received. The PLIC will set the IP bit once
-it accepts an interrupt request from the gateway, and sometime later
-forward an interrupt notification to the target. The target might
-take a while to respond to a new interrupt arriving, but will then
-send an interrupt claim request to the PLIC core to obtain the
-interrupt ID. The PLIC core will atomically return the ID and clear
-the corresponding IP bit, after which no other target can claim the
-same interrupt request. Once the handler has processed the interrupt,
-it sends an interrupt completion message to the gateway to allow a new
-interrupt request.
-
-\section{PLIC Core Specification}
-
-The operation of the PLIC core can be specified as a non-deterministic
-finite-state machine with input and output message queues, with the
-following atomic actions:
-
-\begin{itemize}
-
-\item {\bf Write Register: } A message containing a register write
- request is dequeued. One of the internal registers is written,
- where an internal register can be a priority, an interrupt-enable
- (IE), or a threshold.
-
-\item {\bf Accept Request: } If the IP bit corresponding to the
- interrupt source is clear, a message containing an interrupt request
- from a gateway is dequeued and the IP bit is set.
-
-\item {\bf Process Claim: } An interrupt claim message is dequeued. A
- claim-response message is enqueued to the requester with the ID of
- the highest-priority active interrupt for that target, and the IP
- bit corresponding to this interrupt source is cleared.
-
-\end{itemize}
-
-The value in the EIP bit is determined as a combinational function of
-the PLIC Core state. Interrupt notifications are sent via an
-autonomous process that ensures the EIP value is eventually reflected
-at the target.
-
-Note that the operation of the interrupt gateways is decoupled from
-the PLIC core. A gateway can handle parsing of interrupt signals and
-processing interrupt completion messages concurrently with other
-operations in the PLIC core.
-
-\begin{commentary}
-Figure~\ref{fig:plic} is a high-level conceptual view of the PLIC
-design. The PLIC core can be implemented in many ways provided its
-behavior can always be understood as following from some sequential
-ordering of these atomic actions. In particular, the PLIC might
-process multiple actions in a single clock cycle, or might process
-each action over many clock cycles.
-\end{commentary}
-
-\section{Controlling Access to the PLIC}
-
-In the expected use case, only machine mode accesses the source
-priority, source pending, and target interrupt enables to configure
-the interrupt subsystem. Lower-privilege modes access these features
-via ABI or SBI calls. The interrupt enables act as a protection
-mechanism where a target can only signal completion to an interrupt
-gateway that is currently enabled for that target.
-
-Interrupt handlers that run with lower than machine-mode privilege
-need only be able to perform a claim read and a completion write, and
-to set their target threshold value. The memory map for these
-registers should allow machine mode to protect different targets from
-each other's accesses, using either physical memory protection or
-virtual memory page protections.
-
diff --git a/src/preamble.tex b/src/preamble.tex
deleted file mode 100644
index cb66be4..0000000
--- a/src/preamble.tex
+++ /dev/null
@@ -1,139 +0,0 @@
-% Package includes
-
-\usepackage{graphicx}
-\usepackage{geometry}
-\usepackage{array}
-\usepackage{colortbl}
-\usepackage[svgnames]{xcolor}
-
-\usepackage[colorlinks,citecolor=Navy,linkcolor=Navy]{hyperref}
-\usepackage{placeins}
-\usepackage{longtable}
-\usepackage{multirow}
-\usepackage{float}
-\usepackage{listings}
-\usepackage{comment}
-\usepackage{enumitem}
-\usepackage{verbatimbox}
-
-\usepackage[olditem,oldenum]{paralist}
-
-% Setup margins
-
-\setlength{\topmargin}{-0.5in}
-\setlength{\textheight}{9in}
-\setlength{\oddsidemargin}{0in}
-\setlength{\evensidemargin}{0in}
-\setlength{\textwidth}{6.5in}
-
-% Useful macros
-
-\newcommand{\note}[1]{{\bf [ NOTE: #1 ]}}
-\newcommand{\fixme}[1]{{\bf [ FIXME: #1 ]}}
-\newcommand{\todo}[1]{\marginpar{\footnotesize #1}}
-
-\newcommand{\wunits}[2]{\mbox{#1\,#2}}
-\newcommand{\um}{\mbox{$\mu$m}}
-\newcommand{\xum}[1]{\wunits{#1}{\um}}
-\newcommand{\by}[2]{\mbox{#1$\times$#2}}
-\newcommand{\byby}[3]{\mbox{#1$\times$#2$\times$#3}}
-
-\newlength\savedwidth
-\newcommand\whline[1]{%
- \noalign{%
- \global\savedwidth\arrayrulewidth\global\arrayrulewidth 1.5pt%
- }%
- \cline{#1}%
- \noalign{\vskip\arrayrulewidth}%
- \noalign{\global\arrayrulewidth\savedwidth}%
-}
-
-% Custom list environments
-
-\newlist{tightlist}{itemize}{1}
-\setlist[tightlist]{label=\textbullet,nosep}
-
-\newenvironment{titledtightlist}[1]
-{\noindent
- ~~\textbf{#1}
- \begin{tightlist}}
-{\end{tightlist}}
-
-\newenvironment{commentary}
-{ \vspace{-0.2in}
- \begin{quotation}
- \noindent
- \small \em
- \rule{\linewidth}{1pt}\\
-}
-{
- \end{quotation}
- \vspace{-0.2in}
-}
-
-
-\newenvironment{samepage-commentary}
-{\begin{samepage} \begin{commentary}}
-{\end{commentary} \end{samepage}}
-
-\newenvironment{discussion}
-{ \vspace{-0.2in}
- \begin{quotation}
- \noindent
- \small \em
- \rule{\linewidth}{1pt} \\
- {\bf Discussion:}
-}
-{
- \end{quotation}
- \vspace{-0.2in}
-}
-
-% Other commands and parameters
-
-\pagestyle{myheadings}
-\setlength{\parindent}{0in}
-\setlength{\parskip}{10pt}
-\sloppy
-
-% Commands for register format figures.
-
-% New column types to use in tabular environment for instruction formats.
-% Allocate 0.18in per bit.
-\newcolumntype{I}{>{\centering\arraybackslash}p{0.18in}}
-% Two-bit centered column.
-\newcolumntype{W}{>{\centering\arraybackslash}p{0.36in}}
-% Three-bit centered column.
-\newcolumntype{F}{>{\centering\arraybackslash}p{0.54in}}
-% Four-bit centered column.
-\newcolumntype{Y}{>{\centering\arraybackslash}p{0.72in}}
-% Five-bit centered column.
-\newcolumntype{R}{>{\centering\arraybackslash}p{0.9in}}
-% Six-bit centered column.
-\newcolumntype{S}{>{\centering\arraybackslash}p{1.08in}}
-% Seven-bit centered column.
-\newcolumntype{O}{>{\centering\arraybackslash}p{1.26in}}
-% Eight-bit centered column.
-\newcolumntype{E}{>{\centering\arraybackslash}p{1.44in}}
-% Ten-bit centered column.
-\newcolumntype{T}{>{\centering\arraybackslash}p{1.8in}}
-% Twelve-bit centered column.
-\newcolumntype{M}{>{\centering\arraybackslash}p{2.2in}}
-% Sixteen-bit centered column.
-\newcolumntype{K}{>{\centering\arraybackslash}p{2.88in}}
-% Twenty-bit centered column.
-\newcolumntype{U}{>{\centering\arraybackslash}p{3.6in}}
-% Twenty-bit centered column.
-\newcolumntype{L}{>{\centering\arraybackslash}p{3.6in}}
-% Twenty-five-bit centered column.
-\newcolumntype{J}{>{\centering\arraybackslash}p{4.5in}}
-
-\newcommand{\instbit}[1]{\mbox{\scriptsize #1}}
-\newcommand{\instbitrange}[2]{~\instbit{#1} \hfill \instbit{#2}~}
-\newcommand{\reglabel}[1]{\hfill {\tt #1}\hfill\ }
-
-\newcommand{\wiri}{\textbf{WIRI}}
-\newcommand{\wpri}{\textbf{WPRI}}
-\newcommand{\wlrl}{\textbf{WLRL}}
-\newcommand{\warl}{\textbf{WARL}}
-
diff --git a/src/preface.tex b/src/preface.tex
deleted file mode 100644
index 69615b0..0000000
--- a/src/preface.tex
+++ /dev/null
@@ -1,291 +0,0 @@
-\chapter{Preface}
-
-This document describes the RISC-V unprivileged architecture. This
-release \specrev\ will be used in ratifying the base and standard
-extensions described below.
-
-The RISC-V RVWMO memory model has been ratified at this time. The ISA
-modules marked {\bf Ratification} are scheduled for ratification with
-this release of the specification. The modules marked {\em Frozen}
-are not expected to change before being put up for ratification. The
-modules marked {\em Draft} are expected to change before ratification.
-
-The document contains the following versions of the RISC-V ISA
-modules:
-
-{
-\begin{table}[hbt]
- \centering
- \begin{tabular}{|c|l|c|}
- \hline
- Base & Version & Status\\
- \hline
- RVWMO & 2.0 & Ratified \\
- \bf RV32I & \bf 2.1 & \bf Ratification \\
- \bf RV64I & \bf 2.1 & \bf Ratification \\
- \em RV32E & \em 1.9 & \em Draft \\
- \em RV128I & \em 1.7 & \em Draft \\
- \hline
- Extension & Version & Status \\
- \hline
- \bf Zifencei & \bf 2.0 & \bf Ratification \\
- \bf Zicsr & \bf 2.0 & \bf Ratification \\
- \bf M & \bf 2.0 & \bf Ratification \\
- \bf A & \bf 2.0 & \bf Ratification \\
- \bf F & \bf 2.2 & \bf Ratification \\
- \bf D & \bf 2.2 & \bf Ratification \\
- \bf Q & \bf 2.2 & \bf Ratification \\
- \bf C & \bf 2.0 & \bf Ratification \\
- \em Ztso & \em 0.1 & \em Frozen \\
- \em Counters & \em 2.0 & \em Draft \\
- \em L & \em 0.0 & \em Draft \\
- \em B & \em 0.0 & \em Draft \\
- \em J & \em 0.0 & \em Draft \\
- \em T & \em 0.0 & \em Draft \\
- \em P & \em 0.1 & \em Draft \\
- \em V & \em 0.4 & \em Draft \\
- \em N & \em 1.1 & \em Draft \\
- \em Zam & \em 0.1 & \em Draft \\
- \hline
- \end{tabular}
-\end{table}
-}
-
-The changes in this version of the document include:
-\vspace{-0.2in}
-\begin{itemize}
-\parskip 0pt
-\itemsep 1pt
-\item Changed document version scheme to avoid confusion with versions
- of the ISA modules.
-\item Incremented the version numbers of the base integer ISA to 2.1,
- reflecting the presence of the ratified RVWMO memory model and
- exclusion of FENCE.I, counters, and CSR instructions that were in
- previous base ISA.
-\item Incremented the version numbers of the F and D extensions to 2.2,
- reflecting that version 2.1 changed the canonical NaN, and version
- 2.2 defined the NaN-boxing scheme and changed the definition of the
- FMIN and FMAX instructions.
-\item Changed name of document to refer to ``unprivileged''
- instructions as part of move to separate ISA specifications from
- platform profile mandates.
-\item Added clearer and more precise definitions of execution
- environments, harts, traps, and memory accesses.
-\item Defined instruction-set categories: {\em standard}, {\em
- reserved}, {\em custom}, {\em non-standard}, and {\em
- non-conforming}.
-\item Removed text implying operation under alternate endianness, as
- alternate-endianness operation has not yet been defined for RISC-V.
-\item Changed description of misaligned load and store behavior. The
- specification now allows visible misaligned address traps in
- execution environment interfaces, rather than just mandating
- invisible handling of misaligned loads and stores in user mode.
- Also, now allows access exceptions to be reported for misaligned
- accesses (including atomics) that should not be emulated.
-\item Moved FENCE.I out of the mandatory base and into a separate extension,
- with Zifencei ISA name. FENCE.I was removed from the Linux user ABI and is
- problematic in implementations with large incoherent instruction and
- data caches. However, it remains the only standard
- instruction-fetch coherence mechanism.
-\item Removed prohibitions on using RV32E with other extensions.
-\item Removed platform-specific mandates that certain encodings
- produce illegal instruction exceptions in RV32E and RV64I chapters.
-\item Counter/timer instructions are now not considered part of the
- mandatory base ISA, and so CSR instructions were moved into separate
- chapter and marked as version 2.0, with the unprivileged counters
- moved into another separate chapter. The counters are not ready for
- ratification as there are outstanding issues, including counter
- inaccuracies, and effect of RDTIME with respect to the memory model
- ordering constraints.
-\item Explicitly defined the 16-bit half-precision floating-point
- format for floating-point instructions in the 2-bit {\em fmt field.}
-\item Defined the signed-zero behavior of FMIN.{\em fmt} and FMAX.{\em fmt},
- and changed their behavior on signaling-NaN inputs to conform to the
- minimumNumber and maximumNumber operations in the proposed IEEE 754-201x
- specification.
-\item The memory consistency model, RVWMO, has been defined.
-\item The ``Zam'' extension, which permits misaligned AMOs and specifies their semantics, has been defined.
-\item The ``Ztso'' extension, which enforces a stricter memory consistency model than RVWMO, has been defined.
-\item Improvements to the description and commentary.
-\item Defined the term IALIGN as shorthand to describe the instruction-address
- alignment constraint.
-\end{itemize}
-
-\section*{Preface to Document Version 2.2}
-
-This is version 2.2 of the document describing the RISC-V
-user-level architecture. The document contains the following
-versions of the RISC-V ISA modules:
-\begin{table}[hbt]
- \centering
- \begin{tabular}{|c|l|c|}
- \hline
- Base & \em Version & \em Draft Frozen? \\
- \hline
- RV32I & 2.0 & Y \\
- RV32E & 1.9 & N \\
- RV64I & 2.0 & Y \\
- RV128I & 1.7 & N \\
- \hline
- Extension & Version & Frozen? \\
- \hline
- M & 2.0 & Y \\
- A & 2.0 & Y \\
- F & 2.0 & Y \\
- D & 2.0 & Y \\
- Q & 2.0 & Y \\
- L & 0.0 & N \\
- C & 2.0 & Y \\
- B & 0.0 & N \\
- J & 0.0 & N \\
- T & 0.0 & N \\
- P & 0.1 & N \\
- V & 0.2 & N \\
- N & 1.1 & N \\
- \hline
- \end{tabular}
-\end{table}
-
-To date, no parts of the standard have been officially ratified by the
-RISC-V Foundation, but the components labeled ``frozen'' above are not
-expected to change during the ratification process beyond resolving
-ambiguities and holes in the specification.
-
-The major changes in this version of the document include:
-\begin{itemize}
-\parskip 0pt
-\itemsep 1pt
-\item The previous version of this document was released under a
- Creative Commons Attribution 4.0 International License by the
- original authors, and this and future versions of this document will
- be released under the same license.
-\item Rearranged chapters to put all extensions first in canonical order.
-\item Improvements to the description and commentary.
-\item Modified implicit hinting suggestion on JALR to support more efficient
- macro-op fusion of LUI/JALR and AUIPC/JALR pairs.
-\item Clarification of constraints on load-reserved/store-conditional sequences.
-\item A new table of control and status register (CSR) mappings.
-\item Clarified purpose and behavior of high-order bits of {\tt fcsr}.
-\item Corrected the description of the FNMADD.{\em fmt} and FNMSUB.{\em fmt}
- instructions, which had suggested the incorrect sign of a zero result.
-\item Instructions FMV.S.X and FMV.X.S were renamed to FMV.W.X and
- FMV.X.W respectively to be more consistent with their
- semantics, which did not change.
- The old names will continue to be supported in the tools.
-\item Specified behavior of narrower ($<$FLEN) floating-point values held in
- wider {\tt f} registers using NaN-boxing model.
-\item Defined the exception behavior of FMA($\infty$, 0, qNaN).
-\item Added note indicating that the P extension might be reworked
- into an integer packed-SIMD proposal for fixed-point operations
- using the integer registers.
-\item A draft proposal of the V vector instruction-set extension.
-\item An early draft proposal of the N user-level traps extension.
-\item An expanded pseudoinstruction listing.
-\item Removal of the calling convention chapter, which has been superseded by
- the RISC-V ELF psABI Specification~\cite{riscv-elf-psabi}.
-\item The C extension has been frozen and renumbered version 2.0.
-\end{itemize}
-
-\section*{Preface to Document Version 2.1}
-
-This is version 2.1 of the document describing the RISC-V user-level
-architecture. Note the frozen user-level ISA base and extensions
-IMAFDQ version 2.0 have not changed from the previous version of this
-document~\cite{riscvtr2}, but some specification holes have been fixed
-and the documentation has been improved. Some changes have been made
-to the software conventions.
-\begin{itemize}
-\parskip 0pt
-\itemsep 1pt
-\item Numerous additions and improvements to the commentary sections.
-\item Separate version numbers for each chapter.
-\item Modification to long instruction encodings $>$64 bits to avoid
- moving the {\em rd} specifier in very long instruction formats.
-\item CSR instructions are now described in the base integer format
- where the counter registers are introduced, as opposed to only being
- introduced later in the floating-point section (and the companion
- privileged architecture manual).
-\item The SCALL and SBREAK instructions have been renamed to ECALL and
- EBREAK, respectively. Their encoding and functionality are unchanged.
-\item Clarification of floating-point NaN handling, and a new canonical NaN
- value.
-\item Clarification of values returned by floating-point to integer
- conversions that overflow.
-\item Clarification of LR/SC allowed successes and required failures,
- including use of compressed instructions in the sequence.
-\item A new RV32E base ISA proposal for reduced integer register
- counts, supports MAC extensions.
-\item A revised calling convention.
-\item Relaxed stack alignment for soft-float calling convention, and
- description of the RV32E calling convention.
-\item A revised proposal for the C compressed extension, version 1.9.
-\end{itemize}
-
-\section*{Preface to Version 2.0}
-
-This is the second release of the user ISA specification, and we
-intend the specification of the base user ISA plus general extensions
-(i.e., IMAFD) to remain fixed for future development. The following
-changes have been made since Version 1.0~\cite{riscvtr} of this ISA
-specification.
-
-\vspace{-0.1in}
-\begin{itemize}
-\parskip 0pt
-\itemsep 1pt
-\item The ISA has been divided into an integer base with several
- standard extensions.
-\item The instruction formats have been rearranged to make immediate
- encoding more efficient.
-\item The base ISA has been defined to have a little-endian memory system, with
- big-endian or bi-endian as non-standard variants.
-\item Load-Reserved/Store-Conditional (LR/SC) instructions have been added in
- the atomic instruction extension.
-\item AMOs and LR/SC can support the release consistency model.
-\item The FENCE instruction provides finer-grain memory and I/O
- orderings.
-\item An AMO for fetch-and-XOR (AMOXOR) has been added, and the
- encoding for AMOSWAP has been changed to make room.
-\item The AUIPC instruction, which adds a 20-bit upper immediate to
- the PC, replaces the RDNPC instruction, which only read the current
- PC value. This results in significant savings for position-independent
- code.
-\item The JAL instruction has now moved to the U-Type format with an
- explicit destination register, and the J instruction has been
- dropped being replaced by JAL with {\em rd}={\tt x0}. This removes
- the only instruction with an implicit destination register and
- removes the J-Type instruction format from the base ISA. There is
- an accompanying reduction in JAL reach, but a significant reduction
- in base ISA complexity.
-\item The static hints on the JALR instruction have been dropped. The
- hints are redundant with the {\em rd} and {\em rs1} register
- specifiers for code compliant with the standard calling convention.
-\item The JALR instruction now clears the lowest bit of the calculated
- target address, to simplify hardware and to allow auxiliary information
- to be stored in function pointers.
-\item The MFTX.S and MFTX.D instructions have been renamed to FMV.X.S and
-FMV.X.D, respectively. Similarly, MXTF.S and MXTF.D instructions have been
-renamed to FMV.S.X and FMV.D.X, respectively.
-\item The MFFSR and MTFSR instructions have been renamed to FRCSR and FSCSR,
-respectively. FRRM, FSRM, FRFLAGS, and FSFLAGS instructions have been added
-to individually access the rounding mode and exception flags subfields of
-the {\tt fcsr}.
-\item The FMV.X.S and FMV.X.D instructions now source their operands
-from {\em rs1}, instead of {\em rs2}. This change simplifies datapath
-design.
-\item FCLASS.S and FCLASS.D floating-point classify instructions have been
-added.
-\item A simpler NaN generation and propagation scheme has been
- adopted.
-\item For RV32I, the system performance counters have been extended to
- 64-bits wide, with separate read access to the upper and lower 32 bits.
-\item Canonical NOP and MV encodings have been defined.
-\item Standard instruction-length encodings have been defined for 48-bit,
- 64-bit, and $>$64-bit instructions.
-\item Description of a 128-bit address space variant, RV128, has been added.
-\item Major opcodes in the 32-bit base instruction format have been
- allocated for user-defined custom extensions.
-\item A typographical error that suggested that stores source their
- data from {\em rd} has been corrected to refer to {\em rs2}.
-\end{itemize}
-\vspace{-0.1in}
diff --git a/src/priv-cfi.adoc b/src/priv-cfi.adoc
new file mode 100644
index 0000000..9ee4b4d
--- /dev/null
+++ b/src/priv-cfi.adoc
@@ -0,0 +1,365 @@
+[[priv-cfi]]
+== Control-flow Integrity (CFI)
+
+Control-flow Integrity (CFI) capabilities help defend against Return-Oriented
+Programming (ROP) and Call/Jump-Oriented Programming (COP/JOP) style
+control-flow subversion attacks. The Zicfiss and Zicfilp extensions provide
+backward-edge and forward-edge control flow integrity respectively. Please see
+the Control-flow Integrity chapter of the Unprivileged ISA specification for further
+details on these CFI capabilities and the associated Unprivileged ISA.
+
+[[priv-forward]]
+=== Landing Pad (Zicfilp)
+
+This section specifies the Privileged ISA for the Zicfilp extension.
+
+[[FCFIACT]]
+==== Landing-Pad-Enabled (LPE) State
+
+The term `xLPE` is used to determine if forward-edge CFI using landing pads
+provided by the Zicfilp extension is enabled at a privilege mode.
+
+When S-mode is implemented, it is determined as follows:
+
+.`xLPE` determination when S-mode is implemented
+[width=100%]
+[%header, cols="^4,^12"]
+|===
+|Privilege Mode| xLPE
+| M | `mseccfg.MLPE`
+| S or HS | `menvcfg.LPE`
+| VS | `henvcfg.LPE`
+| U or VU | `senvcfg.LPE`
+|===
+
+When S-mode is not implemented, it is determined as follows:
+
+.`xLPE` determination when S-mode is not implemented
+[width=100%]
+[%header, cols="^4,^12"]
+|===
+|Privilege Mode| xLPE
+| M | `mseccfg.MLPE`
+| U | `menvcfg.LPE`
+|===
+
+[NOTE]
+====
+The Zicfilp must be explicitly enabled for use at each privilege mode.
+
+Programs compiled with the `LPAD` instruction continue to function correctly,
+but without forward-edge CFI protection, when the Zicfilp extension is not
+implemented or is not enabled.
+====
+
+<<<
+
+[[ZICFILP_FORWARD_TRAPS]]
+==== Preserving Expected Landing Pad State on Traps
+
+A trap may need to be delivered to the same or to a higher privilege mode upon
+completion of `JALR`/`C.JALR`/`C.JR`, but before the instruction at the target
+of indirect call/jump was decoded, due to:
+
+* Asynchronous interrupts.
+* Synchronous exceptions with priority higher than that of a software-check
+ exception with `__x__tval` set to "landing pad fault (code=2)" (See
+ <<exception-priority>> of Privileged Specification).
+
+The software-check exception caused by Zicfilp has higher priority than an
+illegal-instruction exception but lower priority than instruction access-fault.
+
+The software-check exception due to the instruction not being an `LPAD`
+instruction when `ELP` is `LP_EXPECTED` or a software-check exception caused by
+the `LPAD` instruction itself leads to a trap being delivered
+to the same or to a higher privilege mode.
+
+In such cases, the `ELP` prior to the trap, the previous `ELP`, must be
+preserved by the trap delivery such that it can be restored on a return from the
+trap. To store the previous `ELP` state on trap delivery to M-mode, an `MPELP`
+bit is provided in the `mstatus` CSR. To store the previous `ELP` state on trap
+delivery to S/HS-mode, an `SPELP` bit is provided in the `mstatus` CSR. The
+`SPELP` bit in `mstatus` can be accessed through the `sstatus` CSR. To store
+the previous `ELP` state on traps to VS-mode, a `SPELP` bit is defined in the
+`vsstatus` (VS-modes version of `sstatus`). To store the previous `ELP` state on
+transition to Debug Mode, a `pelp` bit is defined in the `dcsr` register.
+
+When a trap is taken into privilege mode `x`, the `__x__PELP` is set to `ELP`
+and `ELP` is set to `NO_LP_EXPECTED`.
+
+An `MRET` or `SRET` instruction is used to return from a trap in M-mode or
+S-mode, respectively. When executing an `__x__RET` instruction, if the new
+privilege mode is `y`, then `ELP` is set to the value of `__x__PELP` if
+`__y__LPE` (see <<FCFIACT>>) is 1; otherwise, it is set to `NO_LP_EXPECTED`;
+`__x__PELP` is set to `NO_LP_EXPECTED`.
+
+Upon entry into Debug Mode, the `pelp` bit in `dcsr` is updated with the `ELP`
+at the privilege level the hart was previously in, and the `ELP` is set to
+`NO_LP_EXPECTED`. When a hart resumes from Debug Mode, if the new privilege mode
+is `y`, then `ELP` is set to the value of `pelp` if `__y__LPE` (see <<FCFIACT>>)
+is 1; otherwise, it is set to `NO_LP_EXPECTED`.
+
+See also <<rnmi>> for semantics added to the RNMI trap and the MNRET instruction
+when this extension is implemented.
+
+[NOTE]
+====
+The trap handler in privilege mode `x` must save the `__x__PELP` bit and the
+`x7` register before performing an indirect call/jump if `xLPE=1`. If the
+privilege mode `x` can respond to interrupts and `xLPE=1`, then the trap handler
+should also save these values before enabling interrupts.
+
+The trap handler in privilege mode `x` must restore the saved `__x__PELP` bit
+and the `x7` register before executing the `__x__RET` instruction to return from
+a trap.
+====
+
+<<<
+
+[[priv-backward]]
+=== Shadow Stack (Zicfiss)
+
+This section specifies the Privileged ISA for the Zicfiss extension.
+
+==== Shadow Stack Pointer (`ssp`) CSR access control
+
+Attempts to access the `ssp` CSR may result in either an illegal-instruction
+exception or a virtual-instruction exception, contingent upon the state of the
+*__x__*`envcfg.SSE` fields. The conditions are specified as follows:
+
+* If the privilege mode is less than M and `menvcfg.SSE` is 0, an
+ illegal-instruction exception is raised.
+* Otherwise, if in U-mode and `senvcfg.SSE` is 0, an illegal-instruction
+ exception is raised.
+* Otherwise, if in VS-mode and `henvcfg.SSE` is 0, a virtual-instruction
+ exception is raised.
+* Otherwise, if in VU-mode and either `henvcfg.SSE` or `senvcfg.SSE` is 0,
+ a virtual-instruction exception is raised.
+* Otherwise, the access is allowed.
+
+==== Shadow-Stack-Enabled (SSE) State
+
+The term `xSSE` is used to determine if backward-edge CFI using shadow stacks
+provided by the Zicfiss extension is enabled at a privilege mode.
+
+When S-mode is implemented, it is determined as follows:
+
+.`xSSE` determination when S-mode is implemented
+[width=100%]
+[%header, cols="^4,^12"]
+|===
+|Privilege Mode| `xSSE`
+| M | `0`
+| S or HS | `menvcfg.SSE`
+| VS | `henvcfg.SSE`
+| U or VU | `senvcfg.SSE`
+|===
+
+When S-mode is not implemented, then `xSSE` is 0 at both M and U privilege modes.
+
+[NOTE]
+====
+Activating Zicfiss in U-mode must be done explicitly per process. Not activating
+Zicfiss at U-mode for a process when that application is not compiled with
+Zicfiss allows it to invoke shared libraries that may contain Zicfiss
+instructions. The Zicfiss instructions in the shared library revert to their
+Zimop/Zcmop-defined behavior in this case.
+
+When Zicfiss is enabled in S-mode it is benign to use an operating system that is
+not compiled with Zicfiss instructions. Such an operating system that does
+not use backward-edge CFI for S-mode execution may still activate Zicfiss for
+U-mode applications.
+
+When programs that use Zicfiss instructions are installed on a processor that
+supports the Zicfiss extension but the extension is not enabled at the privilege
+mode where the program executes, the program continues to function correctly but
+without backward-edge CFI protection as the Zicfiss instructions will revert to
+their Zimop/Zcmop-defined behavior.
+
+When programs that use Zicfiss instructions are installed on a processor that
+does not support the Zicfiss extension but supports the Zimop and Zcmop
+extensions, the programs continues to function correctly but without
+backward-edge CFI protection as the Zicfiss instructions will revert to their
+Zimop/Zcmop-defined behavior.
+
+On processors that do not support Zimop/Zcmop extensions, all Zimop/Zcmop code
+points including those used for Zicfiss instructions may cause an
+illegal-instruction exception. Execution of programs that use these instructions
+on such machines is not supported.
+
+Activating Zicfiss in M-mode is currently not supported. Additionally, when
+S-mode is not implemented, activation in U-mode is also not supported. These
+functionalities may be introduced in a future standard extension.
+====
+
+NOTE: Changes to `xSSE` take effect immediately; address-translation caches
+need not be synchronized with SFENCE.VMA, HFENCE.GVMA, or HFENCE.VVMA
+instructions.
+
+
+[[SSMP]]
+==== Shadow Stack Memory Protection
+
+To protect shadow stack memory, the memory is associated with a new page type –
+the Shadow Stack (SS) page – in the single-stage and VS-stage page tables. The
+encoding `R=0`, `W=1`, and `X=0`, is defined to represent an SS page. When
+`menvcfg.SSE=0`, this encoding remains reserved. Similarly, when `V=1` and
+`henvcfg.SSE=0`, this encoding remains reserved at `VS` and `VU` levels.
+
+If `satp.MODE` (or `vsatp.MODE` when `V=1`) is set to `Bare` and the effective
+privilege mode is less than M, shadow stack instructions raise a store/AMO
+access-fault exception. When the effective privilege mode is M, memory access
+by an `SSAMOSWAP.W/D` instruction results in a store/AMO access-fault exception.
+
+Memory mapped as an SS page cannot be written to by instructions other than
+`SSAMOSWAP.W/D`, `SSPUSH`, and `C.SSPUSH`. Attempts will raise a store/AMO
+access-fault exception. Access to a SS page using _cache-block operation_
+(`CBO.*`) instructions is not permitted. Such accesses will raise a store/AMO
+access-fault exception. Implicit accesses, including instruction fetches to an
+SS page, are not permitted. Such accesses will raise an access-fault exception
+appropriate to the access type. However, the shadow stack is readable by all
+instructions that only load from memory.
+
+[NOTE]
+====
+Stores to shadow stack pages by instructions other than `SSAMOSWAP`, `SSPUSH`,
+and `C.SSPUSH` will trigger a store/AMO access-fault exception, not a store/AMO
+page-fault exception, signaling a fatal error. A store/AMO page-fault suggests
+that the operating system could address and rectify the fault, which is not
+feasible in this scenario. Hence, the page-fault handler must decode the opcode
+of the faulting instruction to discern whether the fault was caused by a
+non-shadow-stack instruction writing to an SS page (a fatal condition) or by a
+shadow stack instruction to a non-resident page (a recoverable condition). The
+performance-critical nature of operating system page fault handlers necessitates
+triggering an access fault instead of a page fault, allowing for a
+straightforward distinction between fatal conditions and recoverable faults.
+
+Operating systems must ensure that no writable, non-shadow-stack alias virtual
+address mappings exist for the physical memory backing the shadow stack.
+Furthermore, in systems where an address-misaligned exception supersedes the
+access-fault exception, handlers emulating misaligned stores must be designed to
+cause an access-fault exception when the store is directed to a shadow stack
+page.
+
+All instructions that perform load operations are allowed to read from the
+shadow stack. This feature facilitates debugging and performance profiling by
+allowing examination of the link register values backed up in the shadow stack.
+====
+
+[NOTE]
+====
+As of the drafting of this specification, instruction fetches are the sole type
+of implicit access subjected to single- or VS-stage address translation.
+====
+
+If a shadow stack (SS) instruction raises an access-fault, page-fault, or
+guest-page-fault exception that is supposed to indicate the original instruction
+type (load or store/AMO), then the reported exception cause is respectively a
+store/AMO access fault (code 7), a store/AMO page fault (code 15), or a
+store/AMO guest-page fault (code 23). For shadow stack instructions, the
+reported instruction type is always as though it were a store or AMO, even for
+instructions `SSPOPCHK` and `C.SSPOPCHK` that only read from memory and do not
+write to it.
+
+[NOTE]
+====
+When Zicfiss is implemented, the existing "store/AMO" exceptions can be thought
+of as "store/AMO/SS" exceptions, indicating that the trapping instruction is
+either a store, an AMO, or a shadow stack instruction.
+====
+
+Shadow stack instructions are restricted to accessing shadow stack
+(`pte.xwr=010b`) pages. Should a shadow stack instruction access a page that is
+not designated as a shadow stack page and is not marked as read-only
+(`pte.xwr=001`), a store/AMO access-fault exception will be invoked. Conversely,
+if the page being accessed by a shadow stack instruction is a read-only page, a
+store/AMO page-fault exception will be triggered.
+
+
+[NOTE]
+====
+Shadow stack loads and stores will trigger a store/AMO page-fault if the
+accessed page is read-only, to support copy-on-write (COW) of a shadow stack
+page. If the page has been marked read-only for COW tracking, the page-fault
+handler responds by creating a copy of the page and updates the `pte.xwr` to
+`010b`, thereby designating each copy as a shadow stack page. Conversely, if
+the access targets a genuinely read-only page, the fault being reported as a
+store/AMO page-fault signals to the operating system that the fault is fatal
+and non-recoverable. Reporting the fault as a store/AMO page-fault, even for
+`SSPOPCHK` initiated memory access, aids in the determination of fatality; if
+these were reported as load page-faults, access to a truly read-only page
+might be mistakenly treated as a recoverable fault, leading to the faulting
+instruction being retried indefinitely. The PTE does not provide a read-only
+shadow stack encoding.
+
+Attempts by shadow stack instructions to access pages marked as read-write,
+read-write-execute, read-execute, or execute-only result in a store/AMO
+access-fault exception, similarly indicating a fatal condition.
+
+Shadow stacks should be bounded at each end by guard pages to prevent accidental
+underflows or overflows from one shadow stack into another. Conventionally, a
+guard page for a stack is a page that is not accessible by the process that owns
+the stack.
+====
+
+<<<
+
+If the virtual address in `ssp` is not `XLEN` aligned, then the `SSPUSH`/
+`C.SSPUSH`/`SSPOPCHK`/`C.SSPOPCHK` instructions cause a store/AMO access-fault
+exception.
+
+[NOTE]
+====
+Misaligned accesses to shadow stack are not required and enforcing alignment is
+more secure to detect errors in the program. An access-fault exception is raised
+instead of address-misaligned exception in such cases to indicate fatality and
+that the instruction must not be emulated by a trap handler.
+====
+
+Correct execution of shadow stack instructions that access memory requires the
+the accessed memory to be idempotent. If the memory referenced by
+`SSPUSH`/`C.SSPUSH`/`SSPOPCHK`/`C.SSPOPCHK`/`SSAMOSWAP.W/D` instructions is not
+idempotent, then the instructions cause a store/AMO access-fault exception.
+
+[NOTE]
+====
+The `SSPOPCHK` instruction performs a load followed by a check of the loaded
+data value with the link register as source. If the check against the link
+register faults, and the instruction is restarted by the trap handler, then the
+instruction will perform a load again. If the memory from which the load is
+performed is non-idempotent, then the second load may cause unexpected side
+effects. Shadow stack instructions that access the shadow stack require the
+memory referenced by `ssp` to be idempotent to avoid such concerns. Locating
+shadow stacks in non-idempotent memory, such as non-idempotent device memory,
+is not an expected usage, and requiring memory referenced to be idempotent
+does not pose a significant restriction.
+====
+
+The `U` and `SUM` bit enforcement is performed normally for shadow stack
+instruction initiated memory accesses. The state of the `MXR` bit does not
+affect read access to a shadow stack page as the shadow stack page is always
+readable by all instructions that load from memory.
+
+The G-stage address translation and protections remain unaffected by the Zicfiss
+extension. The `xwr == 010b` encoding in the G-stage PTE remains reserved. When
+G-stage page tables are active, the shadow stack instructions that access memory
+require the G-stage page table to have read-write permission for the accessed
+memory; else a store/AMO guest-page-fault exception is raised.
+
+[NOTE]
+====
+A future extension may define a shadow stack encoding in the G-stage page table
+to support use cases such as a hypervisor enforcing shadow stack protections for
+its guests.
+====
+
+Svpbmt and Svnapot extensions are supported for shadow stack pages.
+
+The PMA checks are extended to require memory referenced by shadow stack
+instructions to be idempotent. The PMP checks are extended to require read-write
+permission for memory accessed by shadow stack instructions. If the PMP does not
+provide read-write permissions or if the accessed memory is not idempotent then
+a store/AMO access-fault exception is raised.
+
+The `SSAMOSWAP.W/D` instructions require the PMA of the accessed memory range to
+provide AMOSwap level support.
diff --git a/src/priv-csrs.adoc b/src/priv-csrs.adoc
new file mode 100644
index 0000000..3fe8daf
--- /dev/null
+++ b/src/priv-csrs.adoc
@@ -0,0 +1,1267 @@
+[[priv-csrs]]
+== Control and Status Registers (CSRs)
+
+The SYSTEM major opcode is used to encode all privileged instructions in
+the RISC-V ISA. These can be divided into two main classes: those that
+atomically read-modify-write control and status registers (CSRs), which
+are defined in the Zicsr extension, and all other privileged
+instructions. The privileged architecture requires the Zicsr extension;
+which other privileged instructions are required depends on the
+privileged-architecture feature set.
+
+In addition to the unprivileged state described in Volume I of this
+manual, an implementation may contain additional CSRs, accessible by
+some subset of the privilege levels using the CSR instructions described
+in Volume I. In this chapter, we map out the CSR address space. The
+following chapters describe the function of each of the CSRs according
+to privilege level, as well as the other privileged instructions which
+are generally closely associated with a particular privilege level. Note
+that although CSRs and instructions are associated with one privilege
+level, they are also accessible at all higher privilege levels.
+
+Standard CSRs do not have side effects on reads but may have side
+effects on writes.
+
+=== CSR Address Mapping Conventions
+
+The standard RISC-V ISA sets aside a 12-bit encoding space (csr[11:0])
+for up to 4,096 CSRs. By convention, the upper 4 bits of the CSR address
+(csr[11:8]) are used to encode the read and write accessibility of the
+CSRs according to privilege level as shown in <<csrrwpriv>>. The top two bits (csr[11:10]) indicate whether the register is read/write (`00`,`01`, or `10`) or read-only (`11`). The next two bits (csr[9:8]) encode the lowest privilege level that can access the CSR.
+
+[NOTE]
+====
+The CSR address convention uses the upper bits of the CSR address to
+encode default access privileges. This simplifies error checking in the
+hardware and provides a larger CSR space, but does constrain the mapping
+of CSRs into the address space.
+
+Implementations might allow a more-privileged level to trap otherwise
+permitted CSR accesses by a less-privileged level to allow these
+accesses to be intercepted. This change should be transparent to the
+less-privileged software.
+====
+
+Instructions that access a non-existent CSR are reserved.
+Attempts to access a CSR without appropriate privilege level
+raise illegal-instruction exceptions or, as described in
+<<sec:hcauses>>, virtual-instruction exceptions.
+Attempts to write a read-only register raise illegal-instruction exceptions.
+A read/write register might also contain some bits that are
+read-only, in which case writes to the read-only bits are ignored.
+
+<<csrrwpriv>> also indicates the convention to
+allocate CSR addresses between standard and custom uses. The CSR
+addresses designated for custom uses will not be redefined by future
+standard extensions.
+
+Machine-mode standard read-write CSRs `0x7A0`-`0x7BF` are reserved for
+use by the debug system. Of these CSRs, `0x7A0`-`0x7AF` are accessible
+to machine mode, whereas `0x7B0`-`0x7BF` are only visible to debug mode.
+Implementations should raise illegal-instruction exceptions on
+machine-mode access to the latter set of registers.
+
+[NOTE]
+====
+Effective virtualization requires that as many instructions run natively
+as possible inside a virtualized environment, while any privileged
+accesses trap to the virtual machine monitor. cite:[goldbergvm] CSRs that are read-only
+at some lower privilege level are shadowed into separate CSR addresses
+if they are made read-write at a higher privilege level. This avoids
+trapping permitted lower-privilege accesses while still causing traps on
+illegal accesses. Currently, the counters are the only shadowed CSRs.
+====
+
+=== CSR Listing
+
+<<ucsrnames>>-<<mcsrnames1>> list the CSRs that
+have currently been allocated CSR addresses. The timers, counters, and
+floating-point CSRs are standard unprivileged CSRs. The other registers
+are used by privileged code, as described in the following chapters.
+Note that not all registers are required on all implementations.
+
+[[csrrwpriv]]
+.Allocation of RISC-V CSR address ranges.
+[%autowidth,float="center",align="center",cols="^,^,^,^,<,<,<,<"]
+[.monofont]
+|===
+3+^|CSR Address 2.2+|Hex 3.2+|Use and Accessibility
+|[11:10] |[9:8] |[7:4]
+8+|Unprivileged and User-Level CSRs
+m|00 m|00 m|XXXX 2+m| 0x000-0x0FF 3+|Standard read/write
+|`01` |`00` |`XXXX` 2+| `0x400-0x4FF` 3+|Standard read/write
+|`10` |`00` |`XXXX` 2+| `0x800-0x8FF` 3+|Custom read/write
+|`11` |`00` |`0XXX` 2+| `0xC00-0xC7F` 3+|Standard read-only
+|`11` |`00` |`10XX` 2+| `0xC80-0xCBF` 3+|Standard read-only
+|`11` |`00` |`11XX` 2+| `0xCC0-0xCFF` 3+|Custom read-only
+8+|Supervisor-Level CSRs
+|`00` |`01` |`XXXX` 2+| `0x100-0x1FF` 3+|Standard read/write
+|`01` |`01` |`0XXX` 2+| `0x500-0x57F` 3+|Standard read/write
+|`01` |`01` |`10XX` 2+| `0x580-0x5BF` 3+|Standard read/write
+|`01` |`01` |`11XX` 2+| `0x5C0-0x5FF` 3+|Custom read/write
+|`10` |`01` |`0XXX` 2+| `0x900-0x97F` 3+|Standard read/write
+|`10` |`01` |`10XX` 2+| `0x980-0x9BF` 3+|Standard read/write
+|`10` |`01` |`11XX` 2+| `0x9C0-0x9FF` 3+|Custom read/write
+|`11` |`01` |`0XXX` 2+| `0xD00-0xD7F` 3+|Standard read-only
+|`11` |`01` |`10XX` 2+| `0xD80-0xDBF` 3+|Standard read-only
+|`11` |`01` |`11XX` 2+| `0xDC0-0xDFF` 3+|Custom read-only
+8+|Hypervisor and VS CSRs
+|`00` |`10` |`XXXX` 2+| `0x200-0x2FF` 3+|Standard read/write
+|`01` |`10` |`0XXX` 2+| `0x600-0x67F` 3+|Standard read/write
+|`01` |`10` |`10XX` 2+| `0x680-0x6BF` 3+|Standard read/write
+|`01` |`10` |`11XX` 2+| `0x6C0-0x6FF` 3+|Custom read/write
+|`10` |`10` |`0XXX` 2+| `0xA00-0xA7F` 3+|Standard read/write
+|`10` |`10` |`10XX` 2+| `0xA80-0xABF` 3+|Standard read/write
+|`10` |`10` |`11XX` 2+| `0xAC0-0xAFF` 3+|Custom read/write
+|`11` |`10` |`0XXX` 2+| `0xE00-0xE7F` 3+|Standard read-only
+|`11` |`10` |`10XX` 2+| `0xE80-0xEBF` 3+|Standard read-only
+|`11` |`10` |`11XX` 2+| `0xEC0-0xEFF` 3+|Custom read-only
+8+|Machine-Level CSRs
+|`00` |`11` |`XXXX` 2+|`0x300-0x3FF` 3+|Standard read/write
+|`01` |`11` |`0XXX` 2+|`0x700-0x77F` 3+|Standard read/write
+|`01` |`11` |`100X` 2+|`0x780-0x79F` 3+|Standard read/write
+|`01` |`11` |`1010` 2+|`0x7A0-0x7AF` 3+|Standard read/write debug CSRs
+|`01` |`11` |`1011` 2+|`0x7B0-0x7BF` 3+|Debug-mode-only CSRs
+|`01` |`11` |`11XX` 2+|`0x7C0-0x7FF` 3+|Custom read/write
+|`10` |`11` |`0XXX` 2+|`0xB00-0xB7F` 3+|Standard read/write
+|`10` |`11` |`10XX` 2+|`0xB80-0xBBF` 3+|Standard read/write
+|`10` |`11` |`11XX` 2+|`0xBC0-0xBFF` 3+|Custom read/write
+|`11` |`11` |`0XXX` 2+|`0xF00-0xF7F` 3+|Standard read-only
+|`11` |`11` |`10XX` 2+|`0xF80-0xFBF` 3+|Standard read-only
+|`11` |`11` |`11XX` 2+|`0xFC0-0xFFF` 3+|Custom read-only
+|===
+
+<<<
+
+[[ucsrnames]]
+.Currently allocated RISC-V unprivileged CSR addresses.
+[float="center",align="center",cols="<10%,<10%,<20%,<60%",options="header"]
+|===
+|Number |Privilege |Name |Description
+4+^|Unprivileged Floating-Point CSRs
+
+|`0x001` +
+`0x002` +
+`0x003`
+|URW +
+URW +
+URW
+|`fflags` +
+`frm` +
+`fcsr`
+|Floating-Point Accrued Exceptions. +
+Floating-Point Dynamic Rounding Mode. +
+Floating-Point Control and Status Register (`frm` +`fflags`).
+
+4+^|Unprivileged Vector CSRs
+
+|`0x008` +
+`0x009` +
+`0x00A` +
+`0x00F` +
+`0xC20` +
+`0xC21` +
+`0xC22`
+|URW +
+URW +
+URW +
+URW +
+URO +
+URO +
+URO
+|`vstart` +
+`vxsat` +
+`vxrm` +
+`vcsr` +
+`vl` +
+`vtype` +
+`vlenb`
+|Vector start position. +
+Fixed-point accrued saturation flag. +
+Fixed-point rounding mode. +
+Vector control and status register. +
+Vector length. +
+Vector data type register. +
+Vector register length in bytes.
+
+4+^|Unprivileged Zicfiss extension CSR
+|`0x011` +
+|URW +
+|`ssp` +
+|Shadow Stack Pointer. +
+
+4+^|Unprivileged Entropy Source Extension CSR
+|`0x015` +
+|URW +
+|`seed` +
+|Seed for cryptographic random bit generators. +
+
+4+^|Unprivileged Zcmt Extension CSR
+|`0x017` +
+|URW +
+|`jvt` +
+|Table jump base vector and control register. +
+
+4+^|Unprivileged Counter/Timers
+
+|`0xC00` +
+`0xC01` +
+`0xC02` +
+`0xC03` +
+`0xC04` +
+ &#160; +
+`0xC1F` +
+`0xC80` +
+`0xC81` +
+`0xC82` +
+`0xC83` +
+`0xC84` +
+&#160; +
+`0xC9F`
+|URO +
+URO +
+URO +
+URO +
+URO +
+&#160; +
+URO +
+URO +
+URO +
+URO +
+URO +
+URO +
+&#160; +
+URO
+|`cycle` +
+`time` +
+`instret` +
+`hpmcounter3` +
+`hpmcounter4` +
+&#8942; +
+`hpmcounter31` +
+`cycleh` +
+`timeh` +
+`instreth` +
+`hpmcounter3h` +
+`hpmcounter4h` +
+&#8942; +
+`hpmcounter31h`
+|Cycle counter for RDCYCLE instruction. +
+Timer for RDTIME instruction. +
+Instructions-retired counter for RDINSTRET instruction. +
+Performance-monitoring counter. +
+Performance-monitoring counter. +
+&#160; +
+Performance-monitoring counter. +
+Upper 32 bits of `cycle`, RV32 only. +
+Upper 32 bits of `time`, RV32 only. +
+Upper 32 bits of `instret`, RV32 only. +
+Upper 32 bits of `hpmcounter3`, RV32 only. +
+Upper 32 bits of `hpmcounter4`, RV32 only. +
+&#160; +
+Upper 32 bits of `hpmcounter31`, RV32 only.
+|===
+
+<<<
+
+[[scsrnames]]
+.Currently allocated RISC-V supervisor-level CSR addresses.
+[%autowidth,float="center",align="center",cols="<,<,<,<",options="header"]
+|===
+|Number |Privilege |Name |Description
+4+^|Supervisor Trap Setup
+
+|`0x100` +
+`0x104` +
+`0x105` +
+`0x106`
+|SRW +
+SRW +
+SRW +
+SRW
+|`sstatus` +
+`sie` +
+`stvec` +
+`scounteren`
+|Supervisor status register. +
+Supervisor interrupt-enable register. +
+Supervisor trap handler base address. +
+Supervisor counter enable.
+
+4+^|Supervisor Configuration
+
+|`0x10A` |SRW |`senvcfg` |Supervisor environment configuration register.
+
+4+^|Supervisor Counter Setup
+
+|`0x120` |SRW |`scountinhibit` |Supervisor counter-inhibit register.
+
+4+^|Supervisor Trap Handling
+
+|`0x140` +
+`0x141` +
+`0x142` +
+`0x143` +
+`0x144` +
+`0xDA0`
+|SRW +
+SRW +
+SRW +
+SRW +
+SRW +
+SRO
+|`sscratch` +
+`sepc` +
+`scause` +
+`stval` +
+`sip` +
+`scountovf`
+|Supervisor scratch register. +
+Supervisor exception program counter. +
+Supervisor trap cause. +
+Supervisor trap value. +
+Supervisor interrupt pending. +
+Supervisor count overflow.
+
+4+^|Supervisor Indirect
+
+|`0x150` +
+`0x151` +
+`0x152` +
+`0x153` +
+`0x155` +
+`0x156` +
+`0x157`
+|SRW +
+SRW +
+SRW +
+SRW +
+SRW +
+SRW +
+SRW
+|`siselect` +
+`sireg` +
+`sireg2` +
+`sireg3` +
+`sireg4` +
+`sireg5` +
+`sireg6`
+|Supervisor indirect register select. +
+Supervisor indirect register alias. +
+Supervisor indirect register alias 2. +
+Supervisor indirect register alias 3. +
+Supervisor indirect register alias 4. +
+Supervisor indirect register alias 5. +
+Supervisor indirect register alias 6.
+
+4+^|Supervisor Protection and Translation
+
+|`0x180` |SRW |`satp` |Supervisor address translation and protection.
+
+4+^|Supervisor Timer Compare
+
+|`0x14D` +
+`0x15D`
+|SRW +
+SRW
+|`stimecmp` +
+`stimecmph`
+|Supervisor timer compare. +
+Upper 32 bits of `stimecmp`, RV32 only.
+
+4+^|Debug/Trace Registers
+
+|`0x5A8` |SRW |`scontext` |Supervisor-mode context register.
+
+4+^|Supervisor Resource Management Configuration
+|`0x181` |SRW |`srmcfg` |Supervisor Resource Management Configuration.
+
+4+^|Supervisor State Enable Registers
+|`0x10C` +
+ `0x10D` +
+ `0x10E` +
+ `0x10F`
+|SRW +
+ SRW +
+ SRW +
+ SRW
+|`sstateen0` +
+ `sstateen1` +
+ `sstateen2` +
+ `sstateen3`
+|Supervisor State Enable 0 Register. +
+ Supervisor State Enable 1 Register. +
+ Supervisor State Enable 2 Register. +
+ Supervisor State Enable 3 Register.
+
+4+^|Supervisor Control Transfer Records Configuration
+|`0x14E` +
+ `0x14F` +
+ `0x15F`
+|SRW +
+ SRW +
+ SRW
+|`sctrctl` +
+ `sctrstatus` +
+ `sctrdepth`
+|Supervisor Control Transfer Records Control Register. +
+ Supervisor Control Transfer Records Status Register. +
+ Supervisor Control Transfer Records Depth Register.
+
+|===
+
+<<<
+
+[[hcsrnames]]
+.Currently allocated RISC-V hypervisor and VS CSR addresses.
+[%autowidth,float="center",align="center",cols="<,<,<,<",options="header"]
+|===
+|Number |Privilege |Name |Description
+4+^|Hypervisor Trap Setup
+
+|`0x600` +
+`0x602` +
+`0x603` +
+`0x604` +
+`0x606` +
+`0x607` +
+`0x612`
+|HRW +
+HRW +
+HRW +
+HRW +
+HRW +
+HRW +
+HRW
+|`hstatus` +
+`hedeleg` +
+`hideleg` +
+`hie` +
+`hcounteren` +
+`hgeie` +
+`hedelegh`
+|Hypervisor status register. +
+Hypervisor exception delegation register. +
+Hypervisor interrupt delegation register. +
+Hypervisor interrupt-enable register. +
+Hypervisor counter enable. +
+Hypervisor guest external interrupt-enable register. +
+Upper 32 bits of `hedeleg`, RV32 only.
+
+4+^|Hypervisor Trap Handling
+
+|`0x643` +
+`0x644` +
+`0x645` +
+`0x64A` +
+`0xE12`
+|HRW +
+HRW +
+HRW +
+HRW +
+HRO
+|`htval` +
+`hip` +
+`hvip` +
+`htinst` +
+`hgeip`
+|Hypervisor trap value. +
+Hypervisor interrupt pending. +
+Hypervisor virtual interrupt pending. +
+Hypervisor trap instruction (transformed). +
+Hypervisor guest external interrupt pending.
+
+4+^|Hypervisor Configuration
+
+|`0x60A` +
+`0x61A`
+|HRW +
+HRW
+|`henvcfg` +
+`henvcfgh`
+|Hypervisor environment configuration register. +
+Upper 32 bits of `henvcfg`, RV32 only.
+
+4+^|Hypervisor Protection and Translation
+
+|`0x680` |HRW |`hgatp` |Hypervisor guest address translation and protection.
+
+4+^|Debug/Trace Registers
+
+|`0x6A8` |HRW |`hcontext` |Hypervisor-mode context register.
+
+4+^|Hypervisor Counter/Timer Virtualization Registers
+
+|`0x605` +
+`0x615`
+|HRW +
+HRW
+|`htimedelta` +
+`htimedeltah`
+|Delta for VS/VU-mode timer. +
+Upper 32 bits of `htimedelta`, RV32 only.
+
+4+^|Hypervisor State Enable Registers
+|`0x60C` +
+ `0x60D` +
+ `0x60E` +
+ `0x60F` +
+ `0x61C` +
+ `0x61D` +
+ `0x61E` +
+ `0x61F`
+|HRW +
+ HRW +
+ HRW +
+ HRW +
+ HRW +
+ HRW +
+ HRW +
+ HRW
+|`hstateen0` +
+ `hstateen1` +
+ `hstateen2` +
+ `hstateen3` +
+ `hstateen0h` +
+ `hstateen1h` +
+ `hstateen2h` +
+ `hstateen3h`
+|Hypervisor State Enable 0 Register. +
+ Hypervisor State Enable 1 Register. +
+ Hypervisor State Enable 2 Register. +
+ Hypervisor State Enable 3 Register. +
+ Upper 32 bits of Hypervisor State Enable 0 Register, RV32 only. +
+ Upper 32 bits of Hypervisor State Enable 1 Register, RV32 only. +
+ Upper 32 bits of Hypervisor State Enable 2 Register, RV32 only. +
+ Upper 32 bits of Hypervisor State Enable 3 Register, RV32 only.
+
+4+^|Virtual Supervisor Registers
+
+|`0x200` +
+`0x204` +
+`0x205` +
+`0x240` +
+`0x241` +
+`0x242` +
+`0x243` +
+`0x244` +
+`0x280`
+|HRW +
+HRW +
+HRW +
+HRW +
+HRW +
+HRW +
+HRW +
+HRW +
+HRW
+|`vsstatus` +
+`vsie` +
+`vstvec` +
+`vsscratch` +
+`vsepc` +
+`vscause` +
+`vstval` +
+`vsip` +
+`vsatp`
+|Virtual supervisor status register. +
+Virtual supervisor interrupt-enable register. +
+Virtual supervisor trap handler base address. +
+Virtual supervisor scratch register. +
+Virtual supervisor exception program counter. +
+Virtual supervisor trap cause. +
+Virtual supervisor trap value. +
+Virtual supervisor interrupt pending. +
+Virtual supervisor address translation and protection.
+
+4+^|Virtual Supervisor Indirect
+
+|`0x250` +
+`0x251` +
+`0x252` +
+`0x253` +
+`0x255` +
+`0x256` +
+`0x257`
+|HRW +
+HRW +
+HRW +
+HRW +
+HRW +
+HRW +
+HRW
+|`vsiselect` +
+`vsireg` +
+`vsireg2` +
+`vsireg3` +
+`vsireg4` +
+`vsireg5` +
+`vsireg6`
+|Virtual supervisor indirect register select. +
+Virtual supervisor indirect register alias. +
+Virtual supervisor indirect register alias 2. +
+Virtual supervisor indirect register alias 3. +
+Virtual supervisor indirect register alias 4. +
+Virtual supervisor indirect register alias 5. +
+Virtual supervisor indirect register alias 6.
+
+4+^|Virtual Supervisor Timer Compare
+
+|`0x24D` +
+`0x25D`
+|HRW +
+HRW
+|`vstimecmp` +
+`vstimecmph`
+|Virtual supervisor timer compare. +
+Upper 32 bits of `vstimecmp`, RV32 only.
+
+4+^|Virtual Supervisor Control Transfer Records Configuration
+|`0x24E`
+|HRW
+|`vsctrctl`
+|Virtual Supervisor Control Transfer Records Control Register.
+
+|===
+
+<<<
+
+[[mcsrnames0]]
+[.monocell]
+.Currently allocated RISC-V machine-level CSR addresses.
+[%autowidth,float="center",align="center",cols="<,<,<,<",options="header"]
+|===
+|Number |Privilege |Name |Description
+4+^|Machine Information Registers
+
+|`0xF11` +
+`0xF12` +
+`0xF13` +
+`0xF14` +
+`0xF15`
+|MRO +
+MRO +
+MRO +
+MRO +
+MRO
+|`mvendorid` +
+`marchid` +
+`mimpid` +
+`mhartid` +
+`mconfigptr`
+|Vendor ID. +
+Architecture ID. +
+Implementation ID. +
+Hardware thread ID. +
+Pointer to configuration data structure.
+
+4+^|Machine Trap Setup
+
+|`0x300` +
+`0x301` +
+`0x302` +
+`0x303` +
+`0x304` +
+`0x305` +
+`0x306` +
+`0x310` +
+`0x312`
+|MRW +
+MRW +
+MRW +
+MRW +
+MRW +
+MRW +
+MRW +
+MRW +
+MRW
+|`mstatus` +
+`misa` +
+`medeleg` +
+`mideleg` +
+`mie` +
+`mtvec` +
+`mcounteren` +
+`mstatush` +
+`medelegh`
+|Machine status register. +
+ISA and extensions +
+Machine exception delegation register. +
+Machine interrupt delegation register. +
+Machine interrupt-enable register. +
+Machine trap-handler base address. +
+Machine counter enable. +
+Additional machine status register, RV32 only. +
+Upper 32 bits of `medeleg`, RV32 only.
+
+4+^|Machine Counter Configuration
+
+|`0x321` +
+`0x322` +
+`0x721` +
+`0x722`
+|MRW +
+MRW +
+MRW +
+MRW
+|`mcyclecfg` +
+`minstretcfg` +
+`mcyclecfgh` +
+`minstretcfgh`
+|Machine cycle counter configuration register. +
+Machine instret counter configuration register. +
+Upper 32 bits of `mcyclecfg`, RV32 only. +
+Upper 32 bits of `minstretcfg`, RV32 only.
+
+4+^|Machine Trap Handling
+
+|`0x340` +
+`0x341` +
+`0x342` +
+`0x343` +
+`0x344` +
+`0x34A` +
+`0x34B`
+|MRW +
+MRW +
+MRW +
+MRW +
+MRW +
+MRW +
+MRW
+|`mscratch` +
+`mepc` +
+`mcause` +
+`mtval` +
+`mip` +
+`mtinst` +
+`mtval2`
+|Machine scratch register. +
+Machine exception program counter. +
+Machine trap cause. +
+Machine trap value. +
+Machine interrupt pending. +
+Machine trap instruction (transformed). +
+Machine second trap value.
+
+4+^|Machine Indirect
+
+|`0x350` +
+`0x351` +
+`0x352` +
+`0x353` +
+`0x355` +
+`0x356` +
+`0x357`
+|MRW +
+MRW +
+MRW +
+MRW +
+MRW +
+MRW +
+MRW
+|`miselect` +
+`mireg` +
+`mireg2` +
+`mireg3` +
+`mireg4` +
+`mireg5` +
+`mireg6`
+|Machine indirect register select. +
+Machine indirect register alias. +
+Machine indirect register alias 2. +
+Machine indirect register alias 3. +
+Machine indirect register alias 4. +
+Machine indirect register alias 5. +
+Machine indirect register alias 6.
+
+4+^|Machine Configuration
+
+|`0x30A` +
+`0x31A` +
+`0x747` +
+`0x757`
+|MRW +
+MRW +
+MRW +
+MRW
+|`menvcfg` +
+`menvcfgh` +
+`mseccfg` +
+`mseccfgh`
+|Machine environment configuration register. +
+Upper 32 bits of `menvcfg`, RV32 only. +
+Machine security configuration register. +
+Upper 32 bits of `mseccfg`, RV32 only.
+
+4+^|Machine Memory Protection
+
+|`0x3A0` +
+`0x3A1` +
+`0x3A2` +
+`0x3A3` +
+&#160; +
+`0x3AE` +
+`0x3AF` +
+`0x3B0` +
+`0x3B1` +
+&#160; +
+`0x3EF`
+|MRW +
+MRW +
+MRW +
+MRW +
+&#160; +
+MRW +
+MRW +
+MRW +
+MRW +
+&#160; +
+MRW
+|`pmpcfg0` +
+`pmpcfg1` +
+`pmpcfg2` +
+`pmpcfg3` +
+&#8943; +
+`pmpcfg14` +
+`pmpcfg15` +
+`pmpaddr0` +
+`pmpaddr1` +
+&#8943; +
+`pmpaddr63`
+|Physical memory protection configuration. +
+Physical memory protection configuration, RV32 only. +
+Physical memory protection configuration. +
+Physical memory protection configuration, RV32 only. +
+&#160; +
+Physical memory protection configuration. +
+Physical memory protection configuration, RV32 only. +
+Physical memory protection address register. +
+Physical memory protection address register. +
+&#160; +
+Physical memory protection address register.
+
+4+^|Machine State Enable Registers
+|`0x30C` +
+ `0x30D` +
+ `0x30E` +
+ `0x30F` +
+ `0x31C` +
+ `0x31D` +
+ `0x31E` +
+ `0x31F`
+|MRW +
+ MRW +
+ MRW +
+ MRW +
+ MRW +
+ MRW +
+ MRW +
+ MRW
+|`mstateen0` +
+ `mstateen1` +
+ `mstateen2` +
+ `mstateen3` +
+ `mstateen0h` +
+ `mstateen1h` +
+ `mstateen2h` +
+ `mstateen3h`
+|Machine State Enable 0 Register. +
+ Machine State Enable 1 Register. +
+ Machine State Enable 2 Register. +
+ Machine State Enable 3 Register. +
+ Upper 32 bits of Machine State Enable 0 Register, RV32 only. +
+ Upper 32 bits of Machine State Enable 1 Register, RV32 only. +
+ Upper 32 bits of Machine State Enable 2 Register, RV32 only. +
+ Upper 32 bits of Machine State Enable 3 Register, RV32 only.
+|===
+
+<<<
+
+[[mcsrnames1]]
+.Currently allocated RISC-V machine-level CSR addresses.
+[%autowidth,float="center",align="center",cols="<,<,<,<",options="header"]
+|===
+|Number |Privilege |Name |Description
+4+^|Machine Non-Maskable Interrupt Handling
+
+|`0x740` +
+`0x741` +
+`0x742` +
+`0x744`
+|MRW +
+MRW +
+MRW +
+MRW
+|`mnscratch` +
+`mnepc` +
+`mncause` +
+`mnstatus`
+|Resumable NMI scratch register. +
+Resumable NMI program counter. +
+Resumable NMI cause. +
+Resumable NMI status.
+
+4+^|Machine Counter/Timers
+
+|`0xB00` +
+`0xB02` +
+`0xB03` +
+`0xB04` +
+&#160; +
+`0xB1F` +
+`0xB80` +
+`0xB82` +
+`0xB83` +
+`0xB84` +
+&#160; +
+`0xB9F`
+|MRW +
+MRW +
+MRW +
+MRW +
+&#160; +
+MRW +
+MRW +
+MRW +
+MRW +
+MRW +
+&#160; +
+MRW +
+|`mcycle` +
+`minstret` +
+`mhpmcounter3` +
+`mhpmcounter4` +
+&#8942; +
+`mhpmcounter31` +
+`mcycleh` +
+`minstreth` +
+`mhpmcounter3h` +
+`mhpmcounter4h` +
+&#8942; +
+`mhpmcounter31h`
+|Machine cycle counter. +
+Machine instructions-retired counter. +
+Machine performance-monitoring counter. +
+Machine performance-monitoring counter. +
+&#160; +
+Machine performance-monitoring counter. +
+Upper 32 bits of `mcycle`, RV32 only. +
+Upper 32 bits of `minstret`, RV32 only. +
+Upper 32 bits of `mhpmcounter3`, RV32 only. +
+Upper 32 bits of `mhpmcounter4`, RV32 only. +
+&#160; +
+Upper 32 bits of `mhpmcounter31`, RV32 only.
+
+4+^|Machine Counter Setup
+
+|`0x320` +
+`0x323` +
+`0x324` +
+&#160; +
+`0x33F` +
+`0x723` +
+`0x724` +
+&#160; +
+`0x73F`
+|MRW +
+MRW +
+MRW +
+&#160; +
+MRW +
+MRW +
+MRW +
+&#160; +
+MRW
+|`mcountinhibit` +
+`mhpmevent3` +
+`mhpmevent4` +
+&#8942; +
+`mhpmevent31` +
+`mhpmevent3h` +
+`mhpmevent4h` +
+&#8942; +
+`mhpmevent31h`
+|Machine counter-inhibit register. +
+Machine performance-monitoring event selector. +
+Machine performance-monitoring event selector. +
+&#160; +
+Machine performance-monitoring event selector. +
+Upper 32 bits of `mhpmevent3`, RV32 only. +
+Upper 32 bits of `mhpmevent4`, RV32 only. +
+&#160; +
+Upper 32 bits of `mhpmevent31`, RV32 only.
+
+4+^|Machine Control Transfer Records Configuration
+|`0x34E`
+|MRW
+|`mctrctl`
+|Machine Control Transfer Records Control Register.
+
+4+^|Debug/Trace Registers (shared with Debug Mode)
+
+|`0x7A0` +
+`0x7A1` +
+`0x7A2` +
+`0x7A3` +
+`0x7A8`
+|MRW +
+MRW +
+MRW +
+MRW +
+MRW
+|`tselect` +
+`tdata1` +
+`tdata2` +
+`tdata3` +
+`mcontext`
+
+|Debug/Trace trigger register select. +
+First Debug/Trace trigger data register. +
+Second Debug/Trace trigger data register. +
+Third Debug/Trace trigger data register. +
+Machine-mode context register.
+
+4+^|Debug Mode Registers
+
+|`0x7B0` +
+`0x7B1` +
+`0x7B2` +
+`0x7B3`
+|DRW +
+DRW +
+DRW +
+DRW +
+|`dcsr` +
+`dpc` +
+`dscratch0` +
+`dscratch1`
+|Debug control and status register. +
+Debug program counter. +
+Debug scratch register 0. +
+Debug scratch register 1.
+|===
+
+[[indcsrs-m]]
+.Currently allocated RISC-V indirect CSR (Smcsrind) mappings - M-mode
+[float="center",align="center",options="header"]
+|===
+| `miselect` | `mireg` | `mireg2` | `mireg3` | `mireg4` | `mireg5` | `mireg6`
+| 0x30 | `iprio0` | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0x3F | `iprio15` | none | none | none | none | none
+| 0x70 | `eidelivery` | none | none | none | none | none
+| 0x71 | 0 | none | none | none | none | none
+| 0x72 | `eithreshold` | none | none | none | none | none
+| 0x73 | 0 | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0x7F | 0 | none | none | none | none | none
+| 0x80 | `eip0` | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0xBF | `eip63` | none | none | none | none | none
+| 0xC0 | `eie0` | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0xFF | `eie63` | none | none | none | none | none
+|===
+
+[[indcsrs-s]]
+.Currently allocated RISC-V indirect CSR (Smcsrind/Sscsrind) mappings - S-mode
+[float="center",align="center",options="header"]
+|===
+| `siselect` | `sireg` | `sireg2` | `sireg3` | `sireg4` | `sireg5` | `sireg6`
+| 0x30 | `iprio0` | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0x3F | `iprio15` | none | none | none | none | none
+| 0x40 | `cycle` | `cyclecfg` | none | `cycleh` | `cyclecfgh` | none
+| 0x41 | none | none | none | none | none | none
+| 0x42 | `instret` | `instretcfg` | none | `instreth` | `instretcfgh` | none
+| 0x43 | `hpmcounter3` | `hpmevent3` | none | `hpmcounter3h` | `hpmevent3h` | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0x5F | `hpmcounter31` | `hpmevent31` | none | `hpmcounter31h` | `hpmevent31h` | none
+| 0x70 | `eidelivery` | none | none | none | none | none
+| 0x71 | 0 | none | none | none | none | none
+| 0x72 | `eithreshold` | none | none | none | none | none
+| 0x73 | 0 | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0x7F | 0 | none | none | none | none | none
+| 0x80 | `eip0` | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0xBF | `eip63` | none | none | none | none | none
+| 0xC0 | `eie0` | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0xFF | `eie63` | none | none | none | none | none
+| 0x200 | `ctrsource0` | `ctrtarget0` | `ctrdata0` | 0 | 0 | 0
+| ... | ... | ... | ... | ... | ... | ...
+| 0x2FF | `ctrsource255` | `ctrtarget255` | `ctrdata255` | 0 | 0 | 0
+|===
+
+[[indcsrs-vs]]
+.Currently allocated RISC-V indirect CSR (Smcsrind/Sscsrind) mappings - VS-mode
+[float="center",align="center",options="header"]
+|===
+| `vsiselect` | `vsireg` | `vsireg2` | `vsireg3` | `vsireg4` | `vsireg5` | `vsireg6`
+| 0x30 | `iprio0` | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0x3F | `iprio15` | none | none | none | none | none
+| 0x70 | `eidelivery` | none | none | none | none | none
+| 0x71 | 0 | none | none | none | none | none
+| 0x72 | `eithreshold` | none | none | none | none | none
+| 0x73 | 0 | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0x7F | 0 | none | none | none | none | none
+| 0x80 | `eip0` | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0xBF | `eip63` | none | none | none | none | none
+| 0xC0 | `eie0` | none | none | none | none | none
+| ... | ... | ... | ... | ... | ... | ...
+| 0xFF | `eie63` | none | none | none | none | none
+| 0x200 | `ctrsource0` | `ctrtarget0` | `ctrdata0` | 0 | 0 | 0
+| ... | ... | ... | ... | ... | ... | ...
+| 0x2FF | `ctrsource255` | `ctrtarget255` | `ctrdata255` | 0 | 0 | 0
+|===
+
+=== CSR Field Specifications
+
+The following definitions and abbreviations are used in specifying the
+behavior of fields within the CSRs.
+
+==== Reserved Writes Preserve Values, Reads Ignore Values (WPRI)
+
+Some whole read/write fields are reserved for future use. Software
+should ignore the values read from these fields, and should preserve the
+values held in these fields when writing values to other fields of the
+same register. For forward compatibility, implementations that do not
+furnish these fields must make them read-only zero. These fields are
+labeled *WPRI* in the register descriptions.
+
+[NOTE]
+====
+To simplify the software model, any backward-compatible future
+definition of previously reserved fields within a CSR must cope with the
+possibility that a non-atomic read/modify/write sequence is used to
+update other fields in the CSR. Alternatively, the original CSR
+definition must specify that subfields can only be updated atomically,
+which may require a two-instruction clear bit/set bit sequence in
+general that can be problematic if intermediate values are not legal.
+====
+
+==== Write/Read Only Legal Values (WLRL)
+
+Some read/write CSR fields specify behavior for only a subset of
+possible bit encodings, with other bit encodings reserved. Software
+should not write anything other than legal values to such a field, and
+should not assume a read will return a legal value unless the last write
+was of a legal value, or the register has not been written since another
+operation (e.g., reset) set the register to a legal value. These fields
+are labeled *WLRL* in the register descriptions.
+
+[NOTE]
+====
+Hardware implementations need only implement enough state bits to
+differentiate between the supported values, but must always return the
+complete specified bit-encoding of any supported value when read.
+====
+
+Implementations are permitted but not required to raise an
+illegal-instruction exception if an instruction attempts to write a
+non-supported value to a *WLRL* field. Implementations can return arbitrary
+bit patterns on the read of a *WLRL* field when the last write was of an
+illegal value, but the value returned should deterministically depend on
+the illegal written value and the value of the field prior to the write.
+
+==== Write Any Values, Reads Legal Values (WARL)
+
+Some read/write CSR fields are only defined for a subset of bit
+encodings, but allow any value to be written while guaranteeing to
+return a legal value whenever read. Assuming that writing the CSR has no
+other side effects, the range of supported values can be determined by
+attempting to write a desired setting then reading to see if the value
+was retained. These fields are labeled *WARL* in the register descriptions.
+
+Implementations will not raise an exception on writes of unsupported
+values to a *WARL* field. Implementations can return any legal value on the
+read of a *WARL* field when the last write was of an illegal value, but the
+legal value returned should deterministically depend on the illegal
+written value and the architectural state of the hart.
+
+=== CSR Field Modulation
+
+If a write to one CSR changes the set of legal values allowed for a
+field of a second CSR, then unless specified otherwise, the second CSR's
+field immediately gets an `UNSPECIFIED` value from among its new legal values. This
+is true even if the field's value before the write remains legal after
+the write; the value of the field may be changed in consequence of the
+write to the controlling CSR.
+
+[NOTE]
+====
+As a special case of this rule, the value written to one CSR may control
+whether a field of a second CSR is writable (with multiple legal values)
+or is read-only. When a write to the controlling CSR causes the second
+CSR's field to change from previously read-only to now writable, that
+field immediately gets an `UNSPECIFIED` but legal value, unless specified otherwise.
+
+***
+Some CSR fields are, when writable, defined as aliases of other CSR
+fields. Let _x_ be such a CSR field, and let _y_ be the CSR field it aliases when writable. If a write to a controlling CSR causes field _x_ to change from previously read-only to now writable, the new value of _x_ is not `UNSPECIFIED` but instead immediately reflects the existing value of its alias _y_, as required.
+====
+
+A change to the value of a CSR for this reason is not a write to the
+affected CSR and thus does not trigger any side effects specified for
+that CSR.
+
+=== Implicit Reads of CSRs
+
+Implementations sometimes perform _implicit_ reads of CSRs. (For
+example, all S-mode instruction fetches implicitly read the `satp` CSR.)
+Unless otherwise specified, the value returned by an implicit read of a
+CSR is the same value that would have been returned by an explicit read
+of the CSR, using a CSR-access instruction in a sufficient privilege
+mode.
+
+[[csrwidthmodulation]]
+=== CSR Width Modulation
+
+If the width of a CSR is changed (for example, by changing SXLEN or
+UXLEN, as described in <<xlen-control>>), the
+values of the _writable_ fields and bits of the new-width CSR are,
+unless specified otherwise, determined from the previous-width CSR as
+though by this algorithm:
+
+. The value of the previous-width CSR is copied to a temporary register
+of the same width.
+. For the read-only bits of the previous-width CSR, the bits at the same
+positions in the temporary register are set to zeros.
+. The width of the temporary register is changed to the new width. If
+the new width _W_ is narrower than the previous width, the
+least-significant _W_ bits of the temporary register are
+retained and the more-significant bits are discarded. If the new width
+is wider than the previous width, the temporary register is
+zero-extended to the wider width.
+. Each writable field of the new-width CSR takes the value of the bits
+at the same positions in the temporary register.
+
+Changing the width of a CSR is not a read or write of the CSR and thus
+does not trigger any side effects.
+
+=== Explicit Accesses to CSRs Wider than XLEN
+
+If a standard CSR is wider than XLEN bits, then an explicit read
+of the CSR returns the register's least-significant XLEN bits,
+and an explicit write to the CSR modifies only the register's
+least-significant XLEN bits, leaving the upper bits unchanged.
+
+Some standard CSRs, such as the counter CSRs of extension
+Zicntr, are always 64 bits, even when XLEN=32 (RV32).
+For each such 64-bit CSR (for example, counter `time`),
+a corresponding 32-bit _high-half CSR_ is usually defined with
+the same name but with the letter '`h`' appended at the end (`timeh`).
+The high-half CSR aliases bits 63:32 of its namesake
+64-bit CSR, thus providing a way for RV32 software
+to read and modify the otherwise-unreachable 32 bits.
+
+Standard high-half CSRs are accessible only when
+the base RISC-V instruction set is RV32 (XLEN=32).
+For RV64 (when XLEN=64), the addresses of all standard high-half CSRs
+are reserved, so an attempt to access a high-half CSR
+typically raises an illegal-instruction exception.
diff --git a/src/priv-csrs.tex b/src/priv-csrs.tex
deleted file mode 100644
index 33651a3..0000000
--- a/src/priv-csrs.tex
+++ /dev/null
@@ -1,457 +0,0 @@
-\chapter{Control and Status Registers (CSRs)}
-
-The SYSTEM major opcode is used to encode all privileged instructions
-in the RISC-V ISA. These can be divided into two main classes: those
-that atomically read-modify-write control and status registers (CSRs),
-and all other privileged instructions. In addition to the user-level
-state described in Volume I of this manual, an implementation may
-contain additional CSRs, accessible by some subset of the privilege
-levels using the CSR instructions described in the user-level manual.
-In this chapter, we map out the CSR address space. The following
-chapters describe the function of each of the CSRs according to
-privilege level, as well as the other privileged instructions which
-are generally closely associated with a particular privilege level.
-Note that although CSRs and instructions are associated with one
-privilege level, they are also accessible at all higher privilege
-levels.
-
-\section{CSR Address Mapping Conventions}
-
-The standard RISC-V ISA sets aside a 12-bit encoding space (csr[11:0])
-for up to 4,096 CSRs. By convention, the upper 4 bits of the CSR
-address (csr[11:8]) are used to encode the read and write
-accessibility of the CSRs according to privilege level as shown in
-Table~\ref{csrrwpriv}. The top two bits (csr[11:10]) indicate whether
-the register is read/write ({\tt 00}, {\tt 01}, or {\tt 10}) or
-read-only ({\tt 11}). The next two bits (csr[9:8]) encode the lowest
-privilege level that can access the CSR.
-
-\begin{commentary}
-The CSR address convention uses the upper bits of the CSR address to
-encode default access privileges. This simplifies error checking in
-the hardware and provides a larger CSR space, but does constrain the
-mapping of CSRs into the address space.
-
-Implementations might allow a more-privileged level to trap otherwise
-permitted CSR accesses by a less-privileged level to allow these
-accesses to be intercepted. This change should be transparent to the
-less-privileged software.
-\end{commentary}
-
-\vspace{0.2in}
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|c|c|c|c|l|}
-\hline
-\multicolumn{3}{|c|}{CSR Address} & Hex & \multicolumn{1}{c|}{Use and Accessibility}\\ \cline{1-3}
-[11:10] & [9:8] & [7:6] & & \\
-\hline
-\multicolumn{5}{|c|}{User CSRs} \\
-\hline
-\tt 00 &\tt 00 &\tt XX & \tt 0x000-0x0FF & Standard read/write \\
-\tt 01 &\tt 00 &\tt XX & \tt 0x400-0x4FF & Standard read/write \\
-\tt 10 &\tt 00 &\tt XX & \tt 0x800-0x8FF & Non-standard read/write \\
-\tt 11 &\tt 00 &\tt 00-10 & \tt 0xC00-0xCBF & Standard read-only \\
-\tt 11 &\tt 00 &\tt 11 & \tt 0xCC0-0xCFF & Non-standard read-only \\
-\hline
-\multicolumn{5}{|c|}{Supervisor CSRs} \\
-\hline
-\tt 00 &\tt 01 &\tt XX & \tt 0x100-0x1FF & Standard read/write \\
-\tt 01 &\tt 01 &\tt 00-10 & \tt 0x500-0x5BF & Standard read/write \\
-\tt 01 &\tt 01 &\tt 11 & \tt 0x5C0-0x5FF & Non-standard read/write \\
-\tt 10 &\tt 01 &\tt 00-10 & \tt 0x900-0x9BF & Standard read/write \\
-\tt 10 &\tt 01 &\tt 11 & \tt 0x9C0-0x9FF & Non-standard read/write \\
-\tt 11 &\tt 01 &\tt 00-10 & \tt 0xD00-0xDBF & Standard read-only \\
-\tt 11 &\tt 01 &\tt 11 & \tt 0xDC0-0xDFF & Non-standard read-only \\
-\hline
-\multicolumn{5}{|c|}{Reserved CSRs} \\
-\hline
-\tt XX &\tt 10 &\tt XX & Reserved & \\
-%% \multicolumn{5}{|c|}{Hypervisor CSRs} \\
-%% \hline
-%% \tt 00 &\tt 10 &\tt XX & \tt 0x200-0x2FF & Standard read/write \\
-%% \tt 01 &\tt 10 &\tt 00-10 & \tt 0x600-0x6BF & Standard read/write \\
-%% \tt 01 &\tt 10 &\tt 11 & \tt 0x6C0-0x6FF & Non-standard read/write \\
-%% \tt 10 &\tt 10 &\tt 00-10 & \tt 0xA00-0xABF & Standard read/write \\
-%% \tt 10 &\tt 10 &\tt 11 & \tt 0xAC0-0xAFF & Non-standard read/write \\
-%% \tt 11 &\tt 10 &\tt 00-10 & \tt 0xE00-0xEBF & Standard read-only \\
-%% \tt 11 &\tt 10 &\tt 11 & \tt 0xEC0-0xEFF & Non-standard read-only \\
-\hline
-\multicolumn{5}{|c|}{Machine CSRs} \\
-\hline
-\tt 00 &\tt 11 &\tt XX & \tt 0x300-0x3FF & Standard read/write \\
-\tt 01 &\tt 11 &\tt 00-10 & \tt 0x700-0x79F & Standard read/write \\
-\tt 01 &\tt 11 &\tt 10 & \tt 0x7A0-0x7AF & Standard read/write debug CSRs \\
-\tt 01 &\tt 11 &\tt 10 & \tt 0x7B0-0x7BF & Debug-mode-only CSRs \\
-\tt 01 &\tt 11 &\tt 11 & \tt 0x7C0-0x7FF & Non-standard read/write \\
-\tt 10 &\tt 11 &\tt 00-10 & \tt 0xB00-0xBBF & Standard read/write \\
-\tt 10 &\tt 11 &\tt 11 & \tt 0xBC0-0xBFF & Non-standard read/write \\
-\tt 11 &\tt 11 &\tt 00-10 & \tt 0xF00-0xFBF & Standard read-only \\
-\tt 11 &\tt 11 &\tt 11 & \tt 0xFC0-0xFFF & Non-standard read-only \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Allocation of RISC-V CSR address ranges.}
-\label{csrrwpriv}
-\end{table*}
-
-Attempts to access a non-existent CSR raise an illegal instruction
-exception. Attempts to access a CSR without appropriate privilege
-level or to write a read-only register also raise illegal instruction
-exceptions. A read/write register might also contain some bits that
-are read-only, in which case writes to the read-only bits are ignored.
-
-Table~\ref{csrrwpriv} also indicates the convention to allocate CSR
-addresses between standard and non-standard uses. The CSR addresses
-reserved for non-standard uses will not be redefined by future
-standard extensions.
-
-\begin{commentary}
-We have dropped the explicit allocation of CSR space for shadow CSRs
-to leave more flexibility for allocated other CSRs. Shadow CSRs can
-still be added in the appropriate R/W space. The counters are the
-only shadowed CSRs in the current spec.
-
-Shadows CSRs provide a read-write address via which a higher privilege
-level can modify a register that is read-only at a lower privilege
-level. Note that if one privilege level has already allocated a
-read/write shadow address, then any higher privilege level can use the
-same CSR address for read/write access to the same register.
-
-Effective virtualization requires that as many instructions run
-natively as possible inside a virtualized environment, while any
-privileged accesses trap to the virtual machine
-monitor~\cite{goldbergvm}. CSRs that are read-only at some lower
-privilege level are shadowed into separate CSR addresses if they are
-made read-write at a higher privilege level. This avoids trapping
-permitted lower-privilege accesses while still causing traps on
-illegal accesses.
-\end{commentary}
-
-Machine-mode standard read-write CSRs {\tt 0x7A0}--{\tt 0x7BF} are
-reserved for use by the debug system. Implementations should raise
-illegal instruction exceptions on machine-mode access to these registers.
-
-\section{CSR Listing}
-
-Tables~\ref{ucsrnames}--\ref{mcsrnames1} list the CSRs that have
-currently been allocated CSR addresses. The timers, counters, and
-floating-point CSRs are standard user-level CSRs, as well as the
-additional user trap registers added by the N extension. The other
-registers are used by privileged code, as described in the following
-chapters. Note that not all registers are required on all
-implementations.
-
-\begin{table}[htb!]
-\begin{center}
-\begin{tabular}{|l|l|l|l|}
-\hline
-Number & Privilege & Name & Description \\
-\hline
-\multicolumn{4}{|c|}{User Trap Setup} \\
-\hline
-\tt 0x000 & URW &\tt ustatus & User status register. \\
-\tt 0x004 & URW &\tt uie & User interrupt-enable register. \\
-\tt 0x005 & URW &\tt utvec & User trap handler base address. \\
-\hline
-\multicolumn{4}{|c|}{User Trap Handling} \\
-\hline
-\tt 0x040 & URW &\tt uscratch & Scratch register for user trap handlers. \\
-\tt 0x041 & URW &\tt uepc & User exception program counter. \\
-\tt 0x042 & URW &\tt ucause & User trap cause. \\
-\tt 0x043 & URW &\tt utval & User bad address or instruction. \\
-\tt 0x044 & URW &\tt uip & User interrupt pending. \\
-\hline
-\multicolumn{4}{|c|}{User Floating-Point CSRs} \\
-\hline
-\tt 0x001 & URW &\tt fflags & Floating-Point Accrued Exceptions. \\
-\tt 0x002 & URW &\tt frm & Floating-Point Dynamic Rounding Mode. \\
-\tt 0x003 & URW &\tt fcsr & Floating-Point Control and Status
-Register ({\tt frm} + {\tt fflags}). \\
-\hline
-\multicolumn{4}{|c|}{User Counter/Timers} \\
-\hline
-\tt 0xC00 & URO &\tt cycle & Cycle counter for RDCYCLE instruction. \\
-\tt 0xC01 & URO &\tt time & Timer for RDTIME instruction. \\
-\tt 0xC02 & URO &\tt instret & Instructions-retired counter for RDINSTRET instruction. \\
-\tt 0xC03 & URO &\tt hpmcounter3 & Performance-monitoring counter. \\
-\tt 0xC04 & URO &\tt hpmcounter4 & Performance-monitoring counter. \\
-& & \multicolumn{1}{c|}{\vdots} & \ \\
-\tt 0xC1F & URO &\tt hpmcounter31 & Performance-monitoring counter. \\
-\tt 0xC80 & URO &\tt cycleh & Upper 32 bits of {\tt cycle}, RV32I only. \\
-\tt 0xC81 & URO &\tt timeh & Upper 32 bits of {\tt time}, RV32I only. \\
-\tt 0xC82 & URO &\tt instreth & Upper 32 bits of {\tt instret}, RV32I only. \\
-\tt 0xC83 & URO &\tt hpmcounter3h & Upper 32 bits of {\tt hpmcounter3}, RV32I only. \\
-\tt 0xC84 & URO &\tt hpmcounter4h & Upper 32 bits of {\tt hpmcounter4}, RV32I only. \\
-& & \multicolumn{1}{c|}{\vdots} & \ \\
-\tt 0xC9F & URO &\tt hpmcounter31h & Upper 32 bits of {\tt hpmcounter31}, RV32I only. \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Currently allocated RISC-V user-level CSR addresses.}
-\label{ucsrnames}
-\end{table}
-
-\begin{table}[htb!]
-\begin{center}
-\begin{tabular}{|l|l|l|l|}
-\hline
-Number & Privilege & Name & Description \\
-\hline
-\multicolumn{4}{|c|}{Supervisor Trap Setup} \\
-\hline
-\tt 0x100 & SRW &\tt sstatus & Supervisor status register. \\
-\tt 0x102 & SRW &\tt sedeleg & Supervisor exception delegation register. \\
-\tt 0x103 & SRW &\tt sideleg & Supervisor interrupt delegation register. \\
-\tt 0x104 & SRW &\tt sie & Supervisor interrupt-enable register. \\
-\tt 0x105 & SRW &\tt stvec & Supervisor trap handler base address. \\
-\tt 0x106 & SRW &\tt scounteren & Supervisor counter enable. \\
-\hline
-\multicolumn{4}{|c|}{Supervisor Trap Handling} \\
-\hline
-\tt 0x140 & SRW &\tt sscratch & Scratch register for supervisor trap handlers. \\
-\tt 0x141 & SRW &\tt sepc & Supervisor exception program counter. \\
-\tt 0x142 & SRW &\tt scause & Supervisor trap cause. \\
-\tt 0x143 & SRW &\tt stval & Supervisor bad address or instruction. \\
-\tt 0x144 & SRW &\tt sip & Supervisor interrupt pending. \\
-\hline
-\multicolumn{4}{|c|}{Supervisor Protection and Translation} \\
-\hline
-\tt 0x180 & SRW &\tt satp & Supervisor address translation and protection. \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Currently allocated RISC-V supervisor-level CSR addresses.}
-\label{scsrnames}
-\end{table}
-
-%% \begin{table}[htb!]
-%% \begin{center}
-%% \begin{tabular}{|l|l|l|l|}
-%% \hline
-%% Number & Privilege & Name & Description \\
-%% \hline
-%% \multicolumn{4}{|c|}{Hypervisor Trap Setup} \\
-%% \hline
-%% \tt 0x200 & HRW &\tt hstatus & Hypervisor status register. \\
-%% \tt 0x202 & HRW &\tt hedeleg & Hypervisor exception delegation register. \\
-%% \tt 0x203 & HRW &\tt hideleg & Hypervisor interrupt delegation register. \\
-%% \tt 0x204 & HRW &\tt hie & Hypervisor interrupt-enable register. \\
-%% \tt 0x205 & HRW &\tt htvec & Hypervisor trap handler base address. \\
-%% \tt 0x206 & HRW &\tt hcounteren & Hypervisor counter enable. \\
-%% \hline
-%% \multicolumn{4}{|c|}{Hypervisor Trap Handling} \\
-%% \hline
-%% \tt 0x240 & HRW &\tt hscratch & Scratch register for hypervisor trap handlers. \\
-%% \tt 0x241 & HRW &\tt hepc & Hypervisor exception program counter. \\
-%% \tt 0x242 & HRW &\tt hcause & Hypervisor trap cause. \\
-%% \tt 0x243 & HRW &\tt htval & Hypervisor bad address or instruction. \\
-%% \tt 0x244 & HRW &\tt hip & Hypervisor interrupt pending. \\
-%% \hline
-%% \multicolumn{4}{|c|}{Hypervisor Protection and Translation} \\
-%% \hline
-%% \tt 0x28X & TBD & TBD & TBD. \\
-%% \hline
-%% \end{tabular}
-%% \end{center}
-%% \caption{Currently allocated RISC-V hypervisor-level CSR addresses.}
-%% \label{hcsrnames}
-%% \end{table}
-
-
-\begin{table}[htb!]
-\begin{center}
-\begin{tabular}{|l|l|l|l|}
-\hline
-Number & Privilege & Name & Description \\
-\hline
-\multicolumn{4}{|c|}{Machine Information Registers} \\
-\hline
-\tt 0xF11 & MRO &\tt mvendorid & Vendor ID. \\
-\tt 0xF12 & MRO &\tt marchid & Architecture ID. \\
-\tt 0xF13 & MRO &\tt mimpid & Implementation ID. \\
-\tt 0xF14 & MRO &\tt mhartid & Hardware thread ID. \\
-\hline
-\multicolumn{4}{|c|}{Machine Trap Setup} \\
-\hline
-\tt 0x300 & MRW &\tt mstatus & Machine status register. \\
-\tt 0x301 & MRW &\tt misa & ISA and extensions \\
-\tt 0x302 & MRW &\tt medeleg & Machine exception delegation register. \\
-\tt 0x303 & MRW &\tt mideleg & Machine interrupt delegation register. \\
-\tt 0x304 & MRW &\tt mie & Machine interrupt-enable register. \\
-\tt 0x305 & MRW &\tt mtvec & Machine trap-handler base address. \\
-\tt 0x306 & MRW &\tt mcounteren & Machine counter enable. \\
-\hline
-\multicolumn{4}{|c|}{Machine Trap Handling} \\
-\hline
-\tt 0x340 & MRW &\tt mscratch & Scratch register for machine trap handlers. \\
-\tt 0x341 & MRW &\tt mepc & Machine exception program counter. \\
-\tt 0x342 & MRW &\tt mcause & Machine trap cause. \\
-\tt 0x343 & MRW &\tt mtval & Machine bad address or instruction. \\
-\tt 0x344 & MRW &\tt mip & Machine interrupt pending. \\
-\hline
-\multicolumn{4}{|c|}{Machine Memory Protection} \\
-\hline
-%\tt 0x380 & MRW &\tt mbase & Base register. \\
-%\tt 0x381 & MRW &\tt mbound & Bound register. \\
-%\tt 0x382 & MRW &\tt mibase & Instruction base register. \\
-%\tt 0x383 & MRW &\tt mibound & Instruction bound register. \\
-%\tt 0x384 & MRW &\tt mdbase & Data base register. \\
-%\tt 0x385 & MRW &\tt mdbound & Data bound register. \\
-\tt 0x3A0 & MRW &\tt pmpcfg0 & Physical memory protection configuration. \\
-\tt 0x3A1 & MRW &\tt pmpcfg1 & Physical memory protection configuration, RV32 only. \\
-\tt 0x3A2 & MRW &\tt pmpcfg2 & Physical memory protection configuration. \\
-\tt 0x3A3 & MRW &\tt pmpcfg3 & Physical memory protection configuration, RV32 only. \\
-\tt 0x3B0 & MRW &\tt pmpaddr0 & Physical memory protection address register. \\
-\tt 0x3B1 & MRW &\tt pmpaddr1 & Physical memory protection address register. \\
-& & \multicolumn{1}{c|}{\vdots} & \ \\
-\tt 0x3BF & MRW &\tt pmpaddr15 & Physical memory protection address register. \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Currently allocated RISC-V machine-level CSR addresses.}
-\label{mcsrnames0}
-\end{table}
-
-\begin{table}[htb!]
-\begin{center}
-\begin{tabular}{|l|l|l|l|}
-\hline
-Number & Privilege & Name & Description \\
-\hline
-\multicolumn{4}{|c|}{Machine Counter/Timers} \\
-\hline
-\tt 0xB00 & MRW &\tt mcycle & Machine cycle counter. \\
-\tt 0xB02 & MRW &\tt minstret & Machine instructions-retired counter. \\
-\tt 0xB03 & MRW &\tt mhpmcounter3 & Machine performance-monitoring counter. \\
-\tt 0xB04 & MRW &\tt mhpmcounter4 & Machine performance-monitoring counter. \\
-& & \multicolumn{1}{c|}{\vdots} & \ \\
-\tt 0xB1F & MRW &\tt mhpmcounter31 & Machine performance-monitoring counter. \\
-\tt 0xB80 & MRW &\tt mcycleh & Upper 32 bits of {\tt mcycle}, RV32I only. \\
-\tt 0xB82 & MRW &\tt minstreth & Upper 32 bits of {\tt minstret}, RV32I only. \\
-\tt 0xB83 & MRW &\tt mhpmcounter3h & Upper 32 bits of {\tt mhpmcounter3}, RV32I only. \\
-\tt 0xB84 & MRW &\tt mhpmcounter4h & Upper 32 bits of {\tt mhpmcounter4}, RV32I only. \\
-& & \multicolumn{1}{c|}{\vdots} & \ \\
-\tt 0xB9F & MRW &\tt mhpmcounter31h & Upper 32 bits of {\tt mhpmcounter31}, RV32I only. \\
-\hline
-\multicolumn{4}{|c|}{Machine Counter Setup} \\
-\hline
-\tt 0x320 & MRW &\tt mcountinhibit & Machine counter-inhibit register. \\
-\tt 0x323 & MRW &\tt mhpmevent3 & Machine performance-monitoring event selector. \\
-\tt 0x324 & MRW &\tt mhpmevent4 & Machine performance-monitoring event selector. \\
-& & \multicolumn{1}{c|}{\vdots} & \ \\
-\tt 0x33F & MRW &\tt mhpmevent31 & Machine performance-monitoring event selector. \\
-\hline
-\multicolumn{4}{|c|}{Debug/Trace Registers (shared with Debug Mode)} \\
-\hline
-\tt 0x7A0 & MRW &\tt tselect & Debug/Trace trigger register select. \\
-\tt 0x7A1 & MRW &\tt tdata1 & First Debug/Trace trigger data register. \\
-\tt 0x7A2 & MRW &\tt tdata2 & Second Debug/Trace trigger data register. \\
-\tt 0x7A3 & MRW &\tt tdata3 & Third Debug/Trace trigger data register. \\
-\hline
-\multicolumn{4}{|c|}{Debug Mode Registers } \\
-\hline
-\tt 0x7B0 & DRW &\tt dcsr & Debug control and status register. \\
-\tt 0x7B1 & DRW &\tt dpc & Debug PC. \\
-\tt 0x7B2 & DRW &\tt dscratch & Debug scratch register. \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Currently allocated RISC-V machine-level CSR addresses.}
-\label{mcsrnames1}
-\end{table}
-
-\clearpage
-
-\section{CSR Field Specifications}
-
-
-The following definitions and abbreviations are used in specifying the
-behavior of fields within the CSRs.
-
-\subsection*{Reserved Writes Preserve Values, Reads Ignore Values (WPRI)}
-
-Some whole read/write fields are reserved for future use. Software
-should ignore the values read from these fields, and should preserve
-the values held in these fields when writing values to other fields of
-the same register.
-For forward compatibility, implementations that do not furnish these fields
-must hardwire them to zero.
-These fields are labeled \wpri\ in the register descriptions.
-
-\begin{commentary}
-To simplify the software model, any backward-compatible future
-definition of previously reserved fields within a CSR must cope with
-the possibility that a non-atomic read/modify/write sequence is used
-to update other fields in the CSR. Alternatively, the original CSR
-definition must specify that subfields can only be updated atomically,
-which may require a two-instruction clear bit/set bit sequence in
-general that can be problematic if intermediate values are not legal.
-\end{commentary}
-
-\subsection*{Write/Read Only Legal Values (WLRL)}
-
-Some read/write CSR fields specify behavior for only a subset of
-possible bit encodings, with other bit encodings reserved. Software
-should not write anything other than legal values to such a field, and
-should not assume a read will return a legal value unless the last
-write was of a legal value, or the register has not been written since
-another operation (e.g., reset) set the register to a legal value.
-These fields are labeled \wlrl\ in the register descriptions.
-
-\begin{commentary}
-Hardware implementations need only implement enough state bits to
-differentiate between the supported values, but must always return the
-complete specified bit-encoding of any supported value when read.
-\end{commentary}
-
-Implementations are permitted but not required to raise an illegal
-instruction exception if an instruction attempts to write a
-non-supported value to a CSR field. Hardware implementations can
-return arbitrary bit patterns on the read of a CSR field when the last
-write was of an illegal value, but the value returned should
-deterministically depend on the illegal written value.
-
-\subsection*{Write Any Values, Reads Legal Values (WARL)}
-
-Some read/write CSR fields are only defined for a subset of bit
-encodings, but allow any value to be written while guaranteeing to
-return a legal value whenever read. Assuming that writing the CSR has
-no other side effects, the range of supported values can be determined
-by attempting to write a desired setting then reading to see if the
-value was retained. These fields are labeled \warl\ in the register
-descriptions.
-
-Implementations will not raise an exception on writes of unsupported
-values to an \warl\ field. Implementations must always
-deterministically return the same legal value after a given illegal
-value is written.
-
-\section{CSR Width Modulation}
-
-If the width of a CSR is changed (for example, by changing MXLEN or UXLEN, as
-described in Section~\ref{xlen-control}), the values of the {\em writable}
-fields and bits of the new-width CSR are, unless specified otherwise,
-determined from the previous-width CSR as though by this algorithm:
-
-\begin{enumerate}
-
-\item The value of the previous-width CSR is copied to a temporary register of
-the same width.
-
-\item For the read-only bits of the previous-width CSR, the bits at the same
-positions in the temporary register are set to zeros.
-
-\item The width of the temporary register is changed to the new width. If the
-new width $W$ is narrower than the previous width, the least-significant $W$
-bits of the temporary register are retained and the more-significant bits are
-discarded. If the new width is wider than the previous width, the temporary
-register is zero-extended to the wider width.
-
-\item Each writable field of the new-width CSR takes the value of the bits at
-the same positions in the temporary register.
-
-\end{enumerate}
-
-Changing the width of a CSR is not a read or write of the CSR and thus
-does not trigger any side effects.
diff --git a/src/priv-history.adoc b/src/priv-history.adoc
new file mode 100644
index 0000000..586fc70
--- /dev/null
+++ b/src/priv-history.adoc
@@ -0,0 +1,22 @@
+== History
+
+=== Research Funding at UC Berkeley
+
+Development of the RISC-V architecture and implementations has been
+partially funded by the following sponsors.
+
+* *Par Lab:* Research supported by Microsoft (Award #024263) and Intel
+(Award #024894) funding and by matching funding by U.C. Discovery (Award
+#DIG07-10227). Additional support came from Par Lab affiliates Nokia,
+NVIDIA, Oracle, and Samsung.
+* *Project Isis:* DoE Award DE-SC0003624.
+* *ASPIRE Lab*: DARPA PERFECT program, Award HR0011-12-2-0016. DARPA
+POEM program Award HR0011-11-C-0100. The Center for Future Architectures
+Research (C-FAR), a STARnet center funded by the Semiconductor Research
+Corporation. Additional support from ASPIRE industrial sponsor, Intel,
+and ASPIRE affiliates, Google, Huawei, Nokia, NVIDIA, Oracle, and
+Samsung.
+
+The content of this paper does not necessarily reflect the position or
+the policy of the US government and no official endorsement should be
+inferred.
diff --git a/src/priv-history.tex b/src/priv-history.tex
deleted file mode 100644
index fadcdc2..0000000
--- a/src/priv-history.tex
+++ /dev/null
@@ -1,29 +0,0 @@
-\chapter{History}
-
-\section{Research Funding at UC Berkeley}
-
-Development of the RISC-V architecture and implementations has been
-partially funded by the following sponsors.
-
-\begin{itemize}
-\item {\bf Par Lab:} Research supported by Microsoft (Award \#024263)
- and Intel (Award \#024894) funding and by matching funding by
- U.C. Discovery (Award \#DIG07-10227). Additional support came from
- Par Lab affiliates Nokia, NVIDIA, Oracle, and Samsung.
-
-\item {\bf Project Isis:} DoE Award DE-SC0003624.
-
-\item {\bf ASPIRE Lab}: DARPA PERFECT program, Award HR0011-12-2-0016.
- DARPA POEM program Award HR0011-11-C-0100. The Center for Future
- Architectures Research (C-FAR), a STARnet center funded by the
- Semiconductor Research Corporation. Additional support from ASPIRE
- industrial sponsor, Intel, and ASPIRE affiliates, Google, Huawei,
- Nokia, NVIDIA, Oracle, and Samsung.
-
-\end{itemize}
-
-The content of this paper does not necessarily reflect the position or the
-policy of the US government and no official endorsement should be
-inferred.
-
-
diff --git a/src/priv-insns.adoc b/src/priv-insns.adoc
new file mode 100644
index 0000000..0020c2d
--- /dev/null
+++ b/src/priv-insns.adoc
@@ -0,0 +1,12 @@
+
+== RISC-V Privileged Instruction Set Listings
+
+This chapter presents instruction-set listings for all instructions
+defined in the RISC-V Privileged Architecture.
+
+The instruction-set listings for unprivileged instructions, including
+the ECALL and EBREAK instructions, are provided in Volume I of this
+manual.
+
+.RISC-V Privileged Instructions
+include::images/bytefield/priv-instr-set.edn[]
diff --git a/src/priv-insns.tex b/src/priv-insns.tex
deleted file mode 100644
index cbfdd70..0000000
--- a/src/priv-insns.tex
+++ /dev/null
@@ -1,9 +0,0 @@
-\chapter{RISC-V Privileged Instruction Set Listings}
-
-This chapter presents instruction-set listings for all instructions
-defined in the RISC-V Privileged Architecture.
-
-The instruction-set listings for unprivileged instructions, including the
-ECALL and EBREAK instructions, are provided in Volume I of this manual.
-
-\input{priv-instr-table}
diff --git a/src/priv-instr-table.tex b/src/priv-instr-table.tex
deleted file mode 100644
index 36b2fe2..0000000
--- a/src/priv-instr-table.tex
+++ /dev/null
@@ -1,118 +0,0 @@
-
-\newpage
-
-\begin{table}[p]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.4in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.4in}p{0.6in}p{0.4in}p{0.6in}p{0.7in}l}
-& & & & & & & & & & \\
- &
-\multicolumn{1}{l}{\instbit{31}} &
-\multicolumn{1}{r}{\instbit{27}} &
-\instbit{26} &
-\instbit{25} &
-\multicolumn{1}{l}{\instbit{24}} &
-\multicolumn{1}{r}{\instbit{20}} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{funct7} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & R-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{6}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} & I-type \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf Trap-Return Instructions} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0000000} &
-\multicolumn{2}{c|}{00010} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{1110011} & URET \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0001000} &
-\multicolumn{2}{c|}{00010} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{1110011} & SRET \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0011000} &
-\multicolumn{2}{c|}{00010} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{1110011} & MRET \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf Interrupt-Management Instructions} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0001000} &
-\multicolumn{2}{c|}{00101} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{1110011} & WFI \\
-\cline{2-11}
-
-
-&
-\multicolumn{10}{c}{} & \\
-&
-\multicolumn{10}{c}{\bf Memory-Management Instructions} & \\
-\cline{2-11}
-
-
-&
-\multicolumn{4}{|c|}{0001001} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{000} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{1110011} & SFENCE.VMA \\
-\cline{2-11}
-
-
-\end{tabular}
-\end{center}
-\end{small}
-\caption{RISC-V Privileged Instructions}
-\end{table}
-
diff --git a/src/priv-intro.adoc b/src/priv-intro.adoc
new file mode 100644
index 0000000..2df7982
--- /dev/null
+++ b/src/priv-intro.adoc
@@ -0,0 +1,216 @@
+[[priv-intro]]
+
+== Introduction
+
+This document describes the RISC-V privileged architecture, which covers
+all aspects of RISC-V systems beyond the unprivileged ISA, including
+privileged instructions as well as additional functionality required for
+running operating systems and attaching external devices.
+
+[NOTE]
+====
+Commentary on our design decisions is formatted as in this paragraph,
+and can be skipped if the reader is only interested in the specification
+itself.
+
+***
+We briefly note that the entire privileged-level design described in
+this document could be replaced with an entirely different
+privileged-level design without changing the unprivileged ISA, and
+possibly without even changing the ABI. In particular, this privileged
+specification was designed to run existing popular operating systems,
+and so embodies the conventional level-based protection model. Alternate
+privileged specifications could embody other more flexible
+protection-domain models. For simplicity of expression, the text is
+written as if this was the only possible privileged architecture.
+====
+
+=== RISC-V Privileged Software Stack Terminology
+
+This section describes the terminology we use to describe components of
+the wide range of possible privileged software stacks for RISC-V.
+
+<<privimps>> shows some of the possible software stacks
+that can be supported by the RISC-V architecture. The left-hand side
+shows a simple system that supports only a single application running on
+an application execution environment (AEE). The application is coded to
+run with a particular application binary interface (ABI). The ABI
+includes the supported user-level ISA plus a set of ABI calls to
+interact with the AEE. The ABI hides details of the AEE from the
+application to allow greater flexibility in implementing the AEE. The
+same ABI could be implemented natively on multiple different host OSs,
+or could be supported by a user-mode emulation environment running on a
+machine with a different native ISA.
+
+[NOTE]
+====
+Our graphical convention represents abstract interfaces using black
+boxes with white text, to separate them from concrete instances of
+components implementing the interfaces.
+====
+[[privimps]]
+.Different implementation stacks supporting various forms of privileged execution.
+image::png/privimps.png[]
+
+The middle configuration shows a conventional operating system (OS) that
+can support multiprogrammed execution of multiple applications. Each
+application communicates over an ABI with the OS, which provides the
+AEE. Just as applications interface with an AEE via an ABI, RISC-V
+operating systems interface with a supervisor execution environment
+(SEE) via a supervisor binary interface (SBI). An SBI comprises the
+user-level and supervisor-level ISA together with a set of SBI function
+calls. Using a single SBI across all SEE implementations allows a single
+OS binary image to run on any SEE. The SEE can be a simple boot loader
+and BIOS-style IO system in a low-end hardware platform, or a
+hypervisor-provided virtual machine in a high-end server, or a thin
+translation layer over a host operating system in an architecture
+simulation environment.
+
+[NOTE]
+====
+Most supervisor-level ISA definitions do not separate the SBI from the
+execution environment and/or the hardware platform, complicating
+virtualization and bring-up of new hardware platforms.
+====
+The rightmost configuration shows a virtual machine monitor
+configuration where multiple multiprogrammed OSs are supported by a
+single hypervisor. Each OS communicates via an SBI with the hypervisor,
+which provides the SEE. The hypervisor communicates with the hypervisor
+execution environment (HEE) using a hypervisor binary interface (HBI),
+to isolate the hypervisor from details of the hardware platform.
+
+[NOTE]
+====
+The ABI, SBI, and HBI are still a work-in-progress, but we are now
+prioritizing support for Type-2 hypervisors where the SBI is provided
+recursively by an S-mode OS.
+====
+
+Hardware implementations of the RISC-V ISA will generally require
+additional features beyond the privileged ISA to support the various
+execution environments (AEE, SEE, or HEE).
+
+=== Privilege Levels
+
+At any time, a RISC-V hardware thread (_hart_) is running at some
+privilege level encoded as a mode in one or more CSRs (control and
+status registers). Three RISC-V privilege levels are currently defined
+as shown in <<privlevels>>.
+
+[[privlevels]]
+.RISC-V privilege levels.
+[%autowidth,float="center",align="center",cols="^,^,^,^",options="header"]
+|===
+|Level |Encoding |Name |Abbreviation
+|0 +
+1 +
+2 +
+3
+|`00` +
+`01` +
+`10` +
+`11`
+|User/Application +
+Supervisor +
+_Reserved_ +
+Machine
+|U +
+S +
+&#160; +
+M
+|===
+
+Privilege levels are used to provide protection between different
+components of the software stack, and attempts to perform operations not
+permitted by the current privilege mode will cause an exception to be
+raised. These exceptions will normally cause traps into an underlying
+execution environment.
+
+[NOTE]
+====
+In the description, we try to separate the privilege level for which
+code is written, from the privilege mode in which it runs, although the
+two are often tied. For example, a supervisor-level operating system can
+run in supervisor-mode on a system with three privilege modes, but can
+also run in user-mode under a classic virtual machine monitor on systems
+with two or more privilege modes. In both cases, the same
+supervisor-level operating system binary code can be used, coded to a
+supervisor-level SBI and hence expecting to be able to use
+supervisor-level privileged instructions and CSRs. When running a guest
+OS in user mode, all supervisor-level actions will be trapped and
+emulated by the SEE running in the higher-privilege level.
+====
+The machine level has the highest privileges and is the only mandatory
+privilege level for a RISC-V hardware platform. Code run in machine-mode
+(M-mode) is usually inherently trusted, as it has low-level access to
+the machine implementation. M-mode can be used to manage secure
+execution environments on RISC-V. User-mode (U-mode) and supervisor-mode
+(S-mode) are intended for conventional application and operating system
+usage respectively.
+
+Each privilege level has a core set of privileged ISA extensions with
+optional extensions and variants. For example, machine-mode supports an
+optional standard extension for memory protection. Also, supervisor mode
+can be extended to support Type-2 hypervisor execution as described in
+<<hypervisor>>.
+
+Implementations might provide anywhere from 1 to 3 privilege modes
+trading off reduced isolation for lower implementation cost, as shown in
+<<privcombs>>.
+
+[[privcombs]]
+.Supported combination of privilege modes.
+[%autowidth,float="center",align="center",cols="^,<,<",options="header"]
+|===
+|Number of levels |Supported Modes |Intended Usage
+|1 +
+2 +
+3
+|M +
+M, U +
+M, S, U
+|Simple embedded systems +
+Secure embedded systems +
+Systems running Unix-like operating systems
+|===
+
+All hardware implementations must provide M-mode, as this is the only
+mode that has unfettered access to the whole machine. The simplest
+RISC-V implementations may provide only M-mode, though this will provide
+no protection against incorrect or malicious application code.
+
+[NOTE]
+====
+The lock feature of the optional PMP facility can provide some limited
+protection even with only M-mode implemented.
+====
+Many RISC-V implementations will also support at least user mode
+(U-mode) to protect the rest of the system from application code.
+Supervisor mode (S-mode) can be added to provide isolation between a
+supervisor-level operating system and the SEE.
+
+A hart normally runs application code in U-mode until some trap (e.g., a
+supervisor call or a timer interrupt) forces a switch to a trap handler,
+which usually runs in a more privileged mode. The hart will then execute
+the trap handler, which will eventually resume execution at or after the
+original trapped instruction in U-mode. Traps that increase privilege
+level are termed _vertical_ traps, while traps that remain at the same
+privilege level are termed _horizontal_ traps. The RISC-V privileged
+architecture provides flexible routing of traps to different privilege
+layers.
+
+[NOTE]
+====
+Horizontal traps can be implemented as vertical traps that return
+control to a horizontal trap handler in the less-privileged mode.
+====
+
+=== Debug Mode
+
+Implementations may also include a debug mode to support off-chip
+debugging and/or manufacturing test. Debug mode (D-mode) can be
+considered an additional privilege mode, with even more access than
+M-mode. The separate debug specification describes operation of
+a RISC-V hart in debug mode. Debug mode reserves a few CSR addresses
+that are only accessible in D-mode, and may also reserve some portions
+of the physical address space on a platform.
diff --git a/src/priv-intro.tex b/src/priv-intro.tex
deleted file mode 100644
index 764e258..0000000
--- a/src/priv-intro.tex
+++ /dev/null
@@ -1,224 +0,0 @@
-\chapter{Introduction}
-
-{\em This is a draft of the privileged architecture description
- document for RISC-V. Feedback welcome. Changes will occur before
- the final release. }
-
-This document describes the RISC-V privileged architecture, which
-covers all aspects of RISC-V systems beyond the user-level ISA,
-including privileged instructions as well as additional functionality
-required for running operating systems and attaching external devices.
-
-\begin{commentary}
-Commentary on our design decisions is formatted as in this paragraph,
-and can be skipped if the reader is only interested in the
-specification itself.
-\end{commentary}
-
-\begin{commentary}
-We briefly note that the entire privileged-level design described in
-this document could be replaced with an entirely different
-privileged-level design without changing the user-level ISA, and
-possibly without even changing the ABI. In particular, this
-privileged specification was designed to run existing popular
-operating systems, and so embodies the conventional level-based
-protection model. Alternate privileged specifications could embody
-other more flexible protection-domain models.
-\end{commentary}
-
-\section{RISC-V Privileged Software Stack Terminology}
-
-This section describes the terminology we use to describe components
-of the wide range of possible privileged software stacks for RISC-V.
-
-Figure~\ref{fig:privimps} shows some of the possible software stacks
-that can be supported by the RISC-V architecture. The left-hand side
-shows a simple system that supports only a single application running
-on an application execution environment (AEE). The application is
-coded to run with a particular application binary interface (ABI).
-The ABI includes the supported user-level ISA plus a set of ABI calls to
-interact with the AEE. The ABI hides details of the AEE from the
-application to allow greater flexibility in implementing the AEE. The
-same ABI could be implemented natively on multiple different host OSs,
-or could be supported by a user-mode emulation environment running on
-a machine with a different native ISA.
-
-\begin{figure}[th]
-\centering
-\includegraphics[width=\textwidth]{figs/privimps.pdf}
-\caption{Different implementation stacks supporting various forms of
- privileged execution.}
-\label{fig:privimps}
-\end{figure}
-
-\begin{commentary}
-Our graphical convention represents abstract interfaces using black
-boxes with white text, to separate them from concrete instances of
-components implementing the interfaces.
-\end{commentary}
-
-The middle configuration shows a conventional operating system (OS)
-that can support multiprogrammed execution of multiple
-applications. Each application communicates over an ABI with the OS,
-which provides the AEE. Just as applications interface with an AEE
-via an ABI, RISC-V operating systems interface with a supervisor
-execution environment (SEE) via a supervisor binary interface (SBI).
-An SBI comprises the user-level and supervisor-level ISA together with
-a set of SBI function calls. Using a single SBI across all SEE
-implementations allows a single OS binary image to run on any SEE.
-The SEE can be a simple boot loader and BIOS-style IO system in a
-low-end hardware platform, or a hypervisor-provided virtual machine in
-a high-end server, or a thin translation layer over a host operating
-system in an architecture simulation environment.
-
-\begin{commentary}
-Most supervisor-level ISA definitions do not separate the SBI from the
-execution environment and/or the hardware platform, complicating
-virtualization and bring-up of new hardware platforms.
-\end{commentary}
-
-The rightmost configuration shows a virtual machine monitor
-configuration where multiple multiprogrammed OSs are supported by a
-single hypervisor. Each OS communicates via an SBI with the
-hypervisor, which provides the SEE. The hypervisor communicates with
-the hypervisor execution environment (HEE) using a hypervisor binary
-interface (HBI), to isolate the hypervisor from details of the
-hardware platform.
-
-\begin{commentary}
-The ABI, SBI, and HBI are still a work-in-progress, but we are now
-prioritizing support for Type-2 hypervisors where the SBI is provided
-recursively by an S-mode OS.
-\end{commentary}
-
-Hardware implementations of the RISC-V ISA will generally require
-additional features beyond the privileged ISA to support the various
-execution environments (AEE, SEE, or HEE).
-
-\section{Privilege Levels}
-
-At any time, a RISC-V hardware thread ({\em hart}) is running at some
-privilege level encoded as a mode in one or more CSRs (control and
-status registers). Three RISC-V privilege levels are currently defined
-as shown in Table~\ref{privlevels}.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|c|c|c|c|}
- \hline
- Level & Encoding & Name & Abbreviation \\ \hline
- 0 & \tt 00 & User/Application & U \\
- 1 & \tt 01 & Supervisor & S \\
- 2 & \tt 10 & {\em Reserved} & \\
- 3 & \tt 11 & Machine & M \\
- \hline
- \end{tabular}
-\end{center}
-\caption{RISC-V privilege levels.}
-\label{privlevels}
-\end{table*}
-
-Privilege levels are used to provide protection between different
-components of the software stack, and attempts to perform operations
-not permitted by the current privilege mode will cause an exception to
-be raised. These exceptions will normally cause traps into an
-underlying execution environment.
-
-The machine level has the highest privileges and is the only mandatory
-privilege level for a RISC-V hardware platform. Code run in
-machine-mode (M-mode) is usually inherently trusted, as it has
-low-level access to the machine implementation. M-mode can be used to
-manage secure execution environments on RISC-V. User-mode (U-mode)
-and supervisor-mode (S-mode) are intended for conventional application
-and operating system usage respectively.
-
-\begin{commentary}
-The previous Hypervisor mode (H-mode) designed to support Type-1
-hypervisors has been removed and the encoding space reserved as we are
-focusing on hypervisor support via an extended S mode suitable for
-both Type-1 and Type-2 hypervisors as described in
-Chapter~\ref{hypervisor}. The encoding space for H is reserved for
-future use and to avoid backwards incompatible changes in bit
-positions in various status registers. The bit positions might be
-reused in the future for different Type-1 hypervisor support or
-possibly additional secure execution modes.
-\end{commentary}
-
-Each privilege level has a core set of privileged ISA extensions with optional
-extensions and variants. For example, machine-mode supports an optional
-standard extension for memory protection. Also, supervisor mode can be
-extended to support Type-2 hypervisor execution as described in
-Chapter~\ref{hypervisor}.
-
-Implementations might provide anywhere from 1 to 3 privilege modes
-trading off reduced isolation for lower implementation cost, as shown
-in Table~\ref{privcombs}.
-
-\begin{commentary}
-In the description, we try to separate the {\em privilege level} for
-which code is written, from the {\em privilege mode} in which it runs,
-although the two are often tied. For example, a supervisor-level
-operating system can run in supervisor-mode on a system with three
-privilege modes, but can also run in user-mode under a classic virtual
-machine monitor on systems with two or more privilege modes. In both
-cases, the same supervisor-level operating system binary code can be
-used, coded to a supervisor-level SBI and hence expecting to be able
-to use supervisor-level privileged instructions and CSRs. When
-running a guest OS in user mode, all supervisor-level actions will be
-trapped and emulated by the SEE running in the higher-privilege level.
-\end{commentary}
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|c|l|l|}
- \hline
- Number of levels & Supported Modes & Intended Usage \\ \hline
- 1 & M & Simple embedded systems \\
- 2 & M, U & Secure embedded systems \\
- 3 & M, S, U & Systems running Unix-like operating systems\\
- \hline
- \end{tabular}
-\end{center}
-\caption{Supported combinations of privilege modes.}
-\label{privcombs}
-\end{table*}
-
-All hardware implementations must provide M-mode, as this is the only
-mode that has unfettered access to the whole machine. The simplest
-RISC-V implementations may provide only M-mode, though this will
-provide no protection against incorrect or malicious application code.
-
-\begin{commentary}
- The lock feature of the optional PMP facility can provide some
- limited protection even with only M-mode implemented.
-\end{commentary}
-
-Many RISC-V implementations will also support at least user mode
-(U-mode) to protect the rest of the system from application code.
-Supervisor mode (S-mode) can be added to provide isolation between a
-supervisor-level operating system and the SEE.
-
-A hart normally runs application code in U-mode until some trap (e.g.,
-a supervisor call or a timer interrupt) forces a switch to a trap
-handler, which usually runs in a more privileged mode. The hart will
-then execute the trap handler, which will eventually resume execution
-at or after the original trapped instruction in U-mode. Traps that
-increase privilege level are termed {\em vertical} traps, while traps
-that remain at the same privilege level are termed {\em horizontal}
-traps. The RISC-V privileged architecture provides flexible routing
-of traps to different privilege layers.
-
-\begin{commentary}
-Horizontal traps can be implemented as vertical traps that
-return control to a horizontal trap handler in the less-privileged mode.
-\end{commentary}
-
-\section{Debug Mode}
-
-Implementations may also include a debug mode to support off-chip
-debugging and/or manufacturing test. Debug mode (D-mode) can be
-considered an additional privilege mode, with even more access than
-M-mode. The separate debug specification proposal describes operation
-of a RISC-V hart in debug mode. Debug mode reserves a few CSR
-addresses that are only accessible in D-mode, and may also reserve
-some portions of the physical memory space on a platform.
diff --git a/src/priv-preface.adoc b/src/priv-preface.adoc
new file mode 100644
index 0000000..a6292bf
--- /dev/null
+++ b/src/priv-preface.adoc
@@ -0,0 +1,597 @@
+[colophon]
+== Preface
+
+This document describes the RISC-V privileged architecture.
+It contains the following versions of the RISC-V ISA modules,
+all of which have been ratified:
+
+[%autowidth,float="center",align="center",cols="^,<",options="header",]
+|===
+|Module |Version
+|*Machine ISA* +
+*Smstateen Extension* +
+*Smcsrind/Sscsrind Extension* +
+*Smepmp Extension* +
+*Smcntrpmf Extension* +
+*Smrnmi Extension* +
+*Smcdeleg Extension* +
+*Smdbltrp Extension* +
+*Smctr Extension* +
+*Supervisor ISA* +
+*Svade Extension* +
+*Svnapot Extension* +
+*Svpbmt Extension* +
+*Svinval Extension* +
+*Svadu Extension* +
+*Svvptc Extension* +
+*Ssqosid Extension* +
+*Sstc Extension* +
+*Sscofpmf Extension* +
+*Ssdbltrp Extension* +
+*Ssqosid Extension* +
+*Hypervisor ISA* +
+*Shlcofideleg Extension* +
+*Svvptc Extension* +
+*Pointer-Masking Extensions* +
+*Svrsw60t59b Extension*
+
+|*1.13* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.13* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0*
+|===
+
+The following changes have been made since version 20250508:
+
+* Addition of the Svrsw60t59b extension for additional PTE reserved-for-software bits.
+
+// Had to make the above a level 1 heading (two equals signs) to avoid error when building
+// the ISA manual as a book with other "parts". This is opposite to what the adoc says to do
+// but otherwise asciidoctor creates the error message:
+//
+// asciidoctor: ERROR: ext/riscv-isa-manual/src/priv-preface.adoc: line 2: invalid part, must have at least one section (e.g., chapter, appendix, etc.)
+//
+// See asciidoctor doc which seems wrong: https://docs.asciidoctor.org/asciidoc/latest/sections/colophon/
+[.big]*_Preface to Version 20250508_*
+
+This document describes the RISC-V privileged architecture.
+
+The ISA modules marked *Ratified* have been ratified at this time. The
+modules marked _Frozen_ are not expected to change significantly before
+being put up for ratification. The modules marked _Draft_ are expected
+to change before ratification.
+
+The document contains the following versions of the RISC-V ISA modules:
+
+[%autowidth,float="center",align="center",cols="^,<,^",options="header",]
+|===
+|Module |Version |Status
+|*Machine ISA* +
+*Smstateen Extension* +
+*Smcsrind/Sscsrind Extension* +
+*Smepmp Extension* +
+*Smcntrpmf Extension* +
+*Smrnmi Extension* +
+*Smcdeleg Extension* +
+*Smdbltrp Extension* +
+*Smctr Extension* +
+*Supervisor ISA* +
+*Svade Extension* +
+*Svnapot Extension* +
+*Svpbmt Extension* +
+*Svinval Extension* +
+*Svadu Extension* +
+*Svvptc Extension* +
+*Ssqosid Extension* +
+*Sstc Extension* +
+*Sscofpmf Extension* +
+*Ssdbltrp Extension* +
+*Ssqosid Extension* +
+*Hypervisor ISA* +
+*Shlcofideleg Extension* +
+*Svvptc Extension* +
+*Pointer-Masking Extensions*
+
+|*1.13* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.13* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0*
+
+|*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified*
+|===
+
+The following changes have been made since version 20241101:
+
+* Addition of the Smctr Control Transfer Records extension.
+* Addition of the Svvptc Extension for Obviating Memory-Management Instructions after Marking PTEs Valid.
+* Addition of the Ssqosid Extension for Quality-of-Service Identifiers.
+* Addition of the Pointer-Masking Extensions.
+
+[.big]*_Preface to Version 20241101_*
+
+This document describes the RISC-V privileged architecture.
+
+The ISA modules marked *Ratified* have been ratified at this time. The
+modules marked _Frozen_ are not expected to change significantly before
+being put up for ratification. The modules marked _Draft_ are expected
+to change before ratification.
+
+The document contains the following versions of the RISC-V ISA modules:
+
+[%autowidth,float="center",align="center",cols="^,<,^",options="header",]
+|===
+|Module |Version |Status
+|*Machine ISA* +
+*Smstateen Extension* +
+*Smcsrind/Sscsrind Extension* +
+*Smepmp Extension* +
+*Smcntrpmf Extension* +
+*Smrnmi Extension* +
+*Smcdeleg Extension* +
+*Smdbltrp Extension* +
+*Supervisor ISA* +
+*Svade Extension* +
+*Svnapot Extension* +
+*Svpbmt Extension* +
+*Svinval Extension* +
+*Svadu Extension* +
+*Sstc Extension* +
+*Sscofpmf Extension* +
+*Ssdbltrp Extension* +
+*Ssqosid Extension* +
+*Hypervisor ISA* +
+*Shlcofideleg Extension* +
+*Svvptc Extension*
+
+|*1.13* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.13* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0*
+
+|*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified*
+|===
+
+[.big]*_Preface to Version 20241017_*
+
+This document describes the RISC-V privileged architecture. This
+release, version 20241017, contains the following versions of the RISC-V ISA
+modules:
+
+[%autowidth,float="center",align="center",cols="^,<,^",options="header",]
+|===
+|Module |Version |Status
+|*Machine ISA* +
+*Smstateen Extension* +
+*Smcsrind/Sscsrind Extension* +
+*Smepmp* +
+*Smcntrpmf* +
+*Smrnmi Extension* +
+*Smcdeleg* +
+*Smdbltrp* +
+*Supervisor ISA* +
+*Svade Extension* +
+*Svnapot Extension* +
+*Svpbmt Extension* +
+*Svinval Extension* +
+*Svadu Extension* +
+*Sstc* +
+*Sscofpmf* +
+*Ssdbltrp* +
+*Hypervisor ISA* +
+*Shlcofideleg* +
+*Svvptc*
+
+|*1.13* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.13* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0*
+
+|*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified*
+|===
+
+The following changes have been made since version 1.12 of the Machine and
+Supervisor ISAs, which, while not strictly backwards compatible, are not
+anticipated to cause software portability problems in practice:
+
+* Redefined `misa`.MXL to be read-only, making MXLEN a constant.
+* Added the constraint that SXLEN&#8805;UXLEN.
+
+Additionally, the following compatible changes have been
+made to the Machine and Supervisor ISAs since version 1.12:
+
+* Defined the `misa`.B field to reflect that the B extension has been
+implemented.
+* Defined the `misa`.V field to reflect that the V extension has been
+implemented.
+* Defined the RV32-only `medelegh` and `hedelegh` CSRs.
+* Defined the misaligned atomicity granule PMA, superseding the proposed Zam
+ extension.
+* Allocated interrupt 13 for Sscofpmf LCOFI interrupt.
+* Defined hardware-error and software-check exception codes.
+* Specified synchronization requirements when changing the PBMTE and ADUE fields
+in `menvcfg` and `henvcfg`.
+* Exposed count-overflow interrupts to VS-mode via the Shlcofideleg extension.
+* Relaxed behavior of some HINTs when MXLEN > XLEN.
+
+Finally, the following clarifications and document improvements have been made
+since the last document release:
+
+* Transliterated the document from LaTeX into AsciiDoc.
+* Included all ratified extensions through March 2024.
+* Clarified that "platform- or custom-use" interrupts are actually
+"platform-use interrupts", where the platform can choose to make some custom.
+* Clarified semantics of explicit accesses to CSRs wider than XLEN bits.
+* Clarified that MXLEN&#8805;SXLEN.
+* Clarified that WFI is not a HINT instruction.
+* Clarified that VS-stage page-table accesses set G-stage A/D bits.
+* Clarified ordering rules when PBMT=IO is used on main-memory regions.
+* Clarified ordering rules for hardware A/D bit updates.
+* Clarified that, for a given exception cause, `__x__tval` might sometimes
+be set to a nonzero value but sometimes not.
+* Clarified exception behavior of unimplemented or inaccessible CSRs.
+* Clarified that Svpbmt allows implementations to override additional PMAs.
+* Replaced the concept of vacant memory regions with inaccessible memory or I/O regions.
+* Clarified that timer and count-overflow interrupts' arrival in
+ interrupt-pending registers is not immediate.
+* Clarified that MXR affects only explicit memory accesses.
+
+[.big]*_Preface to Version 20211203_*
+
+This document describes the RISC-V privileged architecture. This
+release, version 20211203, contains the following versions of the RISC-V
+ISA modules:
+
+[%autowidth,float="center",align="center",cols="^,<,^",options="header",]
+|===
+|Module |Version |Status
+|*Machine ISA* +
+*Supervisor ISA* +
+*Svnapot Extension* +
+*Svpbmt Extension* +
+*Svinval Extension* +
+*Hypervisor ISA* +
+|*1.12* +
+*1.12* +
+*1.0* +
+*1.0* +
+*1.0* +
+*1.0* +
+|*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified* +
+*Ratified*
+|===
+
+The following changes have been made since version 1.11, which, while
+not strictly backwards compatible, are not anticipated to cause software
+portability problems in practice:
+
+* Changed MRET and SRET to clear `mstatus`.MPRV when leaving M-mode.
+* Reserved additional `satp` patterns for future use.
+* Stated that the `scause` Exception Code field must implement bits 4–0
+at minimum.
+* Relaxed I/O regions have been specified to follow RVWMO. The previous
+specification implied that PPO rules other than fences and
+acquire/release annotations did not apply.
+* Constrained the LR/SC reservation set size and shape when using
+page-based virtual memory.
+* PMP changes require an SFENCE.VMA on any hart that implements
+page-based virtual memory, even if VM is not currently enabled.
+* Allowed for speculative updates of page table entry A bits.
+* Clarify that if the address-translation algorithm non-speculatively
+reaches a PTE in which a bit reserved for future standard use is set, a
+page-fault exception must be raised.
+
+Additionally, the following compatible changes have been made since
+version 1.11:
+
+* Removed the N extension.
+* Defined the mandatory RV32-only CSR `mstatush`, which contains most of
+the same fields as the upper 32 bits of RV64’s `mstatus`.
+* Defined the mandatory CSR `mconfigptr`, which if nonzero contains the
+address of a configuration data structure.
+* Defined optional `mseccfg` and `mseccfgh` CSRs, which control the
+machine’s security configuration.
+* Defined `menvcfg`, `henvcfg`, and `senvcfg` CSRs (and RV32-only
+`menvcfgh` and `henvcfgh` CSRs), which control various characteristics
+of the execution environment.
+* Designated part of SYSTEM major opcode for custom use.
+* Permitted the unconditional delegation of less-privileged interrupts.
+* Added optional big-endian and bi-endian support.
+* Made priority of load/store/AMO address-misaligned exceptions
+implementation-defined relative to load/store/AMO page-fault and
+access-fault exceptions.
+* PMP reset values are now platform-defined.
+* An additional 48 optional PMP registers have been defined.
+* Slightly relaxed the atomicity requirement for A and D bit updates
+performed by the implementation.
+* Clarify the architectural behavior of address-translation caches
+* Added Sv57 and Sv57x4 address translation modes.
+* Software breakpoint exceptions are permitted to write either 0 or the
+`pc` to `__x__tval`.
+* Clarified that bare S-mode need not support the SFENCE.VMA
+instruction.
+* Specified relaxed constraints for implicit reads of non-idempotent
+regions.
+* Added the Svnapot Standard Extension, along with the N bit in Sv39,
+Sv48, and Sv57 PTEs.
+* Added the Svpbmt Standard Extension, along with the PBMT bits in Sv39,
+Sv48, and Sv57 PTEs.
+* Added the Svinval Standard Extension and associated instructions.
+
+Finally, the hypervisor architecture proposal has been extensively
+revised.
+
+[.big]*_Preface to Version 1.11_*
+
+This is version 1.11 of the RISC-V privileged architecture. The document
+contains the following versions of the RISC-V ISA modules:
+
+[%autowidth,float="center",align="center",cols="^,<,^",options="header",]
+|===
+|Module |Version |Status
+|*Machine ISA* +
+*Supervisor ISA* +
+_Hypervisor ISA_
+|*1.11* +
+*1.11* +
+_0.3_
+|*Ratified* +
+*Ratified* +
+_Draft_
+|===
+
+Changes from version 1.10 include:
+
+* Moved Machine and Supervisor spec to *Ratified* status.
+* Improvements to the description and commentary.
+* Added a draft proposal for a hypervisor extension.
+* Specified which interrupt sources are reserved for standard use.
+* Allocated some synchronous exception causes for custom use.
+* Specified the priority ordering of synchronous exceptions.
+* Added specification that xRET instructions may, but are not required
+to, clear LR reservations if A extension present.
+* The virtual-memory system no longer permits supervisor mode to execute
+instructions from user pages, regardless of the SUM setting.
+* Clarified that ASIDs are private to a hart, and added commentary about
+the possibility of a future global-ASID extension.
+* SFENCE.VMA semantics have been clarified.
+* Made the `mstatus`.MPP field *WARL*, rather than *WLRL*.
+* Made the unused `__x__ip` fields *WPRI*, rather than *WIRI*.
+* Made the unused `misa` fields *WARL*, rather than *WIRI*.
+* Made the unused `pmpaddr` and `pmpcfg` fields *WARL*, rather than *WIRI*.
+* Required all harts in a system to employ the same PTE-update scheme as
+each other.
+* Rectified an editing error that misdescribed the mechanism by which
+`mstatus.__x__IE` is written upon an exception.
+* Described scheme for emulating misaligned AMOs.
+* Specified the behavior of the `misa` and `__x__epc` registers in systems
+with variable IALIGN.
+* Specified the behavior of writing self-contradictory values to the
+`misa` register.
+* Defined the `mcountinhibit` CSR, which stops performance counters from
+incrementing to reduce energy consumption.
+* Specified semantics for PMP regions coarser than four bytes.
+* Specified contents of CSRs across XLEN modification.
+* Moved PLIC chapter into its own document.
+
+[.big]*_Preface to Version 1.10_*
+
+This is version 1.10 of the RISC-V privileged architecture proposal.
+Changes from version 1.9.1 include:
+
+* The previous version of this document was released under a Creative
+Commons Attribution 4.0 International License by the original authors,
+and this and future versions of this document will be released under the
+same license.
+* The explicit convention on shadow CSR addresses has been removed to
+reclaim CSR space. Shadow CSRs can still be added as needed.
+* The `mvendorid` register now contains the JEDEC code of the core
+provider as opposed to a code supplied by the Foundation. This avoids
+redundancy and offloads work from the Foundation.
+* The interrupt-enable stack discipline has been simplified.
+* An optional mechanism to change the base ISA used by supervisor and
+user modes has been added to the `mstatus` CSR, and the field previously
+called Base in `misa` has been renamed to `MXL` for consistency.
+* Clarified expected use of XS to summarize additional extension state
+status fields in `mstatus`.
+* Optional vectored interrupt support has been added to the `mtvec` and
+`stvec` CSRs.
+* The SEIP and UEIP bits in the `mip` CSR have been redefined to support
+software injection of external interrupts.
+* The `mbadaddr` register has been subsumed by a more general `mtval`
+register that can now capture bad instruction bits on an illegal-instruction
+fault to speed instruction emulation.
+* The machine-mode base-and-bounds translation and protection schemes
+have been removed from the specification as part of moving the virtual
+memory configuration to `sptbr` (now `satp`). Some of the motivation for
+the base and bound schemes are now covered by the PMP registers, but
+space remains available in `mstatus` to add these back at a later date
+if deemed useful.
+* In systems with only M-mode, or with both M-mode and U-mode but
+without U-mode trap support, the `medeleg` and `mideleg` registers now
+do not exist, whereas previously they returned zero.
+* Virtual-memory page faults now have `mcause` values distinct from
+physical-memory access faults. Page-fault exceptions can now be
+delegated to S-mode without delegating exceptions generated by PMA and
+PMP checks.
+* An optional physical-memory protection (PMP) scheme has been proposed.
+* The supervisor virtual memory configuration has been moved from the
+`mstatus` register to the `sptbr` register. Accordingly, the `sptbr`
+register has been renamed to `satp` (Supervisor Address Translation and
+Protection) to reflect its broadened role.
+* The SFENCE.VM instruction has been removed in favor of the improved
+SFENCE.VMA instruction.
+* The `mstatus` bit MXR has been exposed to S-mode via `sstatus`.
+* The polarity of the PUM bit in `sstatus` has been inverted to shorten
+code sequences involving MXR. The bit has been renamed to SUM.
+* Hardware management of page-table entry Accessed and Dirty bits has
+been made optional; simpler implementations may trap to software to set
+them.
+* The counter-enable scheme has changed, so that S-mode can control
+availability of counters to U-mode.
+* H-mode has been removed, as we are focusing on recursive
+virtualization support in S-mode. The encoding space has been reserved
+and may be repurposed at a later date.
+* A mechanism to improve virtualization performance by trapping S-mode
+virtual-memory management operations has been added.
+* The Supervisor Binary Interface (SBI) chapter has been removed, so
+that it can be maintained as a separate specification.
+
+[.big]*_Preface to Version 1.9.1_*
+
+This is version 1.9.1 of the RISC-V privileged architecture proposal.
+Changes from version 1.9 include:
+
+* Numerous additions and improvements to the commentary sections.
+* Change configuration string proposal to be use a search process that
+supports various formats including Device Tree String and flattened
+Device Tree.
+* Made `misa` optionally writable to support modifying base and
+supported ISA extensions. CSR address of `misa` changed.
+* Added description of debug mode and debug CSRs.
+* Added a hardware performance monitoring scheme. Simplified the
+handling of existing hardware counters, removing privileged versions of
+the counters and the corresponding delta registers.
+* Fixed description of SPIE in presence of user-level interrupts.
diff --git a/src/priv-preface.tex b/src/priv-preface.tex
deleted file mode 100644
index 12292ce..0000000
--- a/src/priv-preface.tex
+++ /dev/null
@@ -1,126 +0,0 @@
-\chapter{Preface}
-
-This is {\bf a draft of} version 1.11 of the RISC-V privileged
-architecture proposal. Changes from version 1.10 include:
-
-\begin{itemize}
- \parskip 0pt
- \itemsep 1pt
-\item Improvements to the description and commentary.
-\item Added a draft proposal for a hypervisor extension.
-\item Specified which interrupt sources are reserved for standard use.
-\item Added specification that xRET instructions may, but are not
- required to, clear LR reservations if A extension present.
-\item The virtual-memory system no longer permits supervisor mode to execute
- instructions from user pages, regardless of the SUM setting.
-\item Made the {\tt mstatus}.MPP field \warl, rather than \wlrl.
-\item Made the unused {\em x}{\tt ip} fields \wpri, rather than \wiri.
-\item Made the unused {\tt misa} fields \wlrl, rather than \wiri.
-\item Made the unused {\tt pmpaddr} and {\tt pmpcfg} fields \warl, rather than \wiri.
-\item Required all harts in a system to employ the same PTE-update scheme as each other.
-\item Rectified an editing error that misdescribed the mechanism by which
- {\tt mstatus}.{\em x}IE is written upon an exception.
-\item Added the constraint that if a PMA supports LR, SC, or AMOs, but traps
- misaligned LR, SC, or AMOs, then it also must trap
- misaligned loads and stores.
-\item Specified the behavior of the {\tt misa} and {\em x}{\tt epc} registers in
- systems with variable IALIGN.
-\item Specified the behavior of writing self-contradictory values to the
- {\tt misa} register.
-\item Specified semantics for PMP regions coarser than four bytes.
-\item Specified contents of CSRs across XLEN modification.
-\end{itemize}
-
-\newpage
-
-\section*{Preface to Version 1.10}
-
-This is version 1.10 of the RISC-V privileged
-architecture proposal. Changes from version 1.9.1 include:
-
-\begin{itemize}
- \parskip 0pt
- \itemsep 1pt
-\item The previous version of this document was released under a
- Creative Commons Attribution 4.0 International License by the
- original authors, and this and future versions of this document will
- be released under the same license.
-\item The explicit convention on shadow CSR addresses has been removed
- to reclaim CSR space. Shadow CSRs can still be added as needed.
-\item The {\tt mvendorid} register now contains the JEDEC code of the
- core provider as opposed to a code supplied by the Foundation. This
- avoids redundancy and offloads work from the Foundation.
-\item The interrupt-enable stack discipline has been simplified.
-\item An optional mechanism to change the base ISA used by supervisor
- and user modes has been added to the {\tt mstatus} CSR, and the
- field previously called Base in {\tt misa} has been renamed to {\tt
- MXL} for consistency.
-\item Clarified expected use of XS to summarize additional extension
- state status fields in {\tt mstatus}.
-\item Optional vectored interrupt support has been added to the
- {\tt mtvec} and {\tt stvec} CSRs.
-\item The SEIP and UEIP bits in the {\tt mip} CSR have been redefined
- to support software injection of external interrupts.
- \item The {\tt mbadaddr} register has been subsumed by a more
- general {\tt mtval} register that can now capture bad
- instruction bits on an illegal instruction fault to speed
- instruction emulation.
-\item The machine-mode base-and-bounds translation and protection
- schemes have been removed from the specification as part of moving
- the virtual memory configuration to {\tt sptbr} (now {\tt satp}). Some of the
- motivation for the base and bound schemes are now covered by the PMP
- registers, but space remains available in {\tt mstatus} to add these
- back at a later date if deemed useful.
-\item In systems with only M-mode, or with both M-mode and U-mode but
- without U-mode trap support, the {\tt medeleg} and {\tt mideleg}
- registers now do not exist, whereas previously they returned zero.
-\item Virtual-memory page faults now have {\tt mcause} values distinct from
- physical-memory access exceptions. Page-fault exceptions can now be
- delegated to S-mode without delegating exceptions generated by PMA
- and PMP checks.
-\item An optional physical-memory protection (PMP) scheme has been proposed.
-\item The supervisor virtual memory configuration has been moved from the
- {\tt mstatus} register to the {\tt sptbr} register. Accordingly, the
- {\tt sptbr} register has been renamed to {\tt satp} (Supervisor Address
- Translation and Protection) to reflect its broadened role.
-\item The SFENCE.VM instruction has been removed in favor of the improved
- SFENCE.VMA instruction.
-\item The {\tt mstatus} bit MXR has been exposed to S-mode via {\tt sstatus}.
-\item The polarity of the PUM bit in {\tt sstatus} has been inverted to
- shorten code sequences involving MXR. The bit has been renamed to SUM.
-\item Hardware management of page-table entry Accessed and Dirty bits has
- been made optional; simpler implementations may trap to software to
- set them.
-\item The counter-enable scheme has changed, so that S-mode can
- control availability of counters to U-mode.
-\item H-mode has been removed, as we are focusing on recursive
- virtualization support in S-mode. The encoding space has been
- reserved and may be repurposed at a later date.
-\item A mechanism to improve virtualization performance by
- trapping S-mode virtual-memory management operations has been added.
-\item The Supervisor Binary Interface (SBI) chapter has been removed, so
- that it can be maintained as a separate specification.
-\end{itemize}
-
-\newpage
-
-\section*{Preface to Version 1.9.1}
-
-This is version 1.9.1 of the RISC-V privileged architecture
-proposal. Changes from version 1.9 include:
-
-\begin{itemize}
- \parskip 0pt
- \itemsep 1pt
-\item Numerous additions and improvements to the commentary sections.
-\item Change configuration string proposal to be use a search process
- that supports various formats including Device Tree String and
- flattened Device Tree.
-\item Made {\tt misa} optionally writable to support modifying base
- and supported ISA extensions. CSR address of {\tt misa} changed.
-\item Added description of debug mode and debug CSRs.
-\item Added a hardware performance monitoring scheme. Simplified the
- handling of existing hardware counters, removing privileged versions
- of the counters and the corresponding delta registers.
-\item Fixed description of SPIE in presence of user-level interrupts.
-\end{itemize}
diff --git a/src/q-st-ext.adoc b/src/q-st-ext.adoc
new file mode 100644
index 0000000..b4c7502
--- /dev/null
+++ b/src/q-st-ext.adoc
@@ -0,0 +1,113 @@
+== "Q" Extension for Quad-Precision Floating-Point, Version 2.2
+
+This chapter describes the Q standard extension for 128-bit
+quad-precision binary floating-point instructions compliant with the
+IEEE 754-2008 arithmetic standard. The quad-precision binary
+floating-point instruction-set extension is named "Q"; it depends on
+the double-precision floating-point extension D. The floating-point
+registers are now extended to hold either a single, double, or
+quad-precision floating-point value (FLEN=128). The NaN-boxing scheme
+described in <<nanboxing>> is now extended
+recursively to allow a single-precision value to be NaN-boxed inside a
+double-precision value which is itself NaN-boxed inside a quad-precision
+value.
+
+=== Quad-Precision Load and Store Instructions
+
+New 128-bit variants of LOAD-FP and STORE-FP instructions are added,
+encoded with a new value for the funct3 width field.
+
+include::images/wavedrom/quad-ls.edn[]
+[[quad-ls]]
+//.Quad-precision load and store
+
+FLQ and FSQ are only guaranteed to execute atomically if the effective
+address is naturally aligned and XLEN=128.
+
+FLQ and FSQ do not modify the bits being transferred; in particular, the
+payloads of non-canonical NaNs are preserved.
+
+=== Quad-Precision Computational Instructions
+
+A new supported format is added to the format field of most
+instructions, as shown in <<fpextfmt>>
+
+[[fpextfmt]]
+.Format field encoding.
+[%autowidth,float="center",align="center",cols="^,^,<",options="header",]
+|===
+|_fmt_ field |Mnemonic |Meaning
+|00 |S |32-bit single-precision
+|01 |D |64-bit double-precision
+|10 |H |16-bit half-precision
+|11 |Q |128-bit quad-precision
+|===
+
+The quad-precision floating-point computational instructions are defined
+analogously to their double-precision counterparts, but operate on
+quad-precision operands and produce quad-precision results.
+
+include::images/wavedrom/quad-compute.edn[]
+[[quad-compute]]
+//.Quad-precision computational
+
+=== Quad-Precision Convert and Move Instructions
+
+New floating-point-to-integer and integer-to-floating-point conversion
+instructions are added. These instructions are defined analogously to
+the double-precision-to-integer and integer-to-double-precision
+conversion instructions. FCVT.W.Q or FCVT.L.Q converts a quad-precision
+floating-point number to a signed 32-bit or 64-bit integer,
+respectively. FCVT.Q.W or FCVT.Q.L converts a 32-bit or 64-bit signed
+integer, respectively, into a quad-precision floating-point number.
+FCVT.WU.Q, FCVT.LU.Q, FCVT.Q.WU, and FCVT.Q.LU variants convert to or
+from unsigned integer values. FCVT.L[U].Q and FCVT.Q.L[U] are RV64-only
+instructions. Note FCVT.Q.L[U] always produces an exact result and is unaffected by rounding mode.
+
+include::images/wavedrom/quad-cnvrt-mv.edn[]
+[[quad-cnvrt-mv]]
+//.Quad-precision convert and move
+
+New floating-point-to-floating-point conversion instructions are added.
+These instructions are defined analogously to the double-precision
+floating-point-to-floating-point conversion instructions. FCVT.S.Q or
+FCVT.Q.S converts a quad-precision floating-point number to a
+single-precision floating-point number, or vice-versa, respectively.
+FCVT.D.Q or FCVT.Q.D converts a quad-precision floating-point number to
+a double-precision floating-point number, or vice-versa, respectively.
+
+include::images/wavedrom/quad-cnvt-interchange.edn[]
+[[quad-convert-interchange]]
+//.Quad-precision convert and move interchangeably
+
+Floating-point to floating-point sign-injection instructions, FSGNJ.Q,
+FSGNJN.Q, and FSGNJX.Q are defined analogously to the double-precision
+sign-injection instruction.
+
+include::images/wavedrom/quad-cnvrt-intch-xqqx.edn[]
+[[quad-cnvrt-intch-xqqx]]
+//.Quad-precision convert and move interchangeably XQ-QX
+
+FMV.X.Q and FMV.Q.X instructions are not provided in RV32 or RV64, so
+quad-precision bit patterns must be moved to the integer registers via
+memory.
+
+=== Quad-Precision Floating-Point Compare Instructions
+
+The quad-precision floating-point compare instructions are defined
+analogously to their double-precision counterparts, but operate on
+quad-precision operands.
+
+include::images/wavedrom/quad-float-compare.edn[]
+[[quad-float-compare]]
+//.Quad-precision floatinf-point compare
+
+=== Quad-Precision Floating-Point Classify Instruction
+
+The quad-precision floating-point classify instruction, FCLASS.Q, is
+defined analogously to its double-precision counterpart, but operates on
+quad-precision operands.
+
+include::images/wavedrom/quad-float-clssfy.edn[]
+[[quad-float-clssfy]]
+//.Quad-precision floating point classify
diff --git a/src/q.tex b/src/q.tex
deleted file mode 100644
index 44ab317..0000000
--- a/src/q.tex
+++ /dev/null
@@ -1,307 +0,0 @@
-\chapter{``Q'' Standard Extension for Quad-Precision Floating-Point,
- Version 2.0}
-
-This chapter describes the Q standard extension for 128-bit binary
-floating-point instructions compliant with the IEEE 754-2008
-arithmetic standard. The 128-bit or quad-precision binary
-floating-point instruction subset is named ``Q'', and requires
-RV64IFD. The floating-point registers are now extended to hold either
-a single, double, or quad-precision floating-point value (FLEN=128).
-The NaN-boxing scheme described in Section~\ref{nanboxing} is now
-extended recursively to allow a single-precision value to be NaN-boxed
-inside a double-precision value which is itself NaN-boxed inside a
-quad-precision value.
-
-\section{Quad-Precision Load and Store Instructions}
-
-New 128-bit variants of LOAD-FP and STORE-FP instructions are added,
-encoded with a new value for the funct3 width field.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{width} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-offset[11:0] & base & Q & dest & LOAD-FP \\
-\end{tabular}
-\end{center}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{O@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:5]} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{width} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-offset[11:5] & src & base & Q & offset[4:0] & STORE-FP \\
-\end{tabular}
-\end{center}
-
-FLQ and FSQ are only guaranteed to execute atomically if the effective address
-is naturally aligned and XLEN=128.
-
-FLQ and FSQ do not modify the bits being transferred; in particular, the
-payloads of non-canonical NaNs are preserved.
-
-\section{Quad-Precision Computational Instructions}
-
-A new supported format is added to the format field of most
-instructions, as shown in Table~\ref{tab:fpextfmt}.
-
-\begin{table}[htp]
-\begin{center}
-\begin{tabular}{|c|c|l|}
-\hline
-{\em fmt} field &
-Mnemonic &
-Meaning \\
-\hline
-00 & S & 32-bit single-precision \\
-01 & D & 64-bit double-precision \\
-10 & H & 16-bit half-precision \\
-11 & Q & 128-bit quad-precision \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Format field encoding.}
-\label{tab:fpextfmt}
-\end{table}
-
-The quad-precision floating-point computational instructions are
-defined analogously to their double-precision counterparts, but operate on
-quad-precision operands and produce quad-precision results.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FADD/FSUB & Q & src2 & src1 & RM & dest & OP-FP \\
-FMUL/FDIV & Q & src2 & src1 & RM & dest & OP-FP \\
-FMIN-MAX & Q & src2 & src1 & MIN/MAX & dest & OP-FP \\
-FSQRT & Q & 0 & src & RM & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{rs3} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-src3 & Q & src2 & src1 & RM & dest & F[N]MADD/F[N]MSUB \\
-\end{tabular}
-\end{center}
-
-\section{Quad-Precision Convert and Move Instructions}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCVT.{\em int}.Q & Q & W[U]/L[U] & src & RM & dest & OP-FP \\
-FCVT.Q.{\em int} & Q & W[U]/L[U] & src & RM & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-New floating-point to floating-point conversion instructions FCVT.S.Q,
-FCVT.Q.S, FCVT.D.Q, FCVT.Q.D are added.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCVT.S.Q & S & Q & src & RM & dest & OP-FP \\
-FCVT.Q.S & Q & S & src & RM & dest & OP-FP \\
-FCVT.D.Q & D & Q & src & RM & dest & OP-FP \\
-FCVT.Q.D & Q & D & src & RM & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-Floating-point to floating-point sign-injection instructions, FSGNJ.Q,
-FSGNJN.Q, and FSGNJX.Q are defined analogously to the double-precision
-sign-injection instruction.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FSGNJ & Q & src2 & src1 & J[N]/JX & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-FMV.X.Q and FMV.Q.X instructions are not provided in RV32 or RV64, so
-quad-precision bit patterns must be moved to the integer registers via
-memory.
-
-\begin{commentary}
-RV128 will support FMV.X.Q and FMV.Q.X in the Q extension.
-\end{commentary}
-
-\section{Quad-Precision Floating-Point Compare Instructions}
-
-The quad-precision floating-point compare instructions are
-defined analogously to their double-precision counterparts, but operate on
-quad-precision operands.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCMP & Q & src2 & src1 & EQ/LT/LE & dest & OP-FP \\
-\end{tabular}
-\end{center}
-
-\section{Quad-Precision Floating-Point Classify Instruction}
-
-The quad-precision floating-point classify instruction, FCLASS.Q, is
-defined analogously to its double-precision counterpart, but operates on
-quad-precision operands.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}F@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct5} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{rm} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-5 & 2 & 5 & 5 & 3 & 5 & 7 \\
-FCLASS & Q & 0 & src & 001 & dest & OP-FP \\
-\end{tabular}
-\end{center}
diff --git a/src/rationale.adoc b/src/rationale.adoc
new file mode 100644
index 0000000..52bcac5
--- /dev/null
+++ b/src/rationale.adoc
@@ -0,0 +1,62 @@
+[appendix]
+== Historical Rationale for Extensions
+[[chap:rationale]]
+
+This appendix contains the rationale for RISC-V ISA extensions at the time they
+were ratified.
+Unlike the ISA specification, this appendix is ordered chronologically, so as
+to convey the motivation and architectural reasoning underpinning each
+extension at the time of ratification.
+For extensions ratified prior to the conception of this appendix (ca. 2025),
+the rationale will be added over time.
+In cases where the rationale was not recorded, the authors and editors will
+synthesize it from the historical record.
+
+=== "Zihintpause" Extension for Pause Hint
+
+The PAUSE instruction hints to a hart that it should temporarily reduce its
+rate of execution.
+It is normally used to save energy and execution resources while polling, e.g.
+while waiting for a spinlock to become free.
+
+Much of the debate surrounding this extension centered on whether a facility
+similar to x86's MONITOR/MWAIT should instead be provided.
+We concluded that, even if such a facility were to be defined for RISC-V,
+it would not supplant PAUSE.
+PAUSE is more appropriate when polling for non-memory events, when polling for
+multiple events, or when software does not know precisely what events it is
+polling for.
+(Perhaps surprisingly, the latter case is ubiquitous, in part because it is
+the mechanism expected by the Linux kernel's `cpu_relax` API.)
+
+=== "Zicond" Extension for Integer Conditional Operations
+
+Replacing unpredictable branches with conditional-select or conditional-move
+instructions can mitigate a class of costly branch mispredictions.
+Unfortunately, conditional-select instructions require three source operands.
+These instructions are a logical addition to ISAs that include three-source
+integer instructions for other reasons, but are too costly otherwise.
+
+Some ISAs have instead furnished conditional-move instructions, which consume
+less encoding space and avoid the extra register read in simple
+microarchitectures.
+Unfortunately, in register-renamed microarchitectures, these instructions incur
+costs simlar to conditional select, or require additional microarchitectural
+structures and micro-op-issue constraints.
+
+The Zicond extension was defined to solve the same problem as conditional
+select and conditional move, but with very little incremental cost for complex
+microarchitectures.
+It provides conditional-zero instructions, which read two source operands and,
+based upon the zeroness of the second operand, produce either the first operand
+or zero.
+These instructions can be used as part of a three-instruction sequence to
+synthesize conditional select.
+Several common conditional-execution idioms require only two instructions,
+as would be the case with conditional select or move, including
+conditional addition, subtraction, and bitwise AND, OR, and XOR.
+
+Two conditional-zero instructions are included: one that writes zero if the
+comparand is zero, and one that does so if the comparand is nonzero.
+Variants that perform magnitude comparisons with zero were considered but
+ultimately excluded for insufficient quantitative justification.
diff --git a/src/resources/riscv-spec.bib b/src/resources/riscv-spec.bib
new file mode 100644
index 0000000..d5b77d3
--- /dev/null
+++ b/src/resources/riscv-spec.bib
@@ -0,0 +1,1804 @@
+@Misc{ieee754-2008,
+ key = "{IEEE}",
+ title = "{ANSI/IEEE Std 754-2008}, {IEEE} standard for
+ floating-point arithmetic",
+ publisher = {"Institute of Electrical and Electronic Engineers"},
+ year = 2008
+}
+
+@inproceedings{riscI-isca1981,
+ title = {{RISC I}: {A} Reduced Instruction Set {VLSI} Computer},
+ author = {David A. Patterson and Carlo H. S\'{e}quin},
+ booktitle = {ISCA},
+ location = {Minneapolis, Minnesota, USA},
+ pages = {443-458},
+ year = {1981}
+}
+
+@InProceedings{Katevenis:1983,
+ author = {Katevenis, Manolis G.H. and Sherburne,Jr., Robert W. and Patterson, David A. and S{\'e}quin, Carlo H.},
+ title = {The {RISC II} micro-architecture},
+ booktitle = {Proceedings VLSI 83 Conference},
+ year = 1983,
+ month = {August}}
+
+@article{Katevenis:1984,
+ author = {Katevenis, Manolis G.H. and Sherburne,Jr., Robert W. and Patterson, David A. and S{\'e}quin, Carlo H.},
+ title = {The {RISC II} micro-architecture},
+ journal = {Advances in VLSI and Computer Systems},
+ issue_date = {Fall 1984},
+ volume = {1},
+ number = {2},
+ month = October,
+ year = {1984},
+ pages = {138--152},
+ publisher = {Computer Science Press, Inc.},
+ address = {New York, NY, USA},
+}
+
+@inproceedings{Ungar:1984,
+ author = {David Ungar and Ricki Blau and Peter Foley and Dain Samples
+ and David Patterson},
+ title = {Architecture of {SOAR}: {Smalltalk} on a {RISC}},
+ booktitle = {ISCA},
+ address = {Ann Arbor, MI},
+ year = {1984},
+ pages = {188--197}
+}
+
+@Article{spur-jsscc1989,
+ author = {David D. Lee and Shing I. Kong and Mark D. Hill and
+ George S. Taylor and David A. Hodges and Randy
+ H. Katz and David A. Patterson},
+ title = {A {VLSI} Chip Set for a Multiprocessor
+ Workstation--{Part I}: An {RISC} Microprocessor with
+ Coprocessor Interface and Support for Symbolic
+ Processing},
+ journal = {IEEE JSSC},
+ year = 1989,
+ volume = 24,
+ number = 6,
+ pages = {1688--1698},
+ month = {December}}
+
+@MastersThesis{waterman-ms,
+ author = {Andrew Waterman},
+ title = {{Improving Energy Efficiency and Reducing Code Size with RISC-V Compressed}},
+ school = {University of California, Berkeley},
+ year = 2011,
+ Number = {UCB/EECS-2011-63},
+}
+
+@phdthesis{waterman-phd,
+ Author = {Waterman, Andrew},
+ Title = {Design of the {RISC-V} Instruction Set Architecture},
+ School = {University of California, Berkeley},
+ Year = {2016},
+ Number = {UCB/EECS-2016-1},
+}
+
+@TechReport{riscvtr,
+ author = {Andrew Waterman and Yunsup Lee and David A. Patterson and Krste Asanovi\'{c}},
+ title = {The {RISC-V} Instruction Set Manual, {Volume I}: {Base}
+ User-Level {ISA}},
+ institution = {EECS Department, University of California, Berkeley},
+ year = 2011,
+ number = {UCB/EECS-2011-62},
+ month = {May}}
+
+
+
+@Book{kane:mips:1991,
+ author = {G. Kane and J. Heinrich},
+ title = {MIPS RISC Architecture},
+ publisher = {Prentice Hall},
+ month = {September},
+ year = 1991,
+ note = {ISBN 0135904722},
+ edition = {2nd}
+}
+
+@book{patterson:undergrad:2008,
+ author = {D. A. Patterson and J. L. Hennessy},
+ title = {Computer Organization and Design: The
+ Hardware/Software Interface},
+ edition = {4th},
+ publisher = {Morgan Kaufmann},
+ month = {November},
+ year = {2008},
+ note = {ISBN 0123744938}
+}
+
+@Book{sweetman:mips:2006,
+ author = {D. Sweetman},
+ title = {See {MIPS} Run},
+ edition = {2nd},
+ publisher = {Morgan Kaufmann},
+ year = {2006},
+ month = {October},
+ note = {ISBN 0120884216}
+}
+
+@Misc{mips:arch:2010,
+ author = {MIPS Technologies Inc.},
+ title = {{MIPS32} Architecture for Programmers},
+ year = {2010},
+ note = {\verb!https://www.imgtec.com/mips/architectures/mips32/!}
+}
+
+@Misc{sgi:mipspro:1997,
+ author = {Silicon Graphics Inc.},
+ title = {{MIPSpro} 64-{B}it Porting and Translation Guide},
+ year = {1997},
+ note = {\verb!http://techpubs.sgi.com/!}
+}
+
+@Misc{openriscarch,
+ author = {OpenCores},
+ title = {{OpenRISC} 1000 Architecture Manual, Architecture
+ Version 1.0},
+ month = {December},
+ year = 2012}
+
+@ARTICLE{tremblay-vis-ieeemicro1996,
+author={Tremblay, M. and O'Connor, J.M. and Narayanan, V. and Liang He},
+journal={IEEE Micro},
+title={{VIS} speeds new media processing},
+year={1996},
+month=AUG,
+volume={16},
+number={4},
+pages={10 -20},
+keywords={3D graphics environments;RISC-style instructions;UltraSparc;VIS;Visual Instruction Set;media processing;media-processing algorithms;computer graphics;instruction sets;reduced instruction set computing;},
+ISSN={0272-1732},}
+
+@ARTICLE{lee-max-ieeemicro1996,
+author={Lee, R.B.},
+journal={IEEE Micro},
+title={Subword parallelism with {MAX-2}},
+year={1996},
+month=AUG,
+volume={16},
+number={4},
+pages={51 -59},
+keywords={MAX-2;instruction extensions;media processing;parallel computation;subword parallelism;word-oriented general-purpose processor;instruction sets;multimedia computing;parallel processing;},
+ISSN={0272-1732},}
+
+@ARTICLE{peleg-mmx-ieeemicro1996,
+author={Peleg, A. and Weiser, U.},
+journal={IEEE Micro},
+title={{MMX} technology extension to the {Intel} architecture},
+year={1996},
+month=AUG,
+volume={16},
+number={4},
+pages={42 -50},
+keywords={Intel architecture;MMX;SIMD;communications;compatibility;multimedia;operating systems;microprocessor chips;parallel architectures;},
+ISSN={0272-1732},}
+
+@ARTICLE{raman-sse-ieeemicro2000,
+author={Raman, S.K. and Pentkovski, V. and Keshava, J.},
+journal={IEEE Micro},
+title={Implementing streaming {SIMD} extensions on the {Pentium}-{III} processor },
+year={2000},
+month=JUL/AUG,
+volume={20},
+number={4},
+pages={47 -57},
+keywords={Internet;Pentium III developers;demanding multimedia;die size constraints;streaming SIMD extensions;instruction sets;microprocessor chips;},
+ISSN={0272-1732},}
+
+@misc{lomont-avx-irm2011,
+author={Chris Lomont},
+title = {Introduction to {Intel Advanced Vector Extensions}},
+howpublished = {Intel White Paper},
+year = {2011},
+}
+
+@ARTICLE{goodacre-armisa-computer2005,
+author={Goodacre, J. and Sloss, A.N.},
+journal={Computer},
+title={Parallelism and the {ARM} instruction set architecture},
+year={2005},
+month=JULY,
+volume={38},
+number={7},
+pages={ 42 - 50},
+keywords={ ARM RISC processor; ARM chip design; ARM instruction set architecture; digital signal processor-like operations; exception handling; multiprocessing; reduced-instruction-set computing; subword parallelism; thread-level parallelism; variable execution time; instruction sets; microprocessor chips; parallel architectures; parallel programming; reduced instruction set computing;},
+ISSN={0018-9162},}
+
+@ARTICLE{diefendorff-altivec-ieeemicro2000,
+author={Diefendorff, K. and Dubey, P.K. and Hochsprung, R. and Scale, H.},
+journal={IEEE Micro},
+title={{AltiVec} extension to {PowerPC} accelerates media processing},
+year={2000},
+month=MAR/APR,
+volume={20},
+number={2},
+pages={85 -95},
+keywords={2D image processing;3D graphics;AltiVec extension;Apple G4;Hewlett-Packard added MAX;MDMX;MIPS architecture;MMX;Motorola's MPC 7400;PA-RISC architecture;PowerPC;PowerPC's AltiVec;SSE;Silicon Graphics;Sun enhanced Sparc;alias KNI;handwriting recognition;media mining;media processing;multimedia technologies;narrow/broadband signal processing;personal computing;digital signal processing chips;handwriting recognition;multimedia systems;parallel architectures;},
+ISSN={0272-1732},}
+
+@misc{gwennap-mdmx-mpr1996,
+author={Linley Gwennap},
+title={Digital, {MIPS} Add Multimedia Extensions},
+howpublished = {Microprocessor Report},
+year = {1996},
+}
+@article{majc,
+ author = {Tremblay, Marc and Chan, Jeffrey and Chaudhry, Shailender and Conigliaro, Andrew W. and Tse, Shing Sheung},
+ title = {The {MAJC} Architecture: {A} Synthesis of Parallelism and Scalability},
+ journal = {IEEE Micro},
+ issue_date = {November 2000},
+ volume = {20},
+ number = {6},
+ month = November,
+ year = {2000},
+ pages = {12--25},
+ publisher = {IEEE Computer Society Press},
+ address = {Los Alamitos, CA, USA},
+}
+
+@InProceedings{tx2,
+ author = {John M. Frankovich and H. Philip Peterson},
+ title = {A functional description of the {Lincoln} {TX-2} computer},
+ booktitle = {Western Joint Computer Conference},
+ year = 1957,
+ address = {Los Angeles, CA},
+ month = {February}
+}
+
+
+@TechReport{heil-tr1996,
+ author = {Timothy H. Heil and James E. Smith},
+ title = {Selective Dual Path Execution},
+ institution = {University of Wisconsin - Madison},
+ year = 1996,
+ month = {November}}
+
+@inproceedings{Klauser-1998,
+ author = {Klauser, A. and Austin, T. and Grunwald, D. and Calder, B.},
+ title = {Dynamic Hammock Predication for Non-Predicated Instruction Set Architectures},
+ booktitle = {Proceedings of the 1998 International Conference on Parallel Architectures and Compilation Techniques},
+ series = {PACT '98},
+ year = {1998},
+ address = {Washington, DC, USA},
+}
+
+@inproceedings{Kim-micro2005,
+ author = {Kim, Hyesoon and Mutlu, Onur and Stark, Jared and Patt, Yale N.},
+ title = {Wish Branches: Combining Conditional Branching and Predication for Adaptive Predicated Execution},
+ booktitle = {Proceedings of the 38th annual IEEE/ACM International Symposium on Microarchitecture},
+ series = {MICRO 38},
+ year = {2005},
+ location = {Barcelona, Spain},
+ pages = {43--54},
+}
+
+@INPROCEEDINGS{Gharachorloo90memoryconsistency,
+ author = {Kourosh Gharachorloo and Daniel Lenoski and James Laudon
+ and Phillip Gibbons and Anoop Gupta and John
+ Hennessy},
+ title = {Memory Consistency and Event Ordering in Scalable
+ Shared-Memory Multiprocessors},
+ booktitle = {In Proceedings of the 17th Annual International
+ Symposium on Computer Architecture},
+ year = {1990},
+ pages = {15--26}
+}
+
+
+@inproceedings{Rajwar:2001:SLE,
+ author = {Rajwar, Ravi and Goodman, James R.},
+ title = {Speculative lock elision: enabling highly concurrent multithreaded execution},
+ booktitle = {Proceedings of the 34th annual ACM/IEEE International Symposium on Microarchitecture},
+ series = {MICRO 34},
+ year = {2001},
+ location = {Austin, Texas},
+ pages = {294--305},
+ publisher = {IEEE Computer Society},
+}
+
+@Misc{sparcieee1994,
+ title = {{IEEE} Standard for a 32-bit microprocessor},
+ howpublished = {IEEE Std. 1754-1994},
+ year = 1994}
+
+
+@Book{parisckane1995,
+ author = {Gerry Kane},
+ title = {PA-RISC 2.0 Architecture},
+ publisher = {Prentice Hall},
+ year = 1995,
+ month = {December},
+ note = {ISBN 978-0131827349}}
+
+@article{ibmpower7,
+ title={{IBM} {POWER7} multicore server processor},
+ author={Sinharoy, Balaram and Kalla, R. and Starke, W. J. and Le,
+ H. Q. and Cargnoni, R. and Van Norstrand, J. A. and
+ Ronchetti, B. J. and Stuecheli, J. and Leenstra,
+ J. and Guthrie, G. L. and Nguyen, D. Q. and Blaner,
+ B. and Marino, C. F. and Retter, E. and Williams, P.},
+ journal={IBM Journal of Research and Development},
+ volume={55},
+ number={3},
+ pages={1--1},
+ year={2011},
+ publisher={IBM}
+}
+
+@article{virtio,
+ author = {Russell, Rusty},
+ title = {Virtio: {Towards} a De-facto Standard for Virtual {I/O} Devices},
+ journal = {SIGOPS Oper. Syst. Rev.},
+ issue_date = {July 2008},
+ volume = {42},
+ number = {5},
+ month = jul,
+ year = {2008},
+ issn = {0163-5980},
+ pages = {95--103},
+ numpages = {9},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
+
+@ARTICLE{goldbergvm,
+author={Goldberg, Robert P.},
+journal={Computer},
+title={Survey of virtual machine research},
+year={1974},
+month={June},
+volume={7},
+number={6},
+pages={34-45}
+}
+
+@Manual{alphapalcode,
+ title = {{PALcode} for {Alpha} microprocessors: System Design
+ Guide},
+ organization = {Digital Equipment Corporation},
+ address = {Maynard, Massachusetts},
+ note = {EC-QFGLC-TE},
+ month = {May},
+ year = 1996}
+
+@article{transparent-superpages,
+ author = {Navarro, Juan and Iyer, Sitaram and Druschel, Peter and Cox, Alan},
+ title = {Practical, Transparent Operating System Support for Superpages},
+ journal = {SIGOPS Oper. Syst. Rev.},
+ issue_date = {Winter 2002},
+ volume = {36},
+ number = {SI},
+ month = dec,
+ year = {2002},
+ issn = {0163-5980},
+ pages = {89--104},
+ numpages = {16},
+ url = {https://doi.org/10.1145/844128.844138},
+ doi = {10.1145/844128.844138},
+ acmid = {844138},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+}
+
+@Book{stretch,
+ author = "Werner Buchholz",
+ title = {Planning a computer system: {Project} {Stretch}},
+ publisher = {McGraw-Hill Book Company},
+ year = 1962
+ }
+
+@Article{ibm360,
+ author = {G. M. Amdahl and G. A. Blaauw and F. P. Brooks, Jr.},
+ title = {Architecture of the {IBM} {System/360}},
+ journal = {IBM Journal of R. \& D.},
+ year = 1964,
+ volume = 8,
+ number = 2
+}
+
+@inproceedings{cdc6600,
+ author = {Thornton, James E.},
+ title = {Parallel Operation in the {Control Data 6600}},
+ booktitle = {Proceedings of the October 27-29, 1964, Fall Joint Computer Conference, Part II: Very High Speed Computer Systems},
+ series = {AFIPS '64 (Fall, part II)},
+ year = {1965},
+ location = {San Francisco, California},
+ pages = {33--40}
+}
+
+@InProceedings{jtseng:sbbci,
+ author = {J. Tseng and K. Asanovi\'c},
+ title = {Energy-Efficient Register Access},
+ booktitle = {Proc. of the 13th Symposium on Integrated Circuits and
+ Systems Design},
+ address = {Manaus, Brazil},
+ month = {September},
+ year = 2000,
+ pages = "377--384"
+}
+
+@TechReport{riscvtr2,
+ author = {Andrew Waterman and Yunsup Lee and David A. Patterson and Krste Asanovi\'{c}},
+ title = {The {RISC-V} Instruction Set Manual, {Volume I}: {Base}
+ User-Level {ISA} Version 2.0},
+ institution = {EECS Department, University of California, Berkeley},
+ year = 2014,
+ number = {UCB/EECS-2014-54},
+ month = {May}}
+
+@Article{ibm370varch,
+ author = {W. Buchholz},
+ title = "{The IBM System/370 vector architecture}",
+ journal = {IBM Systems Journal},
+ year = 1986,
+ volume = 25,
+ number = 1,
+ pages = {51--62}
+}
+
+@PhdThesis{krstephd,
+ author = {Krste Asanovi\'c},
+ title = {Vector Microprocessors},
+ school = {University of California at Berkeley},
+ year = 1998,
+ month = {May},
+ note = {Available as techreport UCB/CSD-98-1014}
+}
+
+@InProceedings{vp200,
+ author = "Kenichi Miura and Keiichiro Uchida",
+ title = "{FACOM Vector Processor System: VP-100/VP-200}",
+ editor = "Kawalik",
+ volume = "F7",
+ booktitle = "Proceedings of NATO Advanced Research Workshop on
+ High Speed Computing",
+ year = 1984,
+ publisher = "Springer-Verlag",
+ note = "Also in: IEEE Tutorial Supercomputers: Design and
+ Applications. Kai Hwang(editor), pp59-73"
+}
+@Manual{crayx1asm,
+ title = {Cray Assembly Language {(CAL)} for {Cray} {X1} Systems Reference Manual},
+ organization = {Cray Inc.},
+ edition = {1.1},
+ month = {June},
+ year = 2003}
+}
+
+@misc{riscv-elf-psabi,
+ title = {{RISC-V ELF psABI Specification}},
+ howpublished = {\url{https://github.com/riscv/riscv-elf-psabi-doc/}}
+}
+
+@misc{riscv-asm-manual,
+ key = "{assembly manual}",
+ title = {RISC-V Assembly Programmer's Manual},
+ howpublished = {\url{https://github.com/riscv/riscv-asm-manual}}
+}
+
+
+@inproceedings{lithe-pan-hotpar09,
+author = {Heidi Pan and Benjamin Hindman and Krste Asanovi\'c},
+title = {{Lithe}: Enabling Efficient Composition of Parallel Libraries},
+booktitle = {Proceedings of the 1st USENIX Workshop on Hot Topics in Parallelism (HotPar~'09)},
+month = {March},
+year = {2009},
+address = {Berkeley, CA}}
+
+
+@inproceedings{lithe-pan-pldi10,
+author = {Heidi Pan and Benjamin Hindman and Krste Asanovi\'c},
+title = {Composing Parallel Software Efficiently with {Lithe}},
+booktitle = {31st Conference on Programming Language Design and Implementation},
+month = {June},
+year = {2010},
+address = {Toronto, Canada}}
+
+@article{roux:hal-01091186,
+ TITLE = {{Innocuous Double Rounding of Basic Arithmetic Operations}},
+ AUTHOR = {Roux, Pierre},
+ URL = {https://hal.archives-ouvertes.fr/hal-01091186},
+ JOURNAL = {{Journal of Formalized Reasoning}},
+ PUBLISHER = {{ASDD-AlmaDL}},
+ VOLUME = {7},
+ NUMBER = {1},
+ PAGES = {131-142},
+ YEAR = {2014},
+ MONTH = Nov,
+ DOI = {10.6092/issn.1972-5787/4359},
+ KEYWORDS = {Coq ; double rounding ; floating-point arithmetic},
+ PDF = {https://hal.archives-ouvertes.fr/hal-01091186/file/submission.pdf},
+ HAL_ID = {hal-01091186},
+ HAL_VERSION = {v1},
+}
+
+@electronic{unpriv,
+ title = {RISC-V Instruction Set Manual, Volume I: Unprivileged ISA },
+ url = {https://github.com/riscv/riscv-isa-manual},
+ year = {}
+}
+@inproceedings{queue,
+ author = {Michael, Maged M. and Scott, Michael L.},
+ title = {Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms},
+ year = {1996},
+ isbn = {0897918002},
+ publisher = {Association for Computing Machinery},
+ address = {New York, NY, USA},
+ url = {https://doi.org/10.1145/248052.248106},
+ doi = {10.1145/248052.248106},
+ booktitle = {Proceedings of the Fifteenth Annual ACM Symposium on Principles of Distributed Computing},
+ pages = {267–275},
+ numpages = {9},
+ keywords = {multiprogramming, compare_and_swap, non-blocking, concurrent queue, lock-free},
+ location = {Philadelphia, Pennsylvania, USA},
+ series = {PODC '96}
+}
+
+// Bibliographical refs from Crypto
+
+
+%
+% RISC-V Specifications and draft specifications
+% -----------------------------------------------------------------
+
+@misc{riscv:policy:encodings,
+ title={RISC-V Instruction Encoding Allocation Policy},
+ url={https://docs.google.com/document/d/1uC6QAyFmglGbO9kRR-X8LQWga6B3yBJR7-iw6ZXnfG8/edit#}
+}
+
+@misc{riscv:bitmanip:repo,
+ title = {RISC-V Bit manipulation extension repository},
+ url = {https://github.com/riscv/riscv-bitmanip}
+}
+
+@misc{riscv:bitmanip:draft,
+ title = {RISC-V Bit manipulation extension draft proposal},
+ url = {https://github.com/riscv/riscv-bitmanip/blob/master/bitmanip-draft.pdf}
+}
+
+@article{riscv:spec:user,
+ title={The RISC-V instruction set manual},
+ author={Waterman, Andrew and Lee, Yunsup and Patterson, David and Asanovic, Krste},
+ journal={Volume I: User-Level ISA', version},
+ volume={2},
+ year={2014}
+}
+
+@misc{sail,
+ title = {SAIL ISA Specification Language},
+ url = {https://github.com/rems-project/sail}
+}
+
+@inproceedings{LSYRR:04,
+ title={On permutation operations in cipher design},
+ author={Lee, Ruby B and Shi, ZJ and Yin, Yiqun Lisa and Rivest, Ronald L and Robshaw, Matthew JB},
+ booktitle={International Conference on Information Technology: Coding and Computing, 2004. Proceedings. ITCC 2004.},
+ volume={2},
+ pages={569--577},
+ year={2004},
+ organization={IEEE}
+}
+%
+% NIST Specifications and recommendations
+% -----------------------------------------------------------------
+
+@misc{nist:gcm,
+ author = {Morris Dworkin},
+ title = {Recommendation for Block Cipher Modes of Operation:
+ {Galois}/{Counter} {Mode} ({GCM}) and {GMAC}},
+ howpublished = {NIST Special Publication SP 800-38D},
+ url = {https://doi.org/10.6028/NIST.SP.800-38D},
+ month = {November},
+ year = {2007}
+}
+
+
+@misc{nist:fips:186:4,
+ author = {{NIST}},
+ title = {Digital Signature Standard (DSS)},
+ howpublished = {Federal Information Processing Standards Publication FIPS 186-4},
+ url = {https://doi.org/10.6028/NIST.FIPS.186-4},
+ month = {July},
+ year = {2013}
+}
+
+@misc{nist:fips:197,
+ author = {{NIST}},
+ title = {{Advanced} {Encryption} {Standard} ({AES})},
+ howpublished = {Federal Information Processing Standards Publication FIPS
+ 197},
+ url = {https://doi.org/10.6028/NIST.FIPS.197},
+ month = {November},
+ year = {2001}
+}
+
+
+@misc{nist:fips:180:4,
+ author = {{NIST}},
+ title = {Secure Hash Standard ({SHS})},
+ howpublished = {Federal Information Processing Standards Publication FIPS 180-4},
+ url = {https://doi.org/10.6028/NIST.FIPS.180-4},
+ month = {August},
+ year = {2015}
+}
+
+@misc{nist:fips:202,
+ author = {{NIST}},
+ title = {{SHA}-3 Standard: Permutation-Based Hash and Extendable-Output Functions},
+ howpublished = {Federal Information Processing Standards Publication FIPS
+ 202},
+ url = {https://doi.org/10.6028/NIST.FIPS.202},
+ month = {August},
+ year = {2015}
+}
+
+%
+% PRC Standards (which are also ISO/IEC standards)
+% -----------------------------------------------------------------
+
+
+@Misc{gbt:sm3,
+ title = {{GB}/{T} 32905-2016: {SM3} Cryptographic Hash Algorithm},
+ howpublished = {Also {GM}/{T} 0004-2012. Standardization Administration of China},
+ url = {http://www.gmbz.org.cn/upload/2018-07-24/1532401392982079739.pdf},
+ month = {August},
+ year = {2016}
+}
+
+@Misc{gbt:sm4,
+ title = {{GB}/{T} 32907-2016: {SM4} Block Cipher Algorithm},
+ howpublished = {Also {GM}/{T} 0002-2012. Standardization Administration of China},
+ url = {http://www.gmbz.org.cn/upload/2018-04-04/1522788048733065051.pdf},
+ month = {August},
+ year = {2016}
+}
+
+@Misc{iso:sm3,
+ author = {ISO/IEC},
+ title = {IT Security techniques -- Hash-functions -- Part 3:
+ Dedicated hash-functions},
+ howpublished = {{ISO}/{IEC} Standard 10118-3:2018},
+ year = {2018}
+}
+
+@Misc{iso:sm4,
+ author = {ISO/IEC},
+ title = {Information technology -- Security techniques --
+ Encryption algorithms -- Part 3: Block ciphers. {Amendment}
+ 2: {SM4}},
+ howpublished = {{ISO}/{IEC} Standard 18033-3:2010/DAmd 2 (en)},
+ year = {2018}
+}
+
+
+%
+% Miscellaneous Technical Reports
+% -----------------------------------------------------------------
+
+@techreport{MPP:19,
+ author = {Ben Marshall and Daniel Page and Thinh Pham},
+ title = {{XCrypto}: a cryptographic {ISE} for {RISC-V}},
+ number = {1.0.0},
+ year = {2019},
+ url = {https://github.com/scarv/xcrypto}
+}
+
+%
+% Academic Papers: Misc
+% -----------------------------------------------------------------
+
+
+@article{MNPSW:20,
+title={The design of scalar AES Instruction Set Extensions for RISC-V},
+volume={2021},
+url={https://tches.iacr.org/index.php/TCHES/article/view/8729},
+DOI={10.46586/tches.v2021.i1.109-136},
+number={1},
+journal={IACR Transactions on Cryptographic Hardware and Embedded Systems},
+author={Marshall, Ben and Newell, G. Richard and Page, Dan and Saarinen, Markku-Juhani O. and Wolf, Claire},
+year={2020},
+month={Dec.},
+pages={109-136}
+}
+
+@inproceedings{TGMGD:19,
+ author = {Etienne Tehrani and Tarik Graba and Abdelmalek Si Merabet and Sylvain Guilley and Jean-Luc Danger},
+ title = {Classification of Lightweight Block Ciphers for Specific Processor Accelerated Implementations},
+ year = {2019},
+ month = {11},
+ booktitle = {26th IEEE International Conference on Electronics Circuits and Systems}
+}
+
+@inproceedings{TG:06,
+ title={Instruction set extensions for efficient AES implementation on 32-bit processors},
+ author={Tillich, Stefan and Gro{\ss}sch{\"a}dl, Johann},
+ booktitle={International workshop on cryptographic hardware and embedded systems},
+ pages={270--284},
+ year={2006},
+ organization={Springer}
+}
+
+@inproceedings{DPUVGB:16,
+ title={Design strategies for ARX with provable bounds: Sparx and LAX},
+ author={Dinu, Daniel and Perrin, L{\'e}o and Udovenko, Aleksei and Velichkov, Vesselin and Gro{\ss}sch{\"a}dl, Johann and Biryukov, Alex},
+ booktitle={International Conference on the Theory and Application of Cryptology and Information Security},
+ pages={484--513},
+ year={2016},
+ organization={Springer}
+}
+
+@inproceedings{LSYRR:04,
+ title={On permutation operations in cipher design},
+ author={Lee, Ruby B and Shi, ZJ and Yin, Yiqun Lisa and Rivest, Ronald L and Robshaw, Matthew JB},
+ booktitle={International Conference on Information Technology: Coding and Computing, 2004. Proceedings. ITCC 2004.},
+ volume={2},
+ pages={569--577},
+ year={2004},
+ organization={IEEE}
+}
+
+@article{CDPA:16,
+ title={The Renewed Case for the Reduced Instruction Set Computer: Avoiding ISA Bloat with Macro-Op Fusion for RISC-V},
+ author={Celio, Christopher and Dabbelt, Palmer and Patterson, David A and Asanovi{\'c}, Krste},
+ journal={arXiv preprint arXiv:1607.02318},
+ year={2016}
+}
+
+
+
+%
+% Block Cipher Specifications
+% -----------------------------------------------------------------
+
+@inproceedings{block:prince,
+ title={PRINCE--a low-latency block cipher for pervasive computing applications},
+ author={Borghoff, Julia and Canteaut, Anne and G{\"u}neysu, Tim and Kavun, Elif Bilge and Knezevic, Miroslav and Knudsen, Lars R and Leander, Gregor and Nikov, Ventzislav and Paar, Christof and Rechberger, Christian and others},
+ booktitle={International Conference on the Theory and Application of Cryptology and Information Security},
+ pages={208--225},
+ year={2012},
+ organization={Springer}
+}
+
+@inproceedings{block:present,
+ title={PRESENT: An ultra-lightweight block cipher},
+ author={Bogdanov, Andrey and Knudsen, Lars R and Leander, Gregor and Paar, Christof and Poschmann, Axel and Robshaw, Matthew JB and Seurin, Yannick and Vikkelsoe, Charlotte},
+ booktitle={International workshop on cryptographic hardware and embedded systems},
+ pages={450--466},
+ year={2007},
+ organization={Springer}
+}
+
+@incollection{block:salsa20,
+ title={The Salsa20 family of stream ciphers},
+ author={Bernstein, Daniel J},
+ booktitle={New stream cipher designs},
+ pages={84--97},
+ year={2008},
+ publisher={Springer}
+}
+
+@article{block:rectangle,
+ title={RECTANGLE: a bit-slice lightweight block cipher suitable for multiple platforms},
+ author={Zhang, Wentao and Bao, Zhenzhen and Lin, Dongdai and Rijmen, Vincent and Yang, Bohan and Verbauwhede, Ingrid},
+ journal={Science China Information Sciences},
+ volume={58},
+ number={12},
+ pages={1--15},
+ year={2015},
+ publisher={Springer}
+}
+
+@inproceedings{block:gift,
+ title={GIFT: a small present},
+ author={Banik, Subhadeep and Pandey, Sumit Kumar and Peyrin, Thomas and Sasaki, Yu and Sim, Siang Meng and Todo, Yosuke},
+ booktitle={International Conference on Cryptographic Hardware and Embedded Systems},
+ pages={321--345},
+ year={2017},
+ organization={Springer}
+}
+
+@inproceedings{block:twine,
+ title={TWINE: A Lightweight Block Cipher for Multiple Platforms},
+ author={Suzaki, Tomoyasu and Minematsu, Kazuhiko and Morioka, Sumio and Kobayashi, Eita},
+ booktitle={International Conference on Selected Areas in Cryptography},
+ pages={339--354},
+ year={2012},
+ organization={Springer}
+}
+
+@inproceedings{block:skinny,
+ title={The SKINNY family of block ciphers and its low-latency variant MANTIS},
+ author={Beierle, Christof and Jean, J{\'e}r{\'e}my and K{\"o}lbl, Stefan and Leander, Gregor and Moradi, Amir and Peyrin, Thomas and Sasaki, Yu and Sasdrich, Pascal and Sim, Siang Meng},
+ booktitle={Annual International Cryptology Conference},
+ pages={123--153},
+ year={2016},
+ organization={Springer}
+}
+
+@inproceedings{block:midori,
+ title={Midori: A block cipher for low energy},
+ author={Banik, Subhadeep and Bogdanov, Andrey and Isobe, Takanori and Shibutani, Kyoji and Hiwatari, Harunaga and Akishita, Toru and Regazzoni, Francesco},
+ booktitle={International Conference on the Theory and Application of Cryptology and Information Security},
+ pages={411--436},
+ year={2015},
+ organization={Springer}
+}
+
+@inproceedings{block:camellia,
+ title={Camellia: A 128-bit block cipher suitable for multiple platforms—design andanalysis},
+ author={Aoki, Kazumaro and Ichikawa, Tetsuya and Kanda, Masayuki and Matsui, Mitsuru and Moriai, Shiho and Nakajima, Junko and Tokita, Toshio},
+ booktitle={International Workshop on Selected Areas in Cryptography},
+ pages={39--56},
+ year={2000},
+ organization={Springer}
+}
+
+@inproceedings{block:aria,
+ title={New block cipher: ARIA},
+ author={Kwon, Daesung and Kim, Jaesung and Park, Sangwoo and Sung, Soo Hak and Sohn, Yaekwon and Song, Jung Hwan and Yeom, Yongjin and Yoon, E-Joong and Lee, Sangjin and Lee, Jaewon and others},
+ booktitle={International Conference on Information Security and Cryptology},
+ pages={432--445},
+ year={2003},
+ organization={Springer}
+}
+
+
+
+%
+% Online references
+% -----------------------------------------------------------------
+
+@misc{MJS:LWAES:20,
+ author = "Markku-Juhani O. Saarinen",
+ title = "Lightweight AES ISA",
+ howpublished = "\url{https://github.com/mjosaarinen/lwaes_isa}",
+ year = "2020",
+ month = "01",
+ note = "Retrieved 24th January, 2020.",
+}
+
+@misc{MJS:LWSHA:20,
+ author = "Markku-Juhani O. Saarinen",
+ title = "Lightweight SHA ISA",
+ howpublished = "\url{https://github.com/mjosaarinen/lwsha_isa}",
+ year = "2020",
+ month = "03",
+ note = "Retrieved 26th March, 2020.",
+}
+
+
+@article{tls:1.3,
+ title={The transport layer security (TLS) protocol version 1.3},
+ author={Rescorla, Eric and Dierks, Tim},
+ year={2018},
+ month={August},
+ publisher={DOI 10.17487/RFC8446}
+}
+
+
+%
+% Mostly academic, bibtool sorted (2020-07-08 mjos)
+% -----------------------------------------------------------------
+
+
+@Misc{ AM17,
+ author = {{AMD}},
+ title = {{AMD} Random Number Generator},
+ howpublished = {AMD TechDocs},
+ publisher = {Advanced Micro Devices},
+ url = {https://www.amd.com/system/files/TechDocs/amd-random-number-generator.pdf},
+ month = {June},
+ year = {2017}
+}
+
+@Misc{ AR17,
+ author = {{ARM}},
+ title = {ARM TrustZone True Random Number Generator: Technical Reference Manual},
+ howpublished = {ARM 100976\_0000\_00\_en (rev. r0p0)},
+ publisher = {{ARM}},
+ url = {http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100976_0000_00_en},
+ month = {May},
+ year = {2017}
+}
+
+@Misc{ AR20,
+ author = {{ARM}},
+ title = {Arm Architecture Registers: Armv8, for Armv8-A
+ architecture profile},
+ howpublished = {ARM DDI 0595 (ID033020)},
+ publisher = {{ARM}},
+ url = {https://developer.arm.com/docs/ddi0595/g},
+ month = {April},
+ year = {2020}
+}
+
+@Book{ An20,
+ author = {Ross J. Anderson},
+ title = {Security engineering - a guide to building dependable
+ distributed systems {(3.} ed.)},
+ publisher = {Wiley},
+ isbn = {978-1-119-64278-7},
+ url = {https://www.cl.cam.ac.uk/~rja14/book.html},
+ month = {December},
+ year = {2020}
+}
+
+@Misc{ BS13,
+ author = {{BSI}},
+ title = {Evaluation of random number generators},
+ howpublished = {Version 0.10, BSI},
+ url = {https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_20_AIS_31_Evaluation_of_random_number_generators_e.html},
+ publisher = {BSI},
+ month = {March},
+ year = {2013}
+}
+
+@Misc{ Ba20,
+ author = {Elaine Barker},
+ title = {Recommendation for Key Management: Part 1 -- General},
+ howpublished = {NIST Special Publication SP 0 Part 1, Revision 5},
+ doi = {10.6028/NIST.SP.800-57pt1r5},
+ publisher = {{NIST}},
+ month = {May},
+ year = {2020}
+}
+
+@Article{ Ba86,
+ author = {Per Bak},
+ title = {The Devil's Staircase},
+ journal = {Phys. Today},
+ volume = {39},
+ number = {12},
+ pages = {38--45},
+ doi = {10.1063/1.881047},
+ publisher = {{AIP}},
+ month = {December},
+ year = {1986}
+}
+
+@Misc{ BaBa19,
+ author = {Elaine Barker and William Barker},
+ title = {Recommendation for Key Management: Part 2 -- Best
+ Practices for Key Management Organizations},
+ howpublished = {NIST Special Publication SP 800-57 Part 2, Revision 1},
+ doi = {10.6028/NIST.SP.800-57pt2r1},
+ publisher = {{NIST}},
+ month = {May},
+ year = {2019}
+}
+
+@Misc{ BaDa15,
+ author = {Elaine Barker and Quynh Dang},
+ title = {Recommendation for Key Management, Part 3:
+ Application-Specific Key Management Guidance},
+ howpublished = {NIST Special Publication SP 800-57 Part 3, Revision 1},
+ doi = {10.6028/NIST.SP.800-57pt3r1},
+ publisher = {{NIST}},
+ month = {January},
+ year = {2015}
+}
+
+@InProceedings{ BaFoKa:12,
+ author = {Romain Bardou and Riccardo Focardi and Yusuke Kawamoto and
+ Lorenzo Simionato and Graham Steel and Joe{-}Kai Tsay},
+ title = {Efficient Padding Oracle Attacks on Cryptographic
+ Hardware},
+ booktitle = {Advances in Cryptology - {CRYPTO} 2012 - 32nd Annual
+ Cryptology Conference, Santa Barbara, CA, USA, August
+ 19-23, 2012. Proceedings},
+ pages = {608--625},
+ crossref = {_SaCa12},
+ doi = {10.1007/978-3-642-32009-5\_36},
+ year = {2012}
+}
+
+@Misc{ BaKe15,
+ author = {Elaine Barker and John Kelsey},
+ title = {Recommendation for Random Number Generation Using
+ Deterministic Random Bit Generators},
+ howpublished = {NIST Special Publication SP 800-90A Revision 1},
+ doi = {10.6028/NIST.SP.800-90Ar1},
+ month = {June},
+ year = {2015}
+}
+
+@Misc{ BaKeRo:21,
+ author = {Elaine Barker and John Kelsey and Allen Roginsky and
+ Meltem Sönmez Turan and Darryl Buller and Aaron Kaufer},
+ title = {Recommendation for Random Bit Generator ({RBG})
+ Constructions},
+ howpublished = {Draft NIST Special Publication SP 800-90C},
+ month = {March},
+ year = {2021}
+}
+
+@Article{ BaLuMi:11,
+ author = {Mathieu Baudet and David Lubicz and Julien Micolod and
+ Andr{\'{e}} Tassiaux},
+ title = {On the Security of Oscillator-Based Random Number
+ Generators},
+ journal = {J. Cryptology},
+ volume = {24},
+ number = {2},
+ pages = {398--425},
+ doi = {10.1007/s00145-010-9089-3},
+ year = {2011}
+}
+
+@Article{ BeRePa:14,
+ author = {Georg T. Becker and Francesco Regazzoni and Christof Paar
+ and Wayne P. Burleson},
+ title = {Stealthy dopant-level hardware Trojans: extended version},
+ journal = {J. Cryptographic Engineering},
+ volume = {4},
+ number = {1},
+ pages = {19--31},
+ publisher = {Springer},
+ doi = {10.1007/s13389-013-0068-0},
+ year = {2014}
+}
+
+@Article{ Bl86,
+ author = {Manuel Blum},
+ title = {Independent unbiased coin flips from a correlated biased
+ source -- A finite state Markov chain},
+ journal = {Combinatorica},
+ volume = {6},
+ number = {2},
+ pages = {97--108},
+ doi = {10.1007/BF02579167},
+ year = {1986}
+}
+
+@Article{ BlBlSh86,
+ author = {Lenore Blum and Manuel Blum and Mike Shub},
+ title = {A Simple Unpredictable Pseudo-Random Number Generator},
+ journal = {{SIAM} J. Comput.},
+ volume = {15},
+ number = {2},
+ pages = {364--383},
+ doi = {10.1137/0215025},
+ publisher = {{SIAM}},
+ year = {1986}
+}
+
+@InProceedings{ ChMaGa:16,
+ author = {Stephen Checkoway and Jacob Maskiewicz and Christina
+ Garman and Joshua Fried and Shaanan Cohney and Matthew
+ Green and Nadia Heninger and Ralf{-}Philipp Weinmann and
+ Eric Rescorla and Hovav Shacham},
+ title = {A Systematic Analysis of the Juniper Dual {EC} Incident},
+ booktitle = {Proceedings of the 2016 {ACM} {SIGSAC} Conference on
+ Computer and Communications Security, Vienna, Austria,
+ October 24-28, 2016},
+ pages = {468--479},
+ crossref = {_WeKaKr:16},
+ doi = {10.1145/2976749.2978395},
+ year = {2016}
+}
+
+@Article{ ChMaGa:18,
+ author = {Stephen Checkoway and Jacob Maskiewicz and Christina
+ Garman and Joshua Fried and Shaanan Cohney and Matthew
+ Green and Nadia Heninger and Ralf{-}Philipp Weinmann and
+ Eric Rescorla and Hovav Shacham},
+ title = {Where did {I} leave my keys?: lessons from the Juniper
+ Dual {EC} incident},
+ journal = {Commun. {ACM}},
+ volume = {61},
+ number = {11},
+ pages = {148--155},
+ publisher = {{ACM}},
+ doi = {10.1145/3266291},
+ year = {2018}
+}
+
+@Misc{ Cr17,
+ author = {Common Criteria},
+ title = {Common Methodology for Information Technology Security
+ Evaluation: Evaluation methodology},
+ howpublished = {Specification: Version 3.1 Revision 5},
+ url = {https://commoncriteriaportal.org/cc/},
+ month = {April},
+ year = {2017}
+}
+
+@Misc{ Da02,
+ author = {Robert B. Davies},
+ title = {Exclusive OR (XOR) and hardware random number generators},
+ howpublished = {Author-hosted manuscript},
+ url = {http://www.robertnz.net/pdf/xor2.pdf},
+ month = {February},
+ year = {2002}
+}
+
+@Book{ DaRo58,
+ author = {Wilbur B. Davenport Jr. and William L. Root},
+ title = {An Introduction to the Theory of Random Signals and
+ Noise},
+ url = {https://ieeexplore.ieee.org/servlet/opac?bknumber=5265617},
+ pages = {401},
+ publisher = {McGraw-Hill},
+ year = {1958}
+}
+
+@Article{ El72,
+ author = {Peter Elias},
+ title = {The Efficient Construction of an Unbiased Random
+ Sequence},
+ journal = {Ann. Math. Statist.},
+ volume = {43},
+ number = {3},
+ pages = {865--870},
+ doi = {10.1214/aoms/1177692552},
+ publisher = {Institute of Mathematical Statistics},
+ year = {1972}
+}
+
+@InProceedings{ EvPo16,
+ author = {Dmitry Evtyushkin and Dmitry V. Ponomarev},
+ title = {Covert Channels through Random Number Generator:
+ Mechanisms, Capacity Estimation and Mitigations},
+ booktitle = {Proceedings of the 2016 {ACM} {SIGSAC} Conference on
+ Computer and Communications Security, Vienna, Austria,
+ October 24-28, 2016},
+ pages = {843--857},
+ crossref = {_WeKaKr:16},
+ doi = {10.1145/2976749.2978374},
+ year = {2016}
+}
+
+@InProceedings{ Gr96,
+ author = {Lov K. Grover},
+ title = {A Fast Quantum Mechanical Algorithm for Database Search},
+ booktitle = {Proceedings of the Twenty-eighth Annual ACM Symposium on
+ Theory of Computing},
+ series = {STOC '96},
+ pages = {212--219},
+ url = {http://arxiv.org/pdf/quant-ph/9605043},
+ doi = {10.1145/237814.237866},
+ publisher = {{ACM}},
+ year = 1996
+}
+
+@InProceedings{ GrLaRo:16,
+ author = {Markus Grassl and Brandon Langenberg and Martin Roetteler
+ and Rainer Steinwandt},
+ title = {Applying Grover's Algorithm to {AES:} Quantum Resource
+ Estimates},
+ booktitle = {Post-Quantum Cryptography - 7th International Workshop,
+ PQCrypto 2016, Fukuoka, Japan, February 24-26, 2016,
+ Proceedings},
+ pages = {29--43},
+ crossref = {_Ta16},
+ url = {https://arxiv.org/pdf/1512.04965.pdf},
+ doi = {10.1007/978-3-319-29360-8\_3},
+ year = {2016}
+}
+
+@Misc{ HaKoMa12,
+ author = {Mike Hamburg and Paul Kocher and Mark E. Marson},
+ title = {Analysis of Intel's Ivy Bridge Digital Random Number
+ Generator},
+ howpublished = {Technical Report, Cryptography Research (Prepared for
+ Intel)},
+ month = {March},
+ year = {2012}
+}
+
+@Article{ HaLe98,
+ author = {Ali Hajimiri and Thomas H. Lee},
+ title = {A general theory of phase noise in electrical
+ oscillators},
+ journal = {IEEE Journal of Solid-State Circuits},
+ volume = {33},
+ number = {2},
+ pages = {179--194},
+ publisher = {{IEEE}},
+ doi = {10.1109/4.658619},
+ year = {1998}
+}
+
+@Article{ HaLiLe99,
+ author = {Ali Hajimiri and Sotirios Limotyrakis and Thomas H. Lee},
+ title = {Jitter and phase noise in ring oscillators},
+ journal = { {IEEE} Journal of Solid-State Circuits},
+ volume = {34},
+ number = {6},
+ doi = {10.1109/4.766813},
+ url = {https://authors.library.caltech.edu/4916/1/HAJieeejssc99a.pdf},
+ pages = {790--804},
+ month = {June},
+ year = {1999}
+}
+
+@Article{ HuHe20,
+ author = {Darren Hurley-Smith and Julio C\'esar Hern\'andez-Castro},
+ title = {Quantum Leap and Crash: Searching and Finding Bias in
+ Quantum Random Number Generators},
+ journal = {ACM Transactions on Privacy and Security},
+ volume = {23},
+ number = {3},
+ pages = {1--25},
+ doi = {10.1145/3403643},
+ publisher = {{ACM}},
+ month = {June},
+ year = {2020}
+}
+
+@TechReport{ IS16,
+ author = {{ISO}},
+ type = {Standard},
+ title = {Information technology -- Security techniques -- Testing
+ methods for the mitigation of non-invasive attack classes
+ against cryptographic modules},
+ shorttitle = {{ISO}/{IEC} 17825:2016},
+ language = {en},
+ number = {ISO/IEC 17825:2016},
+ institution = {International Organization for Standardization},
+ year = {2016}
+}
+
+@Misc{ IT19,
+ author = {ITU},
+ title = {Quantum noise random number generator architecture},
+ howpublished = {Recommendation ITU-T X.1702},
+ url = {https://www.itu.int/rec/T-REC-X.1702-201911-I/en},
+ publisher = {International Telecommunications Union},
+ month = {November},
+ year = {2019}
+}
+
+@Misc{ In20,
+ author = {Intel},
+ title = {Deep Dive: Special Register Buffer Data Sampling},
+ url = {https://software.intel.com/security-software-guidance/insights/deep-dive-special-register-buffer-data-sampling},
+ howpublished = {Intel Developer Zone},
+ publisher = {Intel},
+ month = {June},
+ year = {2020}
+}
+
+@Misc{ In20A,
+ author = {Intel},
+ title = {{SRBDS} Mitigation Impact on Intel Secure Key},
+ url = {https://software.intel.com/security-software-guidance/insights/srbds-mitigation-impact-intel-secure-key},
+ howpublished = {Intel Developer Zone},
+ publisher = {Intel},
+ month = {June},
+ year = {2020}
+}
+
+@InProceedings{ JaNaRo:20,
+ author = {Samuel Jaques and Michael Naehrig and Martin Roetteler and
+ Fernando Virdia},
+ title = {Implementing Grover Oracles for Quantum Key Search on
+ {AES} and LowMC},
+ booktitle = {Advances in Cryptology - {EUROCRYPT} 2020 - 39th Annual
+ International Conference on the Theory and Applications of
+ Cryptographic Techniques, Zagreb, Croatia, May 10-14, 2020,
+ Proceedings, Part {II}},
+ pages = {280--310},
+ crossref = {_CaIs20},
+ url = {https://arxiv.org/pdf/1910.01700.pdf},
+ doi = {10.1007/978-3-030-45724-2\_10},
+ year = {2020}
+}
+
+@Article{ KaScVe13,
+ author = {Dusko Karaklajic and J{\"{o}}rn{-}Marc Schmidt and Ingrid
+ Verbauwhede},
+ title = {Hardware Designer's Guide to Fault Attacks},
+ journal = {{IEEE} Trans. Very Large Scale Integr. Syst.},
+ volume = {21},
+ number = {12},
+ pages = {2295--2306},
+ doi = {10.1109/TVLSI.2012.2231707},
+ publisher = {IEEE},
+ year = {2013}
+}
+
+@Misc{ KiSc01,
+ author = {Wolfgang Killmann and Werner Schindler},
+ title = {A Proposal for: Functionality classes and evaluation
+ methodology for true (physical) random number generators},
+ howpublished = {AIS 31, Version 3.1, English Translation, BSI},
+ url = {https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_Functionality_classes_evaluation_methodology_for_true_RNG_e.html},
+ publisher = {BSI},
+ month = {September},
+ year = {2001}
+}
+
+@Misc{ KiSc11,
+ author = {Wolfgang Killmann and Werner Schindler},
+ title = {A Proposal for: Functionality classes for random number
+ generators},
+ howpublished = {AIS 20 / AIS 31, Version 2.0, English Translation, BSI},
+ url = {https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_Functionality_classes_for_random_number_generators_e.html},
+ publisher = {BSI},
+ month = {September},
+ year = {2011}
+}
+
+@Misc{ KoXiHu:21,
+ author = {Nick Kossifidis and Joe Xie and Bill Huffman and Allen
+ Baum and Greg Favor and Tariq Kurd and Fumio Arakawa},
+ title = {{PMP} Enhancements for memory access and execution
+ prevention on Machine mode},
+ howpublished = {Version 0.9.1 -- {RISC}-{V} {TEE} Task Group},
+ month = {May},
+ year = {2021}
+}
+10.1007/978-3-540-71039-4\_21
+@InProceedings{ La08,
+ author = {Patrick Lacharme},
+ title = {Post-Processing Functions for a Biased Physical Random
+ Number Generator},
+ booktitle = {Fast Software Encryption, 15th International Workshop,
+ {FSE} 2008, Lausanne, Switzerland, February 10-13, 2008,
+ Revised Selected Papers},
+ pages = {334--342},
+ crossref = {_Ny08},
+ doi = {10.1007/978-3-540-71039-4\_21},
+ year = {2008}
+}
+
+@Article{ LiBaBo:13,
+ author = {John S. Liberty and Adrian Barrera and David W. Boerstler
+ and Thomas B. Chadwick and Scott R. Cottier and H. Peter
+ Hofstee and Julie A. Rosser and Marty L. Tsai},
+ title = {True hardware random number generation implemented in the
+ 32-nm {SOI} {POWER7+} processor},
+ journal = {{IBM} J. Res. Dev.},
+ volume = {57},
+ number = {6},
+ doi = {10.1147/JRD.2013.2279599},
+ year = {2013}
+}
+
+@InProceedings{ MaMo09,
+ author = {A. Theodore Markettos and Simon W. Moore},
+ title = {The Frequency Injection Attack on Ring-Oscillator-Based
+ True Random Number Generators},
+ booktitle = {Cryptographic Hardware and Embedded Systems - {CHES} 2009,
+ 11th International Workshop, Lausanne, Switzerland,
+ September 6-9, 2009, Proceedings},
+ pages = {317--331},
+ crossref = {_ClGa09},
+ doi = {10.1007/978-3-642-04138-9\_23},
+ year = {2009}
+}
+
+@Misc{ Me18,
+ author = {John P. Mechalas},
+ title = {Intel Digital Random Number Generator (DRNG) Software
+ Implementation Guide},
+ howpublished = {Intel Technical Report, Version 2.1},
+ url = {https://software.intel.com/content/www/us/en/develop/articles/intel-digital-random-number-generator-drng-software-implementation-guide.html},
+ month = {October},
+ year = {2018}
+}
+
+@InProceedings{ MoSuEi:20,
+ author = {Daniel Moghimi and Berk Sunar and Thomas Eisenbarth and
+ Nadia Heninger},
+ title = {{TPM}-{FAIL}: {TPM} meets Timing and Lattice Attacks},
+ booktitle = {29th {USENIX} Security Symposium ({USENIX} Security 20)},
+ url = {https://www.usenix.org/conference/usenixsecurity20/presentation/moghimi-tpm},
+ pages = {To appear},
+ publisher = {{USENIX} Association},
+ month = {August},
+ year = {2020}
+}
+
+@Misc{ Mu20,
+ author = {Stephan M\"uller},
+ title = {Documentation and Analysis of the Linux Random Number
+ Generator, Version 3.6},
+ howpublished = {Prepared for BSI by atsec information security GmbH},
+ url = {https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf},
+ month = {April},
+ year = {2020}
+}
+
+@Misc{ NC20,
+ author = {NCSC},
+ title = {Quantum security technologies},
+ howpublished = {White paper, Version 1.0. National Cyber Security Centre
+ (UK).},
+ url = {https://www.ncsc.gov.uk/whitepaper/quantum-security-technologies},
+ month = {March},
+ year = {2020}
+}
+
+@Misc{ NI16,
+ author = {{NIST}},
+ title = {Submission Requirements and Evaluation Criteria for the
+ Post-Quantum Cryptography Standardization Process},
+ howpublished = {Official Call for Proposals, National Institute for
+ Standards and Technology},
+ url = {http://csrc.nist.gov/groups/ST/post-quantum-crypto/documents/call-for-proposals-final-dec-2016.pdf},
+ month = {December},
+ year = 2016
+}
+
+@Misc{ NI19,
+ author = {{NIST}},
+ title = {Security Requirements for Cryptographic Modules},
+ howpublished = {Federal Information Processing Standards Publication FIPS
+ 140-3},
+ url = {https://doi.org/10.6028/NIST.FIPS.140-3},
+ month = {March},
+ year = {2019}
+}
+
+@Misc{ NICC21,
+ author = {{NIST} and {CCCS}},
+ title = {Implementation Guidance for {FIPS} 140-3 and the
+ Cryptographic Module Validation Program},
+ howpublished = {CMVP},
+ url = {https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf},
+ month = {May},
+ year = {2021}
+}
+
+@Misc{ NS15,
+ author = {{NSA}/{CSS}},
+ title = {Commercial National Security Algorithm Suite},
+ url = {https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm},
+ month = {August},
+ year = 2015
+}
+
+@InCollection{ Ne51,
+ title = {Various Techniques Used in Connection with Random Digits},
+ author = {von Neumann, John},
+ booktitle = {Monte Carlo Method},
+ editor = {Householder, A.~S. and Forsythe, G.~E. and Germond,
+ H.~H.},
+ series = {National Bureau of Standards Applied Mathematics Series},
+ volume = {12},
+ chapter = {13},
+ pages = {36--38},
+ publisher = {US Government Printing Office},
+ address = {Washington, DC},
+ url = {https://mcnp.lanl.gov/pdf_files/nbs_vonneumann.pdf},
+ year = {1951}
+}
+
+@Misc{ Ra20,
+ author = {Rambus},
+ title = {TRNG-IP-76 / EIP-76 Family of FIPS Approved True Random
+ Generators},
+ howpublished = {Commercial Crypto IP. Formerly (2017) available from
+ Inside Secure.},
+ url = {https://www.rambus.com/security/crypto-accelerator-hardware-cores/basic-crypto-blocks/trng-ip-76/},
+ year = {2020}
+}
+
+@InProceedings{ RaMiRa:21,
+ author = {Hany Ragab and Alyssa Milburn and Kaveh Razavi and Herbert
+ Bos and Cristiano Giuffrida},
+ title = {CrossTalk : Speculative Data Leaks Across Cores Are Real},
+ booktitle = {IEEE Symposium on Security \& Privacy 2021},
+ url = {https://download.vusec.net/papers/crosstalk_sp21.pdf},
+ pages = {To appear},
+ publisher = {IEEE},
+ month = {May},
+ year = {2021}
+}
+
+@Article{ Ri44,
+ author = {Stephen O. Rice},
+ title = {Mathematical analysis of random noise (Parts I-II)},
+ journal = {The Bell System Technical Journal},
+ volume = {23},
+ number = {3},
+ pages = {282--332},
+ doi = {10.1002/j.1538-7305.1944.tb00874.x},
+ month = {July},
+ year = {1944}
+}
+
+@Article{ Ri45,
+ author = {Stephen O. Rice},
+ title = {Mathematical analysis of random noise (Parts III-IV))},
+ journal = {The Bell System Technical Journal},
+ volume = {24},
+ number = {1},
+ pages = {46--156},
+ doi = {10.1002/j.1538-7305.1945.tb00453.x},
+ month = {January},
+ year = {1945}
+}
+
+@Misc{ RuSoNe:10,
+ author = {Andrew Rukhin and Juan Soto and James Nechvatal and Miles
+ Smid and Elaine Barker and Stefan Leigh and Mark Levenson
+ and Mark Vangel and David Banks and Alan Heckert and
+ JamesDray and San Vo},
+ title = {A Statistical Test Suite for Random and Pseudorandom
+ Number Generators for Cryptographic Applications},
+ doi = {10.6028/NIST.SP.800-22r1a},
+ month = {April},
+ year = {2010}
+}
+
+@Misc{ Sa19,
+ author = {Jim Salter},
+ title = {How a months-old {AMD} microcode bug destroyed my
+ weekend},
+ howpublished = {Ars Technica},
+ url = {https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/},
+ month = {October},
+ year = {2019}
+}
+
+@InProceedings{ Sa20,
+ author = {Markku-Juhani O. Saarinen},
+ title = {A Lightweight ISA Extension for {AES} and {SM4}},
+ booktitle = {First International Workshop on Secure RISC-V Architecture
+ Design Exploration (SECRISC-V'20)},
+ url = {https://arxiv.org/abs/2002.07041},
+ publisher = {IEEE},
+ month = {August},
+ year = {2020}
+}
+
+
+@InProceedings{ SaNeMa20,
+ author = {Markku-Juhani O. Saarinen and G. Richard Newell and Ben
+ Marshall},
+ title = {Building a Modern {TRNG}: An Entropy Source Interface for
+ {RISC}-{V}},
+ booktitle = {4th Workshop on Attacks and Solutions in Hardware Security
+ (ASHES’20), November 13, 2020, Virtual Event, USA.},
+ doi = {10.1145/3411504.3421212},
+ publisher = {ACM},
+ pages = {93--102},
+ month = {November},
+ year = 2020
+}
+
+@Misc{ Sa21,
+ author = {Markku-Juhani O. Saarinen},
+ title = {On Entropy and Bit Patterns of Ring Oscillator Jitter},
+ url = {https://arxiv.org/abs/2102.02196},
+ howpublished = {Preprint},
+ month = {February},
+ year = 2021
+}
+
+@Misc{ SaNeMa21,
+ author = {Markku-Juhani O. Saarinen and G. Richard Newell and Ben
+ Marshall},
+ title = {Development of The {RISC}-{V} Entropy Source Interface},
+ howpublished = {{IACR} ePrint 2020/866},
+ url = {https://eprint.iacr.org/2029/866},
+ publisher = {Submitted For Publication},
+ month = {June},
+ year = 2021
+}
+
+@Misc{ Sc99,
+ author = {Werner Schindler},
+ title = {Functionality classes and evaluation methodology for
+ deterministic random number generators},
+ howpublished = {AIS 20, Version 2.0, English Translation, BSI},
+ publisher = {BSI},
+ url = {https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_20_Functionality_Classes_Evaluation_Methodology_DRNG_e.html},
+ month = {December},
+ year = {1999}
+}
+
+@InProceedings{ Sh94,
+ author = {Peter W. Shor},
+ title = {Algorithms for quantum computation: Discrete logarithms
+ and factoring},
+ booktitle = {35th Annual Symposium on Foundations of Computer Science,
+ Santa Fe, New Mexico, USA, 20-22 November 1994},
+ pages = {124--134},
+ publisher = {IEEE},
+ doi = {10.1109/SFCS.1994.365700},
+ url = {https://arxiv.org/abs/quant-ph/9508027},
+ year = 1994
+}
+
+@Misc{ TG20,
+ author = {{RISC-V} {Crypto} {TG}},
+ title = {RISC-V Cryptography Extensions},
+ url = {https://github.com/riscv/riscv-crypto},
+ howpublished = {Editor's location -- to be integrated with main
+ specifications},
+ year = {2020}
+}
+
+@Misc{TuBaKe:18,
+ author = {Meltem S\"onmez Turan and Elaine Barker and John Kelsey and
+ Kerry A. McKay and Mary L. Baish and Mike Boyle},
+ title = {Recommendation for the Entropy Sources Used for Random Bit
+ Generation},
+ howpublished = {NIST Special Publication SP 800-90B},
+ doi = {10.6028/NIST.SP.800-90B},
+ month = {January},
+ year = {2018}
+}
+
+@InProceedings{ VaDr10,
+ author = {Michal Varchola and Milos Drutarovsk{\'{y}}},
+ title = {New High Entropy Element for {FPGA} Based True Random
+ Number Generators},
+ booktitle = {Cryptographic Hardware and Embedded Systems, {CHES} 2010,
+ 12th International Workshop, Santa Barbara, CA, USA, August
+ 17-20, 2010. Proceedings},
+ pages = {351--365},
+ crossref = {_MaSt10},
+ doi = {10.1007/978-3-642-15031-9\_24},
+ year = {2010}
+}
+
+@InProceedings{ VaFiAu:10,
+ author = {Boyan Valtchanov and Viktor Fischer and Alain Aubert and
+ Florent Bernard},
+ title = {Characterization of randomness sources in ring
+ oscillator-based true random number generators in FPGAs},
+ booktitle = {13th {IEEE} International Symposium on Design and
+ Diagnostics of Electronic Circuits and Systems, {DDECS}
+ 2010, Vienna, Austria, April 14-16, 2010},
+ pages = {48--53},
+ crossref = {_GrKoSt:10},
+ doi = {10.1109/DDECS.2010.5491819},
+ year = {2010}
+}
+
+@Proceedings{ _CaIs20,
+ editor = {Anne Canteaut and Yuval Ishai},
+ title = {Advances in Cryptology - {EUROCRYPT} 2020 - 39th Annual
+ International Conference on the Theory and Applications of
+ Cryptographic Techniques, Zagreb, Croatia, May 10-14, 2020,
+ Proceedings, Part {II}},
+ series = {Lecture Notes in Computer Science},
+ volume = {12106},
+ publisher = {Springer},
+ doi = {10.1007/978-3-030-45724-2},
+ isbn = {978-3-030-45723-5},
+ year = {2020}
+}
+
+@Proceedings{ _ClGa09,
+ editor = {Christophe Clavier and Kris Gaj},
+ title = {Cryptographic Hardware and Embedded Systems - {CHES} 2009,
+ 11th International Workshop, Lausanne, Switzerland,
+ September 6-9, 2009, Proceedings},
+ series = {Lecture Notes in Computer Science},
+ volume = {5747},
+ publisher = {Springer},
+ doi = {10.1007/978-3-642-04138-9},
+ isbn = {978-3-642-04137-2},
+ year = {2009}
+}
+
+@Proceedings{ _GrKoSt:10,
+ editor = {Elena Gramatov{\'{a}} and Zdenek Kot{\'{a}}sek and Andreas
+ Steininger and Heinrich Theodor Vierhaus and Horst
+ Zimmermann},
+ title = {13th {IEEE} International Symposium on Design and
+ Diagnostics of Electronic Circuits and Systems, {DDECS}
+ 2010, Vienna, Austria, April 14-16, 2010},
+ publisher = {{IEEE} Computer Society},
+ url = {https://ieeexplore.ieee.org/xpl/conhome/5484099/proceeding},
+ isbn = {978-1-4244-6612-2},
+ year = {2010}
+}
+
+@Proceedings{ _MaSt10,
+ editor = {Stefan Mangard and Fran{\c{c}}ois{-}Xavier Standaert},
+ title = {Cryptographic Hardware and Embedded Systems, {CHES} 2010,
+ 12th International Workshop, Santa Barbara, CA, USA, August
+ 17-20, 2010. Proceedings},
+ series = {Lecture Notes in Computer Science},
+ volume = {6225},
+ publisher = {Springer},
+ doi = {10.1007/978-3-642-15031-9},
+ isbn = {978-3-642-15030-2},
+ year = {2010}
+}
+
+@Proceedings{ _Ny08,
+ editor = {Kaisa Nyberg},
+ title = {Fast Software Encryption, 15th International Workshop,
+ {FSE} 2008, Lausanne, Switzerland, February 10-13, 2008,
+ Revised Selected Papers},
+ series = {Lecture Notes in Computer Science},
+ volume = {5086},
+ publisher = {Springer},
+ doi = {10.1007/978-3-540-71039-4},
+ isbn = {978-3-540-71038-7},
+ year = {2008}
+}
+
+@Proceedings{ _SaCa12,
+ editor = {Reihaneh Safavi{-}Naini and Ran Canetti},
+ title = {Advances in Cryptology - {CRYPTO} 2012 - 32nd Annual
+ Cryptology Conference, Santa Barbara, CA, USA, August
+ 19-23, 2012. Proceedings},
+ series = {Lecture Notes in Computer Science},
+ volume = {7417},
+ publisher = {Springer},
+ doi = {10.1007/978-3-642-32009-5},
+ isbn = {978-3-642-32008-8},
+ year = {2012}
+}
+
+@Proceedings{ _Ta16,
+ editor = {Tsuyoshi Takagi},
+ title = {Post-Quantum Cryptography - 7th International Workshop,
+ PQCrypto 2016, Fukuoka, Japan, February 24-26, 2016,
+ Proceedings},
+ series = {Lecture Notes in Computer Science},
+ volume = {9606},
+ publisher = {Springer},
+ doi = {10.1007/978-3-319-29360-8},
+ isbn = {978-3-319-29359-2},
+ year = {2016}
+}
+
+@Book{ _WaAs19,
+ editor = {Andrew Waterman and Krste Asanovi\'c},
+ title = {The {RISC}-{V} Instruction Set Manual, Volume I:
+ User-Level {ISA}},
+ note = {Document Version 20191213},
+ publisher = {RISC-V Foundation},
+ url = {https://riscv.org/specifications/},
+ month = {December},
+ year = 2019
+}
+
+@Book{ _WaAs19A,
+ editor = {Andrew Waterman and Krste Asanovi\'c},
+ title = {The {RISC}-{V} Instruction Set Manual, Volume II:
+ Privileged Architecture},
+ note = {Document Version 20190608-Priv-MSU-Ratified},
+ publisher = {RISC-V Foundation},
+ url = {https://riscv.org/specifications/},
+ month = {June},
+ year = 2019
+}
+
+@Proceedings{ _WeKaKr:16,
+ editor = {Edgar R. Weippl and Stefan Katzenbeisser and Christopher
+ Kruegel and Andrew C. Myers and Shai Halevi},
+ title = {Proceedings of the 2016 {ACM} {SIGSAC} Conference on
+ Computer and Communications Security, Vienna, Austria,
+ October 24-28, 2016},
+ publisher = {{ACM}},
+ url = {http://dl.acm.org/citation.cfm?id=2976749},
+ isbn = {978-1-4503-4139-4},
+ year = {2016}
+}
+@electronic{DEBUG_SPEC,
+ title = {The RISC-V Debug Specification},
+ url = {https://github.com/riscv/riscv-debug-spec},
+ year = {}
+}
+~
+@article{HWASAN,
+ author = {Kostya Serebryany and
+ Evgenii Stepanov and
+ Aleksey Shlyapnikov and
+ Vlad Tsyrklevich and
+ Dmitry Vyukov},
+ title = {Memory Tagging and how it improves {C/C++} memory safety},
+ journal = {CoRR},
+ volume = {abs/1802.09517},
+ year = {2018},
+ url = {http://arxiv.org/abs/1802.09517},
+ eprinttype = {arXiv},
+ eprint = {1802.09517},
+ timestamp = {Mon, 13 Aug 2018 16:46:42 +0200},
+ biburl = {https://dblp.org/rec/journals/corr/abs-1802-09517.bib},
+ bibsource = {dblp computer science bibliography, https://dblp.org}
+}
diff --git a/src/riscv-privileged.adoc b/src/riscv-privileged.adoc
new file mode 100644
index 0000000..b45de8b
--- /dev/null
+++ b/src/riscv-privileged.adoc
@@ -0,0 +1,141 @@
+[[manual:priv,RISC-V ISA Manual, Volume II: Privileged Architecture]]
+= The RISC-V Instruction Set Manual, Volume II: Privileged Architecture
+include::../docs-resources/global-config.adoc[]
+:description: Privileged Architecture
+//development: assume everything can change
+//stable: assume everything could change
+//frozen: of you implement this version you assume the risk that something might change because of the public review cycle but we expect little to no change.
+//ratified: you can implement this and be assured nothing will change. if something needs to change due to an errata or enhancement, it will come out in a new extension. we do not revise extensions.
+:colophon:
+:preface-title: Preamble
+:appendix-caption: Appendix
+:imagesdir: ../docs-resources/images
+:title-logo-image: image:risc-v_logo.png["RISC-V International Logo",pdfwidth=3.25in,align=center]
+ifdef::draft-watermark[]
+:page-background-image: image:draft.png[opacity=20%]
+endif::[]
+//:title-page-background-image: none
+//:back-cover-image: image:backpage.png[opacity=25%]
+// Settings:
+:experimental:
+:reproducible:
+:imagesoutdir: {docdir}/../build/images-out
+:bibtex-file: src/resources/riscv-spec.bib
+:bibtex-order: alphabetical
+:bibtex-style: apa
+:bibtex-format: asciidoc
+:bibtex-throw: false
+:icons: font
+:lang: en
+:example-caption: Example
+:listing-caption: Listing
+:sectnums:
+:sectnumlevels: 5
+:sectlinks:
+:toc: left
+:toclevels: 4
+:source-highlighter: rouge
+:table-caption: Table
+:figure-caption: Figure
+:xrefstyle: short
+:chapter-refsig: Chapter
+:section-refsig: Section
+:appendix-refsig: Appendix
+// Uncomment :data-uri: if your eBook reader is not capable of rendering
+// embedded images. One known affected device is PocketBook InkPad 3.
+:data-uri:
+:hide-uri-scheme:
+:stem: latexmath
+:footnote:
+:le: &#8804;
+:ge: &#8805;
+:ne: &#8800;
+:approx: &#8776;
+:inf: &#8734;
+:circ: &#x2218;
+:bullet: &#x2219;
+:times: &#x00D7;
+:imagesdir: images
+
+_Contributors to all versions of the spec in alphabetical order (please contact editors to suggest corrections):
+Krste Asanović,
+Peter Ashenden,
+Rimas Avižienis,
+Jacob Bachmeyer,
+Allen J. Baum,
+Jonathan Behrens,
+Paolo Bonzini,
+Ruslan Bukin,
+Christopher Celio,
+Chuanhua Chang,
+David Chisnall,
+Anthony Coulter,
+Palmer Dabbelt,
+Monte Dalrymple,
+Paul Donahue,
+Greg Favor,
+Dennis Ferguson,
+Marc Gauthier,
+Andy Glew,
+Gary Guo,
+Mike Frysinger,
+John Hauser,
+David Horner,
+Olof Johansson,
+David Kruckemyer,
+Yunsup Lee,
+Daniel Lustig,
+Andrew Lutomirski,
+Martin Maas,
+Prashanth Mundkur,
+Jonathan Neuschäfer,
+Rishiyur Nikhil,
+Stefan O'Rear,
+Albert Ou,
+John Ousterhout,
+David Patterson,
+Dmitri Pavlov,
+Kade Phillips,
+Josh Scheid,
+Colin Schmidt,
+Michael Taylor,
+Wesley Terpstra,
+Matt Thomas,
+Tommy Thorn,
+Ray VanDeWalker,
+Megan Wachs,
+Steve Wallach,
+Andrew Waterman,
+Claire Wolf,
+Adam Zabrocki,
+and Reinoud Zandijk._
+
+_This document is released under a Creative Commons Attribution 4.0 International License._
+
+_This document is a derivative of the RISC-V
+privileged specification version 1.9.1 released under following license: ©2010-2017 Andrew Waterman, Yunsup Lee, Rimas
+Avižienis,
+David Patterson, Krste Asanović. Creative Commons Attribution 4.0 International License._
+
+include::priv-preface.adoc[]
+include::priv-intro.adoc[]
+include::priv-csrs.adoc[]
+include::machine.adoc[]
+include::smstateen.adoc[]
+include::indirect-csr.adoc[]
+include::smepmp.adoc[]
+include::smcntrpmf.adoc[]
+include::rnmi.adoc[]
+include::smcdeleg.adoc[]
+include::smdbltrp.adoc[]
+include::smctr.adoc[]
+include::supervisor.adoc[]
+include::sstc.adoc[]
+include::sscofpmf.adoc[]
+include::hypervisor.adoc[]
+include::priv-cfi.adoc[]
+include::ssdbltrp.adoc[]
+include::zpm.adoc[]
+include::priv-insns.adoc[]
+include::priv-history.adoc[]
+include::bibliography.adoc[]
diff --git a/src/riscv-privileged.tex b/src/riscv-privileged.tex
deleted file mode 100644
index 20bf4d5..0000000
--- a/src/riscv-privileged.tex
+++ /dev/null
@@ -1,88 +0,0 @@
-%=======================================================================
-% riscv-privileged.tex
-%-----------------------------------------------------------------------
-
-\documentclass[twoside,11pt]{book}
-
-\input{preamble}
-
-\newcommand{\privrev}{1.11-draft}
-
-\begin{document}
-
-\title{{\vspace{-0.7in}\Large {\bf The RISC-V Instruction Set Manual}} \\
- \large {\bf Volume II: Privileged Architecture} \\
- Privileged Architecture Version \privrev \\
- Document Version \privrev \\
- {\bf Warning! This draft specification
- may change before being accepted as standard by the RISC-V Foundation.
- While the editors intend future changes to this specification to be
- forward compatible, it remains possible that
- implementations made to this draft specification will not conform
- to the future standard.}
- \vspace{-0.1in}}
-
-\author{Editors: Andrew Waterman$^{1}$, Krste Asanovi\'{c}$^{1,2}$ \\
- $^{1}$SiFive Inc., \\
- $^{2}$CS Division, EECS Department, University of California, Berkeley \\
- {\tt andrew@sifive.com, krste@berkeley.edu} \\
- \today
-}
-
-\date{}
-\maketitle
-
-Contributors to all versions of the spec in alphabetical order (please contact
-editors to suggest corrections): Krste Asanovi\'{c}, Peter Ashenden, Rimas
-Avi\v{z}ienis, Jacob Bachmeyer, Allen J. Baum, Paolo Bonzini, Ruslan Bukin,
-Christopher Celio, Chuanhua Chang, David Chisnall, Anthony Coulter, Palmer Dabbelt, Monte
-Dalrymple, Dennis Ferguson, Mike Frysinger, John Hauser, David Horner, Olof
-Johansson, Yunsup Lee, Andrew Lutomirski, Prashanth Mundkur,
-Jonathan Neusch{\"a}fer, Rishiyur
-Nikhil, Stefan O'Rear, Albert Ou, John Ousterhout, David Patterson, Dmitri
-Pavlov, Kade Phillips, Colin Schmidt, Wesley Terpstra, Matt Thomas, Tommy Thorn, Ray
-VanDeWalker, Megan Wachs, Steve Wallach, Andrew Waterman, Clifford Wolf,
-and Reinoud Zandijk.
-
-This document is released under a Creative Commons Attribution 4.0
-International License.
-
-This document is a derivative of the RISC-V
-privileged specification version 1.9.1 released under following license:
-\copyright \,2010--2017 Andrew Waterman, Yunsup Lee, Rimas
-Avi\v{z}ienis, David Patterson, Krste Asanovi\'{c}.
-Creative Commons Attribution 4.0 International License.
-
-Please cite as: ``The RISC-V Instruction Set
-Manual, Volume II: Privileged Architecture, Version 1.10'', Editors
-Andrew Waterman and Krste Asanovi\'{c}, RISC-V Foundation, May 2017.
-
-\markboth{Volume II: RISC-V Privileged Architectures V\privrev}
-{Volume II: RISC-V Privileged Architectures V\privrev}
-\thispagestyle{empty}
-
-\frontmatter
-
-\input{priv-preface}
-
-{\hypersetup{linktoc=all,hidelinks}
-\tableofcontents
-}
-
-\mainmatter
-
-\input{priv-intro}
-\input{priv-csrs}
-\input{machine}
-\input{supervisor}
-\input{hypervisor}
-\input{priv-insns}
-
-\input{plic}
-\input{cfgstr}
-\input{priv-history}
-
-\bibliographystyle{plain}
-\bibliography{riscv-spec}
-
-\end{document}
diff --git a/src/riscv-spec.bib b/src/riscv-spec.bib
deleted file mode 100644
index 8dd2d63..0000000
--- a/src/riscv-spec.bib
+++ /dev/null
@@ -1,491 +0,0 @@
-@Misc{ieee754-2008,
- key = "{IEEE}",
- title = "{ANSI/IEEE Std 754-2008}, {IEEE} standard for
- floating-point arithmetic",
- publisher = {"Institute of Electrical and Electronic Engineers"},
- year = 2008
-}
-
-@inproceedings{riscI-isca1981,
- title = {{RISC I}: {A} Reduced Instruction Set {VLSI} Computer},
- author = {David A. Patterson and Carlo H. S\'{e}quin},
- booktitle = {ISCA},
- location = {Minneapolis, Minnesota, USA},
- pages = {443-458},
- year = {1981}
-}
-
-@InProceedings{Katevenis:1983,
- author = {Katevenis, Manolis G.H. and Sherburne,Jr., Robert W. and Patterson, David A. and S{\'e}quin, Carlo H.},
- title = {The {RISC II} micro-architecture},
- booktitle = {Proceedings VLSI 83 Conference},
- year = 1983,
- month = {August}}
-
-@article{Katevenis:1984,
- author = {Katevenis, Manolis G.H. and Sherburne,Jr., Robert W. and Patterson, David A. and S{\'e}quin, Carlo H.},
- title = {The {RISC II} micro-architecture},
- journal = {Advances in VLSI and Computur Systems},
- issue_date = {Fall 1984},
- volume = {1},
- number = {2},
- month = October,
- year = {1984},
- pages = {138--152},
- publisher = {Computer Science Press, Inc.},
- address = {New York, NY, USA},
-}
-
-@inproceedings{Ungar:1984,
- author = {David Ungar and Ricki Blau and Peter Foley and Dain Samples
- and David Patterson},
- title = {Architecture of {SOAR}: {Smalltalk} on a {RISC}},
- booktitle = {ISCA},
- address = {Ann Arbor, MI},
- year = {1984},
- pages = {188--197}
-}
-
-@Article{spur-jsscc1989,
- author = {David D. Lee and Shing I. Kong and Mark D. Hill and
- George S. Taylor and David A. Hodges and Randy
- H. Katz and David A. Patterson},
- title = {A {VLSI} Chip Set for a Multiprocessor
- Workstation--{Part I}: An {RISC} Microprocessor with
- Coprocessor Interface and Support for Symbolic
- Processing},
- journal = {IEEE JSSC},
- year = 1989,
- volume = 24,
- number = 6,
- pages = {1688--1698},
- month = {December}}
-
-@MastersThesis{waterman-ms,
- author = {Andrew Waterman},
- title = {{Improving Energy Efficiency and Reducing Code Size with RISC-V Compressed}},
- school = {University of California, Berkeley},
- year = 2011,
- Number = {UCB/EECS-2011-63},
-}
-
-@phdthesis{waterman-phd,
- Author = {Waterman, Andrew},
- Title = {Design of the {RISC-V} Instruction Set Architecture},
- School = {University of California, Berkeley},
- Year = {2016},
- Number = {UCB/EECS-2016-1},
-}
-
-@TechReport{riscvtr,
- author = {Andrew Waterman and Yunsup Lee and David A. Patterson and Krste Asanovi\'{c}},
- title = {The {RISC-V} Instruction Set Manual, {Volume I}: {Base}
- User-Level {ISA}},
- institution = {EECS Department, University of California, Berkeley},
- year = 2011,
- number = {UCB/EECS-2011-62},
- month = {May}}
-
-
-
-@Book{kane:mips:1991,
- author = {G. Kane and J. Heinrich},
- title = {MIPS RISC Architecture},
- publisher = {Prentice Hall},
- month = {September},
- year = 1991,
- note = {ISBN 0135904722},
- edition = {2nd}
-}
-
-@book{patterson:undergrad:2008,
- author = {D. A. Patterson and J. L. Hennessy},
- title = {Computer Organization and Design: The
- Hardware/Software Interface},
- edition = {4th},
- publisher = {Morgan Kaufmann},
- month = {November},
- year = {2008},
- note = {ISBN 0123744938}
-}
-
-@Book{sweetman:mips:2006,
- author = {D. Sweetman},
- title = {See {MIPS} Run},
- edition = {2nd},
- publisher = {Morgan Kaufmann},
- year = {2006},
- month = {October},
- note = {ISBN 0120884216}
-}
-
-@Misc{mips:arch:2010,
- author = {MIPS Technologies Inc.},
- title = {{MIPS32} Architecture for Programmers},
- year = {2010},
- note = {\verb!https://www.imgtec.com/mips/architectures/mips32/!}
-}
-
-@Misc{sgi:mipspro:1997,
- author = {Silicon Graphics Inc.},
- title = {{MIPSpro} 64-{B}it Porting and Translation Guide},
- year = {1997},
- note = {\verb!http://techpubs.sgi.com/!}
-}
-
-@Misc{openriscarch,
- author = {OpenCores},
- title = {{OpenRISC} 1000 Architecture Manual, Architecture
- Version 1.0},
- month = {December},
- year = 2012}
-
-@ARTICLE{tremblay-vis-ieeemicro1996,
-author={Tremblay, M. and O'Connor, J.M. and Narayanan, V. and Liang He},
-journal={IEEE Micro},
-title={{VIS} speeds new media processing},
-year={1996},
-month=AUG,
-volume={16},
-number={4},
-pages={10 -20},
-keywords={3D graphics environments;RISC-style instructions;UltraSparc;VIS;Visual Instruction Set;media processing;media-processing algorithms;computer graphics;instruction sets;reduced instruction set computing;},
-ISSN={0272-1732},}
-
-@ARTICLE{lee-max-ieeemicro1996,
-author={Lee, R.B.},
-journal={IEEE Micro},
-title={Subword parallelism with {MAX-2}},
-year={1996},
-month=AUG,
-volume={16},
-number={4},
-pages={51 -59},
-keywords={MAX-2;instruction extensions;media processing;parallel computation;subword parallelism;word-oriented general-purpose processor;instruction sets;multimedia computing;parallel processing;},
-ISSN={0272-1732},}
-
-@ARTICLE{peleg-mmx-ieeemicro1996,
-author={Peleg, A. and Weiser, U.},
-journal={IEEE Micro},
-title={{MMX} technology extension to the {Intel} architecture},
-year={1996},
-month=AUG,
-volume={16},
-number={4},
-pages={42 -50},
-keywords={Intel architecture;MMX;SIMD;communications;compatibility;multimedia;operating systems;microprocessor chips;parallel architectures;},
-ISSN={0272-1732},}
-
-@ARTICLE{raman-sse-ieeemicro2000,
-author={Raman, S.K. and Pentkovski, V. and Keshava, J.},
-journal={IEEE Micro},
-title={Implementing streaming {SIMD} extensions on the {Pentium}-{III} processor },
-year={2000},
-month=JUL/AUG,
-volume={20},
-number={4},
-pages={47 -57},
-keywords={Internet;Pentium III developers;demanding multimedia;die size constraints;streaming SIMD extensions;instruction sets;microprocessor chips;},
-ISSN={0272-1732},}
-
-@misc{lomont-avx-irm2011,
-author={Chris Lomont},
-title = {Introduction to {Intel Advanced Vector Extensions}},
-howpublished = {Intel White Paper},
-year = {2011},
-}
-
-@ARTICLE{goodacre-armisa-computer2005,
-author={Goodacre, J. and Sloss, A.N.},
-journal={Computer},
-title={Parallelism and the {ARM} instruction set architecture},
-year={2005},
-month=JULY,
-volume={38},
-number={7},
-pages={ 42 - 50},
-keywords={ ARM RISC processor; ARM chip design; ARM instruction set architecture; digital signal processor-like operations; exception handling; multiprocessing; reduced-instruction-set computing; subword parallelism; thread-level parallelism; variable execution time; instruction sets; microprocessor chips; parallel architectures; parallel programming; reduced instruction set computing;},
-ISSN={0018-9162},}
-
-@ARTICLE{diefendorff-altivec-ieeemicro2000,
-author={Diefendorff, K. and Dubey, P.K. and Hochsprung, R. and Scale, H.},
-journal={IEEE Micro},
-title={{AltiVec} extension to {PowerPC} accelerates media processing},
-year={2000},
-month=MAR/APR,
-volume={20},
-number={2},
-pages={85 -95},
-keywords={2D image processing;3D graphics;AltiVec extension;Apple G4;Hewlett-Packard added MAX;MDMX;MIPS architecture;MMX;Motorola's MPC 7400;PA-RISC architecture;PowerPC;PowerPC's AltiVec;SSE;Silicon Graphics;Sun enhanced Sparc;alias KNI;handwriting recognition;media mining;media processing;multimedia technologies;narrow/broadband signal processing;personal computing;digital signal processing chips;handwriting recognition;multimedia systems;parallel architectures;},
-ISSN={0272-1732},}
-
-@misc{gwennap-mdmx-mpr1996,
-author={Linley Gwennap},
-title={Digital, {MIPS} Add Multimedia Extensions},
-howpublished = {Microprocessor Report},
-year = {1996},
-}
-@article{majc,
- author = {Tremblay, Marc and Chan, Jeffrey and Chaudhry, Shailender and Conigliaro, Andrew W. and Tse, Shing Sheung},
- title = {The {MAJC} Architecture: {A} Synthesis of Parallelism and Scalability},
- journal = {IEEE Micro},
- issue_date = {November 2000},
- volume = {20},
- number = {6},
- month = November,
- year = {2000},
- pages = {12--25},
- publisher = {IEEE Computer Society Press},
- address = {Los Alamitos, CA, USA},
-}
-
-@InProceedings{tx2,
- author = {John M. Frankovich and H. Philip Peterson},
- title = {A functional description of the {Lincoln} {TX-2} computer},
- booktitle = {Western Joint Computer Conference},
- year = 1957,
- address = {Los Angeles, CA},
- month = {February}
-}
-
-
-@TechReport{heil-tr1996,
- author = {Timothy H. Heil and James E. Smith},
- title = {Selective Dual Path Execution},
- institution = {University of Wisconsin - Madison},
- year = 1996,
- month = {November}}
-
-@inproceedings{Klauser-1998,
- author = {Klauser, A. and Austin, T. and Grunwald, D. and Calder, B.},
- title = {Dynamic Hammock Predication for Non-Predicated Instruction Set Architectures},
- booktitle = {Proceedings of the 1998 International Conference on Parallel Architectures and Compilation Techniques},
- series = {PACT '98},
- year = {1998},
- address = {Washington, DC, USA},
-}
-
-@inproceedings{Kim-micro2005,
- author = {Kim, Hyesoon and Mutlu, Onur and Stark, Jared and Patt, Yale N.},
- title = {Wish Branches: Combining Conditional Branching and Predication for Adaptive Predicated Execution},
- booktitle = {Proceedings of the 38th annual IEEE/ACM International Symposium on Microarchitecture},
- series = {MICRO 38},
- year = {2005},
- location = {Barcelona, Spain},
- pages = {43--54},
-}
-
-@INPROCEEDINGS{Gharachorloo90memoryconsistency,
- author = {Kourosh Gharachorloo and Daniel Lenoski and James Laudon
- and Phillip Gibbons and Anoop Gupta and John
- Hennessy},
- title = {Memory Consistency and Event Ordering in Scalable
- Shared-Memory Multiprocessors},
- booktitle = {In Proceedings of the 17th Annual International
- Symposium on Computer Architecture},
- year = {1990},
- pages = {15--26}
-}
-
-
-@inproceedings{Rajwar:2001:SLE,
- author = {Rajwar, Ravi and Goodman, James R.},
- title = {Speculative lock elision: enabling highly concurrent multithreaded execution},
- booktitle = {Proceedings of the 34th annual ACM/IEEE International Symposium on Microarchitecture},
- series = {MICRO 34},
- year = {2001},
- location = {Austin, Texas},
- pages = {294--305},
- publisher = {IEEE Computer Society},
-}
-
-@Misc{sparcieee1994,
- title = {{IEEE} Standard for a 32-bit microprocessor},
- howpublished = {IEEE Std. 1754-1994},
- year = 1994}
-
-
-@Book{parisckane1995,
- author = {Gerry Kane},
- title = {PA-RISC 2.0 Architecture},
- publisher = {Prentice Hall},
- year = 1995,
- month = {December},
- note = {ISBN 978-0131827349}}
-
-@article{ibmpower7,
- title={{IBM} {POWER7} multicore server processor},
- author={Sinharoy, Balaram and Kalla, R. and Starke, W. J. and Le,
- H. Q. and Cargnoni, R. and Van Norstrand, J. A. and
- Ronchetti, B. J. and Stuecheli, J. and Leenstra,
- J. and Guthrie, G. L. and Nguyen, D. Q. and Blaner,
- B. and Marino, C. F. and Retter, E. and Williams, P.},
- journal={IBM Journal of Research and Development},
- volume={55},
- number={3},
- pages={1--1},
- year={2011},
- publisher={IBM}
-}
-
-@article{virtio,
- author = {Russell, Rusty},
- title = {Virtio: {Towards} a De-facto Standard for Virtual {I/O} Devices},
- journal = {SIGOPS Oper. Syst. Rev.},
- issue_date = {July 2008},
- volume = {42},
- number = {5},
- month = jul,
- year = {2008},
- issn = {0163-5980},
- pages = {95--103},
- numpages = {9},
- publisher = {ACM},
- address = {New York, NY, USA},
-}
-
-@ARTICLE{goldbergvm,
-author={Goldberg, Robert P.},
-journal={Computer},
-title={Survey of virtual machine research},
-year={1974},
-month={June},
-volume={7},
-number={6},
-pages={34-45}
-}
-
-@Manual{alphapalcode,
- title = {{PALcode} for {Alpha} microprocessors: System Design
- Guide},
- organization = {Digital Equipment Corporation},
- address = {Maynard, Massachusetts},
- note = {EC-QFGLC-TE},
- month = {May},
- year = 1996}
-
-@article{transparent-superpages,
- author = {Navarro, Juan and Iyer, Sitaram and Druschel, Peter and Cox, Alan},
- title = {Practical, Transparent Operating System Support for Superpages},
- journal = {SIGOPS Oper. Syst. Rev.},
- issue_date = {Winter 2002},
- volume = {36},
- number = {SI},
- month = dec,
- year = {2002},
- issn = {0163-5980},
- pages = {89--104},
- numpages = {16},
- url = {https://doi.org/10.1145/844128.844138},
- doi = {10.1145/844128.844138},
- acmid = {844138},
- publisher = {ACM},
- address = {New York, NY, USA},
-}
-
-@Book{stretch,
- editor = {Werner Buchholz},
- title = {Planning a computer system: {Project} {Stretch}},
- publisher = {McGraw-Hill Book Company},
- year = 1962}
-
-@Article{ibm360,
- author = {G. M. Amdahl and G. A. Blaauw and F. P. Brooks, Jr.},
- title = {Architecture of the {IBM} {System/360}},
- journal = {IBM Journal of R. \& D.},
- year = 1964,
- volume = 8,
- number = 2
-}
-
-@inproceedings{cdc6600,
- author = {Thornton, James E.},
- title = {Parallel Operation in the {Control Data 6600}},
- booktitle = {Proceedings of the October 27-29, 1964, Fall Joint Computer Conference, Part II: Very High Speed Computer Systems},
- series = {AFIPS '64 (Fall, part II)},
- year = {1965},
- location = {San Francisco, California},
- pages = {33--40}
-}
-
-@InProceedings{jtseng:sbbci,
- author = {J. Tseng and K. Asanovi\'c},
- title = {Energy-Efficient Register Access},
- booktitle = {Proc. of the 13th Symposium on Integrated Circuits and
- Systems Design},
- address = {Manaus, Brazil},
- month = {September},
- year = 2000,
- pages = "377--384"
-}
-
-@TechReport{riscvtr2,
- author = {Andrew Waterman and Yunsup Lee and David A. Patterson and Krste Asanovi\'{c}},
- title = {The {RISC-V} Instruction Set Manual, {Volume I}: {Base}
- User-Level {ISA} Version 2.0},
- institution = {EECS Department, University of California, Berkeley},
- year = 2014,
- number = {UCB/EECS-2014-54},
- month = {May}}
-
-@Article{ibm370varch,
- author = {W. Buchholz},
- title = "{The IBM System/370 vector architecture}",
- journal = {IBM Systems Journal},
- year = 1986,
- volume = 25,
- number = 1,
- pages = {51--62}
-}
-
-@PhdThesis{krstephd,
- author = {Krste Asanovi\'c},
- title = {Vector Microprocessors},
- school = {University of California at Berkeley},
- year = 1998,
- month = {May},
- note = {Available as techreport UCB/CSD-98-1014}
-}
-
-@InProceedings{vp200,
- author = "Kenichi Miura and Keiichiro Uchida",
- title = "{FACOM Vector Processor System: VP-100/VP-200}",
- editor = "Kawalik",
- volume = "F7",
- booktitle = "Proceedings of NATO Advanced Research Workshop on
- High Speed Computing",
- year = 1984,
- publisher = "Springer-Verlag",
- note = "Also in: IEEE Tutorial Supercomputers: Design and
- Applications. Kai Hwang(editor), pp59-73"
-}
-@Manual{crayx1asm,
- title = {Cray Assembly Language {(CAL)} for {Cray} {X1} Systems Reference Manual},
- organization = {Cray Inc.},
- edition = {1.1},
- month = {June},
- year = 2003}
-}
-
-@misc{riscv-elf-psabi,
- title = {{RISC-V ELF psABI Specification}},
- howpublished = {\url{https://github.com/riscv/riscv-elf-psabi-doc/}}
-}
-
-@inproceedings{lithe-pan-hotpar09,
-author = {Heidi Pan and Benjamin Hindman and Krste Asanovi\'c},
-title = {{Lithe}: Enabling Efficient Composition of Parallel Libraries},
-booktitle = {Proceedings of the 1st USENIX Workshop on Hot Topics in Parallelism (HotPar~'09)},
-month = {March},
-year = {2009},
-address = {Berkeley, CA}}
-
-
-@inproceedings{lithe-pan-pldi10,
-author = {Heidi Pan and Benjamin Hindman and Krste Asanovi\'c},
-title = {Composing Parallel Software Efficiently with {Lithe}},
-booktitle = {31st Conference on Programming Language Design and Implementation},
-month = {June},
-year = {2010},
-address = {Toronto, Canada}}
-
diff --git a/src/riscv-spec.tex b/src/riscv-spec.tex
deleted file mode 100644
index 156b43b..0000000
--- a/src/riscv-spec.tex
+++ /dev/null
@@ -1,108 +0,0 @@
-%=======================================================================
-% riscv-spec.tex
-%-----------------------------------------------------------------------
-
-\documentclass[twoside,11pt]{book}
-
-\input{preamble}
-
-\newcommand{\specrev}{\mbox{20181221-Public-Review-{\em draft}}}
-
-\begin{document}
-
-\title{\vspace{-0.7in}\Large {\bf The RISC-V Instruction Set Manual} \\
- \large {\bf Volume I: Unprivileged ISA} \\
- Document Version \specrev
- \vspace{-0.1in}}
-
-\author{Editors: Andrew Waterman$^{1}$, Krste Asanovi\'{c}$^{1,2}$ \\
- $^{1}$SiFive Inc., \\
- $^{2}$CS Division, EECS Department, University of California, Berkeley \\
- {\tt andrew@sifive.com, krste@berkeley.edu} \\
- \today
-}
-\date{}
-\maketitle
-
-Contributors to all versions of the spec in
-alphabetical order (please contact editors to suggest
-corrections):
-Arvind, Krste Asanovi\'{c}, Rimas Avi\v{z}ienis, Jacob Bachmeyer, Christopher
-F. Batten, Allen J. Baum, Alex Bradbury, Scott Beamer, Preston Briggs,
-Christopher Celio, Chuanhua Chang, David Chisnall, Paul Clayton, Palmer
-Dabbelt, Roger Espasa, Shaked Flur, Stefan Freudenberger, Jan Gray, Michael
-Hamburg, John Hauser, David Horner, Alexandre Joannou,
-Olof Johansson, Ben Keller, Yunsup Lee,
-Paul Loewenstein, Daniel Lustig, Yatin Manerkar, Luc Maranget, Margaret
-Martonosi, Joseph Myers, Vijayanand Nagarajan, Rishiyur Nikhil, Jonas
-Oberhauser, Stefan O'Rear, Albert Ou, John Ousterhout, David Patterson,
-Christopher Pulte, Jose Renau, Colin Schmidt, Peter Sewell, Susmit Sarkar,
-Michael Taylor, Wesley Terpstra, Matt Thomas, Tommy Thorn, Caroline Trippel,
-Ray VanDeWalker, Muralidaran Vijayaraghavan, Megan Wachs, Andrew Waterman,
-Robert Watson, Derek Williams, Andrew Wright, Reinoud Zandijk, and Sizhuo
-Zhang.
-
-This document is released under a Creative Commons Attribution 4.0
-International License.
-
-This document is a derivative of ``The RISC-V Instruction Set
-Manual, Volume I: User-Level ISA Version 2.1'' released under the following license:
-\copyright \,2010--2017 Andrew Waterman, Yunsup Lee, David Patterson, Krste Asanovi\'{c}.
-Creative Commons Attribution 4.0 International License.
-
-Please cite as: ``The RISC-V Instruction Set
-Manual, Volume I: User-Level ISA, Document Version \specrev'', Editors
-Andrew Waterman and Krste Asanovi\'{c}, RISC-V Foundation, May 2017.
-
-
-\markboth{Volume I: RISC-V Unprivileged ISA V\specrev}
-{Volume I: RISC-V Unprivileged ISA V\specrev}
-\thispagestyle{empty}
-
-\frontmatter
-
-\input{preface}
-
-{\hypersetup{linktoc=all,hidelinks}
-\tableofcontents
-}
-
-\mainmatter
-
-\input{intro}
-\input{rv32}
-\input{zifencei}
-\input{rv32e}
-\input{rv64}
-\input{rv128}
-\input{m}
-\input{a}
-\input{csr}
-\input{counters}
-\input{f}
-\input{d}
-\input{q}
-\input{rvwmo}
-\input{l}
-\input{c}
-\input{b}
-\input{j}
-\input{t}
-\input{p}
-\input{v}
-\input{n}
-\input{zam}
-\input{ztso}
-\input{gmaps}
-\input{assembly}
-\input{extensions}
-\input{naming}
-\input{history}
-
-\appendix
-\input{memory}
-
-\bibliographystyle{plain}
-\bibliography{riscv-spec}
-
-\end{document}
diff --git a/src/riscv-unprivileged.adoc b/src/riscv-unprivileged.adoc
new file mode 100644
index 0000000..1e2aaa9
--- /dev/null
+++ b/src/riscv-unprivileged.adoc
@@ -0,0 +1,210 @@
+[[manual:unpriv,RISC-V ISA Manual, Volume I: Unprivileged Architecture]]
+= The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture
+include::../docs-resources/global-config.adoc[]
+:description: Unprivileged Architecture
+:colophon:
+:preface-title: Preamble
+:appendix-caption: Appendix
+:imagesdir: ../docs-resources/images
+:title-logo-image: image:risc-v_logo.png["RISC-V International Logo",pdfwidth=3.25in,align=center]
+ifdef::draft-watermark[]
+:page-background-image: image:draft.png[opacity=20%]
+endif::[]
+//:title-page-background-image: none
+//:back-cover-image: image:backpage.png[opacity=25%]
+:back-cover-image: image:riscv-horizontal-color.svg[opacity=25%]
+// Settings:
+:experimental:
+:reproducible:
+:imagesoutdir: {docdir}/../build/images-out
+:bibtex-file: src/resources/riscv-spec.bib
+:bibtex-order: alphabetical
+:bibtex-style: apa
+:bibtex-format: asciidoc
+:bibtex-throw: false
+:icons: font
+:lang: en
+:example-caption: Example
+:listing-caption: Listing
+:sectnums:
+:sectnumlevels: 5
+:sectlinks:
+:toc: left
+:toclevels: 5
+:source-highlighter: rouge
+:table-caption: Table
+:figure-caption: Figure
+:xrefstyle: short
+:chapter-refsig: Chapter
+:section-refsig: Section
+:appendix-refsig: Appendix
+// Uncomment :data-uri: if your eBook reader is not capable of rendering
+// embedded images. One known affected device is PocketBook InkPad 3.
+:data-uri:
+:hide-uri-scheme:
+:stem: latexmath
+:footnote:
+:le: &#8804;
+:ge: &#8805;
+:ne: &#8800;
+:approx: &#8776;
+:inf: &#8734;
+:circ: &#x2218;
+:bullet: &#x2219;
+:times: &#x00D7;
+:csrname: envcfg
+:imagesdir: images
+
+_Contributors to all versions of the spec in alphabetical order (please contact editors to suggest corrections):
+Arvind,
+Krste Asanović,
+Derek Atkins,
+Rimas Avižienis,
+Jacob Bachmeyer,
+Christopher F. Batten,
+Allen J. Baum,
+Scott Beamer,
+Abel Bernabeu,
+Hans Boehm,
+Alex Bradbury,
+Preston Briggs,
+Christopher Celio,
+Chuanhua Chang,
+David Chisnall,
+Paul Clayton,
+Palmer Dabbelt,
+L Peter Deutsch,
+Ken Dockser,
+Paul Donahue,
+Aaron Durbin,
+Roger Espasa,
+Greg Favor,
+Shaked Flur,
+Stefan Freudenberger,
+Marc Gauthier,
+Andy Glew,
+Jan Gray,
+Gianluca Guida,
+Michael Hamburg,
+John Hauser,
+Christian Herber,
+David Horner,
+Bruce Hoult,
+Bill Huffman,
+John Ingalls,
+Alexandre Joannou,
+Olof Johansson,
+Ben Keller,
+David Kruckemyer,
+Tariq Kurd,
+Yunsup Lee,
+Paul Loewenstein,
+Daniel Lustig,
+Yatin Manerkar,
+Luc Maranget,
+Ben Marshall,
+Margaret Martonosi,
+Phil McCoy,
+Nathan Menhorn,
+Christoph Müllner,
+Joseph Myers,
+Vijayanand Nagarajan,
+Torbjørn Viem Ness,
+Rishiyur Nikhil,
+Jonas Oberhauser,
+Stefan O'Rear,
+Markku-Juhani O. Saarinen,
+Albert Ou,
+John Ousterhout,
+Daniel Page,
+David Patterson,
+Christopher Pulte,
+Jose Renau,
+Susmit Sarkar,
+Josh Scheid,
+Colin Schmidt,
+Peter Sewell,
+Ved Shanbhogue,
+Brent Spinney,
+Brendan Sweeney,
+Michael Taylor,
+Wesley Terpstra,
+Matt Thomas,
+Tommy Thorn,
+Philipp Tomsich,
+Caroline Trippel,
+Ray VanDeWalker,
+Muralidaran Vijayaraghavan,
+Megan Wachs,
+Paul Wamsley,
+Andrew Waterman,
+Robert Watson,
+David Weaver,
+Derek Williams,
+Claire Wolf,
+Andrew Wright,
+Reinoud Zandijk,
+and Sizhuo Zhang._
+
+_This document is released under a Creative Commons Attribution 4.0 International License._
+
+_This document is a derivative of “The RISC-V Instruction Set Manual, Volume I: User-Level ISA
+Version 2.1” released under the following license: ©2010-2017 Andrew Waterman, Yunsup Lee,
+David Patterson, Krste Asanović. Creative Commons Attribution 4.0 International License.
+Please cite as: “The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document
+Version 20191214-draft”, Editors Andrew Waterman and Krste Asanović, RISC-V Foundation,
+December 2019._
+
+//the colophon allows for a section after the preamble that is part of the frontmatter and therefore not assigned a page number.
+include::colophon.adoc[]
+
+include::intro.adoc[]
+include::rv32.adoc[]
+include::rv32e.adoc[]
+include::rv64.adoc[]
+include::zifencei.adoc[]
+include::zicsr.adoc[]
+include::counters.adoc[]
+include::zihintntl.adoc[]
+include::zihintpause.adoc[]
+include::zimop.adoc[]
+include::zicond.adoc[]
+include::m-st-ext.adoc[]
+include::a-st-ext.adoc[]
+include::zawrs.adoc[]
+include::zacas.adoc[]
+include::zabha.adoc[]
+include::rvwmo.adoc[]
+include::ztso-st-ext.adoc[]
+include::cmo.adoc[]
+include::f-st-ext.adoc[]
+include::d-st-ext.adoc[]
+include::q-st-ext.adoc[]
+include::zfh.adoc[]
+include::bfloat16.adoc[]
+include::zfa.adoc[]
+include::zfinx.adoc[]
+include::c-st-ext.adoc[]
+include::zc.adoc[]
+include::b-st-ext.adoc[]
+include::v-st-ext.adoc[]
+include::scalar-crypto.adoc[]
+include::vector-crypto.adoc[]
+include::unpriv-cfi.adoc[]
+include::zilsd.adoc[]
+include::rv-32-64g.adoc[]
+include::naming.adoc[]
+include::mm-eplan.adoc[]
+include::mm-formal.adoc[]
+
+//Appendices for Vector
+include::vector-examples.adoc[]
+include::calling-convention.adoc[]
+include::rationale.adoc[]
+//include::fraclmul.adoc[]
+//End of Vector appendices
+
+include::index.adoc[]
+// this is generated generated from index markers.
+include::bibliography.adoc[]
+// this references the riscv-spec.bi file that has been copied into the resources directory
diff --git a/src/rnmi.adoc b/src/rnmi.adoc
new file mode 100644
index 0000000..b7468e8
--- /dev/null
+++ b/src/rnmi.adoc
@@ -0,0 +1,166 @@
+[[rnmi]]
+== "Smrnmi" Extension for Resumable Non-Maskable Interrupts, Version 1.0
+
+The base machine-level architecture supports only unresumable
+non-maskable interrupts (UNMIs), where the NMI jumps to a handler in
+machine mode, overwriting the current `mepc` and `mcause` register
+values. If the hart had been executing machine-mode code in a trap
+handler, the previous values in `mepc` and `mcause` would not be
+recoverable and so execution is not generally resumable.
+
+The Smrnmi extension adds support for resumable non-maskable interrupts
+(RNMIs) to RISC-V. The extension adds four new CSRs (`mnepc`, `mncause`,
+`mnstatus`, and `mnscratch`) to hold the interrupted state, and one new
+instruction, MNRET, to resume from the RNMI handler.
+
+=== RNMI Interrupt Signals
+
+The `rnmi` interrupt signals are inputs to the hart. These interrupts
+have higher priority than any other interrupt or exception on the hart
+and cannot be disabled by software. Specifically, they are not disabled
+by clearing the `mstatus`.MIE register.
+
+=== RNMI Handler Addresses
+
+The RNMI interrupt trap handler address is implementation-defined.
+
+RNMI also has an associated exception trap handler address, which is
+implementation defined.
+
+NOTE: For example, some implementations might use the address specified
+in `mtvec` as the RNMI exception trap handler.
+
+=== RNMI CSRs
+
+This extension adds additional M-mode CSRs to enable a resumable
+non-maskable interrupt (RNMI).
+
+.Resumable NMI scratch register `mnscratch`
+include::images/bytefield/mnscratch.edn[]
+
+The `mnscratch` CSR holds an MXLEN-bit read-write register which enables
+the RNMI trap handler to save and restore the context that was
+interrupted.
+
+.Resumable NMI program counter `mnepc`.
+include::images/bytefield/mnepc.edn[]
+
+The `mnepc` CSR is an MXLEN-bit read-write register which on entry to
+the RNMI trap handler holds the PC of the instruction that took the
+interrupt.
+
+The low bit of `mnepc` (`mnepc[0]`) is always zero. On implementations
+that support only IALIGN=32, the two low bits (`mnepc[1:0]`) are always
+zero.
+
+If an implementation allows IALIGN to be either 16 or 32 (by changing
+CSR `misa`, for example), then, whenever IALIGN=32, bit `mnepc[1]` is
+masked on reads so that it appears to be 0. This masking occurs also for
+the implicit read by the MNRET instruction. Though masked, `mnepc[1]`
+remains writable when IALIGN=32.
+
+`mnepc` is a *WARL* register that must be able to hold all valid virtual
+addresses. It need not be capable of holding all possible invalid
+addresses. Prior to writing `mnepc`, implementations may convert an
+invalid address into some other invalid address that `mnepc` is capable
+of holding.
+
+.Resumable NMI cause `mncause`.
+include::images/bytefield/mncause.edn[]
+
+The `mncause` CSR holds the reason for the RNMI.
+If the reason is an interrupt, bit MXLEN-1 is set to 1, and the RNMI
+cause is encoded in the least-significant bits.
+If the reason is an interrupt and RNMI causes are not supported, bit MXLEN-1 is
+set to 1, and zero is written to the least-significant bits.
+If the reason is an exception within M-mode that results in a double trap as
+specified in the Smdbltrp extension, bit MXLEN-1 is set to 0 and the
+least-significant bits are set to the cause code corresponding to the
+exception that precipitated the double trap.
+
+.Resumable NMI status register `mnstatus`.
+include::images/bytefield/mnstatus.edn[]
+
+The `mnstatus` CSR holds a two-bit field, MNPP, which on entry to the
+RNMI trap handler holds the privilege mode of the interrupted context,
+encoded in the same manner as `mstatus`.MPP. It also holds a one-bit
+field, MNPV, which on entry to the RNMI trap handler holds the virtualization
+mode of the interrupted context, encoded in the same manner as
+`mstatus`.MPV.
+
+If the Zicfilp extension is implemented, `mnstatus` also holds the MNPELP
+field, which on entry to the RNMI trap handler holds the previous `ELP` state.
+When an RNMI trap is taken, MNPELP is set to `ELP` and `ELP` is set to 0.
+
+`mnstatus` also holds the NMIE bit. When NMIE=1, non-maskable interrupts
+are enabled. When NMIE=0, _all_ interrupts are disabled.
+
+When NMIE=0, the hart behaves as though `mstatus`.MPRV were clear,
+regardless of the current setting of `mstatus`.MPRV.
+
+Upon reset, NMIE contains the value 0.
+
+[NOTE]
+====
+RNMIs are masked out of reset to give software the opportunity to
+initialize data structures and devices for subsequent RNMI handling.
+====
+
+Software can set NMIE to 1, but attempts to clear NMIE have no effect.
+
+[NOTE]
+====
+Normally, only reset sequences will explicitly set the NMIE bit.
+
+***
+
+That the NMIE bit is settable does not suffice to support the nesting of
+RNMIs. To support this feature in a direct manner would have required
+allowing software to clear the NMIE bit—a design choice that would have
+contravened the concept of non-maskability.
+
+Software that wishes to minimize the latency until the next RNMI is
+taken can follow the top-half/bottom-half model, where the RNMI handler
+itself only enqueues a task to a task queue then returns. The bulk of
+the interrupt servicing is performed later, with RNMIs enabled.
+====
+
+For the purposes of the WFI instruction, NMIE is a global interrupt
+enable, meaning that the setting of NMIE does not affect the operation
+of the WFI instruction.
+
+The other bits in `mnstatus` are _reserved_; software should write zeros
+and hardware implementations should return zeros.
+
+=== MNRET Instruction
+
+MNRET is an M-mode-only instruction that uses the values in `mnepc` and
+`mnstatus` to return to the program counter, privilege mode, and
+virtualization mode of the interrupted context. This instruction also
+sets `mnstatus`.NMIE. If MNRET changes the privilege mode to a mode less privileged than M, it also sets `mstatus`.MPRV to 0.
+If the Zicfilp extension is implemented, then if the new privileged mode
+is __y__, MNRET sets `ELP` to the logical AND of __y__LPE (see <<FCFIACT>>) and `mnstatus`.MNPELP.
+
+=== RNMI Operation
+
+When an RNMI interrupt is detected, the interrupted PC is written to the
+`mnepc` CSR, the type of RNMI to the `mncause` CSR, and the privilege
+mode of the interrupted context to the `mnstatus` CSR. The
+`mnstatus`.NMIE bit is cleared, masking all interrupts.
+
+The hart then enters machine-mode and jumps to the RNMI trap handler
+address.
+
+The RNMI handler can resume original execution using the new MNRET
+instruction, which restores the PC from `mnepc`, the privilege mode from
+`mnstatus`, and also sets `mnstatus`.NMIE, which re-enables interrupts.
+
+If the hart encounters an exception while executing in M-mode with the `mnstatus`.NMIE bit clear, the actions taken are the same as if the exception had occurred while `mnstatus`.NMIE were set, except that the program counter is set to the RNMI exception trap handler address.
+
+[NOTE]
+====
+The Smrnmi extension does not change the behavior of the MRET and SRET
+instructions. In particular, MRET and SRET are unaffected by the
+`mnstatus`.NMIE bit, and their execution does not alter the
+`mnstatus`.NMIE bit.
+====
diff --git a/src/rv-32-64g.adoc b/src/rv-32-64g.adoc
new file mode 100644
index 0000000..415cb3d
--- /dev/null
+++ b/src/rv-32-64g.adoc
@@ -0,0 +1,462 @@
+[[rv32-64g]]
+== RV32/64G Instruction Set Listings
+
+One goal of the RISC-V project is that it be used as a stable software
+development target. For this purpose, we define a combination of a base
+ISA (RV32I or RV64I) plus selected standard extensions (IMAFD, Zicsr,
+Zifencei) as a "general-purpose" ISA, and we use the abbreviation G
+for the IMAFDZicsr_Zifencei combination of instruction-set extensions.
+This chapter presents opcode maps and instruction-set listings for RV32G
+and RV64G.
+
+// note: &#8805; is unicode for >=
+[[opcodemap]]
+.RISC-V base opcode map, inst[1:0]=11
+[%autowidth.stretch,float="center",align="center",cols= ">.^4m, ^.^4m, ^.^4m, ^.^4m, ^.^4m, ^.^4m, ^.^4m, ^.^6m, ^.^4h"]
+|===
+|inst[4:2] .2+|000 .2+|001 .2+|010 .2+|011 .2+|100 .2+|101 .2+|110 .2+|111 (>32b)
+|inst[6:5]
+|00 |LOAD |LOAD-FP |_custom-0_ |MISC-MEM |OP-IMM |AUIPC |OP-IMM-32 |_reserved_
+|01 |STORE |STORE-FP |_custom-1_ |AMO |OP |LUI |OP-32 |_reserved_
+|10 |MADD |MSUB |NMSUB |NMADD |OP-FP |OP-V |_custom-2_ |_reserved_
+|11 |BRANCH |JALR |_reserved_ |JAL |SYSTEM |OP-VE |_custom-3_ |_reserved_
+|===
+
+<<opcodemap>> shows a map of the major opcodes for
+RVG. Opcodes marked as _reserved_
+should be avoided for custom instruction-set extensions as they might be
+used by future standard extensions. Major opcodes marked as _custom-0_
+through _custom-3_ will be avoided by future standard extensions and are
+recommended for use by custom instruction-set extensions within the base
+32-bit instruction format.
+
+We believe RV32G and RV64G provide simple but complete instruction sets
+for a broad range of general-purpose computing. The optional compressed
+instruction set described in <<compressed>> can
+be added (forming RV32GC and RV64GC) to improve performance, code size,
+and energy efficiency, though with some additional hardware complexity.
+
+As we move beyond IMAFDC into further instruction-set extensions, the
+added instructions tend to be more domain-specific and only provide
+benefits to a restricted class of applications, e.g., for multimedia or
+security. Unlike most commercial ISAs, the RISC-V ISA design clearly
+separates the base ISA and broadly applicable standard extensions from
+these more specialized additions.
+
+<<<
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+ |31 |27 |26 |25 |24 | 20|19 | 15| 14 | 12|11 | 7|6 | 0|
+ 4+^|funct7 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R-type
+ 6+^|imm[11:0] 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|I-type
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|funct3 2+^|imm[4:0] 2+^|opcode <|S-type
+ 4+^|imm[12\|10:5] 2+^|rs2 2+^|rs1 2+^|funct3 2+^|imm[4:1\|11] 2+^|opcode <|B-type
+10+^|imm[31:12] 2+^|rd 2+^|opcode <|U-type
+10+^|imm[20\|10:1\|11\|19:12] 2+^|rd 2+^|opcode <|J-type
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV32I Base Instruction Set*
+10+^|imm[31:12] 2+^|rd 2+^|0110111 <|[[norm:lui_enc]]LUI
+10+^|imm[31:12] 2+^|rd 2+^|0010111 <|[[norm:auipc_enc]]AUIPC
+10+^|imm[20\|10:1\|11\|19:12] 2+^|rd 2+^|1101111 <|[[norm:jal_enc]]JAL
+ 6+^|imm[11:0] 2+^|rs1 2+^|000 2+^|rd 2+^|1100111 <|[[norm:jalr_enc]]JALR
+ 4+^|imm[12\|10:5] 2+^|rs2 2+^|rs1 2+^|000 2+^|imm[4:1\|11] 2+^|1100011 <|[[norm:beq_enc]]BEQ
+ 4+^|imm[12\|10:5] 2+^|rs2 2+^|rs1 2+^|001 2+^|imm[4:1\|11] 2+^|1100011 <|[[norm:bne_enc]]BNE
+ 4+^|imm[12\|10:5] 2+^|rs2 2+^|rs1 2+^|100 2+^|imm[4:1\|11] 2+^|1100011 <|[[norm:blt_enc]]BLT
+ 4+^|imm[12\|10:5] 2+^|rs2 2+^|rs1 2+^|101 2+^|imm[4:1\|11] 2+^|1100011 <|[[norm:bge_enc]]BGE
+ 4+^|imm[12\|10:5] 2+^|rs2 2+^|rs1 2+^|110 2+^|imm[4:1\|11] 2+^|1100011 <|[[norm:bltu_enc]]BLTU
+ 4+^|imm[12\|10:5] 2+^|rs2 2+^|rs1 2+^|111 2+^|imm[4:1\|11] 2+^|1100011 <|[[norm:bgeu_enc]]BGEU
+ 6+^|imm[11:0] 2+^|rs1 2+^|000 2+^|rd 2+^|0000011 <|[[norm:lb_enc]]LB
+ 6+^|imm[11:0] 2+^|rs1 2+^|001 2+^|rd 2+^|0000011 <|[[norm:lh_enc]]LH
+ 6+^|imm[11:0] 2+^|rs1 2+^|010 2+^|rd 2+^|0000011 <|[[norm:lw_enc]]LW
+ 6+^|imm[11:0] 2+^|rs1 2+^|100 2+^|rd 2+^|0000011 <|[[norm:lbu_enc]]LBU
+ 6+^|imm[11:0] 2+^|rs1 2+^|101 2+^|rd 2+^|0000011 <|[[norm:lhu_enc]]LHU
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|000 2+^|imm[4:0] 2+^|0100011 <|[[norm:sb_enc]]SB
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|001 2+^|imm[4:0] 2+^|0100011 <|[[norm:sh_enc]]SH
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|010 2+^|imm[4:0] 2+^|0100011 <|[[norm:sw_enc]]SW
+ 6+^|imm[11:0] 2+^|rs1 2+^|000 2+^|rd 2+^|0010011 <|[[norm:addi_enc]]ADDI
+ 6+^|imm[11:0] 2+^|rs1 2+^|010 2+^|rd 2+^|0010011 <|[[norm:slti_enc]]SLTI
+ 6+^|imm[11:0] 2+^|rs1 2+^|011 2+^|rd 2+^|0010011 <|[[norm:sltiu_enc]]SLTIU
+ 6+^|imm[11:0] 2+^|rs1 2+^|100 2+^|rd 2+^|0010011 <|[[norm:xori_enc]]XORI
+ 6+^|imm[11:0] 2+^|rs1 2+^|110 2+^|rd 2+^|0010011 <|[[norm:ori_enc]]ORI
+ 6+^|imm[11:0] 2+^|rs1 2+^|111 2+^|rd 2+^|0010011 <|[[norm:andi_enc]]ANDI
+ 4+^|0000000 2+^|shamt 2+^|rs1 2+^|001 2+^|rd 2+^|0010011 <|[[norm:slli_enc]]SLLI
+ 4+^|0000000 2+^|shamt 2+^|rs1 2+^|101 2+^|rd 2+^|0010011 <|[[norm:srli_enc]]SRLI
+ 4+^|0100000 2+^|shamt 2+^|rs1 2+^|101 2+^|rd 2+^|0010011 <|[[norm:srai_enc]]SRAI
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|0110011 <|[[norm:add_enc]]ADD
+ 4+^|0100000 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|0110011 <|[[norm:sub_enc]]SUB
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|0110011 <|[[norm:sll_enc]]SLL
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0110011 <|[[norm:slt_enc]]SLT
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0110011 <|[[norm:sltu_enc]]SLTU
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|100 2+^|rd 2+^|0110011 <|[[norm:xor_enc]]XOR
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|101 2+^|rd 2+^|0110011 <|[[norm:srl_enc]]SRL
+ 4+^|0100000 2+^|rs2 2+^|rs1 2+^|101 2+^|rd 2+^|0110011 <|[[norm:sra_enc]]SRA
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|110 2+^|rd 2+^|0110011 <|[[norm:or_enc]]OR
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|111 2+^|rd 2+^|0110011 <|[[norm:and_enc]]AND
+ 3+^|fm 2+^|pred 1+^|succ 2+^|rs1 2+^|000 2+^|rd 2+^|0001111 <|[[norm:fence_enc]]FENCE
+ 3+^|1000 2+^|0011 1+^|0011 2+^|00000 2+^|000 2+^|00000 2+^|0001111 <|[[norm:fence-tso_enc]]FENCE.TSO
+ 3+^|0000 2+^|0001 1+^|0000 2+^|00000 2+^|000 2+^|00000 2+^|0001111 <|[[norm:pause_enc]]PAUSE
+ 6+^|000000000000 2+^|00000 2+^|000 2+^|00000 2+^|1110011 <|[[norm:ecall_enc]]ECALL
+ 6+^|000000000001 2+^|00000 2+^|000 2+^|00000 2+^|1110011 <|[[norm:ebreak_enc]]EBREAK
+|===
+
+<<<
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|
+ |31 |27 |26 |25 |24 | 20|19 | 15| 14 | 12|11 | 7|6 | 0|
+ 4+^|funct7 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R-type
+ 6+^|imm[11:0] 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|I-type
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|funct3 2+^|imm[4:0] 2+^|opcode <|S-type
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV64I Base Instruction Set (in addition to RV32I)*
+ 6+^|imm[11:0] 2+^|rs1 2+^|110 2+^|rd 2+^|0000011 <|[[norm:lwu_enc]]LWU
+ 6+^|imm[11:0] 2+^|rs1 2+^|011 2+^|rd 2+^|0000011 <|[[norm:ld_enc]]LD
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|011 2+^|imm[4:0] 2+^|0100011 <|[[norm:sd_enc]]SD
+ 3+^|000000 3+^|shamt 2+^|rs1 2+^|001 2+^|rd 2+^|0010011 <|SLLI
+ 3+^|000000 3+^|shamt 2+^|rs1 2+^|101 2+^|rd 2+^|0010011 <|SRLI
+ 3+^|010000 3+^|shamt 2+^|rs1 2+^|101 2+^|rd 2+^|0010011 <|SRAI
+ 6+^|imm[11:0] 2+^|rs1 2+^|000 2+^|rd 2+^|0011011 <|[[norm:addiw_enc]]ADDIW
+ 4+^|0000000 2+^|shamt 2+^|rs1 2+^|001 2+^|rd 2+^|0011011 <|[[norm:slliw_enc]]SLLIW
+ 4+^|0000000 2+^|shamt 2+^|rs1 2+^|101 2+^|rd 2+^|0011011 <|[[norm:srliw_enc]]SRLIW
+ 4+^|0100000 2+^|shamt 2+^|rs1 2+^|101 2+^|rd 2+^|0011011 <|[[norm:sraiw_enc]]SRAIW
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|0111011 <|[[norm:addw_enc]]ADDW
+ 4+^|0100000 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|0111011 <|[[norm:subw_enc]]SUBW
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|0111011 <|[[norm:sllw_enc]]SLLW
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|101 2+^|rd 2+^|0111011 <|[[norm:srlw_enc]]SRLW
+ 4+^|0100000 2+^|rs2 2+^|rs1 2+^|101 2+^|rd 2+^|0111011 <|[[norm:sraw_enc]]SRAW
+|===
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV32/RV64 _Zifencei_ Standard Extension*
+ 6+^|imm[11:0] 2+^|rs1 2+^|001 2+^|rd 2+^|0001111 <|FENCE.I
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV32/RV64 _Zicsr_ Standard Extension*
+ 6+^|csr 2+^|rs1 2+^|001 2+^|rd 2+^|1110011 <|CSRRW
+ 6+^|csr 2+^|rs1 2+^|010 2+^|rd 2+^|1110011 <|CSRRS
+ 6+^|csr 2+^|rs1 2+^|011 2+^|rd 2+^|1110011 <|CSRRC
+ 6+^|csr 2+^|uimm 2+^|101 2+^|rd 2+^|1110011 <|CSRRWI
+ 6+^|csr 2+^|uimm 2+^|110 2+^|rd 2+^|1110011 <|CSRRSI
+ 6+^|csr 2+^|uimm 2+^|111 2+^|rd 2+^|1110011 <|CSRRCI
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV32M Standard Extension*
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|0110011 <|[[norm:mul_enc]]MUL
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|0110011 <|[[norm:mulh_enc]]MULH
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0110011 <|[[norm:mulhsu_enc]]MULHSU
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0110011 <|[[norm:mulhu_enc]]MULHU
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|100 2+^|rd 2+^|0110011 <|[[norm:div_enc]]DIV
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|101 2+^|rd 2+^|0110011 <|[[norm:divu_enc]]DIVU
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|110 2+^|rd 2+^|0110011 <|[[norm:rem_enc]]REM
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|111 2+^|rd 2+^|0110011 <|[[norm:remu_enc]]REMU
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV64M Standard Extension (in addition to RV32M)*
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|0111011 <|[[norm:mulw_enc]]MULW
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|100 2+^|rd 2+^|0111011 <|[[norm:divw_enc]]DIVW
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|101 2+^|rd 2+^|0111011 <|[[norm:divuw_enc]]DIVUW
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|110 2+^|rd 2+^|0111011 <|[[norm:remw_enc]]REMW
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|111 2+^|rd 2+^|0111011 <|[[norm:remuw_enc]]REMUW
+|===
+
+<<<
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|
+ |31 |27 |26 |25 |24 | 20|19 | 15| 14 | 12|11 | 7|6 | 0|
+ 4+^|funct7 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R-type
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV32A Standard Extension*
+ 2+^|00010 ^|aq ^|rl 2+^|00000 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|LR.W
+ 2+^|00011 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|SC.W
+ 2+^|00001 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|AMOSWAP.W
+ 2+^|00000 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|AMOADD.W
+ 2+^|00100 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|AMOXOR.W
+ 2+^|01100 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|AMOAND.W
+ 2+^|01000 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|AMOOR.W
+ 2+^|10000 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|AMOMIN.W
+ 2+^|10100 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|AMOMAX.W
+ 2+^|11000 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|AMOMINU.W
+ 2+^|11100 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|0101111 <|AMOMAXU.W
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV64A Standard Extension (in addition to RV32A)*
+ 2+^|00010 ^|aq ^|rl 2+^|00000 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|LR.D
+ 2+^|00011 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|SC.D
+ 2+^|00001 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|AMOSWAP.D
+ 2+^|00000 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|AMOADD.D
+ 2+^|00100 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|AMOXOR.D
+ 2+^|01100 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|AMOAND.D
+ 2+^|01000 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|AMOOR.D
+ 2+^|10000 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|AMOMIN.D
+ 2+^|10100 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|AMOMAX.D
+ 2+^|11000 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|AMOMINU.D
+ 2+^|11100 ^|aq ^|rl 2+^|rs2 2+^|rs1 2+^|011 2+^|rd 2+^|0101111 <|AMOMAXU.D
+|===
+
+<<<
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+ |31 |27 |26 |25 |24 | 20|19 | 15| 14 | 12|11 | 7|6 | 0|
+ 4+^|funct7 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R-type
+ 2+^|rs3 2+^|funct2 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R4-type
+ 6+^|imm[11:0] 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|I-type
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|funct3 2+^|imm[4:0] 2+^|opcode <|S-type
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV32F Standard Extension*
+ 6+^|imm[11:0] 2+^|rs1 2+^|010 2+^|rd 2+^|0000111 <|FLW
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|010 2+^|imm[4:0] 2+^|0100111 <|FSW
+ 2+^|rs3 2+^|00 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1000011 <|FMADD.S
+ 2+^|rs3 2+^|00 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1000111 <|FMSUB.S
+ 2+^|rs3 2+^|00 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1001011 <|FNMSUB.S
+ 2+^|rs3 2+^|00 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1001111 <|FNMADD.S
+ 4+^|0000000 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FADD.S
+ 4+^|0000100 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FSUB.S
+ 4+^|0001000 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FMUL.S
+ 4+^|0001100 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FDIV.S
+ 4+^|0101100 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FSQRT.S
+ 4+^|0010000 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FSGNJ.S
+ 4+^|0010000 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FSGNJN.S
+ 4+^|0010000 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|1010011 <|FSGNJX.S
+ 4+^|0010100 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FMIN.S
+ 4+^|0010100 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FMAX.S
+ 4+^|1100000 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.W.S
+ 4+^|1100000 2+^|00001 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.WU.S
+ 4+^|1110000 2+^|00000 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FMV.X.W
+ 4+^|1010000 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|1010011 <|FEQ.S
+ 4+^|1010000 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FLT.S
+ 4+^|1010000 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FLE.S
+ 4+^|1110000 2+^|00000 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FCLASS.S
+ 4+^|1101000 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.S.W
+ 4+^|1101000 2+^|00001 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.S.WU
+ 4+^|1111000 2+^|00000 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FMV.W.X
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV64F Standard Extension (in addition to RV32F)*
+ 4+^|1100000 2+^|00010 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.L.S
+ 4+^|1100000 2+^|00011 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.LU.S
+ 4+^|1101000 2+^|00010 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.S.L
+ 4+^|1101000 2+^|00011 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.S.LU
+|===
+
+<<<
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+ |31 |27 |26 |25 |24 | 20|19 | 15| 14 | 12|11 | 7|6 | 0|
+ 4+^|funct7 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R-type
+ 2+^|rs3 2+^|funct2 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R4-type
+ 6+^|imm[11:0] 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|I-type
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|funct3 2+^|imm[4:0] 2+^|opcode <|S-type
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+|*RV32D Standard Extension*
+ 6+^|imm[11:0] 2+^|rs1 2+^|011 2+^|rd 2+^|0000111 <|FLD
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|011 2+^|imm[4:0] 2+^|0100111 <|FSD
+ 2+^|rs3 2+^|01 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1000011 <|FMADD.D
+ 2+^|rs3 2+^|01 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1000111 <|FMSUB.D
+ 2+^|rs3 2+^|01 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1001011 <|FNMSUB.D
+ 2+^|rs3 2+^|01 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1001111 <|FNMADD.D
+ 4+^|0000001 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FADD.D
+ 4+^|0000101 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FSUB.D
+ 4+^|0001001 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FMUL.D
+ 4+^|0001101 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FDIV.D
+ 4+^|0101101 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FSQRT.D
+ 4+^|0010001 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FSGNJ.D
+ 4+^|0010001 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FSGNJN.D
+ 4+^|0010001 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|1010011 <|FSGNJX.D
+ 4+^|0010101 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FMIN.D
+ 4+^|0010101 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FMAX.D
+ 4+^|0100000 2+^|00001 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.S.D
+ 4+^|0100001 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.D.S
+ 4+^|1010001 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|1010011 <|FEQ.D
+ 4+^|1010001 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FLT.D
+ 4+^|1010001 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FLE.D
+ 4+^|1110001 2+^|00000 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FCLASS.D
+ 4+^|1100001 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.W.D
+ 4+^|1100001 2+^|00001 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.WU.D
+ 4+^|1101001 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.D.W
+ 4+^|1101001 2+^|00001 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.D.WU
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV64D Standard Extension (in addition to RV32D)*
+ 4+^|1100001 2+^|00010 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.L.D
+ 4+^|1100001 2+^|00011 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.LU.D
+ 4+^|1110001 2+^|00000 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FMV.X.D
+ 4+^|1101001 2+^|00010 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.D.L
+ 4+^|1101001 2+^|00011 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.D.LU
+ 4+^|1111001 2+^|00000 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FMV.D.X
+|===
+
+<<<
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|
+ |31 |27 |26 |25 |24 | 20|19 | 15| 14 | 12|11 | 7|6 | 0|
+ 4+^|funct7 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R-type
+ 2+^|rs3 2+^|funct2 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R4-type
+ 6+^|imm[11:0] 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|I-type
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|funct3 2+^|imm[4:0] 2+^|opcode <|S-type
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV32Q Standard Extension*
+ 4+^|imm[11:0] 2+^| 2+^|rs1 2+^|100 2+^|rd 2+^|0000111 <|FLQ
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|100 2+^|imm[4:0] 2+^|0100111 <|FSQ
+ 2+^|rs3 2+^|11 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1000011 <|FMADD.Q
+ 2+^|rs3 2+^|11 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1000111 <|FMSUB.Q
+ 2+^|rs3 2+^|11 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1001011 <|FNMSUB.Q
+ 2+^|rs3 2+^|11 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1001111 <|FNMADD.Q
+ 4+^|0000011 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FADD.Q
+ 4+^|0000111 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FSUB.Q
+ 4+^|0001011 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FMUL.Q
+ 4+^|0001111 2+^|rs2 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FDIV.Q
+ 4+^|0101111 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FSQRT.Q
+ 4+^|0010011 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FSGNJ.Q
+ 4+^|0010011 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FSGNJN.Q
+ 4+^|0010011 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|1010011 <|FSGNJX.Q
+ 4+^|0010111 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FMIN.Q
+ 4+^|0010111 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FMAX.Q
+ 4+^|0100000 2+^|00011 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.S.Q
+ 4+^|0100011 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.Q.S
+ 4+^|0100001 2+^|00011 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.D.Q
+ 4+^|0100011 2+^|00001 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.Q.D
+ 4+^|1010011 2+^|rs2 2+^|rs1 2+^|010 2+^|rd 2+^|1010011 <|FEQ.Q
+ 4+^|1010011 2+^|rs2 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FLT.Q
+ 4+^|1010011 2+^|rs2 2+^|rs1 2+^|000 2+^|rd 2+^|1010011 <|FLE.Q
+ 4+^|1110011 2+^|00000 2+^|rs1 2+^|001 2+^|rd 2+^|1010011 <|FCLASS.Q
+ 4+^|1100011 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.W.Q
+ 4+^|1100011 2+^|00001 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.WU.Q
+ 4+^|1101011 2+^|00000 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.Q.W
+ 4+^|1101011 2+^|00001 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.Q.WU
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|*RV64Q Standard Extension (in addition to RV32Q)*
+ 4+^|1100011 2+^|00010 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.L.Q
+ 4+^|1100011 2+^|00011 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.LU.Q
+ 4+^|1101011 2+^|00010 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.Q.L
+ 4+^|1101011 2+^|00011 2+^|rs1 2+^|rm 2+^|rd 2+^|1010011 <|FCVT.Q.LU
+|===
+
+<<<
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|
+ |31 |27 |26 |25 |24 | 20|19 | 15| 14 | 12|11 | 7|6 | 0|
+ 4+^|funct7 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R-type
+ 2+^|rs3 2+^|funct2 2+^|rs2 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|R4-type
+ 6+^|imm[11:0] 2+^|rs1 2+^|funct3 2+^|rd 2+^|opcode <|I-type
+ 4+^|imm[11:5] 2+^|rs2 2+^|rs1 2+^|funct3 2+^|imm[4:0] 2+^|opcode <|S-type
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^m,^m,^m,^m,^m,^m,^m,<m",options="header"]
+|===
+8+|RV32Zfh Standard Extension
+3+|imm[11:0] |rs1 |001 |rd |0000111 |FLH
+2+|imm[11:5] |rs2 |rs1 |001 |imm[4:0] |0100111 |FSH
+|rs3 |10 |rs2 |rs1 |rm |rd |1000011 |FMADD.H
+|rs3 |10 |rs2 |rs1 |rm |rd |1000111 |FMSUB.H
+|rs3 |10 |rs2 |rs1 |rm |rd |1001011 |FNMSUB.H
+|rs3 |10 |rs2 |rs1 |rm |rd |1001111 |FNMADD.H
+2+|0000010 |rs2 |rs1 |rm |rd |1010011 |FADD.H
+2+|0000110 |rs2 |rs1 |rm |rd |1010011 |FSUB.H
+2+|0001010 |rs2 |rs1 |rm |rd |1010011 |FMUL.H
+2+|0001110 |rs2 |rs1 |rm |rd |1010011 |FDIV.H
+2+|0101110 |00000 |rs1 |rm |rd |1010011 |FSQRT.H
+2+|0010010 |rs2 |rs1 |000 |rd |1010011 |FSGNJ.H
+2+|0010010 |rs2 |rs1 |001 |rd |1010011 |FSGNJN.H
+2+|0010010 |rs2 |rs1 |010 |rd |1010011 |FSGNJX.H
+2+|0010110 |rs2 |rs1 |000 |rd |1010011 |FMIN.H
+2+|0010110 |rs2 |rs1 |001 |rd |1010011 |FMAX.H
+2+|0100000 |00010 |rs1 |rm |rd |1010011 |FCVT.S.H
+2+|0100010 |00000 |rs1 |rm |rd |1010011 |FCVT.H.S
+2+|0100001 |00010 |rs1 |rm |rd |1010011 |FCVT.D.H
+2+|0100010 |00001 |rs1 |rm |rd |1010011 |FCVT.H.D
+2+|0100011 |00010 |rs1 |rm |rd |1010011 |FCVT.Q.H
+2+|0100010 |00011 |rs1 |rm |rd |1010011 |FCVT.H.Q
+2+|1010010 |rs2 |rs1 |010 |rd |1010011 |FEQ.H
+2+|1010010 |rs2 |rs1 |001 |rd |1010011 |FLT.H
+2+|1010010 |rs2 |rs1 |000 |rd |1010011 |FLE.H
+2+|1110010 |00000 |rs1 |001 |rd |1010011 |FCLASS.H
+2+|1100010 |00000 |rs1 |rm |rd |1010011 |FCVT.W.H
+2+|1100010 |00001 |rs1 |rm |rd |1010011 |FCVT.WU.H
+2+|1110010 |00000 |rs1 |000 |rd |1010011 |FMV.X.H
+2+|1101010 |00000 |rs1 |rm |rd |1010011 |FCVT.H.W
+2+|1101010 |00001 |rs1 |rm |rd |1010011 |FCVT.H.WU
+2+|1111010 |00000 |rs1 |000 |rd |1010011 |FMV.H.X
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^m,^m,^m,^m,^m,^m,^m,<m",options="header"]
+|===
+8+|RV64Zfh Standard Extension (in addition to RV32Zfh)
+2+|1100010 |00010 |rs1 |rm |rd |1010011 |FCVT.L.H
+2+|1100010 |00011 |rs1 |rm |rd |1010011 |FCVT.LU.H
+2+|1101010 |00010 |rs1 |rm |rd |1010011 |FCVT.H.L
+2+|1101010 |00011 |rs1 |rm |rd |1010011 |FCVT.H.LU
+|===
+
+[%autowidth.stretch,float="center",align="center",cols="^2m,^2m,^2m,^2m,<2m,>3m, <4m, >4m, <4m, >4m, <4m, >4m, <4m, >4m, <6m"]
+|===
+15+^|Zawrs Standard Extension
+
+6+^|000000001101 2+^|00000 2+^|000 2+^|00000 2+^|1110011 <|WRS.NTO
+6+^|000000011101 2+^|00000 2+^|000 2+^|00000 2+^|1110011 <|WRS.STO
+|===
+
+
+<<rvgcsrnames>> lists the CSRs that have currently been
+allocated CSR addresses. The timers, counters, and floating-point CSRs
+are the only CSRs defined in this specification.
+
+[[rvgcsrnames]]
+.RISC-V control and status register (CSR) address map.
+[%autowidth,float="center",align="center",cols="<m,<,<m,<",options="header"]
+|===
+|Number|Privilege|Name|Description
+4+^|Floating-Point Control and Status Registers
+|0x001|Read write|fflags|Floating-Point Accrued Exceptions.
+|0x002|Read write|frm|Floating-Point Dynamic Rounding Mode.
+|0x003|Read write|fcsr|Floating-Point Control and Status Register (`frm` + `fflags`).
+4+^|Counters and Timers
+|0xC00|Read-only|cycle|Cycle counter for RDCYCLE instruction.
+|0xC01|Read-only|time|Timer for RDTIME instruction.
+|0xC02|Read-only|instret|Instructions-retired counter for RDINSTRET instruction.
+|0xC80|Read-only|cycleh|Upper 32 bits of `cycle`, RV32I only.
+|0xC81|Read-only|timeh|Upper 32 bits of `time`, RV32I only.
+|0xC82|Read-only|instreth|Upper 32 bits of `instret`, RV32I only.
+|===
diff --git a/src/rv128.tex b/src/rv128.tex
deleted file mode 100644
index 64515e3..0000000
--- a/src/rv128.tex
+++ /dev/null
@@ -1,71 +0,0 @@
-\chapter{RV128I Base Integer Instruction Set, Version 1.7}
-\label{rv128}
-
-\begin{quote}
-{\em ``There is only one mistake that can be made in computer design that is
-difficult to recover from---not having enough address bits for memory
-addressing and memory management.''} Bell and Strecker, ISCA-3, 1976.
-\end{quote}
-
-This chapter describes RV128I, a variant of the RISC-V ISA
-supporting a flat 128-bit address space. The variant is a
-straightforward extrapolation of the existing RV32I and RV64I designs.
-
-\begin{commentary}
-The primary reason to extend integer register width is to support
-larger address spaces. It is not clear when a flat address space larger
-than 64 bits will be required. At the time of writing, the fastest
-supercomputer in the world as measured by the Top500 benchmark had
-over \wunits{1}{PB} of DRAM, and would require over 50 bits of address
-space if all the DRAM resided in a single address space. Some
-warehouse-scale computers already contain even larger quantities of
-DRAM, and new dense solid-state non-volatile memories and fast
-interconnect technologies might drive a demand for even larger memory
-spaces. Exascale systems research is targeting \wunits{100}{PB}
-memory systems, which occupy 57 bits of address space. At historic
-rates of growth, it is possible that greater than 64 bits of address
-space might be required before 2030.
-
-History suggests that whenever it becomes clear that more than 64 bits
-of address space is needed, architects will repeat intensive debates
-about alternatives to extending the address space, including
-segmentation, 96-bit address spaces, and software workarounds, until,
-finally, flat 128-bit address spaces will be adopted as the simplest
-and best solution.
-
-We have not frozen the RV128 spec at this time, as there might be need
-to evolve the design based on actual usage of 128-bit address spaces.
-\end{commentary}
-
-RV128I builds upon RV64I in the same way RV64I builds upon RV32I, with
-integer registers extended to 128 bits (i.e., XLEN=128). Most integer
-computational instructions are unchanged as they are defined to
-operate on XLEN bits. The RV64I ``*W'' integer instructions that
-operate on 32-bit values in the low bits of a register are retained,
-and a new set of ``*D'' integer instructions that operate on 64-bit
-values held in the low bits of the 128-bit integer registers are
-added. The ``*D'' instructions consume two major opcodes (OP-IMM-64
-and OP-64) in the standard 32-bit encoding.
-
-\begin{commentary}
- To improve compatibility with RV64, in a reverse of how RV32 to RV64
- was handled, we might change the decoding around to rename RV64I ADD
- as a 64-bit ADDD, and add a 128-bit ADDQ in what was previously the
- OP-64 major opcode (now renamed the OP-128 major opcode).
-\end{commentary}
-
-Shifts by an immediate (SLLI/SRLI/SRAI) are now encoded using the low
-7 bits of the I-immediate, and variable shifts (SLL/SRL/SRA) use the
-low 7 bits of the shift amount source register.
-
-A LDU (load double unsigned) instruction is added using the existing
-LOAD major opcode, along with new LQ and SQ instructions to load and
-store quadword values. SQ is added to the STORE major opcode, while
-LQ is added to the MISC-MEM major opcode.
-
-The floating-point instruction set is unchanged, although the 128-bit
-Q floating-point extension can now support FMV.X.Q and FMV.Q.X
-instructions, together with additional FCVT instructions to and from
-the T (128-bit) integer format.
-
-
diff --git a/src/rv32.adoc b/src/rv32.adoc
new file mode 100644
index 0000000..70bc76c
--- /dev/null
+++ b/src/rv32.adoc
@@ -0,0 +1,1103 @@
+[[rv32]]
+== RV32I Base Integer Instruction Set, Version 2.1
+
+This chapter describes the RV32I base integer instruction set.
+
+[NOTE]
+====
+RV32I was designed to be sufficient to form a compiler target and to
+support modern operating system environments. The ISA was also designed
+to reduce the hardware required in a minimal implementation. RV32I
+contains 40 unique instructions, though a simple implementation might
+cover the ECALL/EBREAK instructions with a single SYSTEM hardware
+instruction that always traps and might be able to implement the FENCE
+instruction as a NOP, reducing base instruction count to 38 total. RV32I
+can emulate almost any other ISA extension (except the A extension,
+which requires additional hardware support for atomicity).
+
+In practice, a hardware implementation including the machine-mode
+privileged architecture will also require the 6 CSR instructions.
+
+Subsets of the base integer ISA might be useful for pedagogical
+purposes, but the base has been defined such that there should be little
+incentive to subset a real hardware implementation beyond omitting
+support for misaligned memory accesses and treating all SYSTEM
+instructions as a single trap.
+====
+
+[NOTE]
+====
+The standard RISC-V assembly language syntax is documented in the
+Assembly Programmer's Manual cite:[riscv-asm-manual].
+====
+
+[NOTE]
+====
+Most of the commentary for RV32I also applies to the RV64I base.
+====
+
+=== Programmers' Model for Base Integer ISA
+
+<<gprs>> shows the unprivileged state for the base integer ISA.
+[#norm:rv32i_xreg_sz]#For RV32I, the 32 `x` registers are each 32 bits wide,
+i.e., `XLEN=32`.# [#norm:x0eq0]#Register `x0` is hardwired with all bits equal to 0.#
+[#norm:rv32i_rv64i_other_xregs]#General purpose registers `x1-x31` hold values that various
+instructions interpret as a collection of Boolean values, or as two's
+complement signed binary integers or unsigned binary integers.#
+
+[[norm:pcreg_op]]
+There is one additional unprivileged register: the program counter `pc`
+holds the address of the current instruction.
+
+[[gprs]]
+.RISC-V base unprivileged integer register state.
+[cols="<,^,>",options="header",width="50%",align="center",grid="rows"]
+|===
+<| [.small]#XLEN-1#| >| [.small]#0#
+3+^| [.small]#x0/zero#
+3+^| [.small]#x1#
+3+^| [.small]#x2#
+3+^| [.small]#x3#
+3+^| [.small]#x4#
+3+^| [.small]#x5#
+3+^| [.small]#x6#
+3+^| [.small]#x7#
+3+^| [.small]#x8#
+3+^| [.small]#x9#
+3+^| [.small]#x10#
+3+^| [.small]#x11#
+3+^| [.small]#x12#
+3+^| [.small]#x13#
+3+^| [.small]#x14#
+3+^| [.small]#x15#
+3+^| [.small]#x16#
+3+^| [.small]#x17#
+3+^| [.small]#x18#
+3+^| [.small]#x19#
+3+^| [.small]#x20#
+3+^| [.small]#x21#
+3+^| [.small]#x22#
+3+^| [.small]#x23#
+3+^| [.small]#x24#
+3+^| [.small]#x25#
+3+^| [.small]#x26#
+3+^| [.small]#x27#
+3+^| [.small]#x28#
+3+^| [.small]#x29#
+3+^| [.small]#x30#
+3+^| [.small]#x31#
+3+^| [.small]#pc#
+|===
+[NOTE]
+====
+There is no dedicated stack pointer or subroutine return address link
+register in the Base Integer ISA; the instruction encoding allows any
+`x` register to be used for these purposes. However, the standard
+software calling convention uses register `x1` to hold the return
+address for a call, with register `x5` available as an alternate link
+register. The standard calling convention uses register `x2` as the
+stack pointer.
+
+Hardware might choose to accelerate function calls and returns that use
+`x1` or `x5`. See the descriptions of the JAL and JALR instructions.
+
+The optional compressed 16-bit instruction format is designed around the
+assumption that `x1` is the return address register and `x2` is the
+stack pointer. Software using other conventions will operate correctly
+but may have greater code size.
+
+The number of available architectural registers can have large impacts
+on code size, performance, and energy consumption. Although 16 registers
+would arguably be sufficient for an integer ISA running compiled code,
+it is impossible to encode a complete ISA with 16 registers in 16-bit
+instructions using a 3-address format. Although a 2-address format would
+be possible, it would increase instruction count and lower efficiency.
+We wanted to avoid intermediate instruction sizes (such as Xtensa's
+24-bit instructions) to simplify base hardware implementations, and once
+a 32-bit instruction size was adopted, it was straightforward to support
+32 integer registers. A larger number of integer registers also helps
+performance on high-performance code, where there can be extensive use
+of loop unrolling, software pipelining, and cache tiling.
+
+For these reasons, we chose a conventional size of 32 integer registers
+for RV32I. Dynamic register usage tends to be dominated by a few
+frequently accessed registers, and register file implementations can be
+optimized to reduce access energy for the frequently accessed
+registers cite:[jtseng:sbbci]. The optional compressed 16-bit instruction format mostly
+only accesses 8 registers and hence can provide a dense instruction
+encoding, while additional instruction-set extensions could support a
+much larger register space (either flat or hierarchical) if desired.
+
+For resource-constrained embedded applications, we have defined the
+RV32E subset, which only has 16 registers
+(<<rv32e>>).
+====
+=== Base Instruction Formats
+In the base RV32I ISA, there are four core instruction formats
+(R/I/S/U), as shown in <<base_instr>>. All are a fixed 32 bits in length.
+The base ISA has `IALIGN=32`, meaning that instructions must be aligned on a four-byte boundary in memory.
+[#norm:taken_cti_misaligned_exc]#An instruction-address-misaligned exception is generated on a taken branch
+or unconditional jump if the target address is not `IALIGN-bit` aligned.
+This exception is reported on the branch or jump instruction, not on the target instruction.#
+[#norm:cond_br_no_ia_misaligned_exc_not_taken]#No instruction-address-misaligned exception is generated
+for a conditional branch that is not taken.#
+
+[NOTE]
+====
+The alignment constraint for base ISA instructions is relaxed to a
+two-byte boundary when instruction extensions with 16-bit lengths or
+other odd multiples of 16-bit lengths are added (i.e., IALIGN=16).
+
+Instruction-address-misaligned exceptions are reported on the branch or
+jump that would cause instruction misalignment to help debugging, and to
+simplify hardware design for systems with IALIGN=32, where these are the
+only places where misalignment can occur.
+====
+
+The behavior upon decoding a reserved instruction is UNSPECIFIED.
+
+[NOTE]
+====
+Some platforms may require that opcodes reserved for standard use raise
+an illegal-instruction exception. Other platforms may permit reserved
+opcode space be used for non-conforming extensions.
+====
+
+The RISC-V ISA keeps the source (_rs1_ and _rs2_) and destination (_rd_)
+registers at the same position in all formats to simplify decoding.
+[#norm:imm_always_sex]#Except for the 5-bit immediates used in CSR instructions (<<csrinsts>>),
+immediates are always sign-extended#,
+and are generally packed towards the leftmost available
+bits in the instruction and have been allocated to reduce hardware
+complexity. In particular, the sign bit for all immediates is always in
+bit 31 of the instruction to speed sign-extension circuitry.
+
+include::images/wavedrom/instruction-formats.edn[]
+[[base_instr,Base instruction formats]]
+RISC-V base instruction formats. Each immediate subfield is labeled with the bit position (imm[x]) in the immediate value being produced, rather than the bit position within the instruction's immediate field as is usually done.
+
+[NOTE]
+====
+Decoding register specifiers is usually on the critical paths in
+implementations, and so the instruction format was chosen to keep all
+register specifiers at the same position in all formats at the expense
+of having to move immediate bits across formats (a property shared with
+RISC-IV aka. SPUR cite:[spur-jsscc1989]).
+
+In practice, most immediates are either small or require all XLEN bits.
+We chose an asymmetric immediate split (12 bits in regular instructions
+plus a special load-upper-immediate instruction with 20 bits) to
+increase the opcode space available for regular instructions.
+
+Immediates are sign-extended because we did not observe a benefit to
+using zero extension for some immediates as in the MIPS ISA and wanted
+to keep the ISA as simple as possible.
+====
+
+=== Immediate Encoding Variants
+
+There are a further two variants of the instruction formats (B/J) based
+on the handling of immediates, as shown in <<baseinstformatsimm>>.
+
+include::images/wavedrom/immediate-variants.edn[]
+[[baseinstformatsimm,Base instruction formats immediate variants.]]
+//.RISC-V base instruction formats showing immediate variants.
+
+
+The only difference between the S and B formats is that the 12-bit
+immediate field is used to encode branch offsets in multiples of 2 in
+the B format. Instead of shifting all bits in the instruction-encoded
+immediate left by one in hardware as is conventionally done, the middle
+bits (imm[10:1]) and sign bit stay in fixed positions, while the lowest
+bit in S format (inst[7]) encodes a high-order bit in B format.
+
+Similarly, the only difference between the U and J formats is that the
+20-bit immediate is shifted left by 12 bits to form U immediates and by
+1 bit to form J immediates. The location of instruction bits in the U
+and J format immediates is chosen to maximize overlap with the other
+formats and with each other.
+
+<<immtypes>> shows the immediates produced by
+each of the base instruction formats, and is labeled to show which
+instruction bit (inst[_y_]) produces each bit of the immediate value.
+
+[[immtypes, Immediate types]]
+include::images/wavedrom/i-immediate.edn[]
+
+include::images/wavedrom/s-immediate.edn[]
+
+include::images/wavedrom/b-immediate.edn[]
+
+include::images/wavedrom/u-immediate.edn[]
+
+.Types of immediate produced by RISC-V instructions.
+include::images/wavedrom/j-immediate.edn[]
+
+
+The fields are labeled with the instruction bits used to construct their value. Sign extensions always uses inst[31].
+
+[NOTE]
+====
+Sign extension is one of the most critical operations on immediates
+(particularly for XLEN>32), and in RISC-V the sign bit for
+all immediates is always held in bit 31 of the instruction to allow
+sign extension to proceed in parallel with instruction decoding.
+
+Although more complex implementations might have separate adders for
+branch and jump calculations and so would not benefit from keeping the
+location of immediate bits constant across types of instruction, we
+wanted to reduce the hardware cost of the simplest implementations. By
+rotating bits in the instruction encoding of B and J immediates instead
+of using dynamic hardware multiplexers to multiply the immediate by 2, we
+reduce instruction signal fanout and immediate multiplexer costs by around a
+factor of 2. The scrambled immediate encoding will add negligible time
+to static or ahead-of-time compilation. For dynamic generation of
+instructions, there is some small additional overhead, but the most
+common short forward branches have straightforward immediate encodings.
+====
+
+=== Integer Computational Instructions
+
+Most integer computational instructions operate on `XLEN` bits of values
+held in the integer register file. Integer computational instructions
+are either encoded as register-immediate operations using the I-type
+format or as register-register operations using the R-type format. The
+destination is register _rd_ for both register-immediate and
+register-register instructions. No integer computational instructions
+cause arithmetic exceptions.
+
+[NOTE]
+====
+We did not include special instruction-set support for overflow checks
+on integer arithmetic operations in the base instruction set, as many
+overflow checks can be cheaply implemented using RISC-V branches.
+Overflow checking for unsigned addition requires only a single
+additional branch instruction after the addition:
+`add t0, t1, t2; bltu t0, t1, overflow`.
+
+For signed addition, if one operand's sign is known, overflow checking
+requires only a single branch after the addition:
+`addi t0, t1, +imm; blt t0, t1, overflow`. This covers the common case
+of addition with an immediate operand.
+
+For general signed addition, three additional instructions after the
+addition are required, leveraging the observation that the sum should be
+less than one of the operands if and only if the other operand is
+negative.
+
+[source,asm]
+....
+ add t0, t1, t2
+ slti t3, t2, 0
+ slt t4, t0, t1
+ bne t3, t4, overflow
+....
+
+In RV64I, checks of 32-bit signed additions can be optimized further by
+comparing the results of ADD and ADDW on the operands.
+====
+
+==== Integer Register-Immediate Instructions
+
+include::images/wavedrom/integer-computational.edn[]
+//.Integer Computational Instructions
+
+[#norm:addi_op]#ADDI adds the sign-extended 12-bit immediate to register _rs1_.#
+[#norm:addi_overflow]#Arithmetic overflow is ignored and the result is simply the low XLEN bits of the result.#
+ADDI _rd, rs1, 0_ is used to implement the MV _rd, rs1_ assembler pseudoinstruction.
+
+[#norm:slti_sltiu_op]#SLTI (set less than immediate) places the value 1 in register _rd_ if
+register _rs1_ is less than the sign-extended immediate when both are
+treated as signed numbers, else 0 is written to _rd_. SLTIU is similar
+but compares the values as unsigned numbers (i.e., the immediate is
+first sign-extended to XLEN bits then treated as an unsigned number).#
+Note, SLTIU _rd, rs1, 1_ sets _rd_ to 1 if _rs1_ equals zero, otherwise
+sets _rd_ to 0 (assembler pseudoinstruction SEQZ _rd, rs_).
+
+[#norm:andi_ori_xori_op]#ANDI, ORI, XORI are logical operations that perform bitwise AND, OR, and
+XOR on register _rs1_ and the sign-extended 12-bit immediate and place
+the result in _rd_.#
+Note, XORI _rd, rs1, -1_ performs a bitwise logical inversion of register _rs1_ (assembler pseudoinstruction NOT _rd, rs_).
+
+include::images/wavedrom/int-comp-slli-srli-srai.edn[]
+[[int-comp-slli-srli-srai]]
+//.Integer register-immediate, SLLI, SRLI, SRAI
+
+Shifts by a constant are encoded as a specialization of the I-type
+format. The operand to be shifted is in _rs1_, and the shift amount is
+encoded in the lower 5 bits of the I-immediate field. The right shift
+type is encoded in bit 30.
+[#norm:slli_op]#SLLI is a logical left shift (zeros are shifted into the lower bits);#
+[#norm:srli_op]#SRLI is a logical right shift (zeros are shifted into the upper bits);# and
+[#norm:srai_op]#SRAI is an arithmetic right shift (the original sign bit is copied into the vacated upper bits).#
+
+include::images/wavedrom/int-comp-lui-aiupc.edn[]
+[[int-comp-lui-aiupc]]
+//.Integer register-immediate, U-immediate
+
+LUI (load upper immediate) is used to build 32-bit constants and uses the U-type format.
+[#norm:lui_op]#LUI places the 32-bit U-immediate value into the
+destination register _rd_, filling in the lowest 12 bits with zeros.#
+
+AUIPC (add upper immediate to `pc`) is used to build `pc`-relative
+addresses and uses the U-type format.
+[#norm:auipc_op]#AUIPC forms a 32-bit offset from
+the U-immediate, filling in the lowest 12 bits with zeros, adds this
+offset to the address of the AUIPC instruction, then places the result
+in register _rd_.#
+
+[NOTE]
+====
+The assembly syntax for `lui` and `auipc` does not represent the lower
+12 bits of the U-immediate, which are always zero.
+
+The AUIPC instruction supports two-instruction sequences to access
+arbitrary offsets from the PC for both control-flow transfers and data
+accesses. The combination of an AUIPC and the 12-bit immediate in a JALR
+can transfer control to any 32-bit PC-relative address, while an AUIPC
+plus the 12-bit immediate offset in regular load or store instructions
+can access any 32-bit PC-relative data address.
+
+The current PC can be obtained by setting the U-immediate to 0. Although
+a JAL +4 instruction could also be used to obtain the local PC (of the
+instruction following the JAL), it might cause pipeline breaks in
+simpler microarchitectures or pollute BTB structures in more complex
+microarchitectures.
+====
+
+==== Integer Register-Register Operations
+
+RV32I defines several arithmetic R-type operations. [#norm:R-type_operands]#All operations read
+the _rs1_ and _rs2_ registers as source operands and write the result into register _rd_.#
+The _funct7_ and _funct3_ fields select the type of operation.
+
+include::images/wavedrom/int-reg-reg.edn[]
+[[int-reg-reg]]
+//.Integer register-register
+
+[#norm:add_op]#ADD performs the addition of _rs1_ and _rs2_.#
+[#norm:sub_op]#SUB performs the subtraction of _rs2_ from _rs1_.#
+[#norm:add_sub_overflow]#Overflows are ignored and the low XLEN bits of results are written to the destination _rd_.#
+[#norm:slt_sltu_op]#SLT and SLTU perform signed and unsigned compares respectively, writing 1 to _rd_ if
+_rs1_ < _rs2_, 0 otherwise.#
+Note, SLTU _rd_, _x0_, _rs2_ sets _rd_ to 1 if _rs2_ is not equal to zero,
+otherwise sets _rd_ to zero (assembler pseudoinstruction SNEZ _rd, rs_).
+[#norm:and_or_xor_op]#AND, OR, and XOR perform bitwise logical operations.#
+
+[#norm:sll_srl_sra_op]#SLL, SRL, and SRA perform logical left, logical right, and arithmetic
+right shifts on the value in register _rs1_ by the shift amount held in
+the lower 5 bits of register _rs2_.#
+
+==== NOP Instruction
+
+include::images/wavedrom/nop.edn[]
+[[nop]]
+//.NOP instructions
+
+The NOP instruction does not change any architecturally visible state,
+except for advancing the `pc` and incrementing any applicable
+performance counters. NOP is encoded as ADDI _x0, x0, 0_.
+
+[NOTE]
+====
+NOPs can be used to align code segments to microarchitecturally
+significant address boundaries, or to leave space for inline code
+modifications. Although there are many possible ways to encode a NOP, we
+define a canonical NOP encoding to allow microarchitectural
+optimizations as well as for more readable disassembly output. The other
+NOP encodings are made available for <<rv32i-hints>>.
+
+ADDI was chosen for the NOP encoding as this is most likely to take
+fewest resources to execute across a range of systems (if not optimized
+away in decode). In particular, the instruction only reads one register.
+Also, an ADDI functional unit is more likely to be available in a
+superscalar design as adds are the most common operation. In particular,
+address-generation functional units can execute ADDI using the same
+hardware needed for base+offset address calculations, while
+register-register ADD or logical/shift operations require additional
+hardware.
+====
+
+=== Control Transfer Instructions
+RV32I provides two types of control transfer instructions: unconditional
+jumps and conditional branches.
+[#norm:no_cti_delay_slots]#Control transfer instructions in RV32I
+do _not_ have architecturally visible delay slots.#
+
+[#norm:ia_fault_exc_on_target]#If an instruction access-fault or instruction page-fault exception
+occurs on the target of a jump or taken branch, the exception is
+reported on the target instruction, not on the jump or branch instruction.#
+
+==== Unconditional Jumps
+The jump and link (JAL) instruction uses the J-type format, where the
+J-immediate encodes a signed offset in multiples of 2 bytes.
+[#norm:jal_target]#The offset is sign-extended and added to the address of the jump instruction to
+form the jump target address.# Jumps can therefore target a &#177;1 MiB range.
+[#norm:jal_op]#JAL stores the address of the instruction
+following the jump ('pc'+4) into register _rd_.#
+The standard software calling convention uses 'x1' as the return address register and 'x5' as
+an alternate link register.
+
+[NOTE]
+====
+The alternate link register supports calling millicode routines (e.g.,
+those to save and restore registers in compressed code) while preserving
+the regular return address register. The register `x5` was chosen as the
+alternate link register as it maps to a temporary in the standard
+calling convention, and has an encoding that is only one bit different
+than the regular link register.
+====
+
+Plain unconditional jumps (assembler pseudoinstruction J) are encoded as
+a JAL with _rd_=`x0`.
+
+include::images/wavedrom/ct-unconditional.edn[]
+[[ct-unconditional]]
+//.The unconditional-jump instruction, JAL
+
+The indirect jump instruction JALR (jump and link register) uses the I-type encoding.
+[#norm:jalr_target]#The target address is obtained by adding the
+sign-extended 12-bit I-immediate to the register _rs1_, then setting the
+least-significant bit of the result to zero.#
+[#norm:jalr_op]#The address of the
+instruction following the jump (`pc`+4) is written to register _rd_.#
+Register `x0` can be used as the destination if the result is not
+required.
+
+Plain unconditional indirect jumps (assembler pseudoinstruction JR) are
+encoded as a JALR with _rd_=`x0`.
+Procedure returns in the standard calling convention (assembler
+pseudoinstruction RET) are encoded as a JALR with _rd_=`x0`, _rs1_=`x1`, and
+_imm_=0.
+
+include::images/wavedrom/ct-unconditional-2.edn[]
+[[ct-unconditional-2]]
+//.The indirect unconditional-jump instruction, JALR
+
+[NOTE]
+====
+The unconditional jump instructions all use PC-relative addressing to
+help support position-independent code. The JALR instruction was defined
+to enable a two-instruction sequence to jump anywhere in a 32-bit
+absolute address range. A LUI instruction can first load _rs1_ with the
+upper 20 bits of a target address, then JALR can add in the lower bits.
+Similarly, AUIPC then JALR can jump anywhere in a 32-bit `pc`-relative
+address range.
+
+Note that the JALR instruction does not treat the 12-bit immediate as
+multiples of 2 bytes, unlike the conditional branch instructions. This
+avoids one more immediate format in hardware. In practice, most uses of
+JALR will have either a zero immediate or be paired with a LUI or AUIPC,
+so the slight reduction in range is not significant.
+
+Clearing the least-significant bit when calculating the JALR target
+address both simplifies the hardware slightly and allows the low bit of
+function pointers to be used to store auxiliary information. Although
+there is potentially a slight loss of error checking in this case, in
+practice jumps to an incorrect instruction address will usually quickly
+raise an exception.
+
+When used with a base _rs1_=`x0`, JALR can be used to
+implement a single instruction subroutine call to the lowest or highest
+address region from anywhere in the address space, which could be used
+to implement fast calls to a small runtime library. Alternatively, an
+ABI could dedicate a general-purpose register to point to a library
+elsewhere in the address space.
+====
+
+The JAL and JALR instructions will generate an
+instruction-address-misaligned exception if the target address is not
+aligned to a four-byte boundary.
+
+[NOTE]
+====
+Instruction-address-misaligned exceptions are not possible on machines
+that support extensions with 16-bit aligned instructions, such as the
+compressed instruction-set extension, C.
+====
+
+Return-address prediction stacks are a common feature of
+high-performance instruction-fetch units, but require accurate detection
+of instructions used for procedure calls and returns to be effective.
+For RISC-V, hints as to the instructions' usage are encoded implicitly
+via the register numbers used. A JAL instruction should push the return
+address onto a return-address stack (RAS) only when _rd_ is 'x1' or
+`x5`. JALR instructions should push/pop a RAS as shown in <<rashints>>.
+
+[[rashints]]
+.Return-address stack prediction hints encoded in the register operands of a JALR instruction.
+[%autowidth,float="center",align="center",cols="^,^,^,<",options="header"]
+|===
+|_rd_ is _x1/x5_ |_rs1_ is _x1/x5_ |_rd_=_rs1_ |RAS action
+
+|No |No |-- |None
+
+|No |Yes |-- |Pop
+
+|Yes |No |-- |Push
+
+|Yes |Yes |No |Pop, then push
+
+|Yes |Yes |Yes |Push
+|===
+
+
+[NOTE]
+====
+Some other ISAs added explicit hint bits to their indirect-jump
+instructions to guide return-address stack manipulation. We use implicit
+hinting tied to register numbers and the calling convention to reduce
+the encoding space used for these hints.
+
+When two different link registers (`x1` and `x5`) are given as _rs1_ and
+_rd_, then the RAS is both popped and pushed to support coroutines. If
+_rs1_ and _rd_ are the same link register (either `x1` or `x5`), the RAS
+is only pushed to enable macro-op fusion of the sequences:
+`lui ra, imm20; jalr ra, imm12(ra)_ and _auipc ra, imm20; jalr ra, imm12(ra)`
+====
+
+==== Conditional Branches
+
+All branch instructions use the B-type instruction format.
+[#norm:br_target]#The 12-bit B-immediate encodes signed offsets in multiples of 2 bytes. The offset
+is sign-extended and added to the address of the branch instruction to give the target address.#
+The conditional branch range is &#177;4 KiB.
+
+include::images/wavedrom/ct-conditional.edn[]
+[[ct-conditional]]
+//.Conditional branches
+
+Branch instructions compare two registers.
+[#norm:beq_bne_op]#BEQ and BNE take the branch if registers _rs1_ and _rs2_ are equal or unequal respectively.#
+[#norm:blt_bltu_op]#BLT and BLTU take the branch if _rs1_ is less than _rs2_, using signed and
+unsigned comparison respectively.#
+[#norm:bge_bgeu_op]#BGE and BGEU take the branch if _rs1_ is greater than or equal to _rs2_,
+using signed and unsigned comparison respectively.#
+Note, BGT, BGTU, BLE, and BLEU can be synthesized by
+reversing the operands to BLT, BLTU, BGE, and BGEU, respectively.
+
+[NOTE]
+====
+Signed array bounds may be checked with a single BLTU instruction, since
+any negative index will compare greater than any nonnegative bound.
+====
+
+Software should be optimized such that the sequential code path is the
+most common path, with less-frequently taken code paths placed out of
+line. Software should also assume that backward branches will be
+predicted taken and forward branches as not taken, at least the first
+time they are encountered. Dynamic predictors should quickly learn any
+predictable branch behavior.
+
+Unlike some other architectures, the RISC-V jump (JAL with _rd_=`x0`)
+instruction should always be used for unconditional branches instead of
+a conditional branch instruction with an always-true condition. RISC-V
+jumps are also PC-relative and support a much wider offset range than
+branches, and will not pollute conditional-branch prediction tables.
+
+[NOTE]
+====
+The conditional branches were designed to include arithmetic comparison
+operations between two registers (as also done in PA-RISC, Xtensa, and
+MIPS R6), rather than use condition codes (x86, ARM, SPARC, PowerPC), or
+to only compare one register against zero (Alpha, MIPS), or two
+registers only for equality (MIPS). This design was motivated by the
+observation that a combined compare-and-branch instruction fits into a
+regular pipeline, avoids additional condition code state or use of a
+temporary register, and reduces static code size and dynamic instruction
+fetch traffic. Another point is that comparisons against zero require
+non-trivial circuit delay (especially after the move to static logic in
+advanced processes) and so are almost as expensive as arithmetic
+magnitude compares. Another advantage of a fused compare-and-branch
+instruction is that branches are observed earlier in the front-end
+instruction stream, and so can be predicted earlier. There is perhaps an
+advantage to a design with condition codes in the case where multiple
+branches can be taken based on the same condition codes, but we believe
+this case to be relatively rare.
+
+We considered but did not include static branch hints in the instruction
+encoding. These can reduce the pressure on dynamic predictors, but
+require more instruction encoding space and software profiling for best
+results, and can result in poor performance if production runs do not
+match profiling runs.
+
+We considered but did not include conditional moves or predicated
+instructions, which can effectively replace unpredictable short forward
+branches. Conditional moves are the simpler of the two, but are
+difficult to use with conditional code that might cause exceptions
+(memory accesses and floating-point operations). Predication adds
+additional flag state to a system, additional instructions to set and
+clear flags, and additional encoding overhead on every instruction. Both
+conditional move and predicated instructions add complexity to
+out-of-order microarchitectures, adding an implicit third source operand
+due to the need to copy the original value of the destination
+architectural register into the renamed destination physical register if
+the predicate is false. Also, static compile-time decisions to use
+predication instead of branches can result in lower performance on
+inputs not included in the compiler training set, especially given that
+unpredictable branches are rare, and becoming rarer as branch prediction
+techniques improve.
+
+We note that various microarchitectural techniques exist to dynamically
+convert unpredictable short forward branches into internally predicated
+code to avoid the cost of flushing pipelines on a branch mispredict cite:[heil-tr1996], cite:[Klauser-1998], cite:[Kim-micro2005] and
+have been implemented in commercial processors cite:[ibmpower7]. The simplest techniques
+just reduce the penalty of recovering from a mispredicted short forward
+branch by only flushing instructions in the branch shadow instead of the
+entire fetch pipeline, or by fetching instructions from both sides using
+wide instruction fetch or idle instruction fetch slots. More complex
+techniques for out-of-order cores add internal predicates on
+instructions in the branch shadow, with the internal predicate value
+written by the branch instruction, allowing the branch and following
+instructions to be executed speculatively and out-of-order with respect
+to other code.
+====
+
+The conditional branch instructions will generate an
+instruction-address-misaligned exception if the target address is not
+aligned to a four-byte boundary and the branch condition evaluates to
+true. If the branch condition evaluates to false, the
+instruction-address-misaligned exception will not be raised.
+
+[NOTE]
+====
+Instruction-address-misaligned exceptions are not possible on machines
+that support extensions with 16-bit aligned instructions, such as the
+compressed instruction-set extension, C.
+====
+
+[[ldst]]
+=== Load and Store Instructions
+RV32I is a load-store architecture, where only load and store
+instructions access memory and arithmetic instructions only operate on
+CPU registers. RV32I provides a 32-bit address space that is
+byte-addressed. The EEI will define what portions of the address space
+are legal to access with which instructions (e.g., some addresses might
+be read only, or support word access only).
+[#norm:load_exc_x0]#Loads with a destination of
+`x0` must still raise any exceptions and cause any other side effects
+even though the load value is discarded.#
+
+[#norm:ENDIANNESS_LITTLE_OR_BIG]#The EEI will define whether the memory system is little-endian or big-endian.#
+[#norm:ldst_endian_byte_invariant]#In RISC-V, endianness is byte-address invariant.#
+
+[NOTE]
+====
+[[norm:ldst_endian_byte_op]]
+In a system for which endianness is byte-address invariant, the
+following property holds: if a byte is stored to memory at some address
+in some endianness, then a byte-sized load from that address in any
+endianness returns the stored value.
+
+[[norm:ldst_little_endian_op]]
+In a little-endian configuration, multibyte stores write the
+least-significant register byte at the lowest memory byte address,
+followed by the other register bytes in ascending order of their
+significance. Loads similarly transfer the contents of the lesser memory
+byte addresses to the less-significant register bytes.
+
+[[norm:ldst_big_endian_op]]
+In a big-endian configuration, multibyte stores write the
+most-significant register byte at the lowest memory byte address,
+followed by the other register bytes in descending order of their
+significance. Loads similarly transfer the contents of the greater
+memory byte addresses to the less-significant register bytes.
+====
+
+include::images/wavedrom/load-store.edn[]
+[[load-store,load and store]]
+//.Load and store instructions
+
+Load and store instructions transfer a value between the registers and
+memory. Loads are encoded in the I-type format and stores are S-type.
+[#norm:ldst_ea]#The effective address is obtained by adding register _rs1_ to the
+sign-extended 12-bit offset.#
+[#norm:load_op]#Loads copy a value from memory to register _rd_.#
+[#norm:store_op]#Stores copy the value in register _rs2_ to memory.#
+
+[#norm:lw_op]#The LW instruction loads a 32-bit value from memory into _rd_.#
+[#norm:lh_op]#LH loads a 16-bit value from memory, then sign-extends to 32-bits before storing
+in _rd_.#
+[#norm:lhu_op]#LHU loads a 16-bit value from memory but then zero extends to
+32-bits before storing in _rd_.#
+[#norm:lb_lbu_op]#LB and LBU are defined analogously for 8-bit values.#
+[#norm:sw_sh_sb_op]#The SW, SH, and SB instructions store 32-bit, 16-bit, and
+8-bit values from the low bits of register _rs2_ to memory.#
+
+Regardless of EEI, [#norm:ldst_no_exc_aligned]#loads and stores whose effective addresses are
+naturally aligned shall not raise an address-misaligned exception.#
+[#norm:MISALIGNED_LDST_EEI_DEPENDENT_BEHAVIOR]#Loads and stores whose effective address is not naturally aligned to the
+referenced datatype (i.e., the effective address is not divisible by the
+size of the access in bytes) have behavior dependent on the EEI.#
+
+An EEI may guarantee that misaligned loads and stores are fully
+supported, and so the software running inside the execution environment
+will never experience a contained or fatal address-misaligned trap. In this case, the
+[#norm:MISALIGNED_LDST_FULLY_HW_SUPPORTED]#misaligned loads and stores can be handled in hardware#, or
+[#norm:MISALIGNED_LDST_INVISIBLE_TRAP]#via an invisible trap into the execution environment implementation#, or possibly a
+[#norm:MISALIGNED_LDST_HW_OR_INVISIBLE_TRAP_FUNC_OF_ADDR]#combination of hardware and invisible trap depending on address.#
+
+An EEI may not guarantee misaligned loads and stores are handled invisibly. In this case,
+[#norm:MISALIGNED_LDST_FULLY_HW_SUPPORTED_OR_VISIBLE_TRAP]#loads and stores that are not naturally aligned
+may either complete execution successfully or raise an exception.#
+[#norm:ldst_addr_misaligned_or_access_fault_exc]#The exception raised can be either an
+address-misaligned exception or an access-fault exception.
+For a memory access that would otherwise be able
+to complete except for the misalignment, an access-fault exception can
+be raised instead of an address-misaligned exception if the misaligned
+access should not be emulated, e.g., if accesses to the memory region
+have side effects.#
+[#norm:MISALIGNED_LDST_CONTAINED_OR_FATAL_TRAP]#When an EEI does not guarantee misaligned loads and
+stores are handled invisibly, the EEI must define if exceptions caused
+by address misalignment result in a contained trap (allowing software
+running inside the execution environment to handle the trap) or a fatal
+trap (terminating execution).#
+
+[NOTE]
+====
+Misaligned accesses are occasionally required when porting legacy code,
+and help performance on applications when using any form of packed-SIMD
+extension or handling externally packed data structures. Our rationale
+for allowing EEIs to choose to support misaligned accesses via the
+regular load and store instructions is to simplify the addition of
+misaligned hardware support. One option would have been to disallow
+misaligned accesses in the base ISAs and then provide some separate ISA
+support for misaligned accesses, either special instructions to help
+software handle misaligned accesses or a new hardware addressing mode
+for misaligned accesses. Special instructions are difficult to use,
+complicate the ISA, and often add new processor state (e.g., SPARC VIS
+align address offset register) or complicate access to existing
+processor state (e.g., MIPS LWL/LWR partial register writes). In
+addition, for loop-oriented packed-SIMD code, the extra overhead when
+operands are misaligned motivates software to provide multiple forms of
+loop depending on operand alignment, which complicates code generation
+and adds to loop startup overhead. New misaligned hardware addressing
+modes take considerable space in the instruction encoding or require
+very simplified addressing modes (e.g., register indirect only).
+====
+
+Even when misaligned loads and stores complete successfully, these
+accesses might run extremely slowly depending on the implementation
+(e.g., when implemented via an invisible trap). Furthermore, whereas
+[#norm:ldst_atomicity_for_aligned]#naturally aligned
+loads and stores are guaranteed to execute atomically#,
+misaligned loads and stores might not, and hence require additional
+synchronization to ensure atomicity.
+
+[NOTE]
+====
+We do not mandate atomicity for misaligned accesses so execution
+environment implementations can use an invisible machine trap and a
+software handler to handle some or all misaligned accesses. If hardware
+misaligned support is provided, software can exploit this by simply
+using regular load and store instructions. Hardware can then
+automatically optimize accesses depending on whether runtime addresses
+are aligned.
+====
+
+[[fence]]
+=== Memory Ordering Instructions
+
+include::images/wavedrom/mem-order.edn[]
+[[mem-order]]
+//.Memory ordering instructions
+
+FENCE instructions are used to order device I/O and memory accesses as
+viewed by other RISC-V harts and external devices or coprocessors. Any
+combination of device input (I), device output (O), memory reads \(R),
+and memory writes (W) may be ordered with respect to any combination of
+the same. Informally, no other RISC-V hart or external device can
+observe any operation in the _successor_ set following a FENCE before
+any operation in the _predecessor_ set preceding the FENCE.
+<<memorymodel>> provides a precise description
+of the RISC-V memory consistency model.
+
+FENCE instructions also order memory reads and writes made by the
+hart as observed by memory reads and writes made by an external device.
+However, FENCE instructions do not order observations of events made by an external
+device using any other signaling mechanism.
+
+[NOTE]
+====
+A device might observe an access to a memory location via some external
+communication mechanism, e.g., a memory-mapped control register that
+drives an interrupt signal to an interrupt controller. This
+communication is outside the scope of the FENCE ordering mechanism and
+hence FENCE instructions can provide no guarantee on when a change in
+the interrupt signal is visible to the interrupt controller. Specific
+devices might provide additional ordering guarantees to reduce software
+overhead but those are outside the scope of the RISC-V memory model.
+====
+
+The EEI will define what I/O operations are possible, and in particular,
+which memory addresses when accessed by load and store instructions will
+be treated and ordered as device input and device output operations
+respectively rather than memory reads and writes. For example,
+memory-mapped I/O devices will typically be accessed with uncached loads
+and stores that are ordered using the I and O bits rather than the R and
+W bits. Instruction-set extensions might also describe new I/O
+instructions that will also be ordered using the I and O bits in a
+FENCE instruction.
+
+[[fm]]
+[float="center",align="center",cols="^1,^1,<3",options="header"]
+.Fence mode encoding
+|===
+|_fm_ field |Mnemonic suffix|Meaning
+|0000 |_none_ |Normal Fence
+|1000 |.TSO |With `FENCE RW,RW`: exclude write-to-read ordering; otherwise: _Reserved for future use._
+|_other_|_other_ |_Reserved for future use._
+|===
+
+The FENCE mode field _fm_ defines the semantics of the FENCE instruction.
+[#norm:fence_op]#A `FENCE`
+(with _fm_=`0000`) orders all memory operations in its predecessor set
+before all memory operations in its successor set.#
+
+A `FENCE.TSO` instruction is encoded as a FENCE instruction
+with _fm_=`1000`, _predecessor_=`RW`, and _successor_=`RW`.
+[#norm:fence-tso_op]#`FENCE.TSO` orders
+all load operations in its predecessor set before all memory operations
+in its successor set, and all store operations in its predecessor set
+before all store operations in its successor set. This leaves `non-AMO`
+store operations in the `FENCE.TSO's` predecessor set unordered with
+`non-AMO` loads in its successor set.#
+
+[NOTE]
+====
+[[norm:fence-tso_ordering_rw_rw_ok]]
+Because `FENCE RW,RW` imposes a superset of the orderings that `FENCE.TSO`
+imposes, it is correct to ignore the _fm_ field and implement `FENCE.TSO` as `FENCE RW,RW`.
+====
+
+[#norm:fence_unused_flds_rsv]#The unused fields in the FENCE
+instructions--_rs1_ and _rd_--are reserved
+for finer-grain fences in future extensions. For forward compatibility,
+base implementations shall ignore these fields#, and standard software
+shall zero these fields. Likewise, many _fm_ and predecessor/successor
+set settings are also reserved for future use.
+Base implementations shall treat all such reserved configurations as
+`FENCE` instructions (with _fm_=`0000`), and standard software shall use only
+non-reserved configurations.
+
+[NOTE]
+====
+[[norm:fence_cons_ok]]
+We chose a relaxed memory model to allow high performance from simple
+machine implementations and from likely future coprocessor or
+accelerator extensions. We separate out I/O ordering from memory R/W
+ordering to avoid unnecessary serialization within a device-driver hart
+and also to support alternative non-memory paths to control added
+coprocessors or I/O devices. Simple implementations may additionally
+ignore the _predecessor_ and _successor_ fields and always execute a
+conservative FENCE on all operations.
+====
+
+[[ecall-ebreak]]
+=== Environment Call and Breakpoints
+`SYSTEM` instructions are used to access system functionality that might
+require privileged access and are encoded using the I-type instruction
+format. These can be divided into two main classes: those that
+atomically read-modify-write control and status registers (CSRs), and
+all other potentially privileged instructions. CSR instructions are
+described in <<csrinsts>>, and the base
+unprivileged instructions are described in the following section.
+
+
+[NOTE]
+====
+The SYSTEM instructions are defined to allow simpler implementations to
+always trap to a single software trap handler. More sophisticated
+implementations might execute more of each system instruction in
+hardware.
+====
+
+include::images/wavedrom/env-call-breakpoint.edn[]
+[[env-call]]
+//.Environment call and breakpoint instructions
+
+These two instructions cause a precise requested trap to the supporting
+execution environment.
+
+[#norm:ecall_op]#The `ECALL` instruction is used to make a service request to the execution environment.#
+The `EEI` will define how parameters for the service request
+are passed, but usually these will be in defined locations in the
+integer register file.
+
+[#norm:ebreak_op]#The `EBREAK` instruction is used to return control to a debugging environment.#
+
+[NOTE]
+====
+ECALL and EBREAK were previously named SCALL and SBREAK. The
+instructions have the same functionality and encoding, but were renamed
+to reflect that they can be used more generally than to call a
+supervisor-level operating system or debugger.
+====
+
+[NOTE]
+====
+EBREAK was primarily designed to be used by a debugger to cause
+execution to stop and fall back into the debugger. EBREAK is also used
+by the standard GCC compiler to mark code paths that should not be
+executed.
+
+Another use of EBREAK is to support "semihosting", where the execution
+environment includes a debugger that can provide services over an
+alternate system call interface built around the EBREAK instruction.
+Because the RISC-V base ISAs do not provide more than one EBREAK
+instruction, RISC-V semihosting uses a special sequence of instructions
+to distinguish a semihosting EBREAK from a debugger inserted EBREAK.
+
+[source,asm]
+....
+ slli x0, x0, 0x1f # Entry NOP
+ ebreak # Break to debugger
+ srai x0, x0, 7 # Exit NOP
+....
+
+Note that these three instructions must be 32-bit-wide instructions,
+i.e., they mustn't be among the compressed 16-bit instructions described
+in <<compressed>>.
+
+The shift NOP instructions are still considered available for use as
+HINTs.
+
+Semihosting is a form of service call and would be more naturally
+encoded as an ECALL using an existing ABI, but this would require the
+debugger to be able to intercept ECALLs, which is a newer addition to
+the debug standard. We intend to move over to using ECALLs with a
+standard ABI, in which case, semihosting can share a service ABI with an
+existing standard.
+
+We note that ARM processors have also moved to using SVC instead of BKPT
+for semihosting calls in newer designs.
+====
+
+=== HINT Instructions
+//[#rv32i-hints,HINT Instructions]
+
+[[rv32i-hints,HINT Instructions]]
+
+RV32I reserves a large encoding space for HINT instructions, which are
+usually used to communicate performance hints to the microarchitecture.
+Like the NOP instruction, HINTs do not change any architecturally
+visible state, except for advancing the `pc` and any applicable
+performance counters. Implementations are always allowed to ignore the
+encoded hints.
+
+Most RV32I HINTs are encoded as integer computational instructions with
+_rd_=`x0`. The other RV32I HINTs are encoded as FENCE instructions with
+a null predecessor or successor set and with _fm_=0.
+
+[NOTE]
+====
+These HINT encodings have been chosen so that simple implementations can
+ignore HINTs altogether, and instead execute a HINT as a regular
+instruction that happens not to mutate the architectural state. For
+example, ADD is a HINT if the destination register is `x0`; the five-bit
+_rs1_ and _rs2_ fields encode arguments to the HINT. However, a simple
+implementation can simply execute the HINT as an ADD of _rs1_ and _rs2_
+that writes `x0`, which has no architecturally visible effect.
+
+[[norm:fence_null_pred_succ_inter]]
+As another example, a FENCE instruction with a zero _pred_ field and a
+zero _fm_ field is a HINT; the _succ_, _rs1_, and _rd_ fields encode the
+arguments to the HINT. A simple implementation can simply execute the
+HINT as a FENCE that orders the null set of prior memory accesses before
+whichever subsequent memory accesses are encoded in the _succ_ field.
+Since the intersection of the predecessor and successor sets is null,
+the instruction imposes no memory orderings, and so it has no
+architecturally visible effect.
+====
+
+<<t-rv32i-hints>> lists all RV32I HINT code points. 91% of the
+HINT space is reserved for standard HINTs. The remainder of the HINT
+space is designated for custom HINTs: no standard HINTs will ever be
+defined in this subspace.
+
+[NOTE]
+====
+We anticipate standard hints to eventually include memory-system spatial
+and temporal locality hints, branch prediction hints, thread-scheduling
+hints, security tags, and instrumentation flags for simulation/emulation.
+====
+
+// this table might still have some problems--some rows might not have landed properly. It needs to be checked cell-by cell.
+
+[[t-rv32i-hints]]
+.RV32I HINT instructions.
+[float="center",align="center",cols="<,<,^,<",options="header"]
+|===
+|Instruction |Constraints |Code Points |Purpose
+
+|LUI |_rd_=`x0` |2^20^ .8+<.^m|_Designated for future standard use_
+
+|AUIPC |_rd_=`x0` |2^20^
+
+|ADDI |_rd_=`x0`, and either _rs1_{ne}``x0`` or _imm_{ne}0 |2^17^−1
+
+|ANDI |_rd_=`x0` |2^17^
+
+|ORI |_rd_=`x0` |2^17^
+
+|XORI |_rd_=`x0` |2^17^
+
+|ADD |_rd_=`x0`, _rs1_{ne}``x0`` |2^10^−32
+
+|ADD |_rd_=`x0`, _rs1_=`x0`, _rs2_{ne}``x2-x5`` | 28
+
+|ADD |_rd_=`x0`, _rs1_=`x0`, _rs2_=`x2-x5` |4|(_rs2_=`x2`) NTL.P1 +
+(_rs2_=`x3`) NTL.PALL +
+(_rs2_=`x4`) NTL.S1 +
+(_rs2_=`x5`) NTL.ALL
+
+|SLLI |_rd_=`x0`, _rs1_=`x0`, _shamt_=31 |1|Semihosting entry marker
+
+|SRAI |_rd_=`x0`, _rs1_=`x0`, _shamt_=7 |1|Semihosting exit marker
+
+|SUB |_rd_=`x0` |2^10^ .11+<.^m|_Designated for future standard use_
+
+|AND |_rd_=`x0` |2^10^
+
+|OR |_rd_=`x0` |2^10^
+
+|XOR |_rd_=`x0` |2^10^
+
+|SLL |_rd_=`x0` |2^10^
+
+|SRL |_rd_=`x0` |2^10^
+
+|SRA |_rd_=`x0` |2^10^
+
+|FENCE|_rd_=`x0`, _rs1_{ne}``x0``, _fm_=0, and either _pred_=0 or _succ_=0| 2^10^−63
+
+|FENCE|_rd_{ne}``x0``, _rs1_=`x0`, _fm_=0, and either _pred_=0 or _succ_=0| 2^10^−63
+
+|FENCE |_rd_=_rs1_=`x0`, _fm_=0, _pred_=0, _succ_{ne}0 |15
+
+|FENCE |_rd_=_rs1_=`x0`, _fm_=0, _pred_{ne}W, _succ_=0 |15
+
+|FENCE |_rd_=_rs1_=`x0`, _fm_=0, _pred_=W, _succ_=0 |1 |PAUSE
+
+4+|
+
+|SLTI |_rd_=`x0` |2^17^ .7+<.^m|_Designated for custom use_
+
+|SLTIU|_rd_=`x0` |2^17^
+
+|SLLI |_rd_=`x0`, and either _rs1_{ne}``x0`` or _shamt_{ne}31 |2^10^−1
+
+|SRLI |_rd_=`x0` |2^10^
+
+|SRAI |_rd_=`x0`, and either _rs1_{ne}``x0`` or _shamt_{ne}7 |2^10^−1
+
+|SLT |_rd_=`x0` |2^10^
+
+|SLTU |_rd_=`x0` |2^10^
+|===
+
+NOTE: `slli x0, x0, 0x1f` and `srai x0, x0, 7` were previously designated as
+custom HINTs, but they have been appropriated for use in semihosting calls, as
+described in <<ecall-ebreak>>.
+To reflect their usage in practice, the base ISA spec has been changed to
+designate them as standard HINTs.
diff --git a/src/rv32.tex b/src/rv32.tex
deleted file mode 100644
index ced9826..0000000
--- a/src/rv32.tex
+++ /dev/null
@@ -1,1370 +0,0 @@
-\chapter{RV32I Base Integer Instruction Set, Version 2.1}
-\label{rv32}
-
-This chapter describes version 2.0 of the RV32I base integer
-instruction set.
-
-\begin{commentary}
-RV32I was designed to be sufficient to form a compiler target and to
-support modern operating system environments. The ISA was also
-designed to reduce the hardware required in a minimal implementation.
-RV32I contains 40 unique instructions, though a simple implementation
-might cover the ECALL/EBREAK instructions with a single SYSTEM
-hardware instruction that always traps and might be able to implement
-the FENCE instruction as a NOP, reducing base instruction count to 38
-total. RV32I can emulate almost any other ISA extension (except the A
-extension, which requires additional hardware support for atomicity).
-
-In practice, a hardware implementation including the machine-mode
-privileged architecture will also require the 6 CSR instructions.
-
-Subsets of the base integer ISA might be useful for pedagogical
-purposes, but the base has been defined such that there should be
-little incentive to subset a real hardware implementation beyond
-omitting support for misaligned memory accesses and treating all
-SYSTEM and FENCE instructions as a single trap.
-\end{commentary}
-
-\begin{commentary}
-Most of the commentary for RV32I also applies to the RV64I base.
-\end{commentary}
-
-\section{Programmers' Model for Base Integer ISA}
-
-Figure~\ref{gprs} shows the unprivileged state for the base integer
-ISA. There are 31 general-purpose registers {\tt x1}--{\tt x31},
-which hold integer values. Register {\tt x0} is hardwired to the
-constant 0. There is no hardwired subroutine return address link
-register, but the standard software calling convention uses register
-{\tt x1} to hold the return address on a call. For RV32I, the {\tt x}
-registers are 32 bits wide, i.e., XLEN=32.
-
-There is one additional unprivileged register: the program counter {\tt pc}
-holds the address of the current instruction.
-
-\begin{commentary}
-The number of available architectural registers can have large impacts
-on code size, performance, and energy consumption. Although 16
-registers would arguably be sufficient for an integer ISA running
-compiled code, it is impossible to encode a complete ISA with 16
-registers in 16-bit instructions using a 3-address format. Although a
-2-address format would be possible, it would increase instruction
-count and lower efficiency. We wanted to avoid intermediate
-instruction sizes (such as Xtensa's 24-bit instructions) to simplify
-base hardware implementations, and once a 32-bit instruction size was
-adopted, it was straightforward to support 32 integer registers. A
-larger number of integer registers also helps performance on
-high-performance code, where there can be extensive use of loop
-unrolling, software pipelining, and cache tiling.
-
-For these reasons, we chose a conventional size of 32 integer
-registers for the base ISA. Dynamic register usage tends to be
-dominated by a few frequently accessed registers, and regfile
-implementations can be optimized to reduce access energy for the
-frequently accessed registers~\cite{jtseng:sbbci}. The optional
-compressed 16-bit instruction format mostly only accesses 8 registers
-and hence can provide a dense instruction encoding, while additional
-instruction-set extensions could support a much larger register space
-(either flat or hierarchical) if desired.
-
-For resource-constrained embedded applications, we have defined the
-RV32E subset, which only has 16 registers (Chapter~\ref{rv32e}).
-\end{commentary}
-
-\begin{figure}[H]
-{\footnotesize
-\begin{center}
-\begin{tabular}{p{2in}}
-\instbitrange{XLEN-1}{0} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ \ \ x0 / zero}} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ x1\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ x2\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ x3\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ x4\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ x5\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ x6\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ x7\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ x8\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ \ x9\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x10\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x11\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x12\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x13\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x14\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x15\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x16\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x17\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x18\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x19\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x20\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x21\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x22\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x23\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x24\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x25\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x26\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x27\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x28\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x29\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x30\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{\ \ \ x31\ \ \ \ \ }} \\ \cline{1-1}
-\multicolumn{1}{c}{XLEN} \\
-
-\instbitrange{XLEN-1}{0} \\ \cline{1-1}
-\multicolumn{1}{|c|}{\reglabel{pc}} \\ \cline{1-1}
-\multicolumn{1}{c}{XLEN} \\
-\end{tabular}
-\end{center}
-}
-\caption{RISC-V base unprivileged integer register state.}
-\label{gprs}
-\end{figure}
-
-\newpage
-
-\section{Base Instruction Formats}
-
-In the base RV32I ISA, there are four core instruction formats
-(R/I/S/U), as shown in Figure~\ref{fig:baseinstformats}. All are a
-fixed 32 bits in length and must be aligned on a four-byte boundary in
-memory. An instruction-address-misaligned exception is generated on a
-taken branch or unconditional jump if the target address is not
-four-byte aligned. This exception is reported on the branch or jump
-instruction, not on the target instruction. No
-instruction-address-misaligned exception is generated for a
-conditional branch that is not taken.
-
-\begin{commentary}
-The alignment constraint for base ISA instructions is relaxed to a
-two-byte boundary when instruction extensions with 16-bit lengths or
-other odd multiples of 16-bit lengths are added (i.e., IALIGN=16).
-
-Instruction-address-misaligned exceptions are reported on the branch
-or jump that would cause instruction misalignment to help debugging,
-and to simplify hardware design for systems with IALIGN=32, where these
-are the only places where misalignment can occur.
-\end{commentary}
-
-\vspace{-0.2in}
-\begin{figure}[h]
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{p{1.2in}@{}p{0.8in}@{}p{0.8in}@{}p{0.6in}@{}p{0.8in}@{}p{1in}l}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\cline{1-6}
-\multicolumn{1}{|c|}{funct7} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} &
-R-type \\
-\cline{1-6}
-\\
-\cline{1-6}
-\multicolumn{2}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} &
-I-type \\
-\cline{1-6}
-\\
-\cline{1-6}
-\multicolumn{1}{|c|}{imm[11:5]} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} &
-S-type \\
-\cline{1-6}
-\\
-\cline{1-6}
-\multicolumn{4}{|c|}{imm[31:12]} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} &
-U-type \\
-\cline{1-6}
-\end{tabular}
-\end{center}
-\caption{RISC-V base instruction formats. Each immediate subfield is
- labeled with the bit position (imm[{\em x}\,]) in the immediate
- value being produced, rather than the bit position within the
- instruction's immediate field as is usually done. }
-\label{fig:baseinstformats}
-\end{figure}
-
-The RISC-V ISA keeps the source ({\em rs1} and {\em rs2}) and
-destination ({\em rd}) registers at the same position in all formats
-to simplify decoding. Except for the 5-bit immediates used in CSR
-instructions (Chapter~\ref{csrinsts}), immediates are always
-sign-extended, and are generally packed towards the leftmost available
-bits in the instruction and have been allocated to reduce hardware
-complexity. In particular, the sign bit for all immediates is always
-in bit 31 of the instruction to speed sign-extension circuitry.
-
-\begin{commentary}
-Decoding register specifiers is usually on the critical paths in
-implementations, and so the instruction format was chosen to keep all
-register specifiers at the same position in all formats at the expense
-of having to move immediate bits across formats (a property shared
-with RISC-IV aka. SPUR~\cite{spur-jsscc1989}).
-
-In practice, most immediates are either small or require all XLEN
-bits. We chose an asymmetric immediate split (12 bits in regular
-instructions plus a special load-upper-immediate instruction with 20
-bits) to increase the opcode space available for regular instructions.
-
-Immediates are sign-extended because we did not observe a benefit to
-using zero-extension for some immediates as in the MIPS ISA and wanted
-to keep the ISA as simple as possible.
-\end{commentary}
-
-\section{Immediate Encoding Variants}
-
-There are a further two variants of the instruction formats (B/J)
-based on the handling of immediates, as shown in
-Figure~\ref{fig:baseinstformatsimm}.
-
-\begin{figure}[h]
-\begin{small}
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{p{0.3in}@{}p{0.8in}@{}p{0.6in}@{}p{0.18in}@{}p{0.7in}@{}p{0.6in}@{}p{0.6in}@{}p{0.3in}@{}p{0.5in}l}
-\\
-\multicolumn{1}{c}{\instbit{31}} &
-\instbitrange{30}{25} &
-\instbitrange{24}{21} &
-\multicolumn{1}{c}{\instbit{20}} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{8} &
-\multicolumn{1}{c}{\instbit{7}} &
-\instbitrange{6}{0} \\
-\cline{1-9}
-\multicolumn{2}{|c|}{funct7} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{2}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} &
-R-type \\
-\cline{1-9}
-\\
-\cline{1-9}
-\multicolumn{4}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{2}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} &
-I-type \\
-\cline{1-9}
-\\
-\cline{1-9}
-\multicolumn{2}{|c|}{imm[11:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{2}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} &
-S-type \\
-\cline{1-9}
-\\
-\cline{1-9}
-\multicolumn{1}{|c|}{imm[12]} &
-\multicolumn{1}{c|}{imm[10:5]} &
-\multicolumn{2}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{imm[4:1]} &
-\multicolumn{1}{c|}{imm[11]} &
-\multicolumn{1}{c|}{opcode} &
-B-type \\
-\cline{1-9}
-\\
-\cline{1-9}
-\multicolumn{6}{|c|}{imm[31:12]} &
-\multicolumn{2}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} &
-U-type \\
-\cline{1-9}
-\\
-\cline{1-9}
-\multicolumn{1}{|c|}{imm[20]} &
-\multicolumn{2}{c|}{imm[10:1]} &
-\multicolumn{1}{c|}{imm[11]} &
-\multicolumn{2}{c|}{imm[19:12]} &
-\multicolumn{2}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} &
-J-type \\
-\cline{1-9}
-\end{tabular}
-\end{center}
-\end{small}
-\caption{RISC-V base instruction formats showing immediate variants.}
-\label{fig:baseinstformatsimm}
-\end{figure}
-
-The only difference between the S and B formats is that the 12-bit
-immediate field is used to encode branch offsets in multiples of 2 in
-the B format. Instead of shifting all bits in the
-instruction-encoded immediate left by one in hardware as is
-conventionally done, the middle bits (imm[10:1]) and sign bit stay in
-fixed positions, while the lowest bit in S format (inst[7]) encodes a
-high-order bit in B format.
-
-Similarly, the only difference between the U and J formats is
-that the 20-bit immediate is shifted left by 12 bits to form U
-immediates and by 1 bit to form J immediates. The location of
-instruction bits in the U and J format immediates is chosen to
-maximize overlap with the other formats and with each other.
-
-Figure~\ref{fig:immtypes} shows the immediates produced by each of the
-base instruction formats, and is labeled to show which instruction
-bit (inst[{\em y}\,]) produces each bit of the immediate value.
-
-\begin{figure}[h]
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{p{0.2in}@{}p{1.2in}@{}p{1.0in}@{}p{0.2in}@{}p{0.7in}@{}p{0.7in}@{}p{0.2in}l}
-\\
-\multicolumn{1}{c}{\instbit{31}} &
-\instbitrange{30}{20} &
-\instbitrange{19}{12} &
-\multicolumn{1}{c}{\instbit{11}} &
-\instbitrange{10}{5} &
-\instbitrange{4}{1} &
-\multicolumn{1}{c}{\instbit{0}} &
-\\
-\cline{1-7}
-\multicolumn{4}{|c|}{--- inst[31] ---} &
-\multicolumn{1}{c|}{inst[30:25]} &
-\multicolumn{1}{c|}{inst[24:21]} &
-\multicolumn{1}{c|}{inst[20]} &
-I-immediate \\
-\cline{1-7}
-\\
-\cline{1-7}
-\multicolumn{4}{|c|}{--- inst[31] ---} &
-\multicolumn{1}{c|}{inst[30:25]} &
-\multicolumn{1}{c|}{inst[11:8]} &
-\multicolumn{1}{c|}{inst[7]} &
-S-immediate \\
-\cline{1-7}
-\\
-\cline{1-7}
-\multicolumn{3}{|c|}{--- inst[31] ---} &
-\multicolumn{1}{c|}{inst[7]} &
-\multicolumn{1}{c|}{inst[30:25]} &
-\multicolumn{1}{c|}{inst[11:8]} &
-\multicolumn{1}{c|}{0} &
-B-immediate \\
-\cline{1-7}
-\\
-\cline{1-7}
-\multicolumn{1}{|c|}{inst[31]} &
-\multicolumn{1}{c|}{inst[30:20]} &
-\multicolumn{1}{c|}{inst[19:12]} &
-\multicolumn{4}{c|}{--- 0 ---} &
-U-immediate \\
-\cline{1-7}
-\\
-\cline{1-7}
-\multicolumn{2}{|c|}{--- inst[31] ---} &
-\multicolumn{1}{c|}{inst[19:12]} &
-\multicolumn{1}{c|}{inst[20]} &
-\multicolumn{1}{c|}{inst[30:25]} &
-\multicolumn{1}{c|}{inst[24:21]} &
-\multicolumn{1}{c|}{0} &
-J-immediate \\
-\cline{1-7}
-\end{tabular}
-\end{center}
-\caption{Types of immediate produced by RISC-V instructions. The fields are labeled with the
- instruction bits used to construct their value. Sign extension
- always uses inst[31].}
-\label{fig:immtypes}
-\end{figure}
-
-\begin{commentary}
-Sign-extension is one of the most critical operations on immediates
-(particularly for XLEN>32), and in RISC-V the sign bit for all immediates
-is always held in bit 31 of the instruction to allow sign-extension to
-proceed in parallel with instruction decoding.
-
-Although more complex implementations might have separate adders for
-branch and jump calculations and so would not benefit from keeping the
-location of immediate bits constant across types of instruction, we
-wanted to reduce the hardware cost of the simplest implementations.
-By rotating bits in the instruction encoding of B and J immediates
-instead of using dynamic hardware muxes to multiply the immediate by
-2, we reduce instruction signal fanout and immediate mux costs by
-around a factor of 2. The scrambled immediate encoding will add
-negligible time to static or ahead-of-time compilation. For dynamic
-generation of instructions, there is some small additional
-overhead, but the most common short forward branches have
-straightforward immediate encodings.
-\end{commentary}
-
-\section{Integer Computational Instructions}
-
-Most integer computational instructions operate on XLEN bits of values
-held in the integer register file. Integer computational instructions
-are either encoded as register-immediate operations using the I-type
-format or as register-register operations using the R-type format.
-The destination is register {\em rd} for both register-immediate and
-register-register instructions. No integer computational instructions
-cause arithmetic exceptions.
-
-\begin{commentary}
-We did not include special instruction-set support for overflow checks
-on integer arithmetic operations in the base instruction set, as many
-overflow checks can be cheaply implemented using RISC-V branches.
-Overflow checking for unsigned addition requires only a single
-additional branch instruction after the addition:
-\verb! add t0, t1, t2; bltu t0, t1, overflow!.
-
-For signed addition, if one operand's sign is known, overflow checking
-requires only a single branch after the addition:
-\verb! addi t0, t1, +imm; blt t0, t1, overflow!. This covers the
-common case of addition with an immediate operand.
-
-For general signed addition, three additional instructions after the
-addition are required, leveraging the observation that the sum should
-be less than one of the operands if and only if the other operand is
-negative.
-\begin{verbatim}
- add t0, t1, t2
- slti t3, t2, 0
- slt t4, t0, t1
- bne t3, t4, overflow
-\end{verbatim}
-In RV64I, checks of 32-bit signed additions can be optimized further by
-comparing the results of ADD and ADDW on the operands.
-\end{commentary}
-
-\subsubsection*{Integer Register-Immediate Instructions}
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{M@{}R@{}S@{}R@{}O}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-I-immediate[11:0] & src & ADDI/SLTI[U] & dest & OP-IMM \\
-I-immediate[11:0] & src & ANDI/ORI/XORI & dest & OP-IMM \\
-\end{tabular}
-\end{center}
-ADDI adds the sign-extended 12-bit immediate to register {\em rs1}.
-Arithmetic overflow is ignored and the result is simply the low
-XLEN bits of the result. ADDI {\em rd, rs1, 0} is used to implement the
-MV {\em rd, rs1} assembler pseudoinstruction.
-
-SLTI (set less than immediate) places the value 1 in register {\em rd}
-if register {\em rs1} is less than the sign-extended immediate when
-both are treated as signed numbers, else 0 is written to {\em rd}.
-SLTIU is similar but compares the values as unsigned numbers (i.e.,
-the immediate is first sign-extended to XLEN bits then treated as an
-unsigned number). Note, SLTIU {\em rd, rs1, 1} sets {\em rd}
-to 1 if {\em rs1} equals zero, otherwise sets {\em rd} to 0 (assembler
-pseudoinstruction SEQZ {\em rd, rs}).
-
-ANDI, ORI, XORI are logical operations that perform bitwise AND, OR,
-and XOR on register {\em rs1} and the sign-extended 12-bit immediate
-and place the result in {\em rd}. Note, XORI {\em rd, rs1, -1}
-performs a bitwise logical inversion of register {\em rs1} (assembler
-pseudoinstruction NOT {\em rd, rs}).
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}R@{}R@{}S@{}R@{}O}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:5]} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-0000000 & shamt[4:0] & src & SLLI & dest & OP-IMM \\
-0000000 & shamt[4:0] & src & SRLI & dest & OP-IMM \\
-0100000 & shamt[4:0] & src & SRAI & dest & OP-IMM \\
-\end{tabular}
-\end{center}
-
-Shifts by a constant are encoded as a specialization of the
-I-type format. The operand to be shifted is in {\em rs1}, and the
-shift amount is encoded in the lower 5 bits of the I-immediate field.
-The right shift type is encoded in bit 30.
-SLLI is a logical left shift (zeros are shifted into the lower bits);
-SRLI is a logical right shift (zeros are shifted into the upper bits);
-and SRAI is an arithmetic right shift (the original sign bit is copied
-into the vacated upper bits).
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{U@{}R@{}O}
-\\
-\instbitrange{31}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[31:12]} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-20 & 5 & 7 \\
-U-immediate[31:12] & dest & LUI \\
-U-immediate[31:12] & dest & AUIPC
-\end{tabular}
-\end{center}
-
-LUI (load upper immediate) is used to build 32-bit constants and uses
-the U-type format. LUI places the U-immediate value in the top 20
-bits of the destination register {\em rd}, filling in the lowest 12
-bits with zeros.
-
-AUIPC (add upper immediate to {\tt pc}) is used to build {\tt pc}-relative
-addresses and uses the U-type format. AUIPC forms a 32-bit offset from the
-20-bit U-immediate, filling in the lowest 12 bits with zeros, adds this offset
-to the {\tt pc} of the AUIPC instruction, then places the result in register {\em rd}.
-
-\begin{commentary}
-The AUIPC instruction supports two-instruction sequences to access
-arbitrary offsets from the PC for both control-flow transfers and data
-accesses. The combination of an AUIPC and the 12-bit immediate in a
-JALR can transfer control to any 32-bit PC-relative address, while an
-AUIPC plus the 12-bit immediate offset in regular load or store
-instructions can access any 32-bit PC-relative data address.
-
-The current PC can be obtained by setting the U-immediate to 0.
-Although a JAL +4 instruction could also be used to obtain the local
-PC (of the instruction following the JAL), it might cause pipeline
-breaks in simpler microarchitectures or pollute BTB structures in more
-complex microarchitectures.
-\end{commentary}
-
-\subsubsection*{Integer Register-Register Operations}
-
-RV32I defines several arithmetic R-type operations. All operations
-read the {\em rs1} and {\em rs2} registers as source operands and
-write the result into register {\em rd}. The {\em funct7} and {\em
- funct3} fields select the type of operation.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}R@{}R@{}S@{}R@{}O}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct7} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-0000000 & src2 & src1 & ADD/SLT/SLTU & dest & OP \\
-0000000 & src2 & src1 & AND/OR/XOR & dest & OP \\
-0000000 & src2 & src1 & SLL/SRL & dest & OP \\
-0100000 & src2 & src1 & SUB/SRA & dest & OP \\
-\end{tabular}
-\end{center}
-
-ADD performs the addition of {\em rs1} and {\em rs2}. SUB performs the
-subtraction of {\em rs2} from {\em rs1}. Overflows are ignored and the low XLEN
-bits of results are written to the destination {\em rd}.
-SLT and SLTU perform signed and unsigned compares
-respectively, writing 1 to {\em rd} if $\mbox{\em rs1} < \mbox{\em
- rs2}$, 0 otherwise. Note, SLTU {\em rd}, {\em x0}, {\em rs2} sets
-{\em rd} to 1 if {\em rs2} is not equal to zero, otherwise sets {\em
- rd} to zero (assembler pseudoinstruction SNEZ {\em rd, rs}). AND, OR, and
-XOR perform bitwise logical operations.
-
-SLL, SRL, and SRA perform logical left, logical right, and arithmetic
-right shifts on the value in register {\em rs1} by the shift amount
-held in the lower 5 bits of register {\em rs2}.
-
-\subsubsection*{NOP Instruction}
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{M@{}R@{}S@{}R@{}O}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-0 & 0 & ADDI & 0 & OP-IMM \\
-\end{tabular}
-\end{center}
-
-The NOP instruction does not change any architecturally visible state, except for
-advancing the {\tt pc} and incrementing any applicable performance
-counters. NOP is encoded as ADDI {\em x0, x0, 0}.
-
-\begin{commentary}
-NOPs can be used to align code segments to microarchitecturally
-significant address boundaries, or to leave space for inline code
-modifications. Although there are many possible ways to encode a NOP,
-we define a canonical NOP encoding to allow microarchitectural
-optimizations as well as for more readable disassembly output. The
-other NOP encodings are made available for HINT instructions
-(Section~\ref{sec:rv32i-hints}).
-
-ADDI was chosen for the NOP encoding as this is most likely to take
-fewest resources to execute across a range of systems (if not
-optimized away in decode). In particular, the instruction only reads
-one register. Also, an ADDI functional unit is more likely to be
-available in a superscalar design as adds are the most common
-operation. In particular, address-generation functional units can
-execute ADDI using the same hardware needed for base+offset address
-calculations, while register-register ADD or logical/shift operations
-require additional hardware.
-\end{commentary}
-
-\section{Control Transfer Instructions}
-
-RV32I provides two types of control transfer instructions:
-unconditional jumps and conditional branches. Control transfer
-instructions in RV32I do {\em not} have architecturally visible delay
-slots.
-
-\subsubsection*{Unconditional Jumps}
-
-\vspace{-0.1in} The jump and link (JAL) instruction uses the J-type
-format, where the J-immediate encodes a signed offset in multiples of
-2 bytes. The offset is sign-extended and added to the {\tt pc}
-to form the jump target address. Jumps can therefore target a
-$\pm$\wunits{1}{MiB} range. JAL stores the address of the instruction
-following the jump ({\tt pc}+4) into register {\em rd}. The standard
-software calling convention uses {\tt x1} as the return address
-register and {\tt x5} as an alternate link register.
-
-\begin{commentary}
-The alternate link register supports calling millicode routines (e.g.,
-those to save and restore registers in compressed code) while
-preserving the regular return address register. The register {\tt x5}
-was chosen as the alternate link register as it maps to a temporary in
-the standard calling convention, and has an encoding that is only one
-bit different than the regular link register.
-\end{commentary}
-
-Plain unconditional jumps (assembler pseudoinstruction J) are encoded as a JAL
-with {\em rd}={\tt x0}.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{W@{}E@{}W@{}R@{}R@{}O}
-\\
-\multicolumn{1}{c}{\instbit{31}} &
-\instbitrange{30}{21} &
-\multicolumn{1}{c}{\instbit{20}} &
-\instbitrange{19}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[20]} &
-\multicolumn{1}{c|}{imm[10:1]} &
-\multicolumn{1}{c|}{imm[11]} &
-\multicolumn{1}{c|}{imm[19:12]} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-1 & 10 & \multicolumn{1}{c}{1} & 8 & 5 & 7 \\
-\multicolumn{4}{c}{offset[20:1]} & dest & JAL \\
-\end{tabular}
-\end{center}
-
-The indirect jump instruction JALR (jump and link register) uses the
-I-type encoding. The target address is obtained by adding the sign-extended
-12-bit I-immediate to the register {\em rs1}, then setting the
-least-significant bit of the result to zero. The address of
-the instruction following the jump ({\tt pc}+4) is written to register
-{\em rd}. Register {\tt x0} can be used as the destination if the
-result is not required.
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-offset[11:0] & base & 0 & dest & JALR \\
-\end{tabular}
-\end{center}
-
-\begin{commentary}
-The unconditional jump instructions all use PC-relative addressing to
-help support position-independent code. The JALR instruction was
-defined to enable a two-instruction sequence to jump anywhere in a
-32-bit absolute address range. A LUI instruction can first load {\em
- rs1} with the upper 20 bits of a target address, then JALR can add
-in the lower bits. Similarly, AUIPC then JALR can jump
-anywhere in a 32-bit {\tt pc}-relative address range.
-
-Note that the JALR instruction does not treat the 12-bit immediate as
-multiples of 2 bytes, unlike the conditional branch instructions.
-This avoids one more immediate format in hardware. In
-practice, most uses of JALR will have either a zero immediate or be
-paired with a LUI or AUIPC, so the slight reduction in range is not
-significant.
-
-Clearing the least-significant bit when calculating the JALR target
-address both simplifies the hardware slightly and allows the
-low bit of function pointers to be used to store auxiliary
-information. Although there is potentially a slight loss of error
-checking in this case, in practice jumps to an incorrect instruction
-address will usually quickly raise an exception.
-
-When used with a base {\em rs1}$=${\tt x0}, JALR can be used to implement
-a single instruction subroutine call to the lowest \wunits{2}{KiB} or highest
-\wunits{2}{KiB} address region from anywhere in the address space, which could
-be used to implement fast calls to a small runtime library.
-\end{commentary}
-
-The JAL and JALR instructions will generate an
-instruction-address-misaligned exception if the target address is not
-aligned to a four-byte boundary.
-
-\begin{commentary}
-Instruction-address-misaligned exceptions are not possible on machines
-that support extensions with 16-bit aligned instructions, such as the
-compressed instruction-set extension, C.
-\end{commentary}
-
-Return-address prediction stacks are a common feature of
-high-performance instruction-fetch units, but require accurate
-detection of instructions used for procedure calls and returns to be
-effective. For RISC-V, hints as to the instructions' usage are encoded
-implicitly via the register numbers used. A JAL instruction should
-push the return address onto a return-address stack (RAS) only when
-{\em rd}$=${\tt x1}/{\tt x5}. JALR instructions should push/pop a
-RAS as shown in the Table~\ref{rashints}.
-\begin{table}[hbt]
-\centering
-\begin{tabular}{|c|c|c|l|}
- \hline
- \em rd & \em rs1 & {\em rs1}$=${\em rd} & RAS action \\
- \hline
- !{\em link} & !{\em link} & - & none \\
- !{\em link} & {\em link} & - & pop \\
- {\em link} & !{\em link} & - & push \\
- {\em link} & {\em link} & 0 & pop, then push \\
- {\em link} & {\em link} & 1 & push \\
- \hline
-\end{tabular}
-\caption{Return-address stack prediction hints encoded in register
- specifiers used in the instruction. In the above, {\em link} is
- true when the register is either {\tt x1} or {\tt x5}.}
-\label{rashints}
-\end{table}
-
-\begin{commentary}
-Some other ISAs added explicit hint bits to their indirect-jump instructions
-to guide return-address stack manipulation. We use implicit hinting tied to
-register numbers and the calling convention to reduce the encoding space used
-for these hints.
-
-When two different link registers ({\tt x1} and {\tt x5}) are given as
-{\em rs1} and {\em rd}, then the RAS is both popped and pushed to
-support coroutines. If {\em rs1} and {\em rd} are the same link
-register (either {\tt x1} or {\tt x5}), the RAS is only pushed to
-enable macro-op fusion of the sequences:\linebreak
-{\tt lui ra, imm20; jalr ra, imm12(ra)} \ and \
-{\tt auipc ra, imm20; jalr ra, imm12(ra)}
-\end{commentary}
-
-\subsubsection*{Conditional Branches}
-
-All branch instructions use the B-type instruction format. The
-12-bit B-immediate encodes signed offsets in multiples of 2, and is
-added to the current {\tt pc} to give the target address. The
-conditional branch range is $\pm$\wunits{4}{KiB}.
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{W@{}R@{}F@{}F@{}R@{}R@{}F@{}S}
-\\
-\multicolumn{1}{c}{\instbit{31}} &
-\instbitrange{30}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{8} &
-\multicolumn{1}{c}{\instbit{7}} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[12]} &
-\multicolumn{1}{c|}{imm[10:5]} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{imm[4:1]} &
-\multicolumn{1}{c|}{imm[11]} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-1 & 6 & 5 & 5 & 3 & 4 & 1 & 7 \\
-\multicolumn{2}{c}{offset[12,10:5]} & src2 & src1 & BEQ/BNE & \multicolumn{2}{c}{offset[11,4:1]} & BRANCH \\
-\multicolumn{2}{c}{offset[12,10:5]} & src2 & src1 & BLT[U] & \multicolumn{2}{c}{offset[11,4:1]} & BRANCH \\
-\multicolumn{2}{c}{offset[12,10:5]} & src2 & src1 & BGE[U] & \multicolumn{2}{c}{offset[11,4:1]} & BRANCH \\
-\end{tabular}
-\end{center}
-
-Branch instructions compare two registers. BEQ and BNE take the
-branch if registers {\em rs1} and {\em rs2} are equal or unequal
-respectively. BLT and BLTU take the branch if {\em rs1} is less than
-{\em rs2}, using signed and unsigned comparison respectively. BGE and
-BGEU take the branch if {\em rs1} is greater than or equal to {\em rs2},
-using signed and unsigned comparison respectively. Note, BGT, BGTU,
-BLE, and BLEU can be synthesized by reversing the operands to BLT,
-BLTU, BGE, and BGEU, respectively.
-
-\begin{commentary}
-Signed array bounds may be checked with a single BLTU instruction, since
-any negative index will compare greater than any nonnegative bound.
-\end{commentary}
-
-Software should be optimized such that the sequential code path is the
-most common path, with less-frequently taken code paths placed out of
-line. Software should also assume that backward branches will be
-predicted taken and forward branches as not taken, at least the
-first time they are encountered. Dynamic predictors should quickly
-learn any predictable branch behavior.
-
-Unlike some other architectures, the RISC-V jump (JAL with {\em
- rd}={\tt x0}) instruction should always be used for unconditional
-branches instead of a conditional branch instruction with an
-always-true condition. RISC-V jumps are also PC-relative and support
-a much wider offset range than branches, and will not pollute
-conditional-branch prediction tables.
-
-\begin{commentary}
-The conditional branches were designed to include arithmetic
-comparison operations between two registers (as also done in PA-RISC
-and Xtensa ISA), rather than use condition codes (x86, ARM, SPARC,
-PowerPC), or to only compare one register against zero (Alpha, MIPS),
-or two registers only for equality (MIPS). This design was motivated
-by the observation that a combined compare-and-branch instruction fits
-into a regular pipeline, avoids additional condition code state or use
-of a temporary register, and reduces static code size and dynamic
-instruction fetch traffic. Another point is that comparisons against
-zero require non-trivial circuit delay (especially after the move to
-static logic in advanced processes) and so are almost as expensive as
-arithmetic magnitude compares. Another advantage of a fused
-compare-and-branch instruction is that branches are observed earlier
-in the front-end instruction stream, and so can be predicted earlier.
-There is perhaps an advantage to a design with condition codes in the
-case where multiple branches can be taken based on the same condition
-codes, but we believe this case to be relatively rare.
-
-We considered but did not include static branch hints in the
-instruction encoding. These can reduce the pressure on dynamic
-predictors, but require more instruction encoding space and
-software profiling for best results, and can result in poor
-performance if production runs do not match profiling runs.
-
-We considered but did not include conditional moves or predicated
-instructions, which can effectively replace unpredictable short
-forward branches. Conditional moves are the simpler of the two, but
-are difficult to use with conditional code that might cause exceptions
-(memory accesses and floating-point operations). Predication adds
-additional flag state to a system, additional instructions to set and
-clear flags, and additional encoding overhead on every instruction.
-Both conditional move and predicated instructions add complexity to
-out-of-order microarchitectures, adding an implicit third source
-operand due to the need to copy the original value of the destination
-architectural register into the renamed destination physical register
-if the predicate is false. Also, static compile-time decisions to use
-predication instead of branches can result in lower performance on
-inputs not included in the compiler training set, especially given
-that unpredictable branches are rare, and becoming rarer as branch
-prediction techniques improve.
-
-We note that various microarchitectural techniques exist to
-dynamically convert unpredictable short forward branches into
-internally predicated code to avoid the cost of flushing pipelines on
-a branch mispredict~\cite{heil-tr1996,Klauser-1998,Kim-micro2005} and
-have been implemented in commercial processors~\cite{ibmpower7}.
-The simplest techniques just reduce the penalty of recovering from a
-mispredicted short forward branch by only flushing instructions in the
-branch shadow instead of the entire fetch pipeline, or by fetching
-instructions from both sides using wide instruction fetch or idle
-instruction fetch slots. More complex techniques for out-of-order
-cores add internal predicates on instructions in the branch shadow,
-with the internal predicate value written by the branch instruction,
-allowing the branch and following instructions to be executed
-speculatively and out-of-order with respect to other code~\cite{ibmpower7}.
-\end{commentary}
-
-\section{Load and Store Instructions}
-
-RV32I is a load-store architecture, where only load and store
-instructions access memory and arithmetic instructions only operate on
-CPU registers. RV32I provides a 32-bit address space that is
-byte-addressed and little-endian. The EEI will
-define what portions of the address space are legal to access with
-which instructions (e.g., some addresses might be read only, or
-support word access only). Loads with a destination of {\tt x0} must
-still raise any exceptions and action any other side effects even
-though the load value is discarded.
-
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-offset[11:0] & base & width & dest & LOAD \\
-\end{tabular}
-\end{center}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{O@{}R@{}R@{}F@{}R@{}O}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:5]} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-offset[11:5] & src & base & width & offset[4:0] & STORE \\
-\end{tabular}
-\end{center}
-
-Load and store instructions transfer a value between the registers and
-memory. Loads are encoded in the I-type format and stores are
-S-type. The effective byte address is obtained by adding register
-{\em rs1} to the sign-extended 12-bit offset. Loads copy a value
-from memory to register {\em rd}. Stores copy the value in register
-{\em rs2} to memory.
-
-The LW instruction loads a 32-bit value from memory into {\em rd}. LH
-loads a 16-bit value from memory, then sign-extends to 32-bits before
-storing in {\em rd}. LHU loads a 16-bit value from memory but then
-zero extends to 32-bits before storing in {\em rd}. LB and LBU are
-defined analogously for 8-bit values. The SW, SH, and SB instructions
-store 32-bit, 16-bit, and 8-bit values from the low bits of register
-{\em rs2} to memory.
-
-Regardless of EEI, loads and stores whose effective addresses are
-naturally aligned shall not raise an address-misaligned exception.
-Loads and stores where the effective address is not naturally aligned
-to the referenced datatype (i.e., on a four-byte boundary for 32-bit
-accesses, and a two-byte boundary for 16-bit accesses) have behavior
-dependent on the EEI.
-
-An EEI may guarantee that misaligned loads and stores are fully
-supported, and so the software running inside the execution
-environment will never experience a contained or fatal
-address-misaligned trap. In this case, the misaligned loads and
-stores can be handled in hardware, or via an invisible trap into the
-execution environment implementation, or possibly a combination of
-hardware and invisible trap depending on address.
-
-An EEI may not guarantee misaligned loads and stores are handled
-invisibly. In this case, loads and stores that are not naturally
-aligned may either complete execution successfully or raise an
-exception. The exception raised can be either an address-misaligned
-exception or an access exception. For a memory access that would
-otherwise be able to complete except for the misalignment, an access
-exception can be raised instead of an address-misaligned exception if
-the misaligned access should not be emulated, e.g., if accesses to the
-memory region have side effects. When an EEI does not guarantee
-misaligned loads and stores are handled invisibly, the EEI must define
-if exceptions caused by address misalignment result in a contained
-trap (allowing software running inside the execution environment to
-handle the trap) or a fatal trap (terminating execution).
-
-\begin{commentary}
-Misaligned accesses are occasionally required when porting legacy
-code, and help performance on applications when using any form of
-packed-SIMD extension or handling externally packed data structures.
-Our rationale for allowing EEIs to choose to support misaligned
-accesses via the regular load and store instructions is to simplify
-the addition of misaligned hardware support. One option would have
-been to disallow misaligned accesses in the base ISA and then provide
-some separate ISA support for misaligned accesses, either special
-instructions to help software handle misaligned accesses or a new
-hardware addressing mode for misaligned accesses. Special
-instructions are difficult to use, complicate the ISA, and often add
-new processor state (e.g., SPARC VIS align address offset register) or
-complicate access to existing processor state (e.g., MIPS LWL/LWR
-partial register writes). In addition, for loop-oriented packed-SIMD
-code, the extra overhead when operands are misaligned motivates
-software to provide multiple forms of loop depending on operand
-alignment, which complicates code generation and adds to loop startup
-overhead. New misaligned hardware addressing modes take considerable
-space in the instruction encoding or require very simplified
-addressing modes (e.g., register indirect only).
-\end{commentary}
-
-Even when misaligned loads and stores complete successfully, these
-accesses might run extremely slowly depending on the implementation
-(e.g., when implemented via an invisible trap). Furthermore, whereas
-naturally aligned loads and stores are guaranteed to execute
-atomically, misaligned loads and stores might not, and hence
-require additional synchronization to ensure atomicity.
-
-\begin{commentary}
-We do not mandate atomicity for misaligned accesses so execution
-environment implementations can use an invisible machine trap and
-a software handler to handle some or all misaligned accesses. If
-hardware misaligned support is provided, software can exploit this by
-simply using regular load and store instructions. Hardware can then
-automatically optimize accesses depending on whether runtime addresses
-are aligned.
-\end{commentary}
-
-\pagebreak
-
-\section{Memory Ordering Instructions}
-\label{sec:fence}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{F@{}IIIIIIIIF@{}F@{}F@{}S}
-\\
-\instbitrange{31}{28} &
-\multicolumn{1}{c}{\instbit{27}} &
-\multicolumn{1}{c}{\instbit{26}} &
-\multicolumn{1}{c}{\instbit{25}} &
-\multicolumn{1}{c}{\instbit{24}} &
-\multicolumn{1}{c}{\instbit{23}} &
-\multicolumn{1}{c}{\instbit{22}} &
-\multicolumn{1}{c}{\instbit{21}} &
-\multicolumn{1}{c}{\instbit{20}} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{fm} &
-\multicolumn{1}{c|}{PI} &
-\multicolumn{1}{c|}{PO} &
-\multicolumn{1}{c|}{PR} &
-\multicolumn{1}{c|}{PW} &
-\multicolumn{1}{|c|}{SI} &
-\multicolumn{1}{c|}{SO} &
-\multicolumn{1}{c|}{SR} &
-\multicolumn{1}{c|}{SW} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-4 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 5 & 3 & 5 & 7 \\
-FM & \multicolumn{4}{c}{predecessor} & \multicolumn{4}{c}{successor} & 0 & FENCE & 0 & MISC-MEM \\
-\end{tabular}
-\end{center}
-
-The FENCE instruction is used to order device I/O and
-memory accesses as viewed by other RISC-V harts and external devices
-or coprocessors. Any combination of device input (I), device output
-(O), memory reads (R), and memory writes (W) may be ordered with
-respect to any combination of the same. Informally, no other RISC-V
-hart or external device can observe any operation in the {\em
- successor} set following a FENCE before any operation in the {\em
- predecessor} set preceding the FENCE.
-Chapter~\ref{ch:memorymodel} provides a precise description of the
-RISC-V memory consistency model.
-
-The EEI will define what I/O operations are possible, and in
-particular, which memory addresses when accessed by load and store instructions will be treated and
-ordered as device input and device output operations respectively
-rather than memory reads and writes. For example, memory-mapped I/O
-devices will typically be accessed with uncached loads and stores that
-are ordered using the I and O bits rather than the R and W bits.
-Instruction-set extensions might also describe new coprocessor I/O
-instructions that will also be ordered using the I and O bits in a
-FENCE.
-
-\begin{table}[htp]
-\begin{small}
-\begin{center}
-\begin{tabular}{|c|c|l|}
-\hline
-{\em fm} field & Mnemonic & Meaning \\
-\hline
-0000 & \em none & Normal Fence \\
-\hline
-\multirow{2}{*}{1000} & \multirow{2}{*}{TSO} & With FENCE RW,RW: exclude write-to-read ordering \\
- & & Otherwise: \em Reserved for future use. \\
-\hline
-\multicolumn{2}{|c|}{\em other} & \em Reserved for future use. \\
-\hline
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Fence mode encoding.}
-\label{fm}
-\end{table}
-
-The fence mode field {\em fm} defines the semantics of the FENCE. A
-FENCE with {\em fm}=0000 orders all memory operations in its
-predecessor set before all memory operations in its successor set.
-
-The optional FENCE.TSO instruction with {\em fm}=1000 orders all load
-operations in its predecessor set before all memory operations in its
-successor set, and all store operations in its predecessor set before
-all store operations in its successor set. This leaves non-AMO store
-operations in the FENCE.TSO's predecessor set unordered with non-AMO
-loads in its successor set.
-
-\begin{commentary}
- The FENCE.TSO encoding was added as an optional extension to the
- original base FENCE instruction encoding. The base definition
- requires that implementations ignore any set bits and treat the
- FENCE as global, and so this is a backwards-compatible extension.
-\end{commentary}
-
-The unused fields in the FENCE instructions---{\em rs1} and {\em rd}---are
-reserved for finer-grain fences in future extensions. For forward
-compatibility, base implementations shall ignore these fields, and standard
-software shall zero these fields. Likewise, many {\em fm} and
-predecessor/successor set settings in Table~\ref{fm} are also reserved
-for future use. Base implementations shall treat all such reserved
-configurations as normal fences with {\em fm}=0000, and standard
-software shall use only non-reserved configurations.
-
-\begin{commentary}
-We chose a relaxed memory model to allow high performance from simple
-machine implementations and from likely future
-coprocessor or accelerator extensions. We separate out I/O ordering
-from memory R/W ordering to avoid unnecessary serialization within a
-device-driver hart and also to support alternative non-memory paths
-to control added coprocessors or I/O devices. Simple implementations
-may additionally ignore the {\em predecessor} and {\em successor}
-fields and always execute a conservative fence on all operations.
-\end{commentary}
-
-\section{Environment Call and Breakpoints}
-
-SYSTEM instructions are used to access system functionality that might
-require privileged access and are encoded using the I-type instruction
-format. These can be divided into two main classes: those that
-atomically read-modify-write control and status registers (CSRs), and
-all other potentially privileged instructions. CSR instructions are
-described in Chapter~\ref{csrinsts}, and the base unprivileged instructions
-are described in the following section.
-
-\begin{commentary}
-The SYSTEM instructions are defined to allow simpler implementations
-to always trap to a single software trap handler. More sophisticated
-implementations might execute more of each system instruction in
-hardware.
-\end{commentary}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{M@{}R@{}F@{}R@{}S}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct12} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-ECALL & 0 & PRIV & 0 & SYSTEM \\
-EBREAK & 0 & PRIV & 0 & SYSTEM \\
-\end{tabular}
-\end{center}
-
-There two instructions cause a precise requested trap to the
-supporting execution environment.
-
-The ECALL instruction is used to make a service request to the
-execution environment. The EEI will define how parameters for the
-service request are passed, but usually these will be in defined
-locations in the integer register file.
-
-The EBREAK instruction is used to return control to a debugging
-environment.
-
-\begin{commentary}
-ECALL and EBREAK were previously named SCALL and SBREAK. The
-instructions have the same functionality and encoding, but were
-renamed to reflect that they can be used more generally than to call a
-supervisor-level operating system or debugger.
-\end{commentary}
-
-\begin{commentary}
- EBREAK was primarily designed to be used by a debugger to cause
- execution to stop and fall back into the debugger. EBREAK is also
- used by the standard gcc compiler to mark code paths that should not
- be executed.
-
- Another use of EBREAK is to support ``semihosting'', where the
- execution environment includes a debugger that can provide services
- over an alternate system call interface built around the EBREAK
- instruction. Because the RISC-V base ISA does not provide more than
- one EBREAK instruction, RISC-V semihosting uses a special sequence of
- instructions to distinguish a semihosting EBREAK from a debugger
- inserted EBREAK.
-\begin{verbatim}
- slli x0, x0, 0x1f # Entry NOP
- ebreak # Break to debugger
- srai x0, x0, 7 # NOP encoding the semihosting call number 7
-\end{verbatim}
- Note that these three instructions must be 32-bit-wide instructions,
- i.e., they mustn't be among the compressed 16-bit instructions
- described in Chapter~\ref{compressed}.
-
- The shift NOP instructions are still considered available for use as
- HINTS.
-
- Semihosting is a form of service call and would be more naturally
- encoded as an ECALL using an existing ABI, but this would require
- the debugger to be able to intercept ECALLs, which is a newer
- addition to the debug standard. We intend to move over to using
- ECALLs with a standard ABI, in which case, semihosting can share a
- service ABI with an existing standard.
-
- We note that ARM processors have also moved to using SVC instead of
- BKPT for semihosting calls in newer designs.
-\end{commentary}
-
-\section{HINT Instructions}
-\label{sec:rv32i-hints}
-
-RV32I reserves a large encoding space for HINT instructions, which are
-usually used to communicate performance hints to the
-microarchitecture. HINTs are encoded as integer computational
-instructions with {\em rd}={\tt x0}. Hence, like the NOP instruction,
-HINTs do not change any architecturally visible state, except for
-advancing the {\tt pc} and any applicable performance counters.
-Implementations are always allowed to ignore the encoded hints.
-
-\begin{commentary}
-This HINT encoding has been chosen so that simple implementations can ignore
-HINTs altogether, and instead execute a HINT as a regular computational
-instruction that happens not to mutate the architectural state. For example, ADD is
-a HINT if the destination register is {\tt x0}; the five-bit {\em rs1} and {\em
-rs2} fields encode arguments to the HINT. However, a simple implementation can
-simply execute the HINT as an ADD of {\em rs1} and {\em rs2} that writes {\tt
-x0}, which has no architecturally visible effect.
-\end{commentary}
-
-Table~\ref{tab:rv32i-hints} lists all RV32I HINT code points. 91\% of the HINT
-space is reserved for standard HINTs, but none are presently defined. The
-remainder of the HINT space is reserved for custom HINTs: no standard HINTs
-will ever be defined in this subspace.
-
-\begin{commentary}
-No standard hints are presently defined. We anticipate
-standard hints to eventually include memory-system spatial and
-temporal locality hints, branch prediction hints, thread-scheduling
-hints, security tags, and instrumentation flags for
-simulation/emulation.
-\end{commentary}
-
-\begin{table}[hbt]
-\centering
-\begin{tabular}{|l|l|c|l|}
- \hline
- Instruction & Constraints & Code Points & Purpose \\ \hline \hline
- LUI & {\em rd}={\tt x0} & $2^{20}$ & \multirow{15}{*}{\em Reserved for future standard use} \\ \cline{1-3}
- AUIPC & {\em rd}={\tt x0} & $2^{20}$ & \\ \cline{1-3}
- \multirow{2}{*}{ADDI} & {\em rd}={\tt x0}, and either & \multirow{2}{*}{$2^{17}-1$} & \\
- & {\em rs1}$\neq${\tt x0} or {\em imm}$\neq$0 & & \\ \cline{1-3}
- ANDI & {\em rd}={\tt x0} & $2^{17}$ & \\ \cline{1-3}
- ORI & {\em rd}={\tt x0} & $2^{17}$ & \\ \cline{1-3}
- XORI & {\em rd}={\tt x0} & $2^{17}$ & \\ \cline{1-3}
- ADD & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SUB & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- AND & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- OR & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- XOR & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SLL & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SRL & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SRA & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- FENCE & {\em pred}=0 or {\em succ}=0 & $2^{5}-1$ & \\ \hline \hline
- SLTI & {\em rd}={\tt x0} & $2^{17}$ & \multirow{7}{*}{\em Reserved for custom use} \\ \cline{1-3}
- SLTIU & {\em rd}={\tt x0} & $2^{17}$ & \\ \cline{1-3}
- SLLI & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SRLI & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SRAI & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SLT & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SLTU & {\em rd}={\tt x0} & $2^{10}$ & \\ \hline
-\end{tabular}
-\caption{RV32I HINT instructions.}
-\label{tab:rv32i-hints}
-\end{table}
-
diff --git a/src/rv32e.adoc b/src/rv32e.adoc
new file mode 100644
index 0000000..3850dc6
--- /dev/null
+++ b/src/rv32e.adoc
@@ -0,0 +1,46 @@
+[[rv32e]]
+== RV32E and RV64E Base Integer Instruction Sets, Version 2.0
+This chapter describes the RV32E and RV64E base integer
+instruction sets, designed for microcontrollers in embedded systems.
+RV32E and RV64E are reduced versions of RV32I and RV64I, respectively:
+the only change is to reduce the number of integer registers to 16. This
+chapter only outlines the differences between RV32E/RV64E and
+RV32I/RV64I, and so should be read after <<rv32>> and <<rv64>>.
+(((RV32E, design)))
+[NOTE]
+====
+RV32E was designed to provide an even smaller base core for embedded
+microcontrollers. There is also interest in RV64E for microcontrollers
+within large SoC designs, and to reduce context state for highly
+threaded 64-bit processors.
+
+Unless otherwise stated, standard extensions compatible with RV32I and
+RV64I are also compatible with RV32E and RV64E, respectively.
+====
+
+=== RV32E and RV64E Programmers’ Model
+RV32E and RV64E reduce the integer register count to 16 general-purpose
+registers, (`x0-x15`), where `x0` is a dedicated zero register.
+
+[NOTE]
+====
+We have found that in the small RV32I core implementations, the upper 16
+registers consume around one quarter of the total area of the core
+excluding memories, thus their removal saves around 25% core area with a
+corresponding core power reduction.
+====
+
+=== RV32E and RV64E Instruction Set Encoding
+(((RV32E, difference from RV32I)))
+RV32E and RV64E use the same instruction-set encoding as RV32I and RV64I
+respectively, except that only registers `x0-x15` are provided. All
+encodings specifying the other registers `x16-x31` are reserved.
+
+[NOTE]
+====
+The previous draft of this chapter made all encodings using the
+`x16-x31` registers available as custom. This version takes a more
+conservative approach, making these reserved so that they can be
+allocated between custom space or new standard encodings at a later
+date.
+====
diff --git a/src/rv32e.tex b/src/rv32e.tex
deleted file mode 100644
index 71ff45f..0000000
--- a/src/rv32e.tex
+++ /dev/null
@@ -1,49 +0,0 @@
-\chapter{RV32E Base Integer Instruction Set, Version 1.9}
-\label{rv32e}
-
-This chapter describes a draft proposal for the RV32E base integer
-instruction set, which is a reduced version of RV32I designed for
-embedded systems. The only change is to reduce the number of integer
-registers to 16. This chapter only outlines the differences between
-RV32E and RV32I, and so should be read after Chapter~\ref{rv32}.
-
-\begin{commentary}
-RV32E was designed to provide an even smaller base core for embedded
-microcontrollers. Although we had mentioned this possibility in
-version 2.0 of this document, we initially resisted defining this
-subset. However, given the demand for the smallest possible 32-bit
-microcontroller, and in the interests of preempting fragmentation in
-this space, we have now defined RV32E as a fourth standard base ISA in
-addition to RV32I, RV64I, and RV128I. There is also interest in
-defining an RV64E to reduce context state for highly threaded 64-bit
-processors.
-\end{commentary}
-
-\section{RV32E Programmers' Model}
-
-RV32E reduces the integer register count to 16 general-purpose
-registers, ({\tt x0}--{\tt x15}), where {\tt x0} is a dedicated zero
-register.
-
-\begin{commentary}
-We have found that in the small RV32I core designs, the upper 16
-registers consume around one quarter of the total area of the core
-excluding memories, thus their removal saves around 25\% core area
-with a corresponding core power reduction.
-\end{commentary}
-
-\begin{commentary}
-This change requires a different calling convention and ABI. In
-particular, RV32E is only used with a soft-float calling convention.
-A new embedded ABI is under consideration that would work across RV32E
-and RV32I.
-\end{commentary}
-
-\section{RV32E Instruction Set}
-
-RV32E uses the same instruction-set encoding as RV32I, except that
-only registers {\tt x0}--{\tt x15} are provided. Any future standard
-extensions will not make use of the instruction bits freed up by the
-reduced register-specifier fields and so these are available for
-custom extensions.
-
diff --git a/src/rv64.adoc b/src/rv64.adoc
new file mode 100644
index 0000000..cfcde3c
--- /dev/null
+++ b/src/rv64.adoc
@@ -0,0 +1,260 @@
+[[rv64]]
+== RV64I Base Integer Instruction Set, Version 2.1
+
+This chapter describes the RV64I base integer instruction set, which
+builds upon the RV32I variant described in <<rv32>>.
+This chapter presents only the differences with RV32I, so should be read
+in conjunction with the earlier chapter.
+
+=== Register State
+
+[#norm:rv64i_xreg_sz]#RV64I widens the integer registers and supported user address space to
+64 bits (XLEN=64 in <<gprs>>).#
+
+=== Integer Computational Instructions
+
+Most integer computational instructions operate on XLEN-bit values.
+Additional instruction variants are provided to manipulate 32-bit values
+in RV64I, indicated by a 'W' suffix to the opcode. [#norm:rv64_w_sex]#These "*W"
+instructions ignore the upper 32 bits of their inputs and always produce
+32-bit signed values, sign-extending them to 64 bits, i.e. bits XLEN-1
+through 31 are equal.#
+
+[NOTE]
+====
+The compiler and calling convention maintain an invariant that all
+32-bit values are held in a sign-extended format in 64-bit registers.
+Even 32-bit unsigned integers extend bit 31 into bits 63 through 32.
+Consequently, conversion between unsigned and signed 32-bit integers is
+a no-op, as is conversion from a signed 32-bit integer to a signed
+64-bit integer. Existing 64-bit wide SLTU and unsigned branch compares
+still operate correctly on unsigned 32-bit integers under this
+invariant. Similarly, existing 64-bit wide logical operations on 32-bit
+sign-extended integers preserve the sign-extension property. A few new
+instructions (ADD[I]W/SUBW/SxxW) are required for addition and shifts to
+ensure reasonable performance for 32-bit values.
+====
+(((RV64I, shifts)))
+(((RV64I, compares)))
+
+==== Integer Register-Immediate Instructions
+
+include::images/wavedrom/rv64i-base-int.edn[]
+[[rv64i-base-int]]
+//.RV64I register-immediate instructions
+
+[#norm:addiw_op]#ADDIW is an RV64I instruction that adds the sign-extended 12-bit
+immediate to register _rs1_ and produces the proper sign extension of a
+32-bit result in _rd_.# [#norm:addiw_overflow]#Overflows are ignored and the result is the low
+32 bits of the result sign-extended to 64 bits.# Note, ADDIW _rd, rs1, 0_
+writes the sign extension of the lower 32 bits of register _rs1_ into
+register _rd_ (assembler pseudoinstruction SEXT.W).
+
+include::images/wavedrom/rv64i-slli.edn[]
+[[rv64i-slli]]
+//.RV64I register-immediate (descr ADDIW) instructions
+
+Shifts by a constant are encoded as a specialization of the I-type
+format using the same instruction opcode as RV32I. The operand to be
+shifted is in _rs1_, and the shift amount is encoded in the lower 6 bits
+of the I-immediate field for RV64I. The right shift type is encoded in
+bit 30. SLLI is a logical left shift (zeros are shifted into the lower
+bits); SRLI is a logical right shift (zeros are shifted into the upper
+bits); and SRAI is an arithmetic right shift (the original sign bit is
+copied into the vacated upper bits).
+(((RV64I, SLLI)))
+(((RV64I, SRKIW)))
+(((RV64I, SRLIW)))
+(((RV64I, RV64I-only)))
+
+include::images/wavedrom/rv64i-slliw.edn[]
+[[rv64i-slliw]]
+
+[#norm:slliw_srliw_sraiw_op]#SLLIW, SRLIW, and SRAIW are RV64I-only instructions that are analogously
+defined but operate on 32-bit values and sign-extend their 32-bit
+results to 64 bits.# [#norm:slliw_srliw_sraiw_imm5_rsv]#SLLIW, SRLIW, and SRAIW encodings with
+_imm[5] {ne} 0_ are reserved.#
+
+[NOTE]
+====
+Previously, SLLIW, SRLIW, and SRAIW with _imm[5] {ne} 0_
+were defined to cause illegal-instruction exceptions, whereas now they
+are marked as reserved. This is a backwards-compatible change.
+====
+
+include::images/wavedrom/rv64-lui-auipc.edn[]
+[[rv64_lui-auipc]]
+//.RV64I register-immediate (descr) instructions
+
+LUI (load upper immediate) uses the same opcode as RV32I.
+[#norm:lui_op_rv64i]#LUI places the
+32-bit U-immediate into register _rd_, filling in the lowest 12 bits
+with zeros. The 32-bit result is sign-extended to 64 bits.#
+(((RV64I, LUI)))
+
+AUIPC (add upper immediate to `pc`) uses the same opcode as RV32I. AUIPC
+is used to build `pc`-relative addresses and uses the U-type format.
+[#norm:auipc_op_rv64i]#AUIPC forms a 32-bit offset from the U-immediate, filling in the lowest
+12 bits with zeros, sign-extends the result to 64 bits, adds it to the
+address of the AUIPC instruction, then places the result in register _rd_.#
+
+[NOTE]
+====
+Note that the set of address offsets that can be formed by pairing LUI
+with LD, AUIPC with JALR, etc. in RV64I is
+[−2^31^−2^11^, 2^31^−2^11^−1].
+====
+
+==== Integer Register-Register Operations
+
+//this diagramdoesn't match the tex specification
+include::images/wavedrom/rv64i-int-reg-reg.edn[]
+[[int_reg-reg]]
+//.RV64I integer register-register instructions
+
+[#norm:addw_subw_op]#ADDW and SUBW are RV64I-only instructions that are defined analogously
+to ADD and SUB but operate on 32-bit values and produce signed 32-bit results.#
+[#norm:addw_subw_overflow]#Overflows are ignored, and the low 32-bits of the result is
+sign-extended to 64-bits and written to the destination register.#
+(((RV64I-only, ADDW)))
+(((RV64I-only, SUBW)))
+
+SLL, SRL, and SRA perform logical left, logical right, and arithmetic
+right shifts on the value in register _rs1_ by the shift amount held in
+register _rs2_. [#norm:sll_srl_sra_sh_amt_rv64i]#In RV64I, only the low 6 bits of _rs2_ are considered
+for the shift amount.#
+
+[#norm:sllw_srlw_sraw_op]#SLLW, SRLW, and SRAW are RV64I-only instructions that are analogously
+defined but operate on 32-bit values and sign-extend their 32-bit
+results to 64 bits. The shift amount is given by _rs2[4:0]_.#
+(((RV64I-only, SLLW)))
+(((RV64I-only, SRLW)))
+(((RV64I-only, SRAW)))
+
+=== Load and Store Instructions
+
+RV64I extends the address space to 64 bits. The execution environment
+will define what portions of the address space are legal to access.
+
+include::images/wavedrom/load-store.edn[]
+[[load_store]]
+//.Load and store instructions
+
+[#norm:ld_op_rv64i]#The LD instruction loads a 64-bit value from memory into register _rd_
+for RV64I.#
+(((RV64I, LD)))
+
+[#norm:lw_op_rv64i]#The LW instruction loads a 32-bit value from memory and sign-extends
+this to 64 bits before storing it in register _rd_ for RV64I.#
+[#norm:lwu_op]#The LWU instruction, on the other hand, zero-extends the 32-bit value from
+memory for RV64I.# [#norm:lh_lhu_lb_lbu_op_rv64i]#LH and LHU are defined analogously for 16-bit values,
+as are LB and LBU for 8-bit values.# [#norm:sd_sw_sh_sb_op_rv64i]#The SD, SW, SH, and SB instructions
+store 64-bit, 32-bit, 16-bit, and 8-bit values from the low bits of
+register _rs2_ to memory respectively.#
+
+[[rv64i-hints]]
+=== HINT Instructions
+
+All instructions that are microarchitectural HINTs in RV32I (see
+<<rv32>>) are also HINTs in RV64I.#
+The additional computational instructions in RV64I expand both the
+standard and custom HINT encoding spaces.
+(((RV64I, HINT)))
+
+<<rv64i-h>> lists all RV64I HINT code points. 91% of the
+HINT space is reserved for standard HINTs. The remainder of the HINT
+space is designated for custom HINTs; no standard HINTs will ever be
+defined in this subspace.
+
+[[rv64i-h]]
+.RV64I HINT instructions.
+[float="center",align="center",cols="<,<,^,<", options="header", grid="all"]
+|===
+|Instruction |Constraints |Code Points |Purpose
+|LUI |_rd_=_x0_ |2^20^ .9+.^|_Designated for future standard use_
+
+|AUIPC |_rd_=_x0_ |2^20^
+
+|ADDI |_rd_=_x0_, and either _rs1_≠_x0_ or _imm_≠0 |2^17^−1
+
+|ANDI |_rd_=_x0_ |2^17^
+
+|ORI |_rd_=_x0_ |2^17^
+
+|XORI |_rd_=_x0_ |2^17^
+
+|ADDIW |_rd_=_x0_ |2^17^
+
+|ADD |_rd_=_x0_, _rs1_≠_x0_ |2^10^−32
+
+|ADD |_rd_=_x0_, _rs1_=_x0_, _rs2_≠_x2_-_x5_ | 28
+
+|ADD |_rd_=_x0_, _rs1_=_x0_, _rs2_=_x2_-_x5_| 4 | (_rs2_=_x2_) NTL.P1 +
+ (_rs2_=_x3_) NTL.PALL +
+ (_rs2_=_x4_) NTL.S1 +
+ (_rs2_=_x5_) NTL.ALL
+
+|SLLI |_rd_=`x0`, _rs1_=`x0`, _shamt_=31 |1|Semihosting entry marker
+
+|SRAI |_rd_=`x0`, _rs1_=`x0`, _shamt_=7 |1|Semihosting exit marker
+
+|SUB |_rd_=_x0_ |2^10^ .16+.^| _Designated for future standard use_
+
+|AND |_rd_=_x0_ |2^10^
+
+|OR |_rd_=_x0_ |2^10^
+
+|XOR |_rd_=_x0_ |2^10^
+
+|SLL |_rd_=_x0_ |2^10^
+
+|SRL |_rd_=_x0_ |2^10^
+
+|SRA |_rd_=_x0_ |2^10^
+
+|ADDW |_rd_=_x0_ |2^10^
+
+|SUBW |_rd_=_x0_ |2^10^
+
+|SLLW |_rd_=_x0_ |2^10^
+
+|SRLW |_rd_=_x0_ |2^10^
+
+|SRAW |_rd_=_x0_ |2^10^
+
+|FENCE |_rd_=_x0_, _rs1_≠_x0_,_fm_=0, and either _pred_=0 or _succ_=0 |2^10^−63
+
+|FENCE |_rd_≠_x0_, _rs1_=_x0_, _fm_=0, and either _pred_=0 or _succ_=0 |2^10^−63
+
+|FENCE |_rd_=_rs1_=_x0_, _fm_=0, _pred_=0, _succ_≠0 |15
+
+|FENCE |_pred_=0 or _succ_=0, _pred_≠W, _succ_ =0 | 15
+
+|FENCE |_rd_=_rs1_=_x0_, _fm_=0, _pred_=W, _succ_=0 |1 | PAUSE
+
+|SLTI |_rd_=_x0_ |2^17^ .10+.^|_Designated for custom use_
+
+|SLTIU |_rd_=_x0_ |2^17^
+
+|SLLI |_rd_=`x0`, and either _rs1_{ne}``x0`` or _shamt_{ne}31 |2^11^−1
+
+|SRLI |_rd_=`x0` |2^11^
+
+|SRAI |_rd_=`x0`, and either _rs1_{ne}``x0`` or _shamt_{ne}7 |2^11^−1
+
+|SLLIW |_rd_=_x0_ |2^10^
+
+|SRLIW |_rd_=_x0_ |2^10^
+
+|SRAIW |_rd_=_x0_ |2^10^
+
+|SLT |_rd_=_x0_ |2^10^
+
+|SLTU |_rd_=_x0_ |2^10^
+|===
+
+NOTE: `slli x0, x0, 0x1f` and `srai x0, x0, 7` were previously designated as
+custom HINTs, but they have been appropriated for use in semihosting calls, as
+described in <<ecall-ebreak>>.
+To reflect their usage in practice, the base ISA spec has been changed to
+designate them as standard HINTs.
diff --git a/src/rv64.tex b/src/rv64.tex
deleted file mode 100644
index d9bda29..0000000
--- a/src/rv64.tex
+++ /dev/null
@@ -1,303 +0,0 @@
-\chapter{RV64I Base Integer Instruction Set, Version 2.1}
-\label{rv64}
-
-This chapter describes the RV64I base integer instruction set, which
-builds upon the RV32I variant described in Chapter~\ref{rv32}. This
-chapter presents only the differences with RV32I, so should be read in
-conjunction with the earlier chapter.
-
-\section{Register State}
-
-RV64I widens the integer registers and supported user address space to
-64 bits (XLEN=64 in Figure~\ref{gprs}).
-
-\section{Integer Computational Instructions}
-
-Most integer computational instructions operate on XLEN-bit values.
-Additional instruction variants are provided to manipulate 32-bit
-values in RV64I, indicated by a `W' suffix to the opcode. These
-``*W'' instructions ignore the upper 32 bits of their inputs and
-always produce 32-bit signed values, i.e. bits XLEN-1 through 31 are
-equal.
-
-\begin{commentary}
-The compiler and calling convention maintain an invariant that all 32-bit
-values are held in a sign-extended format in 64-bit registers. Even 32-bit
-unsigned integers extend bit 31 into bits 63 through 32. Consequently,
-conversion between unsigned and signed 32-bit integers is a no-op,
-as is conversion from a signed 32-bit integer to a signed 64-bit
-integer. Existing 64-bit wide SLTU and unsigned branch compares still operate
-correctly on unsigned 32-bit integers under this invariant. Similarly,
-existing 64-bit wide logical operations on 32-bit sign-extended integers
-preserve the sign-extension property. A few new instructions
-(ADD[I]W/SUBW/SxxW) are required for addition and shifts to ensure reasonable
-performance for 32-bit values.
-\end{commentary}
-
-\newpage
-\subsubsection*{Integer Register-Immediate Instructions}
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{M@{}R@{}S@{}R@{}O}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-I-immediate[11:0] & src & ADDIW & dest & OP-IMM-32 \\
-\end{tabular}
-\end{center}
-
-ADDIW is an RV64I instruction that adds the sign-extended 12-bit
-immediate to register {\em rs1} and produces the proper sign-extension
-of a 32-bit result in {\em rd}. Overflows are ignored and the result
-is the low 32 bits of the result sign-extended to 64 bits. Note,
-ADDIW {\em rd, rs1, 0} writes the sign-extension of the lower 32 bits
-of register {\em rs1} into register {\em rd} (assembler pseudoinstruction
-SEXT.W).
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{R@{}W@{}R@{}R@{}R@{}R@{}O}
-\\
-\instbitrange{31}{26} &
-\multicolumn{1}{c}{\instbit{25}} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:6]} &
-\multicolumn{1}{|c|}{imm[5]} &
-\multicolumn{1}{|c|}{imm[4:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-6 & \multicolumn{1}{c}{1} & 5 & 5 & 3 & 5 & 7 \\
-000000 & shamt[5] & shamt[4:0] & src & SLLI & dest & OP-IMM \\
-000000 & shamt[5] & shamt[4:0] & src & SRLI & dest & OP-IMM \\
-010000 & shamt[5] & shamt[4:0] & src & SRAI & dest & OP-IMM \\
-000000 & 0 & shamt[4:0] & src & SLLIW & dest & OP-IMM-32 \\
-000000 & 0 & shamt[4:0] & src & SRLIW & dest & OP-IMM-32 \\
-010000 & 0 & shamt[4:0] & src & SRAIW & dest & OP-IMM-32 \\
-\end{tabular}
-\end{center}
-
-Shifts by a constant are encoded as a specialization of the I-type
-format using the same instruction opcode as RV32I. The operand to be
-shifted is in {\em rs1}, and the shift amount is encoded in the lower
-6 bits of the I-immediate field for RV64I. The right shift type is
-encoded in bit 30. SLLI is a logical left shift (zeros are shifted
-into the lower bits); SRLI is a logical right shift (zeros are shifted
-into the upper bits); and SRAI is an arithmetic right shift (the
-original sign bit is copied into the vacated upper bits).
-
-SLLIW, SRLIW, and SRAIW are RV64I-only instructions that are
-analogously defined but operate on 32-bit values and produce
-signed 32-bit results. SLLIW, SRLIW, and SRAIW encodings
-with $imm[5] \neq 0$ are reserved.
-
-\begin{commentary}
- Previously, SLLIW, SRLIW, and SRAIW with imm[5]=0 were defined to
- cause illegal instruction exceptions, whereas now they are marked as
- reserved. This is a backwards-compatible change.
-\end{commentary}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{U@{}R@{}O}
-\\
-\instbitrange{31}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[31:12]} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-20 & 5 & 7 \\
-U-immediate[31:12] & dest & LUI \\
-U-immediate[31:12] & dest & AUIPC
-\end{tabular}
-\end{center}
-
-LUI (load upper immediate) uses the same opcode as RV32I. LUI places
-the 20-bit U-immediate into bits 31--12 of register {\em rd} and
-places zero in the lowest 12 bits. The 32-bit result is
-sign-extended to 64 bits.
-
-AUIPC (add upper immediate to {\tt pc}) uses the same opcode as RV32I.
-AUIPC (add upper immediate to {\tt pc}) is used to build {\tt
- pc}-relative addresses and uses the U-type format. AUIPC appends 12
-low-order zero bits to the 20-bit U-immediate, sign-extends the result
-to 64 bits, then adds it to the {\tt pc} and places the result in
-register {\em rd}.
-
-\subsubsection*{Integer Register-Register Operations}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{S@{}R@{}R@{}S@{}R@{}O}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct7} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-0000000 & src2 & src1 & SLL/SRL & dest & OP \\
-0100000 & src2 & src1 & SRA & dest & OP \\
-0000000 & src2 & src1 & ADDW & dest & OP-32 \\
-0000000 & src2 & src1 & SLLW/SRLW & dest & OP-32 \\
-0100000 & src2 & src1 & SUBW/SRAW & dest & OP-32 \\
-\end{tabular}
-\end{center}
-
-ADDW and SUBW are RV64I-only instructions that are defined analogously
-to ADD and SUB but operate on 32-bit values and produce signed 32-bit
-results. Overflows are ignored, and the low 32-bits of the result is
-sign-extended to 64-bits and written to the destination register.
-
-SLL, SRL, and SRA perform logical left, logical right, and arithmetic
-right shifts on the value in register {\em rs1} by the shift amount
-held in register {\em rs2}. In RV64I, only the low 6 bits of {\em
- rs2} are considered for the shift amount.
-
-SLLW, SRLW, and SRAW are RV64I-only instructions that are analogously
-defined but operate on 32-bit values and produce signed 32-bit
-results. The shift amount is given by {\em rs2[4:0]}.
-
-\section{Load and Store Instructions}
-
-RV64I extends the address space to 64 bits. The execution environment
-will define what portions of the address space are legal to access.
-
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{M@{}R@{}S@{}R@{}O}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-offset[11:0] & base & width & dest & LOAD \\
-\end{tabular}
-\end{center}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{O@{}R@{}R@{}S@{}R@{}O}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:5]} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-offset[11:5] & src & base & width & offset[4:0] & STORE \\
-\end{tabular}
-\end{center}
-
-The LD instruction loads a 64-bit value from memory into register {\em
- rd} for RV64I.
-
-The LW instruction loads a 32-bit value from memory and sign-extends
-this to 64 bits before storing it in register {\em rd} for RV64I. The
-LWU instruction, on the other hand, zero-extends the 32-bit value from
-memory for RV64I. LH and LHU are defined analogously for 16-bit
-values, as are LB and LBU for 8-bit values. The SD, SW, SH, and SB
-instructions store 64-bit, 32-bit, 16-bit, and 8-bit values from the
-low bits of register {\em rs2} to memory respectively.
-
-\section{HINT Instructions}
-\label{sec:rv64i-hints}
-
-All instructions that are microarchitectural HINTs in RV32I (see
-Section~\ref{sec:rv32i-hints}) are also HINTs in RV64I. The
-additional computational instructions in RV64I expand both the standard and
-custom HINT encoding spaces.
-
-Table~\ref{tab:rv64i-hints} lists all RV64I HINT code points. 91\% of the HINT
-space is reserved for standard HINTs, but none are presently defined. The
-remainder of the HINT space is reserved for custom HINTs: no standard HINTs
-will ever be defined in this subspace.
-
-\begin{table}[hbt]
-\centering
-\begin{tabular}{|l|l|c|l|}
- \hline
- Instruction & Constraints & Code Points & Purpose \\ \hline \hline
- LUI & {\em rd}={\tt x0} & $2^{20}$ & \multirow{21}{*}{\em Reserved for future standard use} \\ \cline{1-3}
- AUIPC & {\em rd}={\tt x0} & $2^{20}$ & \\ \cline{1-3}
- \multirow{2}{*}{ADDI} & {\em rd}={\tt x0}, and either & \multirow{2}{*}{$2^{17}-1$} & \\
- & {\em rs1}$\neq${\tt x0} or {\em imm}$\neq$0 & & \\ \cline{1-3}
- ANDI & {\em rd}={\tt x0} & $2^{17}$ & \\ \cline{1-3}
- ORI & {\em rd}={\tt x0} & $2^{17}$ & \\ \cline{1-3}
- XORI & {\em rd}={\tt x0} & $2^{17}$ & \\ \cline{1-3}
- ADDIW & {\em rd}={\tt x0} & $2^{17}$ & \\ \cline{1-3}
- ADD & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SUB & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- AND & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- OR & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- XOR & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SLL & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SRL & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SRA & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- ADDW & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SUBW & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SLLW & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SRLW & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SRAW & {\em rd}={\tt x0} & $2^{10}$ & \\ \hline \hline
- SLTI & {\em rd}={\tt x0} & $2^{17}$ & \multirow{10}{*}{\em Reserved for custom use} \\ \cline{1-3}
- SLTIU & {\em rd}={\tt x0} & $2^{17}$ & \\ \cline{1-3}
- SLLI & {\em rd}={\tt x0} & $2^{11}$ & \\ \cline{1-3}
- SRLI & {\em rd}={\tt x0} & $2^{11}$ & \\ \cline{1-3}
- SRAI & {\em rd}={\tt x0} & $2^{11}$ & \\ \cline{1-3}
- SLLIW & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SRLIW & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SRAIW & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SLT & {\em rd}={\tt x0} & $2^{10}$ & \\ \cline{1-3}
- SLTU & {\em rd}={\tt x0} & $2^{10}$ & \\ \hline
-\end{tabular}
-\caption{RV64I HINT instructions.}
-\label{tab:rv64i-hints}
-\end{table}
diff --git a/src/rvc-instr-table.tex b/src/rvc-instr-table.tex
deleted file mode 100644
index ce7f6c5..0000000
--- a/src/rvc-instr-table.tex
+++ /dev/null
@@ -1,537 +0,0 @@
-
-\begin{table}[h]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}l}
-& & & & & & & & & & \\
- &
-\instbit{15} &
-\instbit{14} &
-\instbit{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbit{11} &
-\instbit{10} &
-\instbit{9} &
-\instbit{8} &
-\instbit{7} &
-\instbit{6} &
-\multicolumn{1}{c}{\instbit{5}} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\cline{2-17}
-
-
-&
-\multicolumn{3}{|c|}{000} &
-\multicolumn{8}{c|}{0} &
-\multicolumn{3}{c|}{0} &
-\multicolumn{2}{c|}{00} & {\em Illegal instruction} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{000} &
-\multicolumn{8}{c|}{nzuimm[5:4$\vert$9:6$\vert$2$\vert$3]} &
-\multicolumn{3}{c|}{rd$'$} &
-\multicolumn{2}{c|}{00} & C.ADDI4SPN {\em \tiny (RES, nzuimm=0)} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{001} &
-\multicolumn{3}{c|}{uimm[5:3]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{uimm[7:6]} &
-\multicolumn{3}{c|}{rd$'$} &
-\multicolumn{2}{c|}{00} & C.FLD {\em \tiny (RV32/64)}\\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{001} &
-\multicolumn{3}{c|}{uimm[5:4$\vert$8]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{uimm[7:6]} &
-\multicolumn{3}{c|}{rd$'$} &
-\multicolumn{2}{c|}{00} & C.LQ {\em \tiny (RV128)}\\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{010} &
-\multicolumn{3}{c|}{uimm[5:3]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{uimm[2$\vert$6]} &
-\multicolumn{3}{c|}{rd$'$} &
-\multicolumn{2}{c|}{00} & C.LW \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{011} &
-\multicolumn{3}{c|}{uimm[5:3]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{uimm[2$\vert$6]} &
-\multicolumn{3}{c|}{rd$'$} &
-\multicolumn{2}{c|}{00} & C.FLW {\em \tiny (RV32)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{011} &
-\multicolumn{3}{c|}{uimm[5:3]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{uimm[7:6]} &
-\multicolumn{3}{c|}{rd$'$} &
-\multicolumn{2}{c|}{00} & C.LD {\em \tiny (RV64/128)}\\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{11}{c|}{---} &
-\multicolumn{2}{c|}{00} & {\em Reserved} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{101} &
-\multicolumn{3}{c|}{uimm[5:3]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{uimm[7:6]} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{00} & C.FSD {\em \tiny (RV32/64)}\\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{101} &
-\multicolumn{3}{c|}{uimm[5:4$\vert$8]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{uimm[7:6]} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{00} & C.SQ {\em \tiny (RV128)}\\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{110} &
-\multicolumn{3}{c|}{uimm[5:3]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{uimm[2$\vert$6]} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{00} & C.SW \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{111} &
-\multicolumn{3}{c|}{uimm[5:3]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{uimm[2$\vert$6]} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{00} & C.FSW {\em \tiny (RV32)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{111} &
-\multicolumn{3}{c|}{uimm[5:3]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{2}{c|}{uimm[7:6]} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{00} & C.SD {\em \tiny (RV64/128)}\\
-\cline{2-17}
-
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Instruction listing for RVC, Quadrant 0.}
-\label{rvc-instr-table0}
-\end{table}
-
-\begin{table}[h]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}l}
-& & & & & & & & & & \\
- &
-\instbit{15} &
-\instbit{14} &
-\instbit{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbit{11} &
-\instbit{10} &
-\instbit{9} &
-\instbit{8} &
-\instbit{7} &
-\instbit{6} &
-\multicolumn{1}{c}{\instbit{5}} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{000} &
-\multicolumn{1}{c|}{nzimm[5]} &
-\multicolumn{5}{c|}{0} &
-\multicolumn{5}{c|}{nzimm[4:0]} &
-\multicolumn{2}{c|}{01} & C.NOP {\em \tiny (HINT, nzimm$\neq$0) } \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{000} &
-\multicolumn{1}{c|}{nzimm[5]} &
-\multicolumn{5}{c|}{rs1/rd$\neq$0} &
-\multicolumn{5}{c|}{nzimm[4:0]} &
-\multicolumn{2}{c|}{01} & C.ADDI {\em \tiny (HINT, nzimm=0)} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{001} &
-\multicolumn{11}{c|}{imm[11$\vert$4$\vert$9:8$\vert$10$\vert$6$\vert$7$\vert$3:1$\vert$5]} &
-\multicolumn{2}{c|}{01} & C.JAL {\em \tiny (RV32)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{001} &
-\multicolumn{1}{c|}{imm[5]} &
-\multicolumn{5}{c|}{rs1/rd$\neq$0} &
-\multicolumn{5}{c|}{imm[4:0]} &
-\multicolumn{2}{c|}{01} & C.ADDIW {\em \tiny (RV64/128; RES, rd=0)} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{010} &
-\multicolumn{1}{c|}{imm[5]} &
-\multicolumn{5}{c|}{rd$\neq$0} &
-\multicolumn{5}{c|}{imm[4:0]} &
-\multicolumn{2}{c|}{01} & C.LI {\em \tiny (HINT, rd=0)} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{011} &
-\multicolumn{1}{c|}{nzimm[9]} &
-\multicolumn{5}{c|}{2} &
-\multicolumn{5}{c|}{nzimm[4$\vert$6$\vert$8:7$\vert$5]} &
-\multicolumn{2}{c|}{01} & C.ADDI16SP {\em \tiny (RES, nzimm=0)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{011} &
-\multicolumn{1}{c|}{nzimm[17]} &
-\multicolumn{5}{c|}{rd$\neq$$\{0,2\}$} &
-\multicolumn{5}{c|}{nzimm[16:12]} &
-\multicolumn{2}{c|}{01} & C.LUI {\em \tiny (RES, nzimm=0; HINT, rd=0)}\\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{nzuimm[5]} &
-\multicolumn{2}{c|}{00} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{5}{c|}{nzuimm[4:0]} &
-\multicolumn{2}{c|}{01} & C.SRLI {\em \tiny (RV32 NSE, nzuimm[5]=1)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{2}{c|}{00} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{5}{c|}{0} &
-\multicolumn{2}{c|}{01} & C.SRLI64 {\em \tiny (RV128; RV32/64 HINT)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{nzuimm[5]} &
-\multicolumn{2}{c|}{01} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{5}{c|}{nzuimm[4:0]} &
-\multicolumn{2}{c|}{01} & C.SRAI {\em \tiny (RV32 NSE, nzuimm[5]=1)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{2}{c|}{01} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{5}{c|}{0} &
-\multicolumn{2}{c|}{01} & C.SRAI64 {\em \tiny (RV128; RV32/64 HINT)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{imm[5]} &
-\multicolumn{2}{c|}{10} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{5}{c|}{imm[4:0]} &
-\multicolumn{2}{c|}{01} & C.ANDI \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{2}{c|}{11} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{2}{c|}{00} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{01} & C.SUB \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{2}{c|}{11} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{2}{c|}{01} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{01} & C.XOR \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{2}{c|}{11} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{2}{c|}{10} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{01} & C.OR \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{2}{c|}{11} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{2}{c|}{11} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{01} & C.AND \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{2}{c|}{11} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{2}{c|}{00} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{01} & C.SUBW {\em \tiny (RV64/128; RV32 RES)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{2}{c|}{11} &
-\multicolumn{3}{c|}{rs1$'$/rd$'$} &
-\multicolumn{2}{c|}{01} &
-\multicolumn{3}{c|}{rs2$'$} &
-\multicolumn{2}{c|}{01} & C.ADDW {\em \tiny (RV64/128; RV32 RES)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{2}{c|}{11} &
-\multicolumn{3}{c|}{---} &
-\multicolumn{2}{c|}{10} &
-\multicolumn{3}{c|}{---} &
-\multicolumn{2}{c|}{01} & {\em Reserved} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{2}{c|}{11} &
-\multicolumn{3}{c|}{---} &
-\multicolumn{2}{c|}{11} &
-\multicolumn{3}{c|}{---} &
-\multicolumn{2}{c|}{01} & {\em Reserved} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{101} &
-\multicolumn{11}{c|}{imm[11$\vert$4$\vert$9:8$\vert$10$\vert$6$\vert$7$\vert$3:1$\vert$5]} &
-\multicolumn{2}{c|}{01} & C.J \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{110} &
-\multicolumn{3}{c|}{imm[8$\vert$4:3]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{5}{c|}{imm[7:6$\vert$2:1$\vert$5]} &
-\multicolumn{2}{c|}{01} & C.BEQZ \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{111} &
-\multicolumn{3}{c|}{imm[8$\vert$4:3]} &
-\multicolumn{3}{c|}{rs1$'$} &
-\multicolumn{5}{c|}{imm[7:6$\vert$2:1$\vert$5]} &
-\multicolumn{2}{c|}{01} & C.BNEZ \\
-\cline{2-17}
-
-
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Instruction listing for RVC, Quadrant 1.}
-\label{rvc-instr-table1}
-\end{table}
-
-\begin{table}[h]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}p{0.05in}l}
-& & & & & & & & & & \\
- &
-\instbit{15} &
-\instbit{14} &
-\instbit{13} &
-\multicolumn{1}{c}{\instbit{12}} &
-\instbit{11} &
-\instbit{10} &
-\instbit{9} &
-\instbit{8} &
-\instbit{7} &
-\instbit{6} &
-\multicolumn{1}{c}{\instbit{5}} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{000} &
-\multicolumn{1}{c|}{nzuimm[5]} &
-\multicolumn{5}{c|}{rs1/rd$\neq$0} &
-\multicolumn{5}{c|}{nzuimm[4:0]} &
-\multicolumn{2}{c|}{10} & C.SLLI {\em \tiny (HINT, rd=0; RV32 NSE, nzuimm[5]=1)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{000} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{5}{c|}{rs1/rd$\neq$0} &
-\multicolumn{5}{c|}{0} &
-\multicolumn{2}{c|}{10} & C.SLLI64 {\em \tiny (RV128; RV32/64 HINT; HINT, rd=0)} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{001} &
-\multicolumn{1}{c|}{uimm[5]} &
-\multicolumn{5}{c|}{rd} &
-\multicolumn{5}{c|}{uimm[4:3$\vert$8:6]} &
-\multicolumn{2}{c|}{10} & C.FLDSP {\em \tiny (RV32/64)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{001} &
-\multicolumn{1}{c|}{uimm[5]} &
-\multicolumn{5}{c|}{rd$\neq$0} &
-\multicolumn{5}{c|}{uimm[4$\vert$9:6]} &
-\multicolumn{2}{c|}{10} & C.LQSP {\em \tiny (RV128; RES, rd=0)} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{010} &
-\multicolumn{1}{c|}{uimm[5]} &
-\multicolumn{5}{c|}{rd$\neq$0} &
-\multicolumn{5}{c|}{uimm[4:2$\vert$7:6]} &
-\multicolumn{2}{c|}{10} & C.LWSP {\em \tiny (RES, rd=0)} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{011} &
-\multicolumn{1}{c|}{uimm[5]} &
-\multicolumn{5}{c|}{rd} &
-\multicolumn{5}{c|}{uimm[4:2$\vert$7:6]} &
-\multicolumn{2}{c|}{10} & C.FLWSP {\em \tiny (RV32)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{011} &
-\multicolumn{1}{c|}{uimm[5]} &
-\multicolumn{5}{c|}{rd$\neq$0} &
-\multicolumn{5}{c|}{uimm[4:3$\vert$8:6]} &
-\multicolumn{2}{c|}{10} & C.LDSP {\em \tiny (RV64/128; RES, rd=0)} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{5}{c|}{rs1$\neq$0} &
-\multicolumn{5}{c|}{0} &
-\multicolumn{2}{c|}{10} & C.JR {\em \tiny (RES, rs1=0)}\\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{5}{c|}{rd$\neq$0} &
-\multicolumn{5}{c|}{rs2$\neq$0} &
-\multicolumn{2}{c|}{10} & C.MV {\em \tiny (HINT, rd=0)}\\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{5}{c|}{0} &
-\multicolumn{5}{c|}{0} &
-\multicolumn{2}{c|}{10} & C.EBREAK \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{5}{c|}{rs1$\neq$0} &
-\multicolumn{5}{c|}{0} &
-\multicolumn{2}{c|}{10} & C.JALR \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{100} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{5}{c|}{rs1/rd$\neq$0} &
-\multicolumn{5}{c|}{rs2$\neq$0} &
-\multicolumn{2}{c|}{10} & C.ADD {\em \tiny (HINT, rd=0)} \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{101} &
-\multicolumn{6}{c|}{uimm[5:3$\vert$8:6]} &
-\multicolumn{5}{c|}{rs2} &
-\multicolumn{2}{c|}{10} & C.FSDSP {\em \tiny (RV32/64)}\\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{101} &
-\multicolumn{6}{c|}{uimm[5:4$\vert$9:6]} &
-\multicolumn{5}{c|}{rs2} &
-\multicolumn{2}{c|}{10} & C.SQSP {\em \tiny (RV128)}\\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{110} &
-\multicolumn{6}{c|}{uimm[5:2$\vert$7:6]} &
-\multicolumn{5}{c|}{rs2} &
-\multicolumn{2}{c|}{10} & C.SWSP \\
-\whline{2-17}
-
-&
-\multicolumn{3}{|c|}{111} &
-\multicolumn{6}{c|}{uimm[5:2$\vert$7:6]} &
-\multicolumn{5}{c|}{rs2} &
-\multicolumn{2}{c|}{10} & C.FSWSP {\em \tiny (RV32)} \\
-\cline{2-17}
-
-&
-\multicolumn{3}{|c|}{111} &
-\multicolumn{6}{c|}{uimm[5:3$\vert$8:6]} &
-\multicolumn{5}{c|}{rs2} &
-\multicolumn{2}{c|}{10} & C.SDSP {\em \tiny (RV64/128)}\\
-\cline{2-17}
-
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Instruction listing for RVC, Quadrant 2.}
-\label{rvc-instr-table2}
-\end{table}
diff --git a/src/rvc-opcode-map.tex b/src/rvc-opcode-map.tex
deleted file mode 100644
index 087c6fa..0000000
--- a/src/rvc-opcode-map.tex
+++ /dev/null
@@ -1,27 +0,0 @@
-\vspace{0.1in}
-\definecolor{gray}{RGB}{180,180,180}
-\begin{table*}[htbp]
-\begin{center}
-{\footnotesize
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{|r|c|c|c|c|c|c|c|c|l}
- \cline{1-9}
- inst[15:13] & \multirow{2}{*}{000}& \multirow{2}{*}{001}& \multirow{2}{*}{010}& \multirow{2}{*}{011}& \multirow{2}{*}{100}& \multirow{2}{*}{101}& \multirow{2}{*}{110}& \multirow{2}{*}{111}\\ \cline{1-1}
- inst[1:0] & & & & & & & & \\ \cline{1-9}
- \multirow{3}{*}{00} & \multirow{3}{*}{ADDI4SPN} & FLD & \multirow{3}{*}{LW} & FLW & \multirow{3}{*}{\em Reserved} & FSD & \multirow{3}{*}{SW} & FSW & RV32 \\
- & & FLD & & LD & & FSD & & SD & RV64 \\
- & & LQ & & LD & & SQ & & SD & RV128 \\ \hline
- \multirow{3}{*}{01} & \multirow{3}{*}{ADDI} & JAL & \multirow{3}{*}{LI} & \multirow{3}{*}{LUI/ADDI16SP} & \multirow{3}{*}{MISC-ALU} & \multirow{3}{*}{J} & \multirow{3}{*}{BEQZ} & \multirow{3}{*}{BNEZ} & RV32 \\
- & & ADDIW & & & & & & & RV64 \\
- & & ADDIW & & & & & & & RV128 \\ \hline
- \multirow{3}{*}{10} & \multirow{3}{*}{SLLI} & FLDSP & \multirow{3}{*}{LWSP} & FLWSP & \multirow{3}{*}{J[AL]R/MV/ADD} & FSDSP & \multirow{3}{*}{SWSP} & FSWSP & RV32 \\
- & & FLDSP & & LDSP & & FSDSP & & SDSP & RV64 \\
- & & LQSP & & LDSP & & SQSP & & SDSP & RV128 \\ \cline{1-9}
- \cellcolor{gray} 11 & \multicolumn{8}{c|}{\cellcolor{gray} $>$16b} \\ \cline{1-9}
- \end{tabular}
-}
-\end{center}
-\vspace{-0.15in}
-\caption{RVC opcode map}
-\label{rvcopcodemap}
-\end{table*}
diff --git a/src/rvwmo.adoc b/src/rvwmo.adoc
new file mode 100644
index 0000000..deea986
--- /dev/null
+++ b/src/rvwmo.adoc
@@ -0,0 +1,815 @@
+[[memorymodel]]
+== RVWMO Memory Consistency Model, Version 2.0
+
+This chapter defines the RISC-V memory consistency model. A memory
+consistency model is a set of rules specifying the values that can be
+returned by loads of memory. RISC-V uses a memory model called "RVWMO"
+(RISC-V Weak Memory Ordering) which is designed to provide flexibility
+for architects to build high-performance scalable designs while
+simultaneously supporting a tractable programming model.
+(((design, high performance)))
+(((design, scalable)))
+
+Under RVWMO, code running on a single hart appears to execute in order
+from the perspective of other memory instructions in the same hart, but
+memory instructions from another hart may observe the memory
+instructions from the first hart being executed in a different order.
+Therefore, multithreaded code may require explicit synchronization to
+guarantee ordering between memory instructions from different harts. The
+base RISC-V ISA provides a FENCE instruction for this purpose, described
+in <<fence>>, while the atomics extension "A" additionally defines load-reserved/store-conditional and atomic read-modify-write instructions.
+(((atomics, misaligned)))
+
+The standard ISA extension for total store ordering "Ztso" (<<ztso>>) augments
+RVWMO with additional rules specific to those extensions.
+
+The appendices to this specification provide both axiomatic and
+operational formalizations of the memory consistency model as well as
+additional explanatory material.
+(((FENCE)))
+(((SFENCE)))
+
+[NOTE]
+====
+This chapter defines the memory model for regular main memory
+operations. The interaction of the memory model with I/O memory,
+instruction fetches, FENCE.I, page-table walks, and SFENCE.VMA is not
+(yet) formalized. Some or all of the above may be formalized in a future
+revision of this specification. Future ISA
+extensions such as the V vector and J JIT extensions will need
+to be incorporated into a future revision as well.
+
+Memory consistency models supporting overlapping memory accesses of
+different widths simultaneously remain an active area of academic
+research and are not yet fully understood. The specifics of how memory
+accesses of different sizes interact under RVWMO are specified to the
+best of our current abilities, but they are subject to revision should
+new issues be uncovered.
+====
+
+[[rvwmo]]
+=== Definition of the RVWMO Memory Model
+
+The RVWMO memory model is defined in terms of the _global memory order_,
+a total ordering of the memory operations produced by all harts. In
+general, a multithreaded program has many different possible executions,
+with each execution having its own corresponding global memory order.
+(((RVWMO)))
+
+The global memory order is defined over the primitive load and store
+operations generated by memory instructions. It is then subject to the
+constraints defined in the rest of this chapter. Any execution
+satisfying all of the memory model constraints is a legal execution (as
+far as the memory model is concerned).
+
+[[rvwmo-primitives]]
+==== Memory Model Primitives
+
+The _program order_ over memory operations reflects the order in which
+the instructions that generate each load and store are logically laid
+out in that hart's dynamic instruction stream; i.e., the order in which
+a simple in-order processor would execute the instructions of that hart.
+
+Memory-accessing instructions give rise to _memory operations_. A memory
+operation can be either a _load operation_, a _store operation_, or both
+simultaneously. All memory operations are single-copy atomic: they can
+never be observed in a partially complete state.
+(((operations, memory)))
+
+Among instructions in RV32GC and RV64GC, each aligned memory instruction
+gives rise to exactly one memory operation, with two exceptions. First,
+an unsuccessful SC instruction does not give rise to any memory
+operations.
+Second, floating-point load and store instructions of more than XLEN bits
+(e.g. FLD/FSD in RV32) may each give rise to multiple memory operations.
+An aligned AMO
+gives rise to a single memory operation that is both a load operation
+and a store operation simultaneously.
+
+[NOTE]
+====
+Future ISA
+extensions such as *V* (vector) and *P* (SIMD) may give rise to multiple
+memory operations. However, the memory model for these extensions has
+not yet been formalized.
+====
+
+A misaligned load or store instruction may be decomposed into a set of
+component memory operations of any granularity.
+A floating-point load or store of more than XLEN bits may also be decomposed
+into a set of component memory operations of any granularity.
+The memory
+operations generated by such instructions are not ordered with respect
+to each other in program order, but they are ordered normally with
+respect to the memory operations generated by preceding and subsequent
+instructions in program order.
+The atomics extension "A" does not require execution environments to support
+misaligned atomic instructions at all.
+However, if misaligned atomics are supported via the misaligned atomicity
+granule PMA, then AMOs within an atomicity granule are not decomposed, nor are
+loads and stores defined in the base ISAs, nor are loads and stores of no more
+than XLEN bits defined in the F, D, and Q extensions.
+(((decomposition)))
+
+[NOTE]
+====
+The decomposition of misaligned memory operations down to byte
+granularity facilitates emulation on implementations that do not
+natively support misaligned accesses. Such implementations might, for
+example, simply iterate over the bytes of a misaligned access one by
+one.
+====
+
+An LR instruction and an SC instruction are said to be _paired_ if the
+LR precedes the SC in program order and if there are no other LR or SC
+instructions in between; the corresponding memory operations are said to
+be paired as well (except in case of a failed SC, where no store
+operation is generated). The complete list of conditions determining
+whether an SC must succeed, may succeed, or must fail is defined in
+<<sec:lrsc>>.
+
+Load and store operations may also carry one or more ordering
+annotations from the following set: "acquire-RCpc", "acquire-RCsc",
+"release-RCpc", and "release-RCsc". An AMO or LR instruction with
+_aq_ set has an "acquire-RCsc" annotation. An AMO or SC instruction
+with _rl_ set has a "release-RCsc" annotation. An AMO, LR, or SC
+instruction with both _aq_ and _rl_ set has both "acquire-RCsc" and
+"release-RCsc" annotations.
+
+For convenience, we use the term "acquire annotation" to refer to an
+acquire-RCpc annotation or an acquire-RCsc annotation. Likewise, a
+"release annotation" refers to a release-RCpc annotation or a
+release-RCsc annotation. An "RCpc annotation" refers to an
+acquire-RCpc annotation or a release-RCpc annotation. An _RCsc
+annotation_ refers to an acquire-RCsc annotation or a release-RCsc
+annotation.
+
+[NOTE]
+====
+In the memory model literature, the term "RCpc" stands for release
+consistency with processor-consistent synchronization operations, and
+the term "RCsc" stands for release consistency with sequentially
+consistent synchronization operations.
+
+While there are many different definitions for acquire and release
+annotations in the literature, in the context of RVWMO these terms are
+concisely and completely defined by <<ppo, Preserved Program Order>> rules 5-7.
+
+"RCpc" annotations are currently only used when implicitly assigned to
+every memory access per the standard extension "Ztso"
+(<<ztso>>). Furthermore, although the ISA does not
+currently contain native load-acquire or store-release instructions, nor
+RCpc variants thereof, the RVWMO model itself is designed to be
+forwards-compatible with the potential addition of any or all of the
+above into the ISA in a future extension.
+====
+
+[[mem-dependencies]]
+==== Syntactic Dependencies
+
+The definition of the RVWMO memory model depends in part on the notion
+of a syntactic dependency, defined as follows.
+
+In the context of defining dependencies, a _register_ refers either to
+an entire general-purpose register, some portion of a CSR, or an entire
+CSR. The granularity at which dependencies are tracked through CSRs is
+specific to each CSR and is defined in
+<<csr-granularity>>.
+
+Syntactic dependencies are defined in terms of instructions' _source
+registers_, instructions' _destination registers_, and the way
+instructions _carry a dependency_ from their source registers to their
+destination registers. This section provides a general definition of all
+of these terms; however, <<source-dest-regs>> provides a
+complete listing of the specifics for each instruction.
+
+In general, a register _r_ other than `x0` is a _source
+register_ for an instruction _i_ if any of the following
+hold:
+
+* In the opcode of _i_, _rs1_, _rs2_, or _rs3_ is set to
+_r_
+* _i_ is a CSR instruction, and in the opcode of
+_i_, _csr_ is set to _r_, unless _i_
+is CSRRW or CSRRWI and _rd_ is set to `x0`
+* _r_ is a CSR and an implicit source register for
+_i_, as defined in <<source-dest-regs>>
+* _r_ is a CSR that aliases with another source register for
+_i_
+
+Memory instructions also further specify which source registers are
+_address source registers_ and which are _data source registers_.
+
+In general, a register _r_ other than `x0` is a _destination
+register_ for an instruction _i_ if any of the following
+hold:
+
+* In the opcode of _i_, _rd_ is set to _r_
+* _i_ is a CSR instruction, and in the opcode of
+_i_, _csr_ is set to _r_, unless _i_
+is CSRRS or CSRRC and _rs1_ is set to `x0` or _i_ is CSRRSI
+or CSRRCI and uimm[4:0] is set to zero.
+* _r_ is a CSR and an implicit destination register for
+_i_, as defined in <<source-dest-regs>>
+* _r_ is a CSR that aliases with another destination
+register for _i_
+
+Most non-memory instructions _carry a dependency_ from each of their
+source registers to each of their destination registers. However, there
+are exceptions to this rule; see <<source-dest-regs>>.
+
+Instruction _j_ has a _syntactic dependency_ on instruction
+_i_ via destination register _s_ of
+_i_ and source register _r_ of _j_
+if either of the following hold:
+
+* _s_ is the same as _r_, and no instruction
+program-ordered between _i_ and _j_ has
+_r_ as a destination register
+* There is an instruction _m_ program-ordered between
+_i_ and _j_ such that all of the following hold:
+. _j_ has a syntactic dependency on _m_ via
+destination register _q_ and source register _r_
+. _m_ has a syntactic dependency on _i_ via
+destination register _s_ and source register _p_
+. _m_ carries a dependency from _p_ to
+_q_
+
+Finally, in the definitions that follow, let _a_ and
+_b_ be two memory operations, and let _i_ and
+_j_ be the instructions that generate _a_ and
+_b_, respectively.
+
+_b_ has a _syntactic address dependency_ on _a_
+if _r_ is an address source register for _j_ and
+_j_ has a syntactic dependency on _i_ via source
+register _r_
+
+_b_ has a _syntactic data dependency_ on _a_ if
+_b_ is a store operation, _r_ is a data source
+register for _j_, and _j_ has a syntactic
+dependency on _i_ via source register _r_
+
+_b_ has a _syntactic control dependency_ on _a_
+if there is an instruction _m_ program-ordered between
+_i_ and _j_ such that _m_ is a
+branch or indirect jump and _m_ has a syntactic dependency
+on _i_.
+
+[NOTE]
+====
+Generally speaking, non-AMO load instructions do not have data source
+registers, and unconditional non-AMO store instructions do not have
+destination registers. However, a successful SC instruction is
+considered to have the register specified in _rd_ as a destination
+register, and hence it is possible for an instruction to have a
+syntactic dependency on a successful SC instruction that precedes it in
+program order.
+====
+
+==== Preserved Program Order
+[[ppo]]
+The global memory order for any given execution of a program respects
+some but not all of each hart’s program order. The subset of program
+order that must be respected by the global memory order is known as
+_preserved program order_.
+
+The complete definition of preserved program order is as follows (and
+note that AMOs are simultaneously both loads and stores): memory
+operation _a_ precedes memory operation _b_ in
+preserved program order (and hence also in the global memory order) if
+_a_ precedes _b_ in program order,
+_a_ and _b_ both access regular main memory
+(rather than I/O regions), and any of the following hold:
+
+[[overlapping-ordering]]
+* Overlapping-Address Orderings:
+. _b_ is a store, and
+_a_ and _b_ access overlapping memory addresses
+. _a_ and _b_ are loads,
+_x_ is a byte read by both _a_ and
+_b_, there is no store to _x_ between
+_a_ and _b_ in program order, and
+_a_ and _b_ return values for _x_
+written by different memory operations
+. _a_ is
+generated by an AMO or SC instruction, _b_ is a load, and
+_b_ returns a value written by _a_
+* Explicit Synchronization
+[start=4]
+. There is a FENCE instruction that
+orders _a_ before _b_
+. _a_ has an acquire
+annotation
+. _b_ has a release annotation
+. _a_ and _b_ both have
+RCsc annotations
+. _a_ is paired with
+_b_
+* Syntactic Dependencies
+[start=9]
+. _b_ has a syntactic address
+dependency on _a_
+. _b_ has a syntactic data
+dependency on _a_
+. _b_ is a store, and
+_b_ has a syntactic control dependency on _a_
+* Pipeline Dependencies
+[start=12]
+. _b_ is a
+load, and there exists some store _m_ between
+_a_ and _b_ in program order such that
+_m_ has an address or data dependency on _a_,
+and _b_ returns a value written by _m_
+. _b_ is a store, and
+there exists some instruction _m_ between _a_
+and _b_ in program order such that _m_ has an
+address dependency on _a_
+
+==== Memory Model Axioms
+
+An execution of a RISC-V program obeys the RVWMO memory consistency
+model only if there exists a global memory order conforming to preserved
+program order and satisfying the _load value axiom_, the _atomicity
+axiom_, and the _progress axiom_.
+
+[[ax-load]]
+===== Load Value Axiom
+
+Each byte of each load _i_ returns the value written to that
+byte by the store that is the latest in global memory order among the
+following stores:
+
+. Stores that write that byte and that precede _i_ in the
+global memory order
+. Stores that write that byte and that precede _i_ in
+program order
+
+[[ax-atom]]
+===== Atomicity Axiom
+
+If _r_ and _w_ are paired load and store
+operations generated by aligned LR and SC instructions in a hart
+_h_, _s_ is a store to byte _x_, and
+_r_ returns a value written by _s_, then
+_s_ must precede _w_ in the global memory order,
+and there can be no store from a hart other than _h_ to byte
+_x_ following _s_ and preceding _w_
+in the global memory order.
+[NOTE]
+====
+The <<ax-atom, Atomicity Axiom>> theoretically supports LR/SC pairs of different widths and to
+mismatched addresses, since implementations are permitted to allow SC
+operations to succeed in such cases. However, in practice, we expect
+such patterns to be rare, and their use is discouraged.
+====
+
+[[ax-prog]]
+===== Progress Axiom
+
+No memory operation may be preceded in the global memory order by an
+infinite sequence of other memory operations.
+
+[[csr-granularity]]
+=== CSR Dependency Tracking Granularity
+
+.Granularities at which syntactic dependencies are tracked through CSRs
+[%autowidth,float="center",align="center",cols="<,<,<",options="header",]
+|===
+|Name |Portions Tracked as Independent Units |Aliases
+|_fflags_ |Bits 4, 3, 2, 1, 0 |_fcsr_
+|_frm_ |entire CSR |_fcsr_
+|_fcsr_ |Bits 7-5, 4, 3, 2, 1, 0 |_fflags_, _frm_
+|===
+
+Note: read-only CSRs are not listed, as they do not participate in the
+definition of syntactic dependencies.
+
+[[source-dest-regs]]
+=== Source and Destination Register Listings
+
+This section provides a concrete listing of the source and destination
+registers for each instruction. These listings are used in the
+definition of syntactic dependencies in
+<<mem-dependencies>>.
+
+The term "accumulating CSR" is used to describe a CSR that is both a
+source and a destination register, but which carries a dependency only
+from itself to itself.
+
+Instructions carry a dependency from each source register in the
+"Source Registers" column to each destination register in the
+"Destination Registers" column, from each source register in the
+"Source Registers" column to each CSR in the "Accumulating CSRs"
+column, and from each CSR in the "Accumulating CSRs" column to itself,
+except where annotated otherwise.
+
+Key:
+
+- ^A^Address source register
+
+- ^D^Data source register
+
+- † The instruction does not carry a dependency from
+any source register to any destination register
+
+- ‡ The instruction carries dependencies from source
+register(s) to destination register(s) as specified
+
+.RV32I Base Integer Instruction Set
+[%autowidth,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+||Source Registers |Destination Registers|Accumulating CSRs|
+
+|LUI | |_rd_ | |
+
+|AUIPC | |_rd_ ||
+
+|JAL | |_rd_ ||
+
+|JALR† |_rs1_ |_rd_ ||
+
+|BEQ |_rs1_, _rs2_ | ||
+
+|BNE |_rs1_, _rs2_ | ||
+
+|BLT |_rs1_, _rs2_ | ||
+
+|BGE |_rs1_, _rs2_ | ||
+
+|BLTU |_rs1_, _rs2_ | ||
+
+|BGEU |_rs1_, _rs2_ | ||
+
+|LB † | _rs1_ ^A^ | _rd_ ||
+
+|LH † | _rs1_ ^A^ | _rd_ ||
+
+|LW † | _rs1_ ^A^ | _rd_ ||
+
+|LBU † | _rs1_ ^A^ | _rd_ ||
+
+|LHU † | _rs1_ ^A^ | _rd_ ||
+
+|SB |_rs1_ ^A^, _rs2_ ^D^ | ||
+
+|SH |_rs1_ ^A^, _rs2_ ^D^ | ||
+
+|SW |_rs1_ ^A^, _rs2_ ^D^ | ||
+
+|ADDI |_rs1_ |_rd_ ||
+
+|SLTI |_rs1_ |_rd_ ||
+
+|SLTIU |_rs1_ |_rd_ ||
+
+|XORI |_rs1_ |_rd_ ||
+
+|ORI |_rs1_ |_rd_ ||
+
+|ANDI |_rs1_ |_rd_ ||
+
+|SLLI |_rs1_ |_rd_ ||
+
+|SRLI |_rs1_ |_rd_ ||
+
+|SRAI |_rs1_ |_rd_ ||
+
+|ADD |_rs1_, _rs2_ |_rd_ ||
+
+|SUB |_rs1_, _rs2_ |_rd_ ||
+
+|SLL |_rs1_, _rs2_ |_rd_ ||
+
+|SLT |_rs1_, _rs2_ |_rd_ ||
+
+|SLTU |_rs1_, _rs2_ |_rd_ ||
+
+|XOR |_rs1_, _rs2_ |_rd_ ||
+
+|SRL |_rs1_, _rs2_ |_rd_ ||
+
+|SRA |_rs1_, _rs2_ |_rd_ ||
+
+|OR |_rs1_, _rs2_ |_rd_ ||
+
+|AND |_rs1_, _rs2_ |_rd_ ||
+
+|FENCE | | ||
+
+|FENCE.I | | ||
+
+|ECALL | | ||
+
+|EBREAK | | ||
+
+|CSRRW‡ |_rs1_, _csr_^*^ | _rd_, _csr_ | |^*^unless _rd_=`x0`
+
+5+| ‡ carries a dependency from _rs1_ to _csr_ and from _csr_ to _rd_
+
+|CSRRS‡ |_rs1_, _csr_ |_rd_, _csr_^*^ | |^*^unless _rs1_=`x0`
+
+|CSRRC‡ |_rs1_, _csr_ |_rd_, _csr_^*^ | |^*^unless _rs1_=`x0`
+
+5+| ‡ carries a dependency from _csr_ and _rs1_ to _csr_ and from _csr_ to _rd_
+
+|CSRRWI ‡ |_csr_ ^*^ |_rd_, _csr_ | |^*^unless _rd_=_x0_
+
+5+| ‡ carries a dependency from _csr_ to _rd_
+
+|CSRRSI ‡ |_csr_ |_rd_, _csr_^*^ | |^*^unless uimm[4:0]=0
+
+|CSRRCI ‡ |_csr_ |_rd_, _csr_^*^ | |^*^unless uimm[4:0]=0
+
+5+| ‡ carries a dependency from _csr_ to _rd_ and _csr_
+|===
+
+.RV64I Base Integer Instruction Set
+[%autowidth.stretch,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+| |Source Registers |Destination Registers |Accumulating CSRs|
+
+|_LWU_ † |_rs1_ ^A^ |_rd_ | |
+
+|_LD_ † |_rs1_ ^A^ |_rd_ | |
+
+|SD |_rs1_ ^A^, _rs2_ ^D^ | | |
+
+|SLLI | _rs1_ | _rd_ | |
+
+|SRLI | _rs1_ | _rd_ | |
+
+|SRAI | _rs1_ | _rd_ | |
+
+|ADDIW | _rs1_ | _rd_ | |
+
+|SLLIW | _rs1_ | _rd_ | |
+
+|SRLIW | _rs1_ | _rd_ | |
+
+|SRAIW | _rs1_ | _rd_ | |
+
+|ADDW | _rs1_, _rs2_ |_rd_ ||
+
+|SUBW | _rs1_, _rs2_ |_rd_ ||
+
+|SLLW | _rs1_, _rs2_ |_rd_ ||
+
+|SRLW | _rs1_, _rs2_ |_rd_ ||
+
+|SRAW | _rs1_, _rs2_ |_rd_ ||
+|===
+
+.RV32M Standard Extension
+[%autowidth.stretch,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+| |Source Registers |Destination Registers |Accumulating CSRs|
+
+|MUL | _rs1_, _rs2_ |_rd_ ||
+
+|MULH | _rs1_, _rs2_ |_rd_ ||
+
+|MULHSU |_rs1_, _rs2_ |_rd_ ||
+
+|MULHU |_rs1_, _rs2_ |_rd_ ||
+
+|DIV |_rs1_, _rs2_ |_rd_ ||
+
+|DIVU |_rs1_, _rs2_ |_rd_ ||
+
+|REM |_rs1_, _rs2_ |_rd_ ||
+
+|REMU |_rs1_, _rs2_ |_rd_ ||
+|===
+
+.RV64M Standard Extension
+[%autowidth.stretch,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+||Source Registers |Destination Registers |Accumulating CSRs|
+
+|MULW |_rs1_, _rs2_ |_rd_ ||
+
+|DIVW |_rs1_, _rs2_ |_rd_ ||
+
+|DIVUW |_rs1_, _rs2_ |_rd_ ||
+
+|REMW |_rs1_, _rs2_ |_rd_ ||
+
+|REMUW |_rs1_, _rs2_ |_rd_ ||
+|===
+
+.RV32A Standard Extension
+[%autowidth.stretch,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+||Source Registers |Destination Registers |Accumulating CSRs|
+
+|LR.W† | _rs1_ ^A^ | _rd_ | |
+
+|SC.W† | _rs1_ ^A^, _rs2_ ^D^ | _rd_ ^*^ | | ^*^ if successful
+
+|AMOSWAP.W† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|AMOADD.W† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|AMOXOR.W† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|AMOAND.W† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|AMOOR.W† |_rs1_ ^A^, _rs2_^D^ |_rd_ | |
+
+|AMOMIN.W† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|AMOMAX.W† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|AMOMINU.W† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|AMOMAXU.W† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|===
+
+.RV64A Standard Extension
+[%autowidth.stretch,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+
+| |Source Registers |Destination Registers |Accumulating CSRs|
+
+|LR.D† |_rs1_ ^A^ |_rd_ | |
+
+|SC.D† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ ^*^ | |^*^if successful
+
+|AMOSWAP.D† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|AMOADD.D† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|AMOXOR.D† |_rs1_ ^A^, _rs2_ ^D^ |_rd_ | |
+
+|AMOAND.D† |_rs1_ ^A^, _rs2_^D^ |_rd_ | |
+
+|AMOOR.D† |_rs1_ ^A^, _rs2_^D^ |_rd_ | |
+
+|AMOMIN.D† |_rs1_ ^A^, _rs2_^D^ |_rd_ | |
+
+|AMOMAX.D† |_rs1_ ^A^, _rs2_^D^ |_rd_ | |
+
+|AMOMINU.D† |_rs1_ ^A^, _rs2_^D^ |_rd_ | |
+
+|AMOMAXU.D† |_rs1_ ^A^, _rs2_^D^ |_rd_ | |
+
+|===
+
+.RV32F Standard Extension
+[%autowidth.stretch,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+
+| |Source Registers |Destination Registers |Accumulating CSRs |
+
+
+|FLW† |_rs1_ ^A^ |_rd_ | |
+
+|FSW |_rs1_ ^A^, _rs2_^D^ | | |
+
+|FMADD.S |_rs1_, _rs2_, _rs3_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FMSUB.S |_rs1_, _rs2_, _rs3_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FNMSUB.S |_rs1_, _rs2_, _rs3_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FNMADD.S |_rs1_, _rs2_, _rs3_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FADD.S |_rs1_, _rs2_, frm^*^ |_rd_ |NV, OF, NX |^*^if rm=111
+
+|FSUB.S |_rs1_, _rs2_, frm^*^ |_rd_ |NV, OF, NX |^*^if rm=111
+
+|FMUL.S |_rs1_, _rs2_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FDIV.S |_rs1_, _rs2_, frm^*^ |_rd_ |NV, DZ, OF, UF, NX |^*^if rm=111
+
+|FSQRT.S |_rs1_, frm^*^ |_rd_ |NV, NX |^*^if rm=111
+
+|FSGNJ.S |_rs1_, _rs2_ |_rd_ | |
+
+|FSGNJN.S |_rs1_, _rs2_ |_rd_ | |
+
+|FSGNJX.S |_rs1_, _rs2_ |_rd_ | |
+
+|FMIN.S |_rs1_, _rs2_ |_rd_ |NV |
+
+|FMAX.S |_rs1_, _rs2_ |_rd_ |NV |
+
+|FCVT.W.S |_rs1_, frm^*^ |_rd_ |NV, NX |^*^if rm=111
+
+|FCVT.WU.S |_rs1_, frm^*^ |_rd_ |NV, NX |^*^if rm=111
+
+|FMV.X.W |_rs1_ |_rd_ | |
+
+|FEQ.S |_rs1_, _rs2_ |_rd_ |NV |
+
+|FLT.S |_rs1_, _rs2_ |_rd_ |NV |
+
+|FLE.S |_rs1_, _rs2_ |_rd_ |NV |
+
+|FCLASS.S |_rs1_ |_rd_ | |
+
+|FCVT.S.W |_rs1_, frm^*^ |_rd_ |NX |^*^if rm=111
+
+|FCVT.S.WU |_rs1_, frm^*^ |_rd_ |NX |^*^if rm=111
+
+|FMV.W.X |_rs1_ |_rd_ | |
+
+|===
+
+.RV64F Standard Extension
+[%autowidth.stretch,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+| |Source Registers |Destination Registers |Accumulating CSRs|
+
+|FCVT.L.S |_rs1_, frm^*^ |_rd_ |NV, NX |^*^if rm=111
+
+|FCVT.LU.S |_rs1_, frm^*^ |_rd_ |NV, NX |^*^if rm=111
+
+|FCVT.S.L |_rs1_, frm^*^ |_rd_ |NX |^*^if rm=111
+
+|FCVT.S.LU |_rs1_, frm^*^ |_rd_ |NX |^*^if rm=111
+
+|===
+
+.RV32D Standard Extension
+[%autowidth.stretch,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+
+| |Source Registers|Destination Registers |Accumulating CSRs |
+
+
+|FLD† |_rs1_ ^A^ |_rd_ | |
+
+|FSD |_rs1_ ^A^, _rs2_^D^ | | |
+
+|FMADD.D |_rs1_, _rs2_, _rs3_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FMSUB.D |_rs1_, _rs2_, _rs3_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FNMSUB.D |_rs1_, _rs2_, _rs3_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FNMADD.D |_rs1_, _rs2_, _rs3_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FADD.D |_rs1_, _rs2_, frm^*^ |_rd_ |NV, OF, NX |^*^if rm=111
+
+|FSUB.D |_rs1_, _rs2_, frm^*^ |_rd_ |NV, OF, NX |^*^if rm=111
+
+|FMUL.D |_rs1_, _rs2_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FDIV.D |_rs1_, _rs2_, frm^*^ |_rd_ |NV, DZ, OF, UF, NX |^*^if rm=111
+
+|FSQRT.D |_rs1_, frm^*^ |_rd_ |NV, NX |^*^if rm=111
+
+|FSGNJ.D |_rs1_, _rs2_ |_rd_ | |
+
+|FSGNJN.D |_rs1_, _rs2_ |_rd_ | |
+
+|FSGNJX.D |_rs1_, _rs2_ |_rd_ | |
+
+|FMIN.D |_rs1_, _rs2_ |_rd_ |NV |
+
+|FMAX.D |_rs1_, _rs2_ |_rd_ |NV |
+
+|FCVT.S.D |_rs1_, frm^*^ |_rd_ |NV, OF, UF, NX |^*^if rm=111
+
+|FCVT.D.S |_rs1_ |_rd_ |NV |
+
+|FEQ.D |_rs1_, _rs2_ |_rd_ |NV |
+
+|FLT.D |_rs1_, _rs2_ |_rd_ |NV |
+
+|FLE.D |_rs1_, _rs2_ |_rd_ |NV |
+
+|FCLASS.D |_rs1_ |_rd_ | |
+
+|FCVT.W.D |_rs1_, frm^*^ |_rd_ |NV, NX |^*^if rm=111
+
+|FCVT.WU.D |_rs1_, frm^*^ |_rd_ |NV, NX |^*^if rm=111
+
+|FCVT.D.W |_rs1_ |_rd_ | |
+
+|FCVT.D.WU |_rs1_ |_rd_ | |
+
+|===
+
+.RV64D Standard Extension
+[%autowidth.stretch,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+
+| |Source Registers |Destination Registers |Accumulating CSRs |
+
+|FCVT.L.D |_rs1_, frm^*^ |_rd_ |NV, NX |^*^if rm=111
+
+|FCVT.LU.D |_rs1_, frm^*^ |_rd_ |NV, NX |^*^if rm=111
+
+|FMV.X.D |_rs1_ |_rd_ | |
+
+|FCVT.D.L |_rs1_, frm^*^ |_rd_ |NX |^*^if rm=111
+
+|FCVT.D.LU |_rs1_, frm^*^ |_rd_ |NX |^*^if rm=111
+
+|FMV.D.X |_rs1_ |_rd_ | |
+
+|===
diff --git a/src/rvwmo.tex b/src/rvwmo.tex
deleted file mode 100644
index 94190b1..0000000
--- a/src/rvwmo.tex
+++ /dev/null
@@ -1,217 +0,0 @@
-\chapter{RVWMO Memory Consistency Model, Version 0.1}
-\label{ch:memorymodel}
-
-This chapter defines the RISC-V memory consistency model.
-A memory consistency model is a set of rules specifying the values that can be returned by loads of memory.
-RISC-V uses a memory model called ``RVWMO'' (RISC-V Weak Memory Ordering) which is designed to provide flexibility for architects to build high-performance scalable designs while simultaneously supporting a tractable programming model.
-
-Under RVWMO, code running on a single hart appears to execute in order from the perspective of other memory instructions in the same hart, but memory instructions from another hart may observe the memory instructions from the first hart being executed in a different order.
-Therefore, multithreaded code may require explicit synchronization to guarantee ordering between memory instructions from different harts.
-The base RISC-V ISA provides a FENCE instruction for this purpose, described in Section~\ref{sec:fence}, while the atomics extension ``A'' additionally defines load-reserved/store-conditional and atomic read-modify-write instructions.
-
-The standard ISA extension for misaligned atomics ``Zam'' (Chapter~\ref{sec:zam}) and the standard ISA extension for total store ordering ``Ztso'' (Chapter~\ref{sec:ztso}) augment RVWMO with additional rules specific to those extensions.
-
-The appendices to this specification provide both axiomatic and operational formalizations of the memory consistency model as well as additional explanatory material.
-
-\begin{commentary}
- This chapter defines the memory model for regular main memory operations. The interaction of the memory model with I/O memory, instruction fetches, FENCE.I, page table walks, and SFENCE.VMA is not (yet) formalized. Some or all of the above may be formalized in a future revision of this specification. The RV128 base ISA and future ISA extensions such as the ``V'' vector, ``T'' transactional memory, and ``J'' JIT extensions will need to be incorporated into a future revision as well.
-
- Memory consistency models supporting overlapping memory accesses of different widths simultaneously remain an active area of academic research and are not yet fully understood. The specifics of how memory accesses of different sizes interact under RVWMO are specified to the best of our current abilities, but they are subject to revision should new issues be uncovered.
-\end{commentary}
-
-\section{Definition of the RVWMO Memory Model}
-\label{sec:rvwmo}
-
-The RVWMO memory model is defined in terms of the {\em global memory order}, a total ordering of the memory operations produced by all harts.
-In general, a multithreaded program has many different possible executions, with each execution having its own corresponding global memory order.
-
-The global memory order is defined over the primitive load and store operations generated by memory instructions.
-It is then subject to the constraints defined in the rest of this chapter.
-Any execution satisfying all of the memory model constraints is a legal execution (as far as the memory model is concerned).
-
-\subsection*{Memory Model Primitives}
-\label{sec:rvwmo:primitives}
-The {\em program order} over memory operations reflects the order in which the instructions that generate each load and store are logically laid out in that hart's dynamic instruction stream; i.e., the order in which a simple in-order processor would execute the instructions of that hart.
-
-Memory-accessing instructions give rise to {\em memory operations}.
-A memory operation can be either a {\em load operation}, a {\em store operation}, or both simultaneously.
-All memory operations are single-copy atomic: they can never be observed in a partially-complete state.
-
-Among instructions in RV32GC and RV64GC, each aligned memory instruction gives rise to exactly one memory operation, with two exceptions.
-First, an unsuccessful SC instruction does not give rise to any memory operations.
-Second, FLD and FSD instructions may each give rise to multiple memory operations if XLEN$<$64, as stated in Section~\ref{fld_fsd} and clarified below.
-An aligned AMO gives rise to a single memory operation that is both a load operation and a store operation simultaneously.
-
-\begin{commentary}
- Instructions in the RV128 base instruction set and in future ISA extensions such as V (vector) and P (SIMD) may give rise to multiple memory operations. However, the memory model for these extensions has not yet been formalized.
-\end{commentary}
-
-A misaligned load or store instruction may be decomposed into a set of component memory operations of any granularity.
-An FLD or FSD instruction for which XLEN$<$64 may also be decomposed into a set of component memory operations of any granularity.
-The memory operations generated by such instructions are not ordered with respect to each other in program order, but they are ordered normally with respect to the memory operations generated by preceding and subsequent instructions in program order.
-The atomics extension ``A'' does not require execution environments to support misaligned atomic instructions at all; however, if misaligned atomics are supported via the ``Zam'' extension, LRs, SCs, and AMOs may be decomposed subject to the constraints of the atomicity axiom for misaligned atomics, which is defined in Chapter~\ref{sec:zam}.
-
-\begin{commentary}
- The decomposition of misaligned memory operations down to byte granularity facilitates emulation on implementations that do not natively support misaligned accesses.
- Such implementations might, for example, simply iterate over the bytes of a misaligned access one by one.
-\end{commentary}
-
-An LR instruction and an SC instruction are said to be {\em paired} if the LR precedes the SC in program order and if there are no other LR or SC instructions in between; the corresponding memory operations are said to be paired as well (except in case of a failed SC, where no store operation is generated).
-The complete list of conditions determining whether an SC must succeed, may succeed, or must fail is defined in Section~\ref{sec:lrsc}.
-
-Load and store operations may also carry one or more ordering annotations from the following set: ``acquire-RCpc'', ``acquire-RCsc'', ``release-RCpc'', and ``release-RCsc''.
-An AMO or LR instruction with {\em aq} set has an ``acquire-RCsc'' annotation.
-An AMO or SC instruction with {\em rl} set has a ``release-RCsc'' annotation.
-An AMO, LR, or SC instruction with both {\em aq} and {\em rl} set has both ``acquire-RCsc'' and ``release-RCsc'' annotations.
-
-For convenience, we use the term ``acquire annotation'' to refer to an acquire-RCpc annotation or an acquire-RCsc annotation.
-Likewise, a ``release annotation'' refers to a release-RCpc annotation or a release-RCsc annotation.
-An ``RCpc annotation'' refers to an acquire-RCpc annotation or a release-RCpc annotation.
-An ``RCsc annotation'' refers to an acquire-RCsc annotation or a release-RCsc annotation.
-
-\begin{commentary}
- In the memory model literature, the term ``RCpc'' stands for release consistency with processor-consistent synchronization operations, and the term ``RCsc'' stands for release consistency with sequentially-consistent synchronization operations~\cite{Gharachorloo90memoryconsistency}.
-
- While there are many different definitions for acquire and release annotations in the literature, in the context of RVWMO these terms are concisely and completely defined by Preserved Program Order rules \ref{ppo:acquire}--\ref{ppo:rcsc}.
-
- ``RCpc'' annotations are currently only used when implicitly assigned to every memory access per the standard extension ``Ztso'' (Chapter~\ref{sec:ztso}). Furthermore, although the ISA does not currently contain native load-acquire or store-release instructions, nor RCpc variants thereof, the RVWMO model itself is designed to be forwards-compatible with the potential addition of any or all of the above into the ISA in a future extension.
-\end{commentary}
-
-\subsection*{Syntactic Dependencies}
-\label{sec:memorymodel:dependencies}
-The definition of the RVWMO memory model depends in part on the notion of a syntactic dependency, defined as follows.
-
-In the context of defining dependencies, a ``register'' refers either to an entire general-purpose register, some portion of a CSR, or an entire CSR. The granularity at which dependencies are tracked through CSRs is specific to each CSR and is defined in Section~\ref{sec:csr-granularity}.
-
-Syntactic dependencies are defined in terms of instructions' {\em source registers}, instructions' {\em destination registers}, and the way instructions {\em carry a dependency} from their source registers to their destination registers.
-This section provides a general definition of all of these terms; however, Section~\ref{sec:source-dest-regs} provides a complete listing of the specifics for each instruction.
-
-In general, a register $r$ other than {\tt x0} is a {\em source register} for an instruction $i$ if any of the following hold:
-\begin{itemize}
- \item In the opcode of $i$, {\em rs1}, {\em rs2}, or {\em rs3} is set to $r$
- \item $i$ is a CSR instruction, and in the opcode of $i$, {\em csr} is set to $r$, unless $i$ is CSRRW or CSRRWI and {\em rd} is set to {\tt x0}
- \item $r$ is a CSR and an implicit source register for $i$, as defined in Section~\ref{sec:source-dest-regs}
- \item $r$ is a CSR that aliases with another source register for $i$
-\end{itemize}
-Memory instructions also further specify which source registers are {\em address source registers} and which are {\em data source registers}.
-
-In general, a register $r$ other than {\tt x0} is a {\em destination register} for an instruction $i$ if any of the following hold:
-\begin{itemize}
- \item In the opcode of $i$, {\em rd} is set to $r$
- \item $i$ is a CSR instruction, and in the opcode of $i$, {\em csr} is set to $r$, unless $i$ is CSRRS or CSRRC and {\em rs1} is set to {\tt x0} or $i$ is CSRRSI or CSRRCI and uimm[4:0] is set to zero.
- \item $r$ is a CSR and an implicit destination register for $i$, as defined in Section~\ref{sec:source-dest-regs}
- \item $r$ is a CSR that aliases with another destination register for $i$
-\end{itemize}
-
-Most non-memory instructions {\em carry a dependency} from each of their source registers to each of their destination registers.
-However, there are exceptions to this rule; see Section~\ref{sec:source-dest-regs}
-
-Instruction $j$ has a {\em syntactic dependency} on instruction $i$ via destination register $s$ of $i$ and source register $r$ of $j$ if either of the following hold:
-\begin{itemize}
- \item $s$ is the same as $r$, and no instruction program-ordered between $i$ and $j$ has $r$ as a destination register
- \item There is an instruction $m$ program-ordered between $i$ and $j$ such that all of the following hold:
- \begin{enumerate}
- \item $j$ has a syntactic dependency on $m$ via destination register $q$ and source register $r$
- \item $m$ has a syntactic dependency on $i$ via destination register $s$ and source register $p$
- \item $m$ carries a dependency from $p$ to $q$
- \end{enumerate}
-\end{itemize}
-
-Finally, in the definitions that follow, let $a$ and $b$ be two memory operations, and let $i$ and $j$ be the instructions that generate $a$ and $b$, respectively.
-
-$b$ has a {\em syntactic address dependency} on $a$ if $r$ is an address source register for $j$ and $j$ has a syntactic dependency on $i$ via source register $r$
-
-$b$ has a {\em syntactic data dependency} on $a$ if $b$ is a store operation, $r$ is a data source register for $j$, and $j$ has a syntactic dependency on $i$ via source register $r$
-
-$b$ has a {\em syntactic control dependency} on $a$ if there is an instruction $m$ program-ordered between $i$ and $j$ such that $m$ is a branch or indirect jump and $m$ has a syntactic dependency on $i$.
-
-\begin{commentary}
- Generally speaking, non-AMO load instructions do not have data source registers, and unconditional non-AMO store instructions do not have destination registers. However, a successful SC instruction is considered to have the register specified in {\em rd} as a destination register, and hence it is possible for an instruction to have a syntactic dependency on a successful SC instruction that precedes it in program order.
-\end{commentary}
-
-\subsection*{Preserved Program Order}
-The global memory order for any given execution of a program respects some but not all of each hart's program order.
-The subset of program order that must be respected by the global memory order is known as {\em preserved program order}.
-
-\newcommand{\ppost}{$b$ is a store, and $a$ and $b$ access overlapping memory addresses}
-\newcommand{\ppofence}{There is a FENCE instruction that orders $a$ before $b$}
-\newcommand{\ppoacquire}{$a$ has an acquire annotation}
-\newcommand{\pporelease}{$b$ has a release annotation}
-\newcommand{\pporcsc}{$a$ and $b$ both have RCsc annotations}
-\newcommand{\ppoamoforward}{$a$ is generated by an AMO or SC instruction, $b$ is a load, and $b$ returns a value written by $a$}
-\newcommand{\ppoaddr}{$b$ has a syntactic address dependency on $a$}
-\newcommand{\ppodata}{$b$ has a syntactic data dependency on $a$}
-\newcommand{\ppoctrl}{$b$ is a store, and $b$ has a syntactic control dependency on $a$}
-\newcommand{\ppopair}{$a$ is paired with $b$}
-\newcommand{\ppordw}{$a$ and $b$ are loads, $x$ is a byte read by both $a$ and $b$, there is no store to $x$ between $a$ and $b$ in program order, and $a$ and $b$ return values for $x$ written by different memory operations}
-\newcommand{\ppoaddrdatarfi}{$b$ is a load, and there exists some store $m$ between $a$ and $b$ in program order such that $m$ has an address or data dependency on $a$, and $b$ returns a value written by $m$}
-\newcommand{\ppoaddrpo}{$b$ is a store, and there exists some instruction $m$ between $a$ and $b$ in program order such that $m$ has an address dependency on $a$}
-%\newcommand{\ppoctrlcfence}{$a$ and $b$ are loads, $b$ has a syntactic control dependency on $a$, and there exists a {\tt fence.i} between the branch used to form the control dependency and $b$ in program order}
-%\newcommand{\ppoaddrpocfence}{$a$ is a load, there exists an instruction $m$ which has a syntactic address dependency on $a$, and there exists a {\tt fence.i} between $m$ and $b$ in program order}
-
-The complete definition of preserved program order is as follows (and note that AMOs are simultaneously both loads and stores):
-memory operation $a$ precedes memory operation $b$ in preserved program order (and hence also in the global memory order) if $a$ precedes $b$ in program order, $a$ and $b$ both access regular main memory (rather than I/O regions), and any of the following hold:
-
-\begin{itemize}
- \item Overlapping-Address Orderings:
- \begin{enumerate}
- \item\label{ppo:->st} \ppost
- \item\label{ppo:rdw} \ppordw
- \item\label{ppo:amoforward} \ppoamoforward
- \end{enumerate}
- \item Explicit Synchronization
- \begin{enumerate}[resume]
- \item\label{ppo:fence} \ppofence
- \item\label{ppo:acquire} \ppoacquire
- \item\label{ppo:release} \pporelease
- \item\label{ppo:rcsc} \pporcsc
- \item\label{ppo:pair} \ppopair
- \end{enumerate}
- \item Syntactic Dependencies
- \begin{enumerate}[resume]
- \item\label{ppo:addr} \ppoaddr
- \item\label{ppo:data} \ppodata
- \item\label{ppo:ctrl} \ppoctrl
- \end{enumerate}
- \item Pipeline Dependencies
- \begin{enumerate}[resume]
- \item\label{ppo:addrdatarfi} \ppoaddrdatarfi
- \item\label{ppo:addrpo} \ppoaddrpo
- %\item\label{ppo:ctrlcfence} \ppoctrlcfence
- %\item\label{ppo:addrpocfence} \ppoaddrpocfence
- \end{enumerate}
-\end{itemize}
-
-\subsection*{Memory Model Axioms}
-
-An execution of a RISC-V program obeys the RVWMO memory consistency model only if there exists a global memory order conforming to preserved program order and satisfying the {\em load value axiom}, the {\em atomicity axiom}, and the {\em progress axiom}.
-
-\newcommand{\loadvalueaxiom}{
- Each byte of each load $i$ returns the value written to that byte by the store that is the latest in global memory order among the following stores:
- \begin{enumerate}
- \item Stores that write that byte and that precede $i$ in the global memory order
- \item Stores that write that byte and that precede $i$ in program order
- \end{enumerate}
-}
-
-\newcommand{\atomicityaxiom}{If $r$ and $w$ are paired load and store operations generated by aligned LR and SC instructions in a hart $h$, $s$ is a store to byte $x$, and $r$ returns a value written by $s$, then $s$ must precede $w$ in the global memory order, and there can be no store from a hart other than $h$ to byte $x$ following $s$ and preceding $w$ in the global memory order.}
-
-\newcommand{\progressaxiom}{No memory operation may be preceded in the global memory order by an infinite sequence of other memory operations.}
-
-\paragraph{Load Value Axiom}
-\label{rvwmo:ax:load}
-\loadvalueaxiom
-
-\paragraph{Atomicity Axiom}
-\label{rvwmo:ax:atom}
-\atomicityaxiom
-
-\begin{commentary}
- The \nameref{rvwmo:ax:atom} theoretically supports LR/SC pairs of different widths and to mismatched addresses, since implementations are permitted to allow SC operations to succeed in such cases. However, in practice, we expect such patterns to be rare, and their use is discouraged.
-\end{commentary}
-
-\paragraph{Progress Axiom}
-\label{rvwmo:ax:prog}
-\progressaxiom
-
-\input{dep-table}
diff --git a/src/scalar-crypto.adoc b/src/scalar-crypto.adoc
new file mode 100644
index 0000000..6c3f11b
--- /dev/null
+++ b/src/scalar-crypto.adoc
@@ -0,0 +1,5659 @@
+[[crypto_scalar_instructions]]
+== Cryptography Extensions: Scalar & Entropy Source Instructions, Version 1.0.1
+
+[[crypto_scalar_introduction]]
+=== Introduction
+
+This document describes the _scalar_ cryptography
+extension for RISC-V.
+All instructions described herein use the general-purpose `X`
+registers, and obey the 2-read-1-write register access constraint.
+These instructions are designed to be lightweight and suitable
+for `32` and `64` bit base architectures; from embedded IoT class
+cores to large, application class cores which do not implement a
+vector unit.
+
+This document also describes the architectural interface to an
+Entropy Source, which can be used to generate cryptographic secrets.
+This is found in <<crypto_scalar_es>>.
+
+It also contains a mechanism allowing core implementers to provide
+_"Constant Time Execution"_ guarantees in <<crypto_scalar_zkt>>.
+
+[[crypto_scalar_audience]]
+==== Intended Audience
+
+Cryptography is a specialised subject, requiring people with many different
+backgrounds to cooperate in its secure and efficient implementation.
+Where possible, we have written this specification to be understandable by
+all, though we recognise that the motivations and references to
+algorithms or other specifications and standards may be unfamiliar to those
+who are not domain experts.
+
+This specification anticipates being read and acted on by various people
+with different backgrounds.
+We have tried to capture these backgrounds
+here, with a brief explanation of what we expect them to know, and how
+it relates to the specification.
+We hope this aids people's understanding of which aspects of the specification
+are particularly relevant to them, and which they may (safely!) ignore or
+pass to a colleague.
+
+Cryptographers and cryptographic software developers::
+These are the people we expect to write code using the instructions
+in this specification.
+They should understand fairly obviously the motivations for the
+instructions we include, and be familiar with most of the algorithms
+and outside standards to which we refer.
+We expect the sections on constant time execution
+(<<crypto_scalar_zkt>>)
+and the entropy source
+(<<crypto_scalar_es>>)
+to be chiefly understood with their help.
+
+Computer architects::
+We do not expect architects to have a cryptography background.
+We nonetheless expect architects to be able to examine our instructions
+for implementation issues, understand how the instructions will be used
+in context, and advise on how best to fit the functionality the
+cryptographers want to the ISA interface.
+
+Digital design engineers & micro-architects::
+These are the people who will implement the specification inside a
+core. Again, no cryptography expertise is assumed, but we expect them to
+interpret the specification and anticipate any hardware implementation
+issues, e.g., where high-frequency design considerations apply, or where
+latency/area tradeoffs exist etc.
+In particular, they should be aware of the literature around efficiently
+implementing AES and SM4 SBoxes in hardware.
+
+Verification engineers::
+Responsible for ensuring the correct implementation of the extension
+in hardware.
+No cryptography background is assumed.
+We expect them to identify interesting test cases from the
+specification. An understanding of their real-world usage will help with this.
+We do not expect verification engineers in this sense to be experts
+in entropy source design or certification, since this is a very
+specialised area.
+We do expect them however to identify all of the _architectural_
+test cases around the entropy source interface.
+
+These are by no means the only people concerned with the specification,
+but they are the ones we considered most while writing it.
+
+[[crypto_scalar_sail_specifications]]
+==== Sail Specifications
+
+RISC-V maintains a
+link:https://github.com/riscv/sail-riscv[formal model]
+of the ISA specification,
+implemented in the Sail ISA specification language
+cite:[sail].
+Note that _Sail_ refers to the specification language itself,
+and that there is a _model of RISC-V_, written using Sail.
+It is not correct to refer to "the Sail model".
+This is ambiguous, given there are many models of different ISAs implemented
+using Sail. We refer to the Sail implementation of RISC-V as
+"the RISC-V Sail model".
+
+The Cryptography extension uses inline Sail code snippets from the
+actual model to give canonical descriptions of instruction
+functionality.
+Each instruction is accompanied by its expression in Sail, and includes
+calls to supporting functions which are too verbose to include directly
+in the specification.
+This supporting code is listed in
+<<crypto_scalar_appx_sail>>.
+The
+link:https://alasdair.github.io/manual.html[Sail Manual]
+is recommended reading in order to best understand the code snippets.
+
+Note that this document contains only a subset of the formal model: refer to
+the formal model GitHub
+link:https://github.com/riscv/sail-riscv[repository]
+for the complete model.
+
+[[crypto_scalar_policies]]
+==== Policies
+
+In creating this proposal, we tried to adhere to the following
+policies:
+
+* Where there is a choice between:
+ . supporting diverse implementation strategies for an algorithm
+ or
+ . supporting a single implementation style which is more performant /
+ less expensive;
+ the crypto extension will pick the more constrained but performant
+ option.
+ This fits a common pattern in other parts of the RISC-V specification,
+ where recommended (but not required) instruction sequences for performing
+ particular tasks are given as an example, such that both hardware and
+ software implementers can optimise for only a single use-case.
+
+* The extension will be designed to support _existing_ standardised
+ cryptographic constructs well.
+ It will not try to support proposed standards, or cryptographic
+ constructs which exist only in academia.
+ Cryptographic standards which are settled upon concurrently with or after
+ the RISC-V cryptographic extension standardisation will be dealt with
+ by future additions to, or versions of, the RISC-V cryptographic
+ standard extension. It is anticipated that the NIST Lightweight
+ Cryptography contest and the NIST Post-Quantum Cryptography contest
+ may be dealt with this way, depending on timescales.
+
+* Historically, there has been some discussion
+ cite:[LSYRR:04]
+ on how newly supported operations in general-purpose computing might
+ enable new bases for cryptographic algorithms.
+ The standard will not try to anticipate new useful low-level
+ operations which _may_ be useful as building blocks for
+ future cryptographic constructs.
+
+* Regarding side-channel countermeasures:
+ Where relevant, proposed instructions must aim to remove the
+ possibility of any timing side-channels.
+ For side-channels based on power or electro-magnetic (EM) measurements,
+ the extension will not aim to support countermeasures which are
+ implemented above the ISA abstraction layer.
+ Recommendations will be given where relevant on how micro-architectures
+ can implement instructions in a power/EM side-channel resistant way.
+
+[[crypto_scalar_extensions]]
+=== Extensions Overview
+
+The group of extensions introduced by the Scalar Cryptography Instruction Set
+Extension is listed here.
+
+Detection of individual cryptography extensions uses the
+unified software-based RISC-V discovery method.
+
+[NOTE]
+====
+At the time of writing, these discovery mechanisms are still a work in
+progress.
+====
+
+.A note on extension rationale
+[NOTE, caption="SH"]
+====
+Specialist encryption and decryption instructions are separated into different
+functional groups because some use cases (e.g., Galois/Counter
+Mode in TLS 1.3) do not require decryption functionality.
+
+The NIST and ShangMi algorithms suites are separated because their
+usefulness is heavily dependent on the countries a device is expected to
+operate in. NIST ciphers are a part of most standardised internet
+protocols, while ShangMi ciphers are required for use in China.
+====
+
+[[zbkb-sc,Zbkb-sc]]
+==== `Zbkb` - Bitmanip instructions for Cryptography
+
+This extension contains bit-manipulation instructions that are particularly
+useful for cryptography, most of which are also in the `Zbb` extension.
+Please refer to <<b-st-ext.adoc#zbkb>>.
+
+[[zbkc-sc,Zbkc-sc]]
+==== `Zbkc` - Carry-less multiply instructions
+
+Constant time carry-less multiply for Galois/Counter Mode.
+These are separated from the <<b-st-ext.adoc#zbkb>> because they
+have a considerable implementation overhead which cannot be amortised
+across other instructions.
+
+Please refer to <<b-st-ext.adoc#zbkc>>.
+
+[[zbkx-sc,Zbkx-sc]]
+==== `Zbkx` - Crossbar permutation instructions
+
+These instructions are useful for implementing SBoxes in constant time, and
+potentially with DPA protections.
+These are separated from the <<b-st-ext.adoc#zbkb>> because they
+have an implementation overhead which cannot be amortised
+across other instructions.
+
+Please refer to <<b-st-ext.adoc#zbkx>>.
+
+[[zknd,Zknd]]
+==== `Zknd` - NIST Suite: AES Decryption
+
+Instructions for accelerating the decryption and key-schedule functions of
+the AES block cipher.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+| &#10003; | | aes32dsi | <<insns-aes32dsi>>
+| &#10003; | | aes32dsmi | <<insns-aes32dsmi>>
+| | &#10003; | aes64ds | <<insns-aes64ds>>
+| | &#10003; | aes64dsm | <<insns-aes64dsm>>
+| | &#10003; | aes64im | <<insns-aes64im>>
+| | &#10003; | aes64ks1i | <<insns-aes64ks1i>>
+| | &#10003; | aes64ks2 | <<insns-aes64ks2>>
+|===
+
+NOTE: The <<insns-aes64ks1i>> and <<insns-aes64ks2>> instructions are
+present in both the <<zknd>> and <<zkne>> extensions.
+
+[[zkne,Zkne]]
+==== `Zkne` - NIST Suite: AES Encryption
+
+Instructions for accelerating the encryption and key-schedule functions of
+the AES block cipher.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+| &#10003; | | aes32esi | <<insns-aes32esi>>
+| &#10003; | | aes32esmi | <<insns-aes32esmi>>
+| | &#10003; | aes64es | <<insns-aes64es>>
+| | &#10003; | aes64esm | <<insns-aes64esm>>
+| | &#10003; | aes64ks1i | <<insns-aes64ks1i>>
+| | &#10003; | aes64ks2 | <<insns-aes64ks2>>
+|===
+
+NOTE: The
+<<insns-aes64ks1i,`aes64ks1i`>>
+and
+<<insns-aes64ks2,`aes64ks2`>>
+instructions are present in both the <<zknd>> and <<zkne>> extensions.
+
+[[zknh,Zknh]]
+==== `Zknh` - NIST Suite: Hash Function Instructions
+
+Instructions for accelerating the SHA2 family of cryptographic hash functions,
+as specified in cite:[nist:fips:180:4].
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+| &#10003; | &#10003; | sha256sig0 | <<insns-sha256sig0>>
+| &#10003; | &#10003; | sha256sig1 | <<insns-sha256sig1>>
+| &#10003; | &#10003; | sha256sum0 | <<insns-sha256sum0>>
+| &#10003; | &#10003; | sha256sum1 | <<insns-sha256sum1>>
+| &#10003; | | sha512sig0h | <<insns-sha512sig0h>>
+| &#10003; | | sha512sig0l | <<insns-sha512sig0l>>
+| &#10003; | | sha512sig1h | <<insns-sha512sig1h>>
+| &#10003; | | sha512sig1l | <<insns-sha512sig1l>>
+| &#10003; | | sha512sum0r | <<insns-sha512sum0r>>
+| &#10003; | | sha512sum1r | <<insns-sha512sum1r>>
+| | &#10003; | sha512sig0 | <<insns-sha512sig0>>
+| | &#10003; | sha512sig1 | <<insns-sha512sig1>>
+| | &#10003; | sha512sum0 | <<insns-sha512sum0>>
+| | &#10003; | sha512sum1 | <<insns-sha512sum1>>
+|===
+
+[[zksed,Zksed]]
+==== `Zksed` - ShangMi Suite: SM4 Block Cipher Instructions
+
+Instructions for accelerating the SM4 Block Cipher.
+Note that unlike AES, this cipher uses the same core operation for
+encryption and decryption, hence there is only one
+extension for it.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+| &#10003; | &#10003; | sm4ed | <<insns-sm4ed>>
+| &#10003; | &#10003; | sm4ks | <<insns-sm4ks>>
+|===
+
+[[zksh,Zksh]]
+==== `Zksh` - ShangMi Suite: SM3 Hash Function Instructions
+
+Instructions for accelerating the SM3 hash function.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+| &#10003; | &#10003; | sm3p0 | <<insns-sm3p0>>
+| &#10003; | &#10003; | sm3p1 | <<insns-sm3p1>>
+|===
+
+[[zkr,Zkr]]
+==== `Zkr` - Entropy Source Extension
+
+The entropy source extension defines the `seed` CSR at address `0x015`.
+This CSR provides up to 16 physical `entropy` bits that can be used to
+seed cryptographic random bit generators.
+
+See <<crypto_scalar_es>> for the normative specification and access control
+notes. <<crypto_scalar_appx_es>> contains design rationale and further
+recommendations to implementers.
+
+[[zkn,Zkn]]
+==== `Zkn` - NIST Algorithm Suite
+
+This extension is shorthand for the following set of other extensions:
+
+[%header,cols="^1,4"]
+|===
+|Included Extension
+|Description
+
+| <<zbkb-sc>> | Bitmanipulation instructions for cryptography.
+| <<zbkc-sc>> | Carry-less multiply instructions.
+| <<zbkx-sc>> | Cross-bar Permutation instructions.
+| <<zkne>> | AES encryption instructions.
+| <<zknd>> | AES decryption instructions.
+| <<zknh>> | SHA2 hash function instructions.
+|===
+
+A core which implements `Zkn` must implement all of the above extensions.
+
+[[zks,Zks]]
+==== `Zks` - ShangMi Algorithm Suite
+
+This extension is shorthand for the following set of other extensions:
+
+[%header,cols="^1,4"]
+|===
+|Included Extension
+|Description
+
+| <<zbkb-sc>> | Bitmanipulation instructions for cryptography.
+| <<zbkc-sc>> | Carry-less multiply instructions.
+| <<zbkx-sc>> | Cross-bar Permutation instructions.
+| <<zksed>> | SM4 block cipher instructions.
+| <<zksh>> | SM3 hash function instructions.
+|===
+
+A core which implements `Zks` must implement all of the above extensions.
+
+[[zk,Zk]]
+==== `Zk` - Standard scalar cryptography extension
+
+This extension is shorthand for the following set of other extensions:
+
+[%header,cols="^1,4"]
+|===
+|Included Extension
+|Description
+
+| <<zkn>> | NIST Algorithm suite extension.
+| <<zkr>> | Entropy Source extension.
+| <<crypto_scalar_zkt,Zkt>> | Data independent execution latency extension.
+|===
+
+A core which implements `Zk` must implement all of the above extensions.
+
+==== `Zkt` - Data Independent Execution Latency
+
+This extension allows CPU implementers to indicate to
+cryptographic software developers that a subset of RISC-V instructions
+are guaranteed to be implemented such that their execution latency
+is independent of the data values they operate on.
+A complete description of this extension is found in
+<<crypto_scalar_zkt>>.
+
+// ------------------------------------------------------------
+
+[[crypto_scalar_insns, reftext="Scalar Cryptography Instructions"]]
+=== Instructions
+
+[#insns-aes32dsi, reftext="AES final round decrypt (RV32)"]
+==== aes32dsi
+
+Synopsis::
+AES final round decryption instruction for RV32.
+
+Mnemonic::
+aes32dsi rd, rs1, rs2, bs
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x15},
+{bits: 2, name: 'bs'},
+]}
+....
+
+Description::
+This instruction sources a single byte from `rs2` according to `bs`.
+To this it applies the inverse AES SBox operation, and XOR's the result with
+`rs1`.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (AES32DSI (bs,rs2,rs1,rd)) = {
+ let shamt : bits( 5) = bs @ 0b000; /* shamt = bs*8 */
+ let si : bits( 8) = (X(rs2)[31..0] >> shamt)[7..0]; /* SBox Input */
+ let so : bits(32) = 0x000000 @ aes_sbox_inv(si);
+ let result : bits(32) = X(rs1)[31..0] ^ rol32(so, unsigned(shamt));
+ X(rd) = EXTS(result); RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknd>> (RV32)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV32)
+| v1.0.0
+| Ratified
+| <<zk>> (RV32)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-aes32dsmi, reftext="AES middle round decrypt (RV32)"]
+==== aes32dsmi
+
+Synopsis::
+AES middle round decryption instruction for RV32.
+
+Mnemonic::
+aes32dsmi rd, rs1, rs2, bs
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x17},
+{bits: 2, name: 'bs'},
+]}
+....
+
+Description::
+This instruction sources a single byte from `rs2` according to `bs`.
+To this it applies the inverse AES SBox operation, and a partial inverse
+MixColumn, before XOR'ing the result with `rs1`.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (AES32DSMI (bs,rs2,rs1,rd)) = {
+ let shamt : bits( 5) = bs @ 0b000; /* shamt = bs*8 */
+ let si : bits( 8) = (X(rs2)[31..0] >> shamt)[7..0]; /* SBox Input */
+ let so : bits( 8) = aes_sbox_inv(si);
+ let mixed : bits(32) = aes_mixcolumn_byte_inv(so);
+ let result : bits(32) = X(rs1)[31..0] ^ rol32(mixed, unsigned(shamt));
+ X(rd) = EXTS(result); RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknd>> (RV32)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV32)
+| v1.0.0
+| Ratified
+| <<zk>> (RV32)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-aes32esi, reftext="AES final round encrypt (RV32)"]
+==== aes32esi
+
+Synopsis::
+AES final round encryption instruction for RV32.
+
+Mnemonic::
+aes32esi rd, rs1, rs2, bs
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x11},
+{bits: 2, name: 'bs'},
+]}
+....
+
+Description::
+This instruction sources a single byte from `rs2` according to `bs`.
+To this it applies the forward AES SBox operation,
+before XOR'ing the result with `rs1`.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (AES32ESI (bs,rs2,rs1,rd)) = {
+ let shamt : bits( 5) = bs @ 0b000; /* shamt = bs*8 */
+ let si : bits( 8) = (X(rs2)[31..0] >> shamt)[7..0]; /* SBox Input */
+ let so : bits(32) = 0x000000 @ aes_sbox_fwd(si);
+ let result : bits(32) = X(rs1)[31..0] ^ rol32(so, unsigned(shamt));
+ X(rd) = EXTS(result); RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zkne>> (RV32)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV32)
+| v1.0.0
+| Ratified
+| <<zk>> (RV32)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-aes32esmi, reftext="AES middle round encrypt (RV32)"]
+==== aes32esmi
+
+Synopsis::
+AES middle round encryption instruction for RV32.
+
+Mnemonic::
+aes32esmi rd, rs1, rs2, bs
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x13},
+{bits: 2, name: 'bs'},
+]}
+....
+
+Description::
+This instruction sources a single byte from `rs2` according to `bs`.
+To this it applies the forward AES SBox operation, and a partial forward
+MixColumn, before XOR'ing the result with `rs1`.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (AES32ESMI (bs,rs2,rs1,rd)) = {
+ let shamt : bits( 5) = bs @ 0b000; /* shamt = bs*8 */
+ let si : bits( 8) = (X(rs2)[31..0] >> shamt)[7..0]; /* SBox Input */
+ let so : bits( 8) = aes_sbox_fwd(si);
+ let mixed : bits(32) = aes_mixcolumn_byte_fwd(so);
+ let result : bits(32) = X(rs1)[31..0] ^ rol32(mixed, unsigned(shamt));
+ X(rd) = EXTS(result); RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zkne>> (RV32)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV32)
+| v1.0.0
+| Ratified
+| <<zk>> (RV32)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-aes64ds, reftext="AES decrypt final round (RV64)"]
+==== aes64ds
+
+Synopsis::
+AES final round decryption instruction for RV64.
+
+Mnemonic::
+aes64ds rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x1d},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+Uses the two 64-bit source registers to represent the entire AES state,
+and produces _half_ of the next round output, applying the Inverse ShiftRows
+and SubBytes steps.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+.Note To Software Developers
+[NOTE,caption="SH"]
+====
+The following code snippet shows the final round of the AES block decryption.
+`t0` and `t1` hold the current round state.
+`t2` and `t3` hold the next round state.
+
+ aes64ds t2, t0, t1
+ aes64ds t3, t1, t0
+
+Note the reversed register order of the second instruction.
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (AES64DS(rs2, rs1, rd)) = {
+ let sr : bits(64) = aes_rv64_shiftrows_inv(X(rs2)[63..0], X(rs1)[63..0]);
+ let wd : bits(64) = sr[63..0];
+ X(rd) = aes_apply_inv_sbox_to_each_byte(wd);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknd>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-aes64dsm, reftext="AES decrypt middle round (RV64)"]
+==== aes64dsm
+
+Synopsis::
+AES middle round decryption instruction for RV64.
+
+Mnemonic::
+aes64dsm rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x1f},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+Uses the two 64-bit source registers to represent the entire AES state,
+and produces _half_ of the next round output, applying the Inverse ShiftRows,
+SubBytes and MixColumns steps.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+.Note To Software Developers
+[NOTE,caption="SH"]
+====
+The following code snippet shows one middle round of the AES block decryption.
+`t0` and `t1` hold the current round state.
+`t2` and `t3` hold the next round state.
+
+ aes64dsm t2, t0, t1
+ aes64dsm t3, t1, t0
+
+Note the reversed register order of the second instruction.
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (AES64DSM(rs2, rs1, rd)) = {
+ let sr : bits(64) = aes_rv64_shiftrows_inv(X(rs2)[63..0], X(rs1)[63..0]);
+ let wd : bits(64) = sr[63..0];
+ let sb : bits(64) = aes_apply_inv_sbox_to_each_byte(wd);
+ X(rd) = aes_mixcolumn_inv(sb[63..32]) @ aes_mixcolumn_inv(sb[31..0]);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknd>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-aes64es, reftext="AES encrypt final round instruction (RV64)"]
+==== aes64es
+
+Synopsis::
+AES final round encryption instruction for RV64.
+
+Mnemonic::
+aes64es rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x19},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+Uses the two 64-bit source registers to represent the entire AES state,
+and produces _half_ of the next round output, applying the ShiftRows and
+SubBytes steps.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+.Note To Software Developers
+[NOTE,caption="SH"]
+====
+The following code snippet shows the final round of the AES block encryption.
+`t0` and `t1` hold the current round state.
+`t2` and `t3` hold the next round state.
+
+ aes64es t2, t0, t1
+ aes64es t3, t1, t0
+
+Note the reversed register order of the second instruction.
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (AES64ES(rs2, rs1, rd)) = {
+ let sr : bits(64) = aes_rv64_shiftrows_fwd(X(rs2)[63..0], X(rs1)[63..0]);
+ let wd : bits(64) = sr[63..0];
+ X(rd) = aes_apply_fwd_sbox_to_each_byte(wd);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zkne>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-aes64esm, reftext="AES encrypt middle round instruction (RV64)"]
+==== aes64esm
+
+Synopsis::
+AES middle round encryption instruction for RV64.
+
+Mnemonic::
+aes64esm rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x1b},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+Uses the two 64-bit source registers to represent the entire AES state,
+and produces _half_ of the next round output, applying the ShiftRows,
+SubBytes and MixColumns steps.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+.Note To Software Developers
+[NOTE,caption="SH"]
+====
+The following code snippet shows one middle round of the AES block encryption.
+`t0` and `t1` hold the current round state.
+`t2` and `t3` hold the next round state.
+
+ aes64esm t2, t0, t1
+ aes64esm t3, t1, t0
+
+Note the reversed register order of the second instruction.
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (AES64ESM(rs2, rs1, rd)) = {
+ let sr : bits(64) = aes_rv64_shiftrows_fwd(X(rs2)[63..0], X(rs1)[63..0]);
+ let wd : bits(64) = sr[63..0];
+ let sb : bits(64) = aes_apply_fwd_sbox_to_each_byte(wd);
+ X(rd) = aes_mixcolumn_fwd(sb[63..32]) @ aes_mixcolumn_fwd(sb[31..0]);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zkne>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-aes64im, reftext="AES Decrypt KeySchedule MixColumns (RV64)"]
+==== aes64im
+
+Synopsis::
+This instruction accelerates the inverse MixColumns step of the AES
+Block Cipher, and is used to aid creation of the decryption KeySchedule.
+
+Mnemonic::
+aes64im rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x0},
+{bits: 5, name: 0x18},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+The instruction applies the inverse MixColumns
+transformation to two columns of the state array, packed into a single
+64-bit register.
+It is used to create the inverse cipher KeySchedule, according to
+the equivalent inverse cipher construction in
+cite:[nist:fips:197] (Page 23, Section 5.3.5).
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (AES64IM(rs1, rd)) = {
+ let w0 : bits(32) = aes_mixcolumn_inv(X(rs1)[31.. 0]);
+ let w1 : bits(32) = aes_mixcolumn_inv(X(rs1)[63..32]);
+ X(rd) = w1 @ w0;
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknd>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-aes64ks1i, reftext="AES Key Schedule Instruction 1 (RV64)"]
+==== aes64ks1i
+
+Synopsis::
+This instruction implements part of the KeySchedule operation for the
+AES Block cipher involving the SBox operation.
+
+Mnemonic::
+aes64ks1i rd, rs1, rnum
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 4, name: 'rnum'},
+{bits: 1, name: 0x1},
+{bits: 5, name: 0x18},
+{bits: 2, name: 0},
+]}
+....
+
+Description::
+This instruction implements the rotation, SubBytes and Round Constant
+addition steps of the AES block cipher Key Schedule.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+Note that `rnum` must be in the range `0x0..0xA`.
+The values `0xB..0xF` are reserved.
+
+Operation::
+[source,sail]
+--
+function clause execute (AES64KS1I(rnum, rs1, rd)) = {
+ if(unsigned(rnum) > 10) then {
+ handle_illegal(); RETIRE_SUCCESS
+ } else {
+ let tmp1 : bits(32) = X(rs1)[63..32];
+ let rc : bits(32) = aes_decode_rcon(rnum); /* round number -> round constant */
+ let tmp2 : bits(32) = if (rnum ==0xA) then tmp1 else ror32(tmp1, 8);
+ let tmp3 : bits(32) = aes_subword_fwd(tmp2);
+ let result : bits(64) = (tmp3 ^ rc) @ (tmp3 ^ rc);
+ X(rd) = EXTZ(result);
+ RETIRE_SUCCESS
+ }
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zkne>> (RV64)
+| v1.0.0
+| Ratified
+| <<zknd>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-aes64ks2, reftext="AES Key Schedule Instruction 2 (RV64)"]
+==== aes64ks2
+
+Synopsis::
+This instruction implements part of the KeySchedule operation for the
+AES Block cipher.
+
+Mnemonic::
+aes64ks2 rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x1f},
+{bits: 2, name: 0x1},
+]}
+....
+
+Description::
+This instruction implements the additional XOR'ing of key words as
+part of the AES block cipher Key Schedule.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (AES64KS2(rs2, rs1, rd)) = {
+ let w0 : bits(32) = X(rs1)[63..32] ^ X(rs2)[31..0];
+ let w1 : bits(32) = X(rs1)[63..32] ^ X(rs2)[31..0] ^ X(rs2)[63..32];
+ X(rd) = w1 @ w0;
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zkne>> (RV64)
+| v1.0.0
+| Ratified
+| <<zknd>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-andn-sc,reftext="AND with inverted operand"]
+==== andn
+
+Synopsis::
+AND with inverted operand
+
+Mnemonic::
+andn _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x7, attr: ['ANDN']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x20, attr: ['ANDN'] },
+]}
+....
+
+Description::
+This instruction performs the bitwise logical AND operation between _rs1_ and the bitwise inversion of _rs2_.
+
+Operation::
+[source,sail]
+--
+X(rd) = X(rs1) & ~X(rs2);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|1.0.0
+|Ratified
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-brev8-sc,reftext="Reverse bits in bytes"]
+==== brev8
+
+Synopsis::
+Reverse the bits in each byte of a source register.
+
+Mnemonic::
+brev8 _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5 },
+ { bits: 5, name: 'rs' },
+ { bits: 12, name: 0x687 }
+]}
+....
+
+Description::
+This instruction reverses the order of the bits in every byte of a register.
+
+Operation::
+[source,sail]
+--
+result : xlenbits = EXTZ(0b0);
+foreach (i from 0 to sizeof(xlen) by 8) {
+ result[i+7..i] = reverse_bits_in_byte(X(rs1)[i+7..i]);
+};
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-clmul-sc,reftext="Carry-less multiply (low-part)"]
+==== clmul
+
+Synopsis::
+Carry-less multiply (low-part)
+
+Mnemonic::
+clmul _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['CLMUL'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x5, attr: ['MINMAX/CLMUL'] },
+]}
+....
+
+Description::
+clmul produces the lower half of the 2·XLEN carry-less product.
+
+Operation::
+[source,sail]
+--
+let rs1_val = X(rs1);
+let rs2_val = X(rs2);
+let output : xlenbits = 0;
+
+foreach (i from 0 to (xlen - 1) by 1) {
+ output = if ((rs2_val >> i) & 1)
+ then output ^ (rs1_val << i);
+ else output;
+}
+
+X[rd] = output
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbc (<<#zbc>>)
+|1.0.0
+|Ratified
+
+|Zbkc (<<#zbkc-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-clmulh-sc,reftext="Carry-less multiply (high-part)"]
+==== clmulh
+
+Synopsis::
+Carry-less multiply (high-part)
+
+Mnemonic::
+clmulh _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x3, attr: ['CLMULH'] },
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x5, attr: ['MINMAX/CLMUL'] },
+]}
+....
+
+Description::
+clmulh produces the upper half of the 2·XLEN carry-less product.
+
+Operation::
+[source,sail]
+--
+let rs1_val = X(rs1);
+let rs2_val = X(rs2);
+let output : xlenbits = 0;
+
+foreach (i from 1 to xlen by 1) {
+ output = if ((rs2_val >> i) & 1)
+ then output ^ (rs1_val >> (xlen - i));
+ else output;
+}
+
+X[rd] = output
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbc (<<#zbc>>)
+|1.0.0
+|Ratified
+
+|Zbkc (<<#zbkc-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-orn-sc,reftext="OR with inverted operand"]
+==== orn
+
+Synopsis::
+OR with inverted operand
+
+Mnemonic::
+orn _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x6, attr: ['ORN']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x20, attr: ['ORN'] },
+]}
+....
+
+Description::
+This instruction performs the bitwise logical OR operation between _rs1_ and the bitwise inversion of _rs2_.
+
+Operation::
+[source,sail]
+--
+X(rd) = X(rs1) | ~X(rs2);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0.0
+|Ratified
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-pack-sc,reftext="Pack low halves of registers"]
+==== pack
+
+Synopsis::
+Pack the low halves of _rs1_ and _rs2_ into _rd_.
+
+Mnemonic::
+pack _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ {bits: 7, name: 0x33, attr: ['OP'] },
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 0x4, attr:['PACK']},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'rs2'},
+ {bits: 7, name: 0x4, attr:['PACK']},
+]}
+....
+
+Description::
+The pack instruction packs the XLEN/2-bit lower halves of _rs1_ and _rs2_ into
+_rd_, with _rs1_ in the lower half and _rs2_ in the upper half.
+
+Operation::
+[source,sail]
+--
+let lo_half : bits(xlen/2) = X(rs1)[xlen/2-1..0];
+let hi_half : bits(xlen/2) = X(rs2)[xlen/2-1..0];
+X(rd) = EXTZ(hi_half @ lo_half);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-packh-sc,reftext="Pack low bytes of registers"]
+==== packh
+
+Synopsis::
+Pack the low bytes of _rs1_ and _rs2_ into _rd_.
+
+Mnemonic::
+packh _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ {bits: 7, name: 0x33, attr: ['OP'] },
+ {bits: 5, name: 'rd'},
+ {bits: 3, name: 0x7, attr: ['PACKH']},
+ {bits: 5, name: 'rs1'},
+ {bits: 5, name: 'rs2'},
+ {bits: 7, name: 0x4, attr: ['PACKH']},
+]}
+....
+
+Description::
+And the packh instruction packs the least-significant bytes of
+_rs1_ and _rs2_ into the 16 least-significant bits of _rd_,
+zero extending the rest of _rd_.
+
+Operation::
+[source,sail]
+--
+let lo_half : bits(8) = X(rs1)[7..0];
+let hi_half : bits(8) = X(rs2)[7..0];
+X(rd) = EXTZ(hi_half @ lo_half);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-packw-sc,reftext="Pack low 16-bits of registers (RV64)"]
+==== packw
+
+Synopsis::
+Pack the low 16-bits of _rs1_ and _rs2_ into _rd_ on RV64.
+
+Mnemonic::
+packw _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 2, name: 0x3},
+{bits: 5, name: 0xe},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x4},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 7, name: 0x4},
+]}
+....
+
+Description::
+This instruction packs the low 16 bits of
+_rs1_ and _rs2_ into the 32 least-significant bits of _rd_,
+sign extending the 32-bit result to the rest of _rd_.
+This instruction only exists on RV64 based systems.
+
+Operation::
+[source,sail]
+--
+let lo_half : bits(16) = X(rs1)[15..0];
+let hi_half : bits(16) = X(rs2)[15..0];
+X(rd) = EXTS(hi_half @ lo_half);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-rev8-sc,reftext="Byte-reverse register"]
+==== rev8
+
+Synopsis::
+Byte-reverse register
+
+Mnemonic::
+rev8 _rd_, _rs_
+
+Encoding (RV32)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5 },
+ { bits: 5, name: 'rs' },
+ { bits: 12, name: 0x698 }
+]}
+....
+
+Encoding (RV64)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5 },
+ { bits: 5, name: 'rs' },
+ { bits: 12, name: 0x6b8 }
+]}
+....
+
+Description::
+This instruction reverses the order of the bytes in _rs_.
+
+Operation::
+[source,sail]
+--
+let input = X(rs);
+let output : xlenbits = 0;
+let j = xlen - 1;
+
+foreach (i from 0 to (xlen - 8) by 8) {
+ output[i..(i + 7)] = input[(j - 7)..j];
+ j = j - 8;
+}
+
+X[rd] = output
+--
+
+.Note
+[NOTE, caption="A" ]
+===============================================================
+The *rev8* mnemonic corresponds to different instruction encodings in RV32 and RV64.
+===============================================================
+
+.Software Hint
+[NOTE, caption="SH" ]
+===============================================================
+The byte-reverse operation is only available for the full register
+width. To emulate word-sized and halfword-sized byte-reversal,
+perform a `rev8 rd,rs` followed by a `srai rd,rd,K`, where K is
+XLEN-32 and XLEN-16, respectively.
+===============================================================
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0.0
+|Ratified
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-rol-sc,reftext="Rotate left (Register)"]
+==== rol
+
+Synopsis::
+Rotate Left (Register)
+
+Mnemonic::
+rol _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['ROL']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x30, attr: ['ROL'] },
+]}
+....
+
+Description::
+This instruction performs a rotate left of _rs1_ by the amount in least-significant log2(XLEN) bits of _rs2_.
+
+Operation::
+[source,sail]
+--
+let shamt = if xlen == 32
+ then X(rs2)[4..0]
+ else X(rs2)[5..0];
+let result = (X(rs1) << shamt) | (X(rs1) >> (xlen - shamt));
+
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0.0
+|Ratified
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-rolw-sc,reftext="Rotate Left Word (Register)"]
+==== rolw
+
+Synopsis::
+Rotate Left Word (Register)
+
+Mnemonic::
+rolw _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x3b, attr: ['OP-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x1, attr: ['ROLW']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x30, attr: ['ROLW'] },
+]}
+....
+
+Description::
+This instruction performs a rotate left on the least-significant word of _rs1_ by the amount in least-significant 5 bits of _rs2_.
+The resulting word value is sign-extended by copying bit 31 to all of the more-significant bits.
+
+Operation::
+[source,sail]
+--
+let rs1 = EXTZ(X(rs1)[31..0])
+let shamt = X(rs2)[4..0];
+let result = (rs1 << shamt) | (rs1 >> (32 - shamt));
+X(rd) = EXTS(result[31..0]);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0.0
+|Ratified
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-ror-sc, reftext="Rotate right (Register)"]
+==== ror
+
+Synopsis::
+Rotate Right
+
+Mnemonic::
+ror _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['ROR']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x30, attr: ['ROR'] },
+]}
+....
+
+Description::
+This instruction performs a rotate right of _rs1_ by the amount in least-significant log2(XLEN) bits of _rs2_.
+
+Operation::
+[source,sail]
+--
+let shamt = if xlen == 32
+ then X(rs2)[4..0]
+ else X(rs2)[5..0];
+let result = (X(rs1) >> shamt) | (X(rs1) << (xlen - shamt));
+
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0.0
+|Ratified
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-rori-sc,reftext="Rotate right (Immediate)"]
+==== rori
+
+Synopsis::
+Rotate Right (Immediate)
+
+Mnemonic::
+rori _rd_, _rs1_, _shamt_
+
+Encoding (RV32)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['RORI']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'shamt' },
+ { bits: 7, name: 0x30, attr: ['RORI'] },
+]}
+....
+
+Encoding (RV64)::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x13, attr: ['OP-IMM'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['RORI']},
+ { bits: 5, name: 'rs1' },
+ { bits: 6, name: 'shamt' },
+ { bits: 6, name: 0x18, attr: ['RORI'] },
+]}
+....
+
+Description::
+This instruction performs a rotate right of _rs1_ by the amount in the least-significant log2(XLEN) bits of _shamt_.
+For RV32, the encodings corresponding to shamt[5]=1 are reserved.
+
+Operation::
+[source,sail]
+--
+let shamt = if xlen == 32
+ then shamt[4..0]
+ else shamt[5..0];
+let result = (X(rs1) >> shamt) | (X(rs1) << (xlen - shamt));
+
+X(rd) = result;
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0.0
+|Ratified
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-roriw-sc,reftext="Rotate right Word (Immediate)"]
+==== roriw
+
+Synopsis::
+Rotate Right Word by Immediate
+
+Mnemonic::
+roriw _rd_, _rs1_, _shamt_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x1b, attr: ['OP-IMM-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['RORIW']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'shamt' },
+ { bits: 7, name: 0x30, attr: ['RORIW'] },
+]}
+....
+
+Description::
+This instruction performs a rotate right on the least-significant word
+of _rs1_ by the amount in the least-significant log2(XLEN) bits of
+_shamt_.
+The resulting word value is sign-extended by copying bit 31 to all of
+the more-significant bits.
+
+
+Operation::
+[source,sail]
+--
+let rs1_data = EXTZ(X(rs1)[31..0];
+let result = (rs1_data >> shamt) | (rs1_data << (32 - shamt));
+X(rd) = EXTS(result[31..0]);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0.0
+|Ratified
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-rorw-sc,reftext="Rotate right Word (Register)"]
+==== rorw
+
+Synopsis::
+Rotate Right Word (Register)
+
+Mnemonic::
+rorw _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x3b, attr: ['OP-32'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['RORW']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x30, attr: ['RORW'] },
+]}
+....
+
+Description::
+This instruction performs a rotate right on the least-significant word of _rs1_ by the amount in least-significant 5 bits of _rs2_.
+The resultant word is sign-extended by copying bit 31 to all of the more-significant bits.
+
+Operation::
+[source,sail]
+--
+let rs1 = EXTZ(X(rs1)[31..0])
+let shamt = X(rs2)[4..0];
+let result = (rs1 >> shamt) | (rs1 << (32 - shamt));
+X(rd) = EXTS(result);
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0.0
+|Ratified
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-sha256sig0, reftext="SHA2-256 Sigma0 instruction"]
+==== sha256sig0
+
+Synopsis::
+Implements the Sigma0 transformation function as used in
+the SHA2-256 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha256sig0 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x2},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+This instruction is supported for both RV32 and RV64 base architectures.
+For RV32, the entire `XLEN` source register is operated on.
+For RV64, the low `32` bits of the source register are operated on, and the
+result sign extended to `XLEN` bits.
+Though named for SHA2-256, the instruction works for both the
+SHA2-224 and SHA2-256 parameterizations as described in
+cite:[nist:fips:180:4].
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA256SIG0(rs1,rd)) = {
+ let inb : bits(32) = X(rs1)[31..0];
+ let result : bits(32) = ror32(inb, 7) ^ ror32(inb, 18) ^ (inb >> 3);
+ X(rd) = EXTS(result);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>>
+| v1.0.0
+| Ratified
+| <<zkn>>
+| v1.0.0
+| Ratified
+| <<zk>>
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha256sig1, reftext="SHA2-256 Sigma1 instruction"]
+==== sha256sig1
+
+Synopsis::
+Implements the Sigma1 transformation function as used in
+the SHA2-256 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha256sig1 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x3},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+This instruction is supported for both RV32 and RV64 base architectures.
+For RV32, the entire `XLEN` source register is operated on.
+For RV64, the low `32` bits of the source register are operated on, and the
+result sign extended to `XLEN` bits.
+Though named for SHA2-256, the instruction works for both the
+SHA2-224 and SHA2-256 parameterizations as described in
+cite:[nist:fips:180:4].
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA256SIG1(rs1,rd)) = {
+ let inb : bits(32) = X(rs1)[31..0];
+ let result : bits(32) = ror32(inb, 17) ^ ror32(inb, 19) ^ (inb >> 10);
+ X(rd) = EXTS(result);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>>
+| v1.0.0
+| Ratified
+| <<zkn>>
+| v1.0.0
+| Ratified
+| <<zk>>
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha256sum0, reftext="SHA2-256 Sum0 instruction"]
+==== sha256sum0
+
+Synopsis::
+Implements the Sum0 transformation function as used in
+the SHA2-256 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha256sum0 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x0},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+This instruction is supported for both RV32 and RV64 base architectures.
+For RV32, the entire `XLEN` source register is operated on.
+For RV64, the low `32` bits of the source register are operated on, and the
+result sign extended to `XLEN` bits.
+Though named for SHA2-256, the instruction works for both the
+SHA2-224 and SHA2-256 parameterizations as described in
+cite:[nist:fips:180:4].
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA256SUM0(rs1,rd)) = {
+ let inb : bits(32) = X(rs1)[31..0];
+ let result : bits(32) = ror32(inb, 2) ^ ror32(inb, 13) ^ ror32(inb, 22);
+ X(rd) = EXTS(result);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>>
+| v1.0.0
+| Ratified
+| <<zkn>>
+| v1.0.0
+| Ratified
+| <<zk>>
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha256sum1, reftext="SHA2-256 Sum1 instruction"]
+==== sha256sum1
+
+Synopsis::
+Implements the Sum1 transformation function as used in
+the SHA2-256 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha256sum1 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x1},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+This instruction is supported for both RV32 and RV64 base architectures.
+For RV32, the entire `XLEN` source register is operated on.
+For RV64, the low `32` bits of the source register are operated on, and the
+result sign extended to `XLEN` bits.
+Though named for SHA2-256, the instruction works for both the
+SHA2-224 and SHA2-256 parameterizations as described in
+cite:[nist:fips:180:4].
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA256SUM1(rs1,rd)) = {
+ let inb : bits(32) = X(rs1)[31..0];
+ let result : bits(32) = ror32(inb, 6) ^ ror32(inb, 11) ^ ror32(inb, 25);
+ X(rd) = EXTS(result);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>>
+| v1.0.0
+| Ratified
+| <<zkn>>
+| v1.0.0
+| Ratified
+| <<zk>>
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha512sig0h, reftext="SHA2-512 Sigma0 high (RV32)"]
+==== sha512sig0h
+
+Synopsis::
+Implements the _high half_ of the Sigma0 transformation, as
+used in the SHA2-512 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha512sig0h rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0xe},
+{bits: 2, name: 0x1},
+]}
+....
+
+Description::
+This instruction is implemented on RV32 only.
+Used to compute the Sigma0 transform of the SHA2-512 hash function
+in conjunction with the <<insns-sha512sig0l,`sha512sig0l`>> instruction.
+The transform is a 64-bit to 64-bit function, so the input and output
+are each represented by two 32-bit registers.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+[NOTE]
+.Note to software developers
+====
+The entire Sigma0 transform for SHA2-512 may be computed on RV32
+using the following instruction sequence:
+
+ sha512sig0l t0, a0, a1
+ sha512sig0h t1, a1, a0
+
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA512SIG0H(rs2, rs1, rd)) = {
+ X(rd) = EXTS((X(rs1) >> 1) ^ (X(rs1) >> 7) ^ (X(rs1) >> 8) ^
+ (X(rs2) << 31) ^ (X(rs2) << 24) );
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>> (RV32)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV32)
+| v1.0.0
+| Ratified
+| <<zk>> (RV32)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha512sig0l, reftext="SHA2-512 Sigma0 low (RV32)"]
+==== sha512sig0l
+
+Synopsis::
+Implements the _low half_ of the Sigma0 transformation, as
+used in the SHA2-512 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha512sig0l rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0xa},
+{bits: 2, name: 0x1},
+]}
+....
+
+Description::
+This instruction is implemented on RV32 only.
+Used to compute the Sigma0 transform of the SHA2-512 hash function
+in conjunction with the <<insns-sha512sig0h,`sha512sig0h`>> instruction.
+The transform is a 64-bit to 64-bit function, so the input and output
+are each represented by two 32-bit registers.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+[NOTE]
+.Note to software developers
+====
+The entire Sigma0 transform for SHA2-512 may be computed on RV32
+using the following instruction sequence:
+
+ sha512sig0l t0, a0, a1
+ sha512sig0h t1, a1, a0
+
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA512SIG0L(rs2, rs1, rd)) = {
+ X(rd) = EXTS((X(rs1) >> 1) ^ (X(rs1) >> 7) ^ (X(rs1) >> 8) ^
+ (X(rs2) << 31) ^ (X(rs2) << 25) ^ (X(rs2) << 24) );
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>> (RV32)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV32)
+| v1.0.0
+| Ratified
+| <<zk>> (RV32)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha512sig1h, reftext="SHA2-512 Sigma1 high (RV32)"]
+==== sha512sig1h
+
+Synopsis::
+Implements the _high half_ of the Sigma1 transformation, as
+used in the SHA2-512 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha512sig1h rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0xf},
+{bits: 2, name: 0x1},
+]}
+....
+
+Description::
+This instruction is implemented on RV32 only.
+Used to compute the Sigma1 transform of the SHA2-512 hash function
+in conjunction with the <<insns-sha512sig1l,`sha512sig1l`>> instruction.
+The transform is a 64-bit to 64-bit function, so the input and output
+are each represented by two 32-bit registers.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+[NOTE]
+.Note to software developers
+====
+The entire Sigma1 transform for SHA2-512 may be computed on RV32
+using the following instruction sequence:
+
+ sha512sig1l t0, a0, a1
+ sha512sig1h t1, a1, a0
+
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA512SIG1H(rs2, rs1, rd)) = {
+ X(rd) = EXTS((X(rs1) << 3) ^ (X(rs1) >> 6) ^ (X(rs1) >> 19) ^
+ (X(rs2) >> 29) ^ (X(rs2) << 13) );
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>> (RV32)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV32)
+| v1.0.0
+| Ratified
+| <<zk>> (RV32)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha512sig1l, reftext="SHA2-512 Sigma1 low (RV32)"]
+==== sha512sig1l
+
+Synopsis::
+Implements the _low half_ of the Sigma1 transformation, as
+used in the SHA2-512 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha512sig1l rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0xb},
+{bits: 2, name: 0x1},
+]}
+....
+
+Description::
+This instruction is implemented on RV32 only.
+Used to compute the Sigma1 transform of the SHA2-512 hash function
+in conjunction with the <<insns-sha512sig1h,`sha512sig1h`>> instruction.
+The transform is a 64-bit to 64-bit function, so the input and output
+are each represented by two 32-bit registers.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+[NOTE]
+.Note to software developers
+====
+The entire Sigma1 transform for SHA2-512 may be computed on RV32
+using the following instruction sequence:
+
+ sha512sig1l t0, a0, a1
+ sha512sig1h t1, a1, a0
+
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA512SIG1L(rs2, rs1, rd)) = {
+ X(rd) = EXTS((X(rs1) << 3) ^ (X(rs1) >> 6) ^ (X(rs1) >> 19) ^
+ (X(rs2) >> 29) ^ (X(rs2) << 26) ^ (X(rs2) << 13) );
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>> (RV32)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV32)
+| v1.0.0
+| Ratified
+| <<zk>> (RV32)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha512sum0r, reftext="SHA2-512 Sum0 (RV32)"]
+==== sha512sum0r
+
+Synopsis::
+Implements the Sum0 transformation, as
+used in the SHA2-512 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha512sum0r rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x1},
+]}
+....
+
+Description::
+This instruction is implemented on RV32 only.
+Used to compute the Sum0 transform of the SHA2-512 hash function.
+The transform is a 64-bit to 64-bit function, so the input and output
+is represented by two 32-bit registers.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+[NOTE]
+.Note to software developers
+====
+The entire Sum0 transform for SHA2-512 may be computed on RV32
+using the following instruction sequence:
+
+ sha512sum0r t0, a0, a1
+ sha512sum0r t1, a1, a0
+
+Note the reversed source register ordering.
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA512SUM0R(rs2, rs1, rd)) = {
+ X(rd) = EXTS((X(rs1) << 25) ^ (X(rs1) << 30) ^ (X(rs1) >> 28) ^
+ (X(rs2) >> 7) ^ (X(rs2) >> 2) ^ (X(rs2) << 4) );
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>> (RV32)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV32)
+| v1.0.0
+| Ratified
+| <<zk>> (RV32)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha512sum1r, reftext="SHA2-512 Sum1 (RV32)"]
+==== sha512sum1r
+
+Synopsis::
+Implements the Sum1 transformation, as
+used in the SHA2-512 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha512sum1r rd, rs1, rs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x9},
+{bits: 2, name: 0x1},
+]}
+....
+
+Description::
+This instruction is implemented on RV32 only.
+Used to compute the Sum1 transform of the SHA2-512 hash function.
+The transform is a 64-bit to 64-bit function, so the input and output
+is represented by two 32-bit registers.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+[NOTE]
+.Note to software developers
+====
+The entire Sum1 transform for SHA2-512 may be computed on RV32
+using the following instruction sequence:
+
+ sha512sum1r t0, a0, a1
+ sha512sum1r t1, a1, a0
+
+Note the reversed source register ordering.
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA512SUM1R(rs2, rs1, rd)) = {
+ X(rd) = EXTS((X(rs1) << 23) ^ (X(rs1) >> 14) ^ (X(rs1) >> 18) ^
+ (X(rs2) >> 9) ^ (X(rs2) << 18) ^ (X(rs2) << 14) );
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>> (RV32)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV32)
+| v1.0.0
+| Ratified
+| <<zk>> (RV32)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha512sig0, reftext="SHA2-512 Sigma0 instruction (RV64)"]
+==== sha512sig0
+
+Synopsis::
+Implements the Sigma0 transformation function as used in
+the SHA2-512 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha512sig0 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x6},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+This instruction is supported for the RV64 base architecture.
+It implements the Sigma0 transform of the SHA2-512 hash function.
+cite:[nist:fips:180:4].
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA512SIG0(rs1, rd)) = {
+ X(rd) = ror64(X(rs1), 1) ^ ror64(X(rs1), 8) ^ (X(rs1) >> 7);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha512sig1, reftext="SHA2-512 Sigma1 instruction (RV64)"]
+==== sha512sig1
+
+Synopsis::
+Implements the Sigma1 transformation function as used in
+the SHA2-512 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha512sig1 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x7},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+This instruction is supported for the RV64 base architecture.
+It implements the Sigma1 transform of the SHA2-512 hash function.
+cite:[nist:fips:180:4].
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA512SIG1(rs1, rd)) = {
+ X(rd) = ror64(X(rs1), 19) ^ ror64(X(rs1), 61) ^ (X(rs1) >> 6);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha512sum0, reftext="SHA2-512 Sum0 instruction (RV64)"]
+==== sha512sum0
+
+Synopsis::
+Implements the Sum0 transformation function as used in
+the SHA2-512 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha512sum0 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x4},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+This instruction is supported for the RV64 base architecture.
+It implements the Sum0 transform of the SHA2-512 hash function.
+cite:[nist:fips:180:4].
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA512SUM0(rs1, rd)) = {
+ X(rd) = ror64(X(rs1), 28) ^ ror64(X(rs1), 34) ^ ror64(X(rs1) ,39);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sha512sum1, reftext="SHA2-512 Sum1 instruction (RV64)"]
+==== sha512sum1
+
+Synopsis::
+Implements the Sum1 transformation function as used in
+the SHA2-512 hash function cite:[nist:fips:180:4].
+
+Mnemonic::
+sha512sum1 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x5},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+This instruction is supported for the RV64 base architecture.
+It implements the Sum1 transform of the SHA2-512 hash function.
+cite:[nist:fips:180:4].
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (SHA512SUM1(rs1, rd)) = {
+ X(rd) = ror64(X(rs1), 14) ^ ror64(X(rs1), 18) ^ ror64(X(rs1) ,41);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zknh>> (RV64)
+| v1.0.0
+| Ratified
+| <<zkn>> (RV64)
+| v1.0.0
+| Ratified
+| <<zk>> (RV64)
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sm3p0, reftext="SM3 P0 transform"]
+==== sm3p0
+
+Synopsis::
+Implements the _P0_ transformation function as used in
+the SM3 hash function cite:[gbt:sm3,iso:sm3].
+
+Mnemonic::
+sm3p0 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x8},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+This instruction is supported for the RV32 and RV64 base architectures.
+It implements the _P0_ transform of the SM3 hash function cite:[gbt:sm3,iso:sm3].
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+.Supporting Material
+[NOTE]
+====
+This instruction is based on work done in cite:[MJS:LWSHA:20].
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (SM3P0(rs1, rd)) = {
+ let r1 : bits(32) = X(rs1)[31..0];
+ let result : bits(32) = r1 ^ rol32(r1, 9) ^ rol32(r1, 17);
+ X(rd) = EXTS(result);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zksh>>
+| v1.0.0
+| Ratified
+| <<zks>>
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sm3p1, reftext="SM3 P1 transform"]
+==== sm3p1
+
+Synopsis::
+Implements the _P1_ transformation function as used in
+the SM3 hash function cite:[gbt:sm3,iso:sm3].
+
+Mnemonic::
+sm3p1 rd, rs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x13},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0x9},
+{bits: 5, name: 0x8},
+{bits: 2, name: 0x0},
+]}
+....
+
+Description::
+This instruction is supported for the RV32 and RV64 base architectures.
+It implements the _P1_ transform of the SM3 hash function cite:[gbt:sm3,iso:sm3].
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+.Supporting Material
+[NOTE]
+====
+This instruction is based on work done in cite:[MJS:LWSHA:20].
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (SM3P1(rs1, rd)) = {
+ let r1 : bits(32) = X(rs1)[31..0];
+ let result : bits(32) = r1 ^ rol32(r1, 15) ^ rol32(r1, 23);
+ X(rd) = EXTS(result);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zksh>>
+| v1.0.0
+| Ratified
+| <<zks>>
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sm4ed, reftext="SM4 Encrypt/Decrypt Instruction"]
+==== sm4ed
+
+Synopsis::
+Accelerates the block encrypt/decrypt operation of the SM4 block cipher
+cite:[gbt:sm4, iso:sm4].
+
+Mnemonic::
+sm4ed rd, rs1, rs2, bs
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x18},
+{bits: 2, name: 'bs'},
+]}
+....
+
+Description::
+Implements a T-tables in hardware style approach to accelerating the
+SM4 round function.
+A byte is extracted from `rs2` based on `bs`, to which the SBox and
+linear layer transforms are applied, before the result is XOR'd with
+`rs1` and written back to `rd`.
+This instruction exists on RV32 and RV64 base architectures.
+On RV64, the 32-bit result is sign extended to XLEN bits.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (SM4ED (bs,rs2,rs1,rd)) = {
+ let shamt : bits(5) = bs @ 0b000; /* shamt = bs*8 */
+ let sb_in : bits(8) = (X(rs2)[31..0] >> shamt)[7..0];
+ let x : bits(32) = 0x000000 @ sm4_sbox(sb_in);
+ let y : bits(32) = x ^ (x << 8) ^ ( x << 2) ^
+ (x << 18) ^ ((x & 0x0000003F) << 26) ^
+ ((x & 0x000000C0) << 10);
+ let z : bits(32) = rol32(y, unsigned(shamt));
+ let result: bits(32) = z ^ X(rs1)[31..0];
+ X(rd) = EXTS(result);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zksed>>
+| v1.0.0
+| Ratified
+| <<zks>>
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-sm4ks, reftext="SM4 Key Schedule Instruction"]
+==== sm4ks
+
+Synopsis::
+Accelerates the Key Schedule operation of the SM4 block cipher
+cite:[gbt:sm4, iso:sm4].
+
+Mnemonic::
+sm4ks rd, rs1, rs2, bs
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x33},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x0},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 5, name: 0x1a},
+{bits: 2, name: 'bs'},
+]}
+....
+
+Description::
+Implements a T-tables in hardware style approach to accelerating the
+SM4 Key Schedule.
+A byte is extracted from `rs2` based on `bs`, to which the SBox and
+linear layer transforms are applied, before the result is XOR'd with
+`rs1` and written back to `rd`.
+This instruction exists on RV32 and RV64 base architectures.
+On RV64, the 32-bit result is sign extended to XLEN bits.
+This instruction must _always_ be implemented such that its execution
+latency does not depend on the data being operated on.
+
+Operation::
+[source,sail]
+--
+function clause execute (SM4KS (bs,rs2,rs1,rd)) = {
+ let shamt : bits(5) = (bs @ 0b000); /* shamt = bs*8 */
+ let sb_in : bits(8) = (X(rs2)[31..0] >> shamt)[7..0];
+ let x : bits(32) = 0x000000 @ sm4_sbox(sb_in);
+ let y : bits(32) = x ^ ((x & 0x00000007) << 29) ^ ((x & 0x000000FE) << 7) ^
+ ((x & 0x00000001) << 23) ^ ((x & 0x000000F8) << 13) ;
+ let z : bits(32) = rol32(y, unsigned(shamt));
+ let result: bits(32) = z ^ X(rs1)[31..0];
+ X(rd) = EXTS(result);
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+| <<zksed>>
+| v1.0.0
+| Ratified
+| <<zks>>
+| v1.0.0
+| Ratified
+|===
+
+<<<
+
+[#insns-unzip-sc,reftext="Bit deinterleave"]
+==== unzip
+
+Synopsis::
+Place odd and even bits of the source register into upper and lower halves of
+the destination register, respectively.
+
+Mnemonic::
+unzip _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 2, name: 0x3},
+{bits: 5, name: 0x4},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x5},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0xf},
+{bits: 7, name: 0x4},
+]}
+....
+
+Description::
+This instruction scatters all of the odd and even bits of a source word into
+the high and low halves of a destination word.
+It is the inverse of the <<insns-zip-sc,zip>> instruction.
+This instruction is available only on RV32.
+
+Operation::
+[source,sail]
+--
+foreach (i from 0 to xlen/2-1) {
+ X(rd)[i] = X(rs1)[2*i]
+ X(rd)[i+xlen/2] = X(rs1)[2*i+1]
+}
+--
+
+.Software Hint
+[NOTE, caption="SH" ]
+===============================================================
+This instruction is useful for implementing the SHA3 cryptographic
+hash function on a 32-bit architecture, as it implements the
+bit-interleaving operation used to speed up the 64-bit rotations
+directly.
+===============================================================
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb-sc>>) (RV32)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[#insns-xnor-sc,reftext="Exclusive NOR"]
+==== xnor
+
+Synopsis::
+Exclusive NOR
+
+Mnemonic::
+xnor _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x4, attr: ['XNOR']},
+ { bits: 5, name: 'rs1' },
+ { bits: 5, name: 'rs2' },
+ { bits: 7, name: 0x20, attr: ['XNOR'] },
+]}
+....
+
+Description::
+This instruction performs the bit-wise exclusive-NOR operation on _rs1_ and _rs2_.
+
+Operation::
+[source,sail]
+--
+X(rd) = ~(X(rs1) ^ X(rs2));
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbb (<<#zbb>>)
+|v1.0.0
+|Ratified
+
+|Zbkb (<<#zbkb-sc>>)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+[#insns-xperm8-sc,reftext="Crossbar permutation (bytes)"]
+==== xperm8
+
+Synopsis::
+Byte-wise lookup of indices into a vector in registers.
+
+Mnemonic::
+xperm8 _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 2, name: 0x3},
+{bits: 5, name: 0xc},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x4},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 7, name: 0x14},
+]}
+....
+
+Description::
+The xperm8 instruction operates on bytes.
+The _rs1_ register contains a vector of XLEN/8 8-bit elements.
+The _rs2_ register contains a vector of XLEN/8 8-bit indexes.
+The result is each element in _rs2_ replaced by the indexed element in _rs1_,
+or zero if the index into _rs2_ is out of bounds.
+
+Operation::
+[source,sail]
+--
+val xperm8_lookup : (bits(8), xlenbits) -> bits(8)
+function xperm8_lookup (idx, lut) = {
+ (lut >> (idx @ 0b000))[7..0]
+}
+
+function clause execute ( XPERM8 (rs2,rs1,rd)) = {
+ result : xlenbits = EXTZ(0b0);
+ foreach(i from 0 to xlen by 8) {
+ result[i+7..i] = xperm8_lookup(X(rs2)[i+7..i], X(rs1));
+ };
+ X(rd) = result;
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkx (<<#zbkx>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+
+[#insns-xperm4-sc,reftext="Crossbar permutation (nibbles)"]
+==== xperm4
+
+Synopsis::
+Nibble-wise lookup of indices into a vector.
+
+Mnemonic::
+xperm4 _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 2, name: 0x3},
+{bits: 5, name: 0xc},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x2},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'rs2'},
+{bits: 7, name: 0x14},
+]}
+....
+
+Description::
+The xperm4 instruction operates on nibbles.
+The _rs1_ register contains a vector of XLEN/4 4-bit elements.
+The _rs2_ register contains a vector of XLEN/4 4-bit indexes.
+The result is each element in _rs2_ replaced by the indexed element in _rs1_,
+or zero if the index into _rs2_ is out of bounds.
+
+Operation::
+[source,sail]
+--
+val xperm4_lookup : (bits(4), xlenbits) -> bits(4)
+function xperm4_lookup (idx, lut) = {
+ (lut >> (idx @ 0b00))[3..0]
+}
+
+function clause execute ( XPERM4 (rs2,rs1,rd)) = {
+ result : xlenbits = EXTZ(0b0);
+ foreach(i from 0 to xlen by 4) {
+ result[i+3..i] = xperm4_lookup(X(rs2)[i+3..i], X(rs1));
+ };
+ X(rd) = result;
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkx (<<#zbkx>>)
+|v1.0
+|Ratified
+|===
+
+<<<
+
+[#insns-zip-sc,reftext="Bit interleave"]
+==== zip
+
+Synopsis::
+Interleave upper and lower halves of the source register into odd and even
+bits of the destination register, respectively.
+
+Mnemonic::
+zip _rd_, _rs_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 2, name: 0x3},
+{bits: 5, name: 0x4},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 0xf},
+{bits: 7, name: 0x4},
+]}
+....
+
+Description::
+This instruction gathers bits from the high and low halves of the source
+word into odd/even bit positions in the destination word.
+It is the inverse of the <<insns-unzip-sc,unzip>> instruction.
+This instruction is available only on RV32.
+
+Operation::
+[source,sail]
+--
+foreach (i from 0 to xlen/2-1) {
+ X(rd)[2*i] = X(rs1)[i]
+ X(rd)[2*i+1] = X(rs1)[i+xlen/2]
+}
+--
+
+.Software Hint
+[NOTE, caption="SH" ]
+===============================================================
+This instruction is useful for implementing the SHA3 cryptographic
+hash function on a 32-bit architecture, as it implements the
+bit-interleaving operation used to speed up the 64-bit rotations
+directly.
+===============================================================
+
+Included in::
+[%header,cols="4,2,2"]
+|===
+|Extension
+|Minimum version
+|Lifecycle state
+
+|Zbkb (<<#zbkb-sc>>) (RV32)
+|v1.0.0-rc4
+|Ratified
+|===
+
+<<<
+
+[[crypto_scalar_es]]
+=== Entropy Source
+
+The `seed` CSR provides an interface to a NIST SP 800-90B cite:[TuBaKe:18]
+or BSI AIS-31 cite:[KiSc11] compliant physical Entropy Source (ES).
+
+An entropy source, by itself, is not a cryptographically secure Random
+Bit Generator (RBG), but can be used to build standard (and nonstandard)
+RBGs of many types with the help of symmetric cryptography. Expected usage
+is to condition (typically with SHA-2/3) the output from an entropy source and
+use it to seed a cryptographically secure Deterministic Random Bit Generator
+(DRBG) such as AES-based `CTR_DRBG` cite:[BaKe15].
+The combination of an Entropy Source, Conditioning, and a DRBG can be used
+to create random bits securely cite:[BaKeRo:21].
+See <<crypto_scalar_appx_es>> for a non-normative description of a
+certification and self-certification procedures, design rationale, and more
+detailed suggestions on how the entropy source output can be used.
+
+[[crypto_scalar_seed_csr]]
+==== The `seed` CSR
+
+`seed` is an unprivileged CSR located at address `0x015`.
+The 32-bit contents of `seed` are as follows:
+
+[%autowidth.stretch,cols="^,^,<",options="header",]
+|=======================================================================
+|Bits |Name |Description
+
+|`31:30` |`OPST` |Status: `BIST` (00), `WAIT` (01), `ES16` (10), `DEAD`
+(11).
+
+|`29:24` |_reserved_ |For future use by the RISC-V specification.
+
+|`23:16` |_custom_ |Designated for custom and experimental use.
+
+|`15: 0` |`entropy` |16 bits of randomness, only when `OPST=ES16`.
+|=======================================================================
+
+Attempts to access the `seed` CSR using a read-only CSR-access instruction
+(`CSRRS`/`CSRRC` with _rs1_=`x0` or `CSRRSI`/`CSRRCI` with _uimm_=0) raise an
+illegal-instruction exception; any other CSR-access instruction may be used
+to access `seed`.
+The write value (in `rs1` or `uimm`) must be ignored by implementations.
+The purpose of the write is to signal polling and flushing.
+
+Software normally uses the instruction `csrrw rd, seed, x0` to read the `seed`
+CSR.
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 0x73, attr: "SYSTEM"},
+{bits: 5, name: 'rd'},
+{bits: 3, name: 0x1, attr: "CSRRW"},
+{bits: 5, name: 0x0, attr: "x0"},
+{bits: 12, name: 0x15, attr: "seed = 0x015"},
+]}
+....
+
+The `seed` CSR is also access controlled by execution mode, and attempted
+read or write access will raise an illegal-instruction exception outside M mode
+unless access is explicitly granted. See <<crypto_scalar_es_access>> for
+more details.
+
+The status bits `seed[31:30]` = `OPST` may be `ES16` (10),
+indicating successful polling, or one of three entropy polling failure
+statuses `BIST` (00), `WAIT` (01), or `DEAD` (11), discussed below.
+
+Each returned `seed[15:0]` = `entropy` value represents unique randomness
+when `OPST`=`ES16` (`seed[31:30]` = `10`), even if its numerical value is
+the same as that of a previously polled `entropy` value. The implementation
+requirements of `entropy` bits are defined in <<crypto_scalar_es_req>>.
+When `OPST` is not `ES16`, `entropy` must be set to 0.
+An implementation may safely set reserved and custom bits to zeros.
+
+For security reasons, the interface guarantees that secret `entropy`
+words are not made available multiple times. Hence polling (reading) must
+also have the side effect of clearing (wipe-on-read) the `entropy` contents and
+changing the state to `WAIT` (unless there is `entropy`
+immediately available for `ES16`). Other states (`BIST`, `WAIT`, and `DEAD`)
+may be unaffected by polling.
+
+The Status Bits returned in `seed[31:30]`=`OPST`:
+
+* `00` - `BIST`
+indicates that Built-In Self-Test "on-demand" (BIST) testing is being
+performed. If `OPST` returns temporarily to `BIST` from any other
+state, this signals a non-fatal self-test alarm,
+which is non-actionable, apart from being logged.
+Such a `BIST` alarm must be latched until polled at least once to enable
+software to record its occurrence.
+
+* `01` - `WAIT`
+means that a sufficient amount of entropy is not yet available. This
+is not an error condition and may (in fact) be more frequent than ES16
+since physical entropy sources often have low bandwidth.
+
+* `10` - `ES16`
+indicates success; the low bits `seed[15:0]` will have 16 bits of
+randomness (`entropy`), which is guaranteed to meet certain minimum entropy
+requirements, regardless of implementation.
+
+* `11` - `DEAD`
+is an unrecoverable self-test error. This may indicate a hardware
+fault, a security issue, or (extremely rarely) a type-1 statistical
+false positive in the continuous testing procedures. In case of a fatal
+failure, an immediate lockdown may also be an appropriate response in
+dedicated security devices.
+
+**Example.** `0x8000ABCD` is a valid `ES16` status output, with `0xABCD`
+being the `entropy` value. `0xFFFFFFFF` is an invalid output (`DEAD`) with
+no `entropy` value.
+
+[[crypto_scalar_es_state,reftext="Entropy Source State Transition Diagram"]]
+====
+image::es_state.svg[title="Entropy Source state transition diagram.", align="center",scaledwidth=40%]
+Normally the operational state alternates between WAIT
+(no data) and ES16, which means that 16 bits of randomness (`entropy`)
+have been polled. BIST (Built-in Self-Test) only occurs after reset
+or to signal a non-fatal self-test alarm (if reached after WAIT or
+ES16). DEAD is an unrecoverable error state.
+====
+
+[[crypto_scalar_es_req]]
+==== Entropy Source Requirements
+
+The output `entropy` (`seed[15:0]` in ES16 state) is not necessarily
+fully conditioned randomness due to hardware and energy limitations
+of smaller, low-powered implementations. However, minimum requirements are
+defined. The main requirement is that 2-to-1 cryptographic post-processing
+in 256-bit input blocks will yield 128-bit "full entropy" output blocks.
+Entropy source users may make this conservative assumption but are not
+prohibited from using more than twice the number of seed bits relative
+to the desired resulting entropy.
+
+An implementation of the entropy source should meet at least one of the
+following requirements sets in order to be considered a secure and
+safe design:
+
+* <<crypto_scalar_es_req_90b>>: A physical entropy source meeting
+ NIST SP 800-90B cite:[TuBaKe:18] criteria with evaluated min-entropy
+ of 192 bits for each 256 output bits (min-entropy rate 0.75).
+
+* <<crypto_scalar_es_req_ptg2>>: A physical entropy source meeting the
+ AIS-31 PTG.2 cite:[KiSc11] criteria, implying average Shannon entropy
+ rate 0.997. The source must also meet the NIST 800-90B
+ min-entropy rate 192/256 = 0.75.
+
+* <<crypto_scalar_es_req_virt>>: A virtual entropy source is a DRBG
+ seeded from a physical entropy source. It must have at least a
+ 256-bit (Post-Quantum Category 5) internal security level.
+
+All implementations must signal initialization, test mode, and health
+alarms as required by respective standards. This may require the implementer
+to add non-standard (custom) test interfaces in a secure and safe manner,
+an example of which is described in <<crypto_scalar_es_getnoise>>
+
+
+[[crypto_scalar_es_req_90b]]
+===== NIST SP 800-90B / FIPS 140-3 Requirements
+
+All NIST SP 800-90B cite:[TuBaKe:18] required components and health test
+mechanisms must be implemented.
+
+The entropy requirement is satisfied if 128 bits of _full entropy_ can be
+obtained from each 256-bit (16*16 -bit) successful, but possibly
+non-consecutive `entropy` (ES16) output sequence using a vetted conditioning
+algorithm such as a cryptographic hash (See Section 3.1.5.1.1, SP 800-90B
+cite:[TuBaKe:18]). In practice, a min-entropy rate of 0.75 or larger is
+required for this.
+
+Note that 128 bits of estimated input min-entropy does not yield 128 bits of
+conditioned, full entropy in SP 800-90B/C evaluation. Instead, the
+implication is that every 256-bit sequence should have min-entropy of at
+least 128+64 = 192 bits, as discussed in SP 800-90C cite:[BaKeRo:21];
+the likelihood of successfully "guessing" an individual 256-bit output
+sequence should not be higher than 2^-192^ even with (almost)
+unconstrained amount of entropy source data and computational power.
+
+Rather than attempting to define all the mathematical and architectural
+properties that the entropy source must satisfy, we define that the physical
+entropy source be strong and robust enough to pass the equivalent of
+NIST SP 800-90 evaluation and certification for full entropy when
+conditioned cryptographically in ratio 2:1 with 128-bit output blocks.
+
+Even though the requirement is defined in terms of 128-bit full entropy
+blocks, we recommend 256-bit security. This can be accomplished by using
+at least 512 `entropy` bits to initialize a DRBG that has 256-bit security.
+
+[[crypto_scalar_es_req_ptg2]]
+===== BSI AIS-31 PTG.2 / Common Criteria Requirements
+
+For alternative Common Criteria certification (or self-certification),
+AIS 31 PTG.2 class cite:[KiSc11] (Sect. 4.3.) required hardware components
+and mechanisms must be implemented.
+In addition to AIS-31 PTG.2 randomness requirements (Shannon entropy rate of
+0.997 as evaluated in that standard), the overall min-entropy requirement of
+remains, as discussed in <<crypto_scalar_es_req_90b>>. Note that 800-90B
+min-entropy can be significantly lower than AIS-31 Shannon entropy. These
+two metrics should not be equated or confused with each other.
+
+
+[[crypto_scalar_es_req_virt]]
+===== Virtual Sources: Security Requirement
+
+NOTE: A virtual source is not an ISA compliance requirement. It is defined
+for the benefit of the RISC-V security ecosystem so that virtual systems
+may have a consistent level of security.
+
+A virtual source is not a physical entropy source but provides
+additional protection against covert channels, depletion attacks, and host
+identification in operating environments that can not be entirely trusted
+with direct access to a hardware resource. Despite limited trust,
+implementers should try to guarantee that even such environments have
+sufficient entropy available for secure cryptographic operations.
+
+A virtual source traps access to the `seed` CSR, emulates it, or
+otherwise implements it, possibly without direct access to a physical entropy
+source. The output can be cryptographically secure pseudorandomness
+instead of real entropy, but must have at least 256-bit security, as defined
+below. A virtual source is intended especially for guest operating
+systems, sandboxes, emulators, and similar use cases.
+
+As a technical definition, a random-distinguishing attack against
+the output should require computational resources comparable or greater
+than those required for exhaustive key search on a secure block cipher
+with a 256-bit key (e.g., AES 256). This applies to both classical
+and quantum computing models, but only classical information flows.
+The virtual source security requirement maps to Post-Quantum Security
+Category 5 cite:[NI16].
+
+Any implementation of the `seed` CSR that limits the security
+strength shall not reduce it to less than 256 bits. If the security
+level is under 256 bits, then the interface must not be available.
+
+A virtual entropy source does not need to implement `WAIT` or `BIST` states.
+It should fail (`DEAD`) if the host DRBG or entropy source fails and
+there is insufficient seeding material for the host DRBG.
+
+
+[[crypto_scalar_es_access]]
+==== Access Control to `seed`
+
+The `seed` CSR is by default only available in M mode, but can be made
+available to other modes via the `mseccfg.sseed` and `mseccfg.useed`
+access control bits. `sseed` is bit `9` of and `useed` is
+bit `8` of the `mseccfg` CSR.
+Without the corresponding access control bit set to 1, any attempted
+access to `seed` from U, S, or HS modes will raise an illegal-instruction
+exception.
+
+VS and VU modes are present in systems with Hypervisor (H) extension
+implemented. If desired, a hypervisor can emulate accesses to the seed CSR
+from a virtual machine. Attempted access to `seed` from virtual modes
+VS and VU always raises an exception; a read-only instruction causes an
+illegal-instruction exception, while a read-write instruction (that can
+potentially be emulated) causes a virtual-instruction exception only if
+`mseccfg.sseed=1`. Note that `mseccfg.useed` has no effect on the exception
+type for either VS or VU modes.
+
+.Entropy Source Access Control.
+
+[cols="1,1,1,7",options="header",]
+|=======================================================================
+|Mode | `sseed` | `useed` | Description
+
+| M
+| `*`
+| `*`
+| The `seed` CSR is always available in machine mode as normal (with a
+CSR read-write instruction.) Attempted read without a write raises an
+illegal-instruction exception regardless of mode and access control bits.
+
+| U
+| `*`
+| `0`
+| Any `seed` CSR access raises an illegal-instruction exception.
+
+| U
+| `*`
+| `1`
+| The `seed` CSR is accessible as normal. No exception is raised for read-write.
+
+| S/HS
+| `0`
+| `*`
+| Any `seed` CSR access raises an illegal-instruction exception.
+
+
+| S/HS
+| `1`
+| `*`
+| The `seed` CSR is accessible as normal. No exception is raised for read-write.
+
+| VS/VU
+| `0`
+| `*`
+| Any `seed` CSR access raises an illegal-instruction exception.
+
+| VS/VU
+| `1`
+| `*`
+| A read-write `seed` access raises a virtual-instruction exception,
+while other access conditions raise an illegal-instruction exception.
+
+|=======================================================================
+
+
+Systems should implement carefully considered access control policies from
+lower privilege modes to physical entropy sources. The system can trap
+attempted access to `seed` and feed a less privileged client
+_virtual entropy source_ data (<<crypto_scalar_es_req_virt>>) instead of
+invoking an SP 800-90B (<<crypto_scalar_es_req_90b>>) or PTG.2
+(<<crypto_scalar_es_req_ptg2>>) _physical entropy source_. Emulated `seed`
+data generation is made with an appropriately seeded, secure software DRBG.
+See <<crypto_scalar_appx_es_access>> for security considerations related
+to direct access to entropy sources.
+
+Implementations may implement `mseccfg` such that `[s,u]seed` is a read-only
+constant value `0`. Software may discover if access to the `seed` CSR can be
+enabled in U and S mode by writing a `1` to `[s,u]seed` and reading back
+the result.
+
+If S or U mode is not implemented, then the corresponding `[s,u]seed`
+bits of `mseccfg` must be hardwired to zero.
+The `[s,u]seed` bits must have a defined reset value. The system
+must not allow them to be in an undefined state after a reset.
+`mseccfg` exists if `Zkr` is implemented, or if it is required by other
+processor features. If `Zkr` is _not_ implemented, the `[s,u]seed` bits must
+be hardwired to zero.
+
+[[crypto_scalar_zkt]]
+
+=== Data Independent Execution Latency Subset: Zkt
+
+The Zkt extension attests that the machine has data-independent execution
+time for a safe subset of instructions. This property is commonly called
+_"constant-time"_ although should not be taken with that literal meaning.
+
+All currently defined cryptographic instructions (Zk* and Zbk* extensions) are on
+this list, together with a set of relevant supporting instructions from
+I, M, C, and B extensions.
+
+
+.Note to software developers
+[NOTE,caption="SH"]
+====
+Failure to prevent leakage of sensitive parameters via the direct
+timing channel is considered a serious security vulnerability and will
+typically result in a CERT CVE security advisory.
+====
+
+==== Scope and Goal
+
+An "ISA contract" is made between a programmer and the RISC-V implementation
+that Zkt instructions do not leak information about processed secret data
+(plaintext, keying information, or other "sensitive security parameters" --
+FIPS 140-3 term) through differences in execution latency. Zkt does _not_
+define a set of instructions available in the core; it just restricts the
+behaviour of certain instructions if those are implemented.
+
+Currently, the scope of this document is within scalar RV32/RV64 processors.
+Vector cryptography instructions (and appropriate vector support instructions)
+will be added later, as will other security-related functions that wish
+to assert leakage-free execution latency properties.
+
+Loads, stores, conditional branches are excluded, along with a set of
+instructions that are rarely necessary to process secret data. Also excluded
+are instructions for which workarounds exist in standard cryptographic
+middleware due to the limitations of other ISA processors.
+
+The stated goal is that OpenSSL, BoringSSL (Android), the Linux Kernel,
+and similar trusted software will not have directly observable
+timing side channels when compiled and running on a Zkt-enabled RISC-V target.
+The Zkt extension explicitly states many of the common latency assumptions
+made by cryptography developers.
+
+Vendors do not have to implement all of the list's instructions to be Zkt
+compliant; however, if they claim to have Zkt and implement any of the listed instructions, it must have data-independent latency.
+
+For example, many simple RV32I and RV64I cores (without Multiply, Compressed,
+Bitmanip, or Cryptographic extensions) are technically compliant with Zkt.
+A constant-time AES can be implemented on them using "bit-slice" techniques,
+but it will be excruciatingly slow when compared to implementation with AES
+instructions. There are no guarantees that even a bit-sliced cipher
+implementation (largely based on boolean logic instructions) is secure on a
+core without Zkt attestation.
+
+Out-of-order implementations adhering to Zkt are still free to fuse, crack,
+change or even ignore sequences of instructions, so long as the optimisations
+are applied deterministically, and not based on operand data.
+The guiding principle should be that no information about the data being
+operated on should be leaked based on the execution latency.
+
+[NOTE]
+====
+It is left to future extensions or other techniques to tackle the problem
+of data-independent execution in implementations which advanced out-of-order
+capabilities which use value prediction, or which are otherwise data-dependent.
+====
+
+.Note to software developers
+[WARNING,caption="SH"]
+====
+Programming techniques can only mitigate leakage directly caused by
+arithmetic, caches, and branches. Other ISAs have had micro-architectural
+issues such as Spectre, Meltdown, Speculative Store Bypass, Rogue System
+Register Read, Lazy FP State Restore, Bounds Check Bypass Store, TLBleed,
+and L1TF/Foreshadow, etc. See e.g.
+link:https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance[NSA Hardware and Firmware Security Guidance]
+
+It is not within the remit of this proposal to mitigate these
+_micro-architectural_ leakages.
+====
+
+==== Background
+
+* Timing attacks are much more powerful than was realised before the 2010s,
+which has led to a significant mitigation effort in current cryptographic
+code-bases.
+* Cryptography developers use static and dynamic security testing tools
+to trace the handling of secret information and detect occasions where it
+influences a branch or is used for a table lookup.
+* Architectural testing for Zkt can be pragmatic and semi-formal;
+_security by design_ against basic timing attacks can usually be achieved via
+conscious implementation (of relevant iterative multi-cycle instructions or
+instructions composed of micro-ops) in way that avoids data-dependent latency.
+* Laboratory testing may utilize statistical timing attack leakage analysis
+techniques such as those described in ISO/IEC 17825 cite:[IS16].
+* Binary executables should not contain secrets in the instruction encodings
+(Kerckhoffs's principle), so instruction timing may leak information about
+immediates, ordering of input registers, etc. There may be an exception to this
+in systems where a binary loader modifies the executable for purposes of
+relocation -- and it is desirable to keep the execution location (PC) secret.
+This is why instructions such as LUI, AUIPC, and ADDI are on the list.
+* The rules used by audit tools are relatively simple to understand.
+Very briefly; we call the plaintext, secret keys, expanded keys, nonces,
+and other such variables "secrets". A secret variable (arithmetically)
+modifying any other variable/register turns that into a secret too.
+If a secret ends up in address calculation affecting a load or store, that
+is a violation. If a secret affects a branch's condition, that is also a
+violation. A secret variable location or register becomes a non-secret via
+specific zeroization/sanitisation or by being declared ciphertext
+(or otherwise no-longer-secret information). In essence, secrets can only
+"touch" instructions on the Zkt list while they are secrets.
+
+==== Specific Instruction Rationale
+
+* HINT instruction forms (typically encodings with _rd_=`x0`) are excluded from
+the data-independent time requirement.
+* Floating point (F, D, Q, L extensions) are currently excluded from the
+constant-time requirement as they have very few applications in standardised
+cryptography. We may consider adding floating point add, sub, multiply as a
+constant time requirement for some floating point extension in case a specific
+algorithm (such as the PQC Signature algorithm Falcon) becomes critical.
+* Cryptographers typically assume division to be variable-time (while
+multiplication is constant time) and implement their Montgomery reduction
+routines with that assumption.
+* Zicsr, Zifencei are excluded.
+* Some instructions are on the list simply because we see no harm in
+including them in testing scope.
+
+
+==== Programming Information
+
+For background information on secure programming "models", see:
+
+* Thomas Pornin: _"Why Constant-Time Crypto?"_ (A great introduction to timing assumptions.) https://www.bearssl.org/constanttime.html
+* Jean-Philippe Aumasson: _"Guidelines for low-level cryptography software."_
+(A list of recommendations.) https://github.com/veorq/cryptocoding
+* Peter Schwabe: _"Timing Attacks and Countermeasures."_
+(Lecture slides -- nice references.)
+https://summerschool-croatia.cs.ru.nl/2016/slides/PeterSchwabe.pdf
+* Adam Langley: _"ctgrind."_ (This is from 2010 but is still relevant.)
+https://www.imperialviolet.org/2010/04/01/ctgrind.html
+* Kris Kwiatkowski: _"Constant-time code verification with Memory Sanitizer."_
+https://www.amongbytes.com/post/20210709-testing-constant-time/
+* For early examples of timing attack vulnerabilities, see
+https://www.kb.cert.org/vuls/id/997481 and related academic papers.
+
+
+==== Zkt listings
+
+The following instructions are included in the `Zkt` subset
+They are listed here grouped by their original parent extension.
+
+.Note to implementers
+[NOTE, caption="SH"]
+====
+You do not need to implement all of these instructions to implement `Zkt`.
+Rather, every one of these instructions that the core does implement must
+adhere to the requirements of `Zkt`.
+====
+
+===== RVI (Base Instruction Set)
+
+Only basic arithmetic and `slt*` (for carry computations) are included.
+The data-independent timing requirement does not apply to HINT instruction
+encoding forms of these instructions.
+
+[%header,cols="^1,^1,4"]
+|===
+|RV32
+|RV64
+|Mnemonic
+
+| &#10003; | &#10003; | lui _rd_, _imm_
+| &#10003; | &#10003; | auipc _rd_, _imm_
+| &#10003; | &#10003; | addi _rd_, _rs1_, _imm_
+| &#10003; | &#10003; | slti _rd_, _rs1_, _imm_
+| &#10003; | &#10003; | sltiu _rd_, _rs1_, _imm_
+| &#10003; | &#10003; | xori _rd_, _rs1_, _imm_
+| &#10003; | &#10003; | ori _rd_, _rs1_, _imm_
+| &#10003; | &#10003; | andi _rd_, _rs1_, _imm_
+| &#10003; | &#10003; | slli _rd_, _rs1_, _imm_
+| &#10003; | &#10003; | srli _rd_, _rs1_, _imm_
+| &#10003; | &#10003; | srai _rd_, _rs1_, _imm_
+| &#10003; | &#10003; | add _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | sub _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | sll _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | slt _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | sltu _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | xor _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | srl _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | sra _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | or _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | and _rd_, _rs1_, _rs2_
+| | &#10003; | addiw _rd_, _rs1_, _imm_
+| | &#10003; | slliw _rd_, _rs1_, _imm_
+| | &#10003; | srliw _rd_, _rs1_, _imm_
+| | &#10003; | sraiw _rd_, _rs1_, _imm_
+| | &#10003; | addw _rd_, _rs1_, _rs2_
+| | &#10003; | subw _rd_, _rs1_, _rs2_
+| | &#10003; | sllw _rd_, _rs1_, _rs2_
+| | &#10003; | srlw _rd_, _rs1_, _rs2_
+| | &#10003; | sraw _rd_, _rs1_, _rs2_
+|===
+
+===== RVM (Multiply)
+
+Multiplication is included; division and remaindering excluded.
+
+[%header,cols="^1,^1,4"]
+|===
+|RV32
+|RV64
+|Mnemonic
+
+| &#10003; | &#10003; | mul _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | mulh _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | mulhsu _rd_, _rs1_, _rs2_
+| &#10003; | &#10003; | mulhu _rd_, _rs1_, _rs2_
+| | &#10003; | mulw _rd_, _rs1_, _rs2_
+|===
+
+===== RVC (Compressed)
+
+Same criteria as in RVI. Organised by quadrants.
+
+[%header,cols="^1,^1,4"]
+|===
+|RV32
+|RV64
+|Mnemonic
+
+| &#10003; | &#10003; | c.nop
+| &#10003; | &#10003; | c.addi
+| | &#10003; | c.addiw
+| &#10003; | &#10003; | c.lui
+| &#10003; | &#10003; | c.srli
+| &#10003; | &#10003; | c.srai
+| &#10003; | &#10003; | c.andi
+| &#10003; | &#10003; | c.sub
+| &#10003; | &#10003; | c.xor
+| &#10003; | &#10003; | c.or
+| &#10003; | &#10003; | c.and
+| | &#10003; | c.subw
+| | &#10003; | c.addw
+| &#10003; | &#10003; | c.slli
+| &#10003; | &#10003; | c.mv
+| &#10003; | &#10003; | c.add
+|===
+
+===== Zcb Extension
+
+These instructions are compressed versions of I and M instructions that are
+included in Zkt.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+| &#10003; | &#10003; | c.mul | <<insns-c_mul>>
+| &#10003; | &#10003; | c.not | <<insns-c_not>>
+| &#10003; | &#10003; | c.zext.b | <<insns-c_zext_b>>
+|===
+
+===== RVK (Scalar Cryptography)
+
+All K-specific instructions are included.
+Additionally, `seed` CSR latency should be independent of `ES16` state output
+`entropy` bits, as that is a sensitive security parameter.
+See <<crypto_scalar_appx_es_access>>.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+| &#10003; | | aes32dsi | <<insns-aes32dsi>>
+| &#10003; | | aes32dsmi | <<insns-aes32dsmi>>
+| &#10003; | | aes32esi | <<insns-aes32esi>>
+| &#10003; | | aes32esmi | <<insns-aes32esmi>>
+| | &#10003; | aes64ds | <<insns-aes64ds>>
+| | &#10003; | aes64dsm | <<insns-aes64dsm>>
+| | &#10003; | aes64es | <<insns-aes64es>>
+| | &#10003; | aes64esm | <<insns-aes64esm>>
+| | &#10003; | aes64im | <<insns-aes64im>>
+| | &#10003; | aes64ks1i | <<insns-aes64ks1i>>
+| | &#10003; | aes64ks2 | <<insns-aes64ks2>>
+| &#10003; | &#10003; | sha256sig0 | <<insns-sha256sig0>>
+| &#10003; | &#10003; | sha256sig1 | <<insns-sha256sig1>>
+| &#10003; | &#10003; | sha256sum0 | <<insns-sha256sum0>>
+| &#10003; | &#10003; | sha256sum1 | <<insns-sha256sum1>>
+| &#10003; | | sha512sig0h | <<insns-sha512sig0h>>
+| &#10003; | | sha512sig0l | <<insns-sha512sig0l>>
+| &#10003; | | sha512sig1h | <<insns-sha512sig1h>>
+| &#10003; | | sha512sig1l | <<insns-sha512sig1l>>
+| &#10003; | | sha512sum0r | <<insns-sha512sum0r>>
+| &#10003; | | sha512sum1r | <<insns-sha512sum1r>>
+| | &#10003; | sha512sig0 | <<insns-sha512sig0>>
+| | &#10003; | sha512sig1 | <<insns-sha512sig1>>
+| | &#10003; | sha512sum0 | <<insns-sha512sum0>>
+| | &#10003; | sha512sum1 | <<insns-sha512sum1>>
+| &#10003; | &#10003; | sm3p0 | <<insns-sm3p0>>
+| &#10003; | &#10003; | sm3p1 | <<insns-sm3p1>>
+| &#10003; | &#10003; | sm4ed | <<insns-sm4ed>>
+| &#10003; | &#10003; | sm4ks | <<insns-sm4ks>>
+|===
+
+
+===== RVB (Bitmanip)
+
+The <<zbkb-sc>>, <<zbkc-sc>> and <<zbkx-sc>> extensions are included in their entirety.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+| &#10003; | &#10003; | clmul | <<insns-clmul-sc>>
+| &#10003; | &#10003; | clmulh | <<insns-clmulh-sc>>
+| &#10003; | &#10003; | xperm4 | <<insns-xperm4-sc>>
+| &#10003; | &#10003; | xperm8 | <<insns-xperm8-sc>>
+| &#10003; | &#10003; | ror | <<insns-ror-sc>>
+| &#10003; | &#10003; | rol | <<insns-rol-sc>>
+| &#10003; | &#10003; | rori | <<insns-rori-sc>>
+| | &#10003; | rorw | <<insns-rorw-sc>>
+| | &#10003; | rolw | <<insns-rolw-sc>>
+| | &#10003; | roriw | <<insns-roriw-sc>>
+| &#10003; | &#10003; | andn | <<insns-andn-sc>>
+| &#10003; | &#10003; | orn | <<insns-orn-sc>>
+| &#10003; | &#10003; | xnor | <<insns-xnor-sc>>
+| &#10003; | &#10003; | pack | <<insns-pack-sc>>
+| &#10003; | &#10003; | packh | <<insns-packh-sc>>
+| | &#10003; | packw | <<insns-packw-sc>>
+| &#10003; | &#10003; | brev8 | <<insns-brev8-sc>>
+| &#10003; | &#10003; | rev8 | <<insns-rev8-sc>>
+| &#10003; | | zip | <<insns-zip-sc>>
+| &#10003; | | unzip | <<insns-unzip-sc>>
+|===
+
+[[crypto_scalar_appx_rationale]]
+=== Instruction Rationale
+
+This section contains various rationale, design notes and usage
+recommendations for the instructions in the scalar cryptography
+extension. It also tries to record how the designs of instructions were
+derived, or where they were contributed from.
+
+==== AES Instructions
+
+The 32-bit instructions were derived from work in cite:[MJS:LWAES:20] and
+contributed to the RISC-V cryptography extension.
+The 64-bit instructions were developed collaboratively by task group
+members on our mailing list.
+
+Supporting material, including rationale and a design space exploration
+for all of the AES instructions in the specification can be found in the paper
+_"link:https://doi.org/10.46586/tches.v2021.i1.109-136[The design of scalar AES Instruction Set Extensions for RISC-V]"_ cite:[MNPSW:20].
+
+
+==== SHA2 Instructions
+
+These instructions were developed based on academic
+work at the University of Bristol as part of the XCrypto project
+cite:[MPP:19], and contributed to the RISC-V cryptography extension.
+
+The RV32 SHA2-512 instructions were based on this work, and developed
+in cite:[MJS:LWSHA:20], before being contributed in the same way.
+
+==== SM3 and SM4 Instructions
+
+The SM4 instructions were derived from work in cite:[MJS:LWAES:20], and
+are hence very similar to the RV32 AES instructions.
+
+The SM3 instructions were inspired by the SHA2 instructions, and
+based on development work done in cite:[MJS:LWSHA:20], before being
+contributed to the RISC-V cryptography extension.
+
+[[crypto_scalar_zkb]]
+==== Bitmanip Instructions for Cryptography
+
+Many of the primitive operations used in symmetric key cryptography
+and cryptographic hash functions are well supported by the
+RISC-V Bitmanip extensions (see <<bits>>).
+
+NOTE: This section repeats much of the information in
+<<zbkb-sc>>,
+<<zbkc-sc>>
+and
+<<zbkx-sc>>,
+but includes more rationale.
+
+We proposed that the scalar cryptographic extension _reuse_ a
+subset of the instructions from the Bitmanip extensions `Zb[abc]` directly.
+Specifically, this would mean that
+a core implementing
+_either_
+the scalar cryptographic extensions,
+_or_
+the `Zb[abc]`,
+_or_
+both,
+would be required to implement these instructions.
+
+===== Rotations
+
+----
+RV32, RV64: RV64 only:
+ ror rd, rs1, rs2 rorw rd, rs1, rs2
+ rol rd, rs1, rs2 rolw rd, rs1, rs2
+ rori rd, rs1, imm roriw rd, rs1, imm
+----
+
+See <<zbkb>> for details of these instructions.
+
+.Notes to software developers
+[NOTE,caption="SH"]
+====
+Standard bitwise rotation is a primitive operation in many block ciphers
+and hash functions; it features particularly in the ARX (Add, Rotate, Xor)
+class of block ciphers and stream ciphers.
+
+* Algorithms making use of 32-bit rotations:
+ SHA256, AES (Shift Rows), ChaCha20, SM3.
+* Algorithms making use of 64-bit rotations:
+ SHA512, SHA3.
+====
+
+===== Bit & Byte Permutations
+
+----
+RV32, RV64:
+ brev8 rd, rs1
+ rev8 rd, rs1
+----
+
+See <<zbkb>> for details of these instructions.
+
+.Notes to software developers
+[NOTE,caption="SH"]
+====
+Reversing bytes in words is very common in cryptography when setting a
+standard endianness for input and output data.
+Bit reversal within bytes is used for implementing the GHASH component
+of Galois/Counter Mode (GCM) cite:[nist:gcm].
+====
+
+----
+RV32:
+ zip rd, rs1
+ unzip rd, rs1
+----
+
+See <<zbkb>> for details of these instructions.
+
+.Notes to software developers
+[NOTE,caption="SH"]
+====
+These instructions perform a bit-interleave (or de-interleave) operation, and
+are useful for implementing the 64-bit rotations in the
+SHA3 cite:[nist:fips:202] algorithm on
+a 32-bit architecture.
+On RV64, the relevant operations in SHA3 can be done natively using
+rotation instructions, so `zip` and `unzip` are not required.
+====
+
+===== Carry-less Multiply
+
+----
+RV32, RV64:
+ clmul rd, rs1, rs2
+ clmulh rd, rs1, rs2
+----
+
+See <<zbkc>> for details of these instructions.
+See <<crypto_scalar_zkt>> for additional implementation
+requirements for these instructions, related to data independent
+execution latency.
+
+.Notes to software developers
+[NOTE,caption="SH"]
+====
+As is mentioned there, obvious cryptographic use-cases for carry-less
+multiply are for Galois Counter Mode (GCM) block cipher operations.
+GCM is recommended by NIST as a block cipher mode of operation
+cite:[nist:gcm], and is the only _required_ mode for the TLS 1.3
+protocol.
+====
+
+===== Logic With Negate
+
+----
+RV32, RV64:
+ andn rd, rs1, rs2
+ orn rd, rs1, rs2
+ xnor rd, rs1, rs2
+----
+
+See <<zbkb>> for details of these instructions.
+These instructions are useful inside hash functions, block ciphers and
+for implementing software based side-channel countermeasures like masking.
+The `andn` instruction is also useful for constant time word-select
+in systems without the ternary Bitmanip `cmov` instruction.
+
+.Notes to software developers
+[NOTE,caption="SH"]
+====
+In the context of Cryptography, these instructions are useful for:
+SHA3/Keccak Chi step,
+Bit-sliced function implementations,
+Software based power/EM side-channel countermeasures based on masking.
+====
+
+===== Packing
+
+----
+RV32, RV64: RV64:
+ pack rd, rs1, rs2 packw rd, rs1, rs2
+ packh rd, rs1, rs2
+----
+
+See <<zbkb>> for details of these instructions.
+
+.Notes to software developers
+[NOTE,caption="SH"]
+====
+The `pack*` instructions are
+useful for re-arranging halfwords within words, and
+generally getting data into the right shape prior to applying transforms.
+This is particularly useful for cryptographic algorithms which pass inputs
+around as (potentially un-aligned) byte strings, but can operate on words
+made out of those byte strings.
+This occurs (for example) in AES when loading blocks and keys (which may not
+be word aligned) into registers to perform the round functions.
+====
+
+===== Crossbar Permutation Instructions
+
+----
+RV32, RV64:
+ xperm4 rd, rs1, rs2
+ xperm8 rd, rs1, rs2
+----
+
+See <<zbkx>> for a complete description of these instructions.
+
+The `xperm4` instruction operates on nibbles.
+`GPR[rs1]` contains a vector of `XLEN/4` 4-bit elements.
+`GPR[rs2]` contains a vector of `XLEN/4` 4-bit indexes.
+The result is each element in `GPR[rs2]` replaced by the indexed element
+in `GPR[rs1]`, or zero if the index into `GPR[rs2]` is out of bounds.
+
+The `xperm8` instruction operates on bytes.
+`GPR[rs1]` contains a vector of `XLEN/8` 8-bit elements.
+`GPR[rs2]` contains a vector of `XLEN/8` 8-bit indexes.
+The result is each element in `GPR[rs2]` replaced by the indexed element
+in `GPR[rs1]`, or zero if the index into `GPR[rs2]` is out of bounds.
+
+.Notes to software developers
+[NOTE,caption="SH"]
+====
+The instruction can be used to implement arbitrary bit
+permutations.
+For cryptography, they can accelerate bit-sliced implementations,
+permutation layers of block ciphers, masking based countermeasures
+and SBox operations.
+
+Lightweight block ciphers using 4-bit SBoxes include:
+PRESENT cite:[block:present],
+Rectangle cite:[block:rectangle],
+GIFT cite:[block:gift],
+Twine cite:[block:twine],
+Skinny, MANTIS cite:[block:skinny],
+Midori cite:[block:midori].
+
+National ciphers using 8-bit SBoxes include:
+Camellia cite:[block:camellia] (Japan),
+Aria cite:[block:aria] (Korea),
+AES cite:[nist:fips:197] (USA, Belgium),
+SM4 cite:[gbt:sm4] (China)
+Kuznyechik (Russia).
+
+All of these SBoxes can be implemented efficiently, in constant
+time, using the `xperm8` instruction
+footnote:l[link:http://svn.clairexen.net/handicraft/2020/lut4perm/demo02.cc[]].
+Note that this technique is also suitable for masking based
+side-channel countermeasures.
+====
+
+[[crypto_scalar_appx_es]]
+
+=== Entropy Source Rationale and Recommendations
+
+This *non-normative* appendix focuses on the rationale, security,
+self-certification, and implementation aspects of entropy sources. Hence we
+also discuss non-ISA system features that may be needed for cryptographic
+standards compliance and security testing.
+
+==== Checklists for Design and Self-Certification
+
+The security of cryptographic systems is based on secret bits and keys.
+These bits need to be random and originate from cryptographically secure
+Random Bit Generators (RBGs). An Entropy Source (ES) is required to
+construct secure RBGs.
+
+While entropy source implementations do not have to be certified
+designs, RISC-V expects that they behave in a compatible manner and do not
+create unnecessary security risks to users. Self-evaluation and testing
+following appropriate security standards is usually needed to achieve this.
+
+* *ISA Architectural Tests.* Verify, to the extent possible, that RISC-V ISA
+ requirements in this specification are correctly implemented. This includes
+ the state transitions (<<crypto_scalar_es>> and
+ <<crypto_scalar_es_getnoise>>), access control
+ (<<crypto_scalar_es_access>>), and that `seed` ES16 `entropy` words
+ can only be read destructively.
+ The scope of RISC-V ISA architectural tests are those behaviors that
+ are independent of the physical entropy source details. A smoke test ES
+ module may be helpful in design phase.
+* *Technical justification for entropy.* This may take the form of a
+ stochastic model or a heuristic argument that explains why the noise
+ source output is from a random, rather than pseudorandom (deterministic)
+ process, and is not easily predictable or externally observable.
+ A complete physical model is not necessary; research literature can be
+ cited. For example, one can show that a good ring oscillator noise derives
+ an amount of physical entropy from local, spontaneously occurring
+ Johnson-Nyquist thermal noise cite:[Sa21], and is therefore not merely
+ "random-looking".
+* *Entropy Source Design Review.* An entropy source is more than a noise
+ source, and must have features such as health tests
+ (<<crypto_scalar_es_security_controls>>),
+ a conditioner (<<crypto_scalar_appx_es_intro-cond>>), and a security
+ boundary with clearly defined interfaces. One may tabulate the SHALL
+ statements of SP 800-90B cite:[TuBaKe:18], FIPS 140-3 Implementation
+ Guidance cite:[NICC21], AIS-31 cite:[KiSc11] or other standards being
+ used. Official and non-official checklist tables are available:
+ https://github.com/usnistgov/90B-Shall-Statements
+* *Experimental Tests.* The raw noise source is subjected to entropy
+ estimation as defined in NIST 800-90B, Section 3 cite:[TuBaKe:18].
+ The interface described in <<crypto_scalar_es_getnoise>> can used be to
+ record datasets for this purpose. One also needs to show experimentally
+ that the conditioner and health test components work appropriately to
+ meet the ES16 output entropy requirements of <<crypto_scalar_es_req>>.
+ For SP 800-90B, NIST has made a min-entropy estimation
+ package freely available:
+ https://github.com/usnistgov/SP800-90B_EntropyAssessment
+* **Resilience.** Above physical engineering steps should consider the
+ operational environment of the device, which may be unexpected or
+ hostile (actively attempting to exploit vulnerabilities in the design).
+
+See <<crypto_scalar_appx_es_implementation>> for a discussion of various
+implementation options.
+
+NOTE: It is one of the goals of the RISC-V Entropy Source specification
+that a standard 90B Entropy Source Module or AIS-31 RNG IP may be licensed
+from a third party and integrated with a RISC-V processor design. Compared
+to older (FIPS 140-2) RNG and DRBG modules, an entropy source module may
+have a relatively small area (just a few thousand NAND2 gate equivalent).
+CMVP is introducing an "Entropy Source Validation Scope" which potentially
+allows 90B validations to be reused for different (FIPS 140-3) modules.
+
+==== Standards and Terminology
+
+As a fundamental security function, the generation of random numbers is
+governed by numerous standards and technical evaluation methods, the main
+ones being FIPS 140-3 cite:[NI19,NICC21] required for U.S. Federal use,
+and Common Criteria Methodology cite:[Cr17] used in high-security evaluations
+internationally.
+
+Note that FIPS 140-3 is a significantly updated standard compared
+to its predecessor FIPS 140-2 and is only coming into use in the 2020s.
+
+These standards set many of the technical requirements for the RISC-V
+entropy source design, and we use their terminology if possible.
+
+
+[[crypto_scalar_es_fig_rng,reftext="TRNG Components"]]
+====
+image::es_dataflow.svg[align="center",scaledwidth=50%]
+The `seed` CSR provides an Entropy Source (ES) interface, not a stateful
+random number generator. As a result, it can support arbitrary
+security levels. Cryptographic (AES, SHA-2/3) ISA Extensions
+can be used to construct high-speed DRBGs that are seeded from the
+entropy source.
+====
+
+[[crypto_scalar_appx_es_intro-es]]
+===== Entropy Source (ES)
+
+Entropy sources are built by sampling and processing data from a noise
+source (<<crypto_scalar_appx_es_noise_sources>>).
+We will only consider physical sources of true randomness in this work.
+Since these are directly based on natural phenomena and are subject to
+environmental conditions (which may be adversarial), they require features
+that monitor the "health" and quality of those sources.
+
+The requirements for physical entropy sources are specified in
+NIST SP 800-90B cite:[TuBaKe:18] (<<crypto_scalar_es_req_90b>>)
+for U.S. Federal FIPS 140-3 cite:[NI19] evaluations and
+in BSI AIS-31 cite:[KiSc01,KiSc11] (<<crypto_scalar_es_req_ptg2>>)
+for high-security Common Criteria evaluations.
+There is some divergence in the types of health tests and entropy metrics
+mandated in these standards, and RISC-V enables support for both alternatives.
+
+[[crypto_scalar_appx_es_intro-cond]]
+===== Conditioning: Cryptographic and Non-Cryptographic
+
+Raw physical randomness (noise) sources are rarely statistically
+perfect, and some generate very large amounts of bits, which need to be
+"debiased" and reduced to a smaller number of bits. This process is
+called conditioning. A secure hash function is an example of a
+cryptographic conditioner. It is important to note that even though
+hashing may make any data look random, it does not increase its
+entropy content.
+
+Non-cryptographic conditioners and extractors such as von Neumann's
+"debiased coin tossing" cite:[Ne51] are easier to implement
+efficiently but may reduce entropy content (in individual bits removed)
+more than cryptographic hashes, which mix the input entropy very
+efficiently. However, they do not require cryptanalytic or computational
+hardness assumptions and are therefore inherently more future-proof.
+See <<crypto_scalar_appx_es_noncrypto>> for a more detailed
+discussion.
+
+[[crypto_scalar_appx_es_intro-prng]]
+===== Pseudorandom Number Generator (PRNG)
+
+Pseudorandom Number Generators (PRNGs) use deterministic mathematical
+formulas to create abundant random numbers from a smaller amount of
+"seed" randomness. PRNGs are also divided into cryptographic and
+non-cryptographic ones.
+
+Non-cryptographic PRNGs, such as LFSRs and the linear-congruential
+generators found in many programming libraries, may generate statistically
+satisfactory random numbers but must never be used for cryptographic
+keying. This is because they are not designed to resist
+_cryptanalysis_; it is usually possible to take some output and
+mathematically derive the "seed" or the internal state of the PRNG
+from it. This is a security problem since knowledge of the state
+allows the attacker to compute future or past outputs.
+
+[[crypto_scalar_appx_es_intro-drbg]]
+===== Deterministic Random Bit Generator (DRBG)
+
+Cryptographic PRNGs are also known as Deterministic Random Bit
+Generators (DRBGs), a term used by SP 800-90A cite:[BaKe15]. A strong
+cryptographic algorithm such as AES cite:[nist:fips:197] or SHA-2/3
+cite:[nist:fips:202,nist:fips:180:4]
+is used to produce random bits from a seed. The secret
+seed material is like a cryptographic key; determining the seed
+from the DRBG output is as hard as breaking AES or a strong hash function.
+This also illustrates that the seed/key needs to be long enough and
+come from a trusted Entropy Source. The DRBG should still be frequently
+refreshed (reseeded) for forward and backward security.
+
+==== Specific Rationale and Considerations
+
+===== The `seed` CSR
+
+See <<crypto_scalar_seed_csr>>.
+
+The interface was designed to be simple so that a vendor- and
+device-independent driver component (e.g., in Linux kernel,
+embedded firmware, or a cryptographic library) may use `seed` to
+generate truly random bits.
+
+An entropy source does not require a high-bandwidth interface;
+a single DRBG source initialization only requires 512 bits
+(256 bits of entropy), and DRBG output can be shared by any number of
+callers. Once initiated, a DRBG requires new entropy only to mitigate
+the risk of state compromise.
+
+From a security perspective, it is essential that the side effect of
+flushing the secret entropy bits occurs upon reading. Hence we mandate
+a write operation on this particular CSR.
+
+A blocking instruction may have been easier to use, but most users should
+be querying a (D)RBG instead of an entropy source.
+Without a polling-style mechanism, the entropy source could hang for
+thousands of cycles under some circumstances. A `wfi` or `pause`
+mechanism (at least potentially) allows energy-saving sleep on MCUs
+and context switching on higher-end CPUs.
+
+The reason for the particular `OPST = seed[31:0]` two-bit mechanism is to
+provide redundancy. The "fault" bit combinations `11` (`DEAD`) and `00`
+(`BIST`) are more likely for electrical reasons if feature discovery fails
+and the entropy source is actually not available.
+
+The 16-bit bandwidth was a compromise motivated by the desire to
+provide redundancy in the return value, some protection against
+potential Power/EM leakage (further alleviated by the 2:1 cryptographic
+conditioning discussed in <<crypto_scalar_appx_es_crypto-cond>>),
+and the desire to have all of the bits "in the same place" on
+both RV32 and RV64 architectures for programming convenience.
+
+===== NIST SP 800-90B
+
+See <<crypto_scalar_es_req_90b>>.
+
+SP 800-90C cite:[BaKeRo:21] states that each conditioned block of n bits
+is required to have n+64 bits of input entropy to attain full entropy.
+Hence NIST SP 800-90B cite:[TuBaKe:18] min-entropy assessment must
+guarantee at least 128 + 64 = 192 bits input entropy per 256-bit block
+(cite:[BaKeRo:21], Sections 4.1. and 4.3.2).
+Only then a hashing of 16 * 16 = 256 bits from the entropy source
+will produce the desired 128 bits of full entropy. This follows from
+the specific requirements, threat model, and distinguishability proof
+contained in SP 800-90C cite:[BaKeRo:21], Appendix A.
+The implied min-entropy rate is 192/256=12/16=0.75. The expected
+Shannon entropy is much larger.
+
+In FIPS 140-3 / SP 800-90 classification, an RBG2(P) construction is a
+cryptographically secure RBG with continuous access to a physical entropy
+source (`seed`) and output generated by a fully seeded, secure DRBG.
+The entropy source can also be used to build RBG3
+full entropy sources cite:[BaKeRo:21]. The concatenation of output words
+corresponds to the `Get_ES_Bitstring` function.
+
+The 128-bit output block size was selected because that is the output
+size of the CBC-MAC conditioner specified in Appendix F of cite:[TuBaKe:18]
+and also the smallest key size we expect to see in applications.
+
+If NIST SP 800-90B certification is chosen, the entropy source
+should implement at least the health tests defined in
+Section 4.4 of cite:[TuBaKe:18]: the repetition count test and adaptive
+proportion test, or show that the same flaws will be detected
+by vendor-defined tests.
+
+===== BSI AIS-31
+
+See <<crypto_scalar_es_req_ptg2>>.
+
+PTG.2 is one of the security and functionality classes defined in
+BSI AIS 20/31 cite:[KiSc11]. The PTG.2 source requirements work as a
+building block for other types of BSI generators (e.g., DRBGs, or
+PTG.3 TRNG with appropriate software post-processing).
+
+For validation purposes, the PTG.2 requirements may be mapped to
+security controls T1-3 (<<crypto_scalar_es_security_controls>>) and the
+interface as follows:
+
+* P1 *[PTG.2.1]* Start-up tests map to T1 and reset-triggered (on-demand)
+`BIST` tests.
+* P2 *[PTG.2.2]* Continuous testing total failure maps to T2 and the
+`DEAD` state.
+* P3 *[PTG.2.3]* Online tests are continuous tests of T2 – entropy output
+is prevented in the `BIST` state.
+* P4 *[PTG.2.4]* Is related to the design of effective entropy source
+health tests, which we encourage.
+* P5 *[PTG.2.5]* Raw random sequence may be checked via the GetNoise
+interface (<<crypto_scalar_es_getnoise>>).
+* P6 *[PTG.2.6]* Test Procedure A cite:[KiSc11] (Sect 2.4.4.1) is a
+part of the evaluation process, and we suggest self-evaluation using these
+tests even if AIS-31 certification is not sought.
+* P7 *[PTG.2.7]* Average Shannon entropy of "internal random bits"
+exceeds 0.997.
+
+Note how P7 concerns Shannon entropy, not min-entropy as with NIST
+sources. Hence the min-entropy requirement needs to be also stated.
+PTG.2 modules built and certified to the AIS-31 standard can also meet the
+"full entropy" condition after 2:1 cryptographic conditioning, but not
+necessarily so. The technical validation process is somewhat different.
+
+===== Virtual Sources
+
+<<crypto_scalar_es_req_virt>>.
+
+All sources that are not direct physical sources (meeting the SP 800-90B
+or the AIS-31 PTG.2 requirements) need to meet the security requirements
+of virtual entropy sources. It is assumed that a virtual entropy source
+is not a limiting, shared bandwidth resource (but a software DRBG).
+
+DRBGs can be used to feed other (virtual) DRBGs, but that does not
+increase the absolute amount of entropy in the system.
+The entropy source must be able to support current and future security
+standards and applications. The 256-bit requirement maps to
+"Category 5" of NIST Post-Quantum Cryptography (4.A.5
+"Security Strength Categories" in cite:[NI16]) and TOP SECRET schemes
+in Suite B and the newer U.S. Government CNSA Suite cite:[NS15].
+
+[[crypto_scalar_appx_es_access]]
+===== Security Considerations for Direct Hardware Access
+
+<<crypto_scalar_es_access>>.
+
+The ISA implementation and system design must try to ensure that the
+hardware-software interface minimizes avenues for adversarial
+information flow even if not explicitly forbidden in the specification.
+
+For security, virtualization requires both conditioning and DRBG processing
+of physical entropy output. It is recommended if a single physical entropy
+source is shared between multiple different virtual machines or if the
+guest OS is untrusted. A virtual entropy source is significantly more
+resistant to depletion attacks and also lessens the risk from covert channels.
+
+The direct `mseccfg.[s,u]seed` option allows one to draw a security boundary
+around a component in relation to Sensitive Security Parameter (SSP) flows,
+even if that component is not in M mode. This is
+helpful when implementing trusted enclaves. Such modules can enforce the
+entire key lifecycle from birth (in the entropy source) to death
+(zeroization) to occur without the key being passed across the boundary
+to external code.
+
+*Depletion.*
+Active polling may deny the entropy source to another simultaneously
+running consumer. This can (for example) delay the instantiation of that
+virtual machine if it requires entropy to initialize fully.
+
+*Covert Channels.*
+Direct access to a component such as the entropy source can be used to
+establish communication channels across security boundaries. Active
+polling from one consumer makes the resource unavailable WAIT instead of
+ES16 to another (which is polling infrequently). Such interactions can
+be used to establish low-bandwidth channels.
+
+*Hardware Fingerprinting.*
+An entropy source (and its noise source circuits) may have a uniquely
+identifiable hardware "signature." This can be harmless or even useful
+in some applications (as random sources may exhibit Physically Un-clonable
+Function (PUF) -like features)
+but highly undesirable in others (anonymized virtualized environments
+and enclaves). A DRBG masks such statistical features.
+
+*Side Channels.*
+Some of the most devastating practical attacks against real-life
+cryptosystems have used inconsequential-looking additional
+information, such as padding error messages cite:[BaFoKa:12]
+or timing information cite:[MoSuEi:20].
+
+We urge implementers against creating unnecessary information flows
+via status or custom bits or to allow any other mechanism to disable or
+affect the entropy source output. All information flows and interaction
+mechanisms must be considered from an adversarial viewpoint:
+the fewer the better.
+
+As an example of side-channel analysis, we note that the entropy
+polling interface is typically not "constant time." One needs to
+analyze what kind of information is revealed via the timing oracle;
+one way of doing it is to model `seed` as a rejection
+sampler. Such a timing oracle can reveal information about the noise
+source type and entropy source usage, but not about the random output
+`entropy` bits themselves. If it does, additional countermeasures are
+necessary.
+
+[[crypto_scalar_es_security_controls]]
+==== Security Controls and Health Tests
+
+The primary purpose of a cryptographic entropy source is to produce
+secret keying material. In almost all cases, a hardware entropy source
+must implement appropriate _security controls_ to guarantee
+unpredictability, prevent leakage, detect attacks, and deny adversarial
+control over the entropy output or ts generation mechanism. Explicit
+security controls are required for security testing and certification.
+
+Many of the security controls built into the device are called "health
+checks." Health checks can take the form of integrity checks, start-up
+tests, and on-demand tests. These tests can be implemented in hardware
+or firmware, typically both. Several are mandated by standards such as
+NIST SP 800-90B cite:[NI19].
+The choice of appropriate health tests depends on the
+certification target, system architecture, threat model, entropy
+source type, and other factors.
+
+Health checks are not intended for hardware diagnostics but for detecting
+security issues. Hence the default action in case of a failure should be
+aimed at damage control: Limiting further output and preventing weak
+crypto keys from being generated.
+
+We discuss three specific testing requirements T1-T3. The testing requirement
+follows from the definition of an Entropy Source; without it, the module is
+simply a noise source and can't be trusted to safely generate keying material.
+
+===== T1: On-demand testing
+
+A sequence of simple tests is invoked via resetting, rebooting, or
+powering up the hardware (not an ISA signal). The implementation will
+simply return `BIST` during the initial start-up self-test period;
+in any case, the driver must wait for them to finish before starting
+cryptographic operations. Upon failure, the entropy source will enter
+a no-output `DEAD` state.
+
+*Rationale.*
+Interaction with hardware self-test mechanisms
+from the software side should be minimal; the term "on-demand" does not
+mean that the end-user or application program should be able to invoke
+them in the field (the term is a throwback to an age of discrete,
+non-autonomous crypto devices with human operators).
+
+===== T2: Continuous checks
+
+If an error is detected in continuous tests or
+environmental sensors, the entropy source will enter a no-output state.
+We define that a non-critical alarm is signaled if the entropy source
+returns to `BIST` state from live (`WAIT` or `ES16`) states. Critical
+failures will result in `DEAD` state immediately. A hardware-based
+continuous testing mechanism must not make statistical information
+externally available, and it must be zeroized periodically or upon
+demand via reset, power-up, or similar signal.
+
+*Rationale.*
+Physical attacks can occur while the device is running. The design
+should avoid guiding such active attacks by revealing detailed
+status information. Upon detection of an attack, the default action
+should be aimed at damage control -- to prevent weak crypto keys from
+being generated.
+
+The statistical nature of some tests makes "type-1" false
+positives a possibility. There may also be requirements for signaling
+of non-fatal alarms; AIS 31 specifies "noise alarms" that can go off
+with non-negligible probability even if the device is functioning
+correctly; these can be signaled with `BIST`.
+There rarely is anything that can or should be done about a non-fatal
+alarm condition in an operator-free, autonomous system.
+
+The state of statistical runtime health checks (such as counters)
+is potentially correlated with some secret keying material, hence
+the zeroization requirement.
+
+===== T3: Fatal error states
+
+Since the security of most cryptographic operations depends on the
+entropy source, a system-wide "default deny" security policy approach
+is appropriate for most entropy source failures. A hardware test failure
+should at least result in the `DEAD` state and possibly reset/halt.
+It’s a show stopper: The entropy source (or its cryptographic client
+application) _must not_ be allowed to run if its secure operation
+can’t be guaranteed.
+
+*Rationale.*
+These tests can complement other integrity and tamper resistance
+mechanisms (See Chapter 18 of cite:[An20] for examples).
+
+Some hardware random generators are, by their physical construction,
+exposed to relatively non-adversarial environmental and manufacturing
+issues. However, even such "innocent" failure modes may indicate
+a _fault attack_ cite:[KaScVe13] and therefore should be addressed
+as a system integrity failure rather than as a diagnostic issue.
+
+Security architects will understand to use
+permanent or hard-to-recover "security-fuse" lockdowns only if the
+threshold of a test is such that the probability of false-positive is
+negligible over the entire device lifetime.
+
+===== Information Flows
+
+Some of the most devastating practical attacks
+against real-life cryptosystems have used inconsequential-looking
+additional information, such as padding error messages cite:[BaFoKa:12]
+or timing information cite:[MoSuEi:20]. In cryptography, such
+out-of-band information sources are called "oracles."
+
+To guarantee that no sensitive data is read twice and that different
+callers don’t get correlated output, it is required that hardware
+implements _wipe-on-read_ on the randomness pathway during each read
+(successful poll). For the same reasons, only complete and fully
+processed random words shall be made available via `entropy` (ES16 status
+of `seed`).
+
+This also applies to the raw noise source. The raw source interface has
+been delegated to an optional vendor-specific test interface.
+Importantly the test interface and the main interface should not be
+operational at the same time.
+
+[quote, NIST SP 800-90B, Noise Source Requirements]
+The noise source state shall be protected from adversarial
+knowledge or influence to the greatest extent possible. The methods
+used for this shall be documented, including a description of the
+(conceptual) security boundary's role in protecting the noise source
+from adversarial observation or influence.
+
+An entropy source is a singular resource, subject to depletion
+and also covert channels cite:[EvPo16]. Observation of the entropy
+can be the same as the observation of the noise source output, as
+cryptographic conditioning is mandatory only as a post-processing step.
+SP 800-90B and other security standards mandate protection of
+noise bits from observation and also influence.
+
+[[crypto_scalar_appx_es_implementation]]
+==== Implementation Strategies
+
+As a general rule, RISC-V specifies the ISA only. We provide some
+additional suggestions so that portable, vendor-independent middleware
+and kernel components can be created. The actual hardware implementation
+and certification are left to vendors and circuit designers;
+the discussion in this Section is purely informational.
+
+When considering implementation options and trade-offs, one must look
+at the entire information flow.
+
+. *A Noise Source* generates private, unpredictable signals
+ from stable and well-understood physical random events.
+. *Sampling* digitizes the noise signal into a raw stream of
+ bits. This raw data also needs to be protected by the design.
+. *Continuous health tests* ensure that the noise source
+ and its environment meet their operational parameters.
+. *Non-cryptographic conditioners* remove much of the bias
+ and correlation in input noise.
+. *Cryptographic conditioners* produce full entropy
+ output, completely indistinguishable from ideal random.
+. *DRBG* takes in `>=256` bits of seed entropy as keying
+ material and uses a "one way" cryptographic process to rapidly
+ generate bits on demand (without revealing the seed/state).
+
+Steps 1-4 (possibly 5) are considered to be part of the Entropy
+Source (ES) and provided by the `seed` CSR.
+Adding the software-side cryptographic steps 5-6 and control logic
+complements it into a True Random Number Generator (TRNG).
+
+[[crypto_scalar_appx_es_noise_sources]]
+===== Ring Oscillators
+
+We will give some examples of common noise sources that can be
+implemented in the processor itself (using standard cells).
+
+The most common entropy source type in production use today is
+based on "free running" ring oscillators and their timing jitter.
+Here, an odd number of inverters is connected into a loop from which
+noise source bits are sampled in relation to a reference clock
+cite:[BaLuMi:11]. The sampled bit sequence may be expected to be
+relatively uncorrelated (close to IID) if the sample rate is suitably low
+cite:[KiSc11]. However, further processing is usually required.
+
+AMD cite:[AM17], ARM cite:[AR17], and IBM cite:[LiBaBo:13] are
+examples of ring oscillator TRNGs intended for high-security
+applications.
+
+There are related metastability-based generator designs such as
+Transition Effect Ring Oscillator (TERO) cite:[VaDr10].
+The differential/feedback Intel construction cite:[HaKoMa12] is slightly
+different but also falls into the same general metastable
+oscillator-based category.
+
+The main benefits of ring oscillators are: (1) They can be implemented
+with standard cell libraries without external components --
+and even on FPGAs cite:[VaFiAu:10], (2) there is an established theory
+for their behavior cite:[HaLe98,HaLiLe99,BaLuMi:11], and (3) ample
+precedent exists for testing and certifying them at the highest security
+levels.
+
+Ring oscillators also have well-known implementation pitfalls.
+Their output is sometimes highly dependent on temperature,
+which must be taken into account in testing and modeling.
+If the ring oscillator construction is parallelized, it is important
+that the number of stages and/or inverters in each chain is suitable to
+avoid entropy reduction due to harmonic "Huyghens synchronization"
+cite:[Ba86].
+Such harmonics can also be inserted maliciously in a frequency
+injection attack, which can have devastating results cite:[MaMo09].
+Countermeasures are related to circuit design; environmental sensors,
+electrical filters, and usage of a differential oscillator may help.
+
+===== Shot Noise
+
+A category of random sources consisting of discrete events
+and modeled as a Poisson process is called "shot noise."
+There's a long-established precedent of certifying them; the
+AIS 31 document cite:[KiSc11] itself offers reference designs based on
+noisy diodes. Shot noise sources are often more resistant to
+temperature changes than ring oscillators.
+Some of these generators can also be fully implemented with standard
+cells (The Rambus / Inside Secure generic TRNG IP cite:[Ra20] is
+described as a Shot Noise generator).
+
+===== Other types of noise
+
+It may be possible to certify more exotic noise sources and designs,
+although their stochastic model needs to be equally well understood,
+and their CPU interfaces must be secure.
+See <<crypto_scalar_appx_es_quantum>> for a discussion of Quantum
+entropy sources.
+
+[[crypto_scalar_appx_es_cont-tests]]
+===== Continuous Health Tests
+
+Health monitoring requires some state information related
+to the noise source to be maintained. The tests should be designed
+in a way that a specific number of samples guarantees a state
+flush (no hung states). We suggest flush size `W =< 1024` to
+match with the NIST SP 800-90B required tests (See Section 4.4 in
+cite:[TuBaKe:18]). The state is also fully zeroized in a system reset.
+
+The two mandatory tests can be built with minimal circuitry.
+Full histograms are not required, only simple counter registers:
+repetition count, window count, and sample count.
+Repetition count is reset every time the output sample value
+changes; if the count reaches a certain cutoff limit, a noise alarm
+(`BIST`) or failure (`DEAD`) is signaled. The window counter is
+used to save every W'th output (typically `W` in { 512, 1024 }).
+The frequency of this reference sample in the following window is
+counted; cutoff values are defined in the standard. We see that the
+structure of the mandatory tests is such that, if well implemented,
+no information is carried beyond a limit of `W` samples.
+
+Section 4.5 of cite:[TuBaKe:18] explicitly permits additional
+developer-defined tests, and several more were defined in early
+versions of FIPS 140-1 before being "crossed out." The choice
+of additional tests depends on the nature and implementation of the
+physical source.
+
+Especially if a non-cryptographic conditioner is used in hardware,
+it is possible that the AIS 31 cite:[KiSc11] online tests are
+implemented by driver software. They can also be implemented in hardware.
+For some security profiles, AIS 31 mandates that their tolerances are
+set in a way that the probability of an alarm is at least 10^-6^
+yearly under "normal usage." Such requirements are problematic
+in modern applications since their probability is too high for
+critical systems.
+
+There rarely is anything that can or should be done about a non-fatal
+alarm condition in an operator-free, autonomous system. However,
+AIS 31 allows the DRBG component to keep running despite a failure in
+its Entropy Source, so we suggest re-entering a temporary `BIST`
+state (<<crypto_scalar_es_security_controls>>) to signal a non-fatal
+statistical error if such (non-actionable) signaling is necessary.
+Drivers and applications can react to this appropriately (or simply
+log it), but it will not directly affect the availability of the TRNG.
+A permanent error condition should result in `DEAD` state.
+
+[[crypto_scalar_appx_es_noncrypto]]
+===== Non-cryptographic Conditioners
+
+As noted in <<crypto_scalar_appx_es_intro-cond>>, physical randomness
+sources generally require a post-processing step called _conditioning_ to
+meet the desired quality requirements, which are outlined in
+<<crypto_scalar_es_req>>.
+
+The approach taken in this interface is to allow a combination of
+non-cryptographic and cryptographic filtering to take place. The
+first stage (hardware) merely needs to be able to distill the entropy
+comfortably above the necessary level.
+
+* One may take a set of bits from a noise source and XOR them
+ together to produce a less biased (and more independent) bit.
+ However, such an XOR may introduce "pseudorandomness" and
+ make the output difficult to analyze.
+* The von Neumann extractor cite:[Ne51] looks at consecutive
+ pairs of bits, rejects 00 and 11, and outputs 0 or 1 for
+ 01 and 10, respectively. It will reduce the number of bits to
+ less than 25% of the original, but the output is provably unbiased
+ (assuming independence).
+* Blum's extractor cite:[Bl86] can be used on sources
+ whose behavior resembles N-state Markov chains. If its
+ assumptions hold, it also removes dependencies, creating an
+ independent and identically distributed (IID) source.
+* Other linear and non-linear correctors such as those
+ discussed by Dichtl and Lacharme cite:[La08].
+
+Note that the hardware may also implement a full cryptographic conditioner
+in the entropy source, even though the software driver still needs
+a cryptographic conditioner, too (<<crypto_scalar_es_req>>).
+
+*Rationale:*
+The main advantage of non-cryptographic extractors is in their
+energy efficiency, relative simplicity, and amenability to mathematical
+analysis. If well designed, they can be evaluated in
+conjunction with a stochastic model of the noise source itself.
+They do not require computational hardness assumptions.
+
+[[crypto_scalar_appx_es_crypto-cond]]
+===== Cryptographic Conditioners
+
+For secure use, cryptographic conditioners are always required on the
+software side of the ISA boundary. They may also be implemented on the
+hardware side if necessary. In any case, the `entropy` ES16 output must
+always be compressed 2:1 (or more) before being used as keying material
+or considered "full entropy."
+
+Examples of cryptographic conditioners include the random pool of the
+Linux operating system, secure hash functions (SHA-2/3, SHAKE
+cite:[nist:fips:202,nist:fips:180:4]), and the AES / CBC-MAC
+construction in Appendix F, SP 800-90B cite:[TuBaKe:18].
+
+In some constructions, such as the Linux RNG and SHA-3/SHAKE
+cite:[nist:fips:202] based generators, the cryptographic conditioning
+and output (DRBG) generation are provided by the same component.
+
+*Rationale:*
+For many low-power targets constructions the type of hardware AES CBC-MAC
+conditioner used by Intel cite:[Me18] and AMD cite:[AM17] would be too
+complex and energy-hungry to implement solely to serve the `seed` CSR.
+On the other hand, simpler non-cryptographic conditioners may be too
+wasteful on input entropy if high-quality random output is required --
+(ARM TrustZone TRBG cite:[AR17] outputs only 10Kbit/sec at 200 MHz.)
+Hence a resource-saving compromise is made between hardware and software
+generation.
+
+[[crypto_scalar_appx_es_drbgs]]
+===== The Final Random: DRBGs
+
+All random bits reaching end users and applications must come from a
+cryptographic DRBG. These are generally implemented by the driver
+component in software. The RISC-V AES and SHA instruction set extensions
+should be used if available since they offer additional
+security features such as timing attack resistance.
+
+Currently recommended DRBGs are defined in NIST SP 800-90A (Rev 1)
+cite:[BaKe15]: `CTR_DRBG`, `Hash_DRBG`, and `HMAC_DRBG`.
+Certification often requires known answer tests (KATs) for the symmetric
+components and the DRBG as a whole. These are significantly easier to
+implement in software than in hardware. In addition to the directly
+certifiable SP 800-90A DRBGs, a Linux-style random pool construction
+based on ChaCha20 cite:[Mu20] can be used, or an appropriate construction
+based on SHAKE256 cite:[nist:fips:202].
+
+These are just recommendations; programmers can adjust the usage of the
+CPU Entropy Source to meet future requirements.
+
+[[crypto_scalar_appx_es_quantum]]
+===== Quantum vs. Classical Random
+
+[quote,U.K. NCSC QRNG Guidance, March 2020]
+The NCSC believes that classical RNGs will continue to
+meet our needs for government and military applications for the
+foreseeable future.
+
+A Quantum Random Number Generator (QRNG) is a TRNG whose source of
+randomness can be unambiguously identified to be a specific
+quantum phenomenon such as quantum state superposition, quantum state
+entanglement, Heisenberg uncertainty, quantum tunneling, spontaneous
+emission, or radioactive decay cite:[IT19].
+
+Direct quantum entropy is theoretically the best possible kind of
+entropy. A typical TRNG based on electronic noise is also largely
+based on quantum phenomena and is equally unpredictable - the difference
+is that the relative amount of quantum and classical physics involved is
+difficult to quantify for a classical TRNG.
+
+QRNGs are designed in a way that allows the amount of quantum-origin
+entropy to be modeled and estimated. This distinction is important in
+the security model used by QKD (Quantum Key Distribution) security
+mechanisms which can be used to protect the physical layer (such as
+fiber optic cables) against interception by using quantum mechanical
+effects directly.
+
+This security model means that many of the available QRNG devices do
+not use cryptographic conditioning and may fail cryptographic statistical
+requirements cite:[HuHe20]. Many implementers may consider them to be
+entropy sources instead.
+
+Relatively little research has gone into QRNG implementation security,
+but many QRNG designs are arguably more susceptible to leakage than
+classical generators (such as ring oscillators) as they tend to employ
+external components and mixed materials. As an example, amplification of
+a photon detector signal may be observable in power analysis,
+which classical noise-based sources are designed to resist.
+
+===== Post-Quantum Cryptography
+
+PQC public-key cryptography standards cite:[NI16] do not require
+quantum-origin randomness, just sufficiently secure keying material.
+Recall that cryptography aims to protect the confidentiality and
+integrity of data itself and does not place any requirements on
+the physical communication channel (like QKD).
+
+Classical good-quality TRNGs are perfectly suitable
+for generating the secret keys for PQC protocols that are hard for
+quantum computers to break but implementable on classical computers.
+What matters in cryptography is that the secret keys have enough true
+randomness (entropy) and that they are generated and stored securely.
+
+Of course, one must avoid DRBGs that are based on problems that are
+easily solvable with quantum computers, such as factoring cite:[Sh94]
+in the case of the Blum-Blum-Shub generator cite:[BlBlSh86].
+Most symmetric algorithms are not affected as the best quantum
+attacks are still exponential to key size cite:[Gr96].
+
+As an example, the original Intel RNG cite:[Me18], whose output generation
+is based on AES-128, can be attacked using Grover's algorithm
+with approximately square-root effort cite:[JaNaRo:20].
+While even "64-bit" quantum security is extremely difficult to
+break, many applications specify a higher security requirement.
+NIST cite:[NI16] defines AES-128 to be "Category 1" equivalent
+post-quantum security, while AES-256 is "Category 5" (highest).
+We avoid this possible future issue by exposing direct access
+to the entropy source which can derive its security from
+information-theoretic assumptions only.
+
+[[crypto_scalar_es_getnoise]]
+==== Suggested GetNoise Test Interface
+
+Compliance testing, characterization, and configuration of entropy sources
+require access to raw, unconditioned noise samples. This conceptual test
+interface is named GetNoise in Section 2.3.2 of NIST SP 800-90B
+cite:[TuBaKe:18].
+
+Since this type of interface is both necessary for security testing
+and also constitutes a potential backdoor to the cryptographic key generation
+process, we define a safety behavior that compliant implementations can
+have for temporarily disabling the entropy source `seed` CSR interface during
+test.
+
+In order for shared RISC-V self-certification scripts (and drivers) to
+accommodate the test interface in a secure fashion, we suggest that it is
+implemented as a custom, M-mode only CSR, denoted here as `mnoise`.
+
+This non-normative interface is not intended to be used as a source of
+randomness or for other production use.
+We define the semantics for single bit for this interface, `mnoise[31]`,
+which is named `NOISE_TEST`, which will affect the behavior of `seed`
+if implemented.
+
+When `NOISE_TEST = 1` in `mnoise`, the `seed` CSR must not return
+anything via `ES16`; it should be in `BIST` state unless the source
+is `DEAD`. When `NOISE_TEST` is again disabled, the entropy source
+shall return from `BIST` via an appropriate zeroization and self-test
+mechanism.
+
+The behavior of other input and output bits is largely left to the vendor
+(as they depend on the technical details of the physical entropy source),
+as is the address of the custom `mnoise` CSR. Other contents and behavior of the
+CSR only can be interpreted in the context of `mvendorid`, `marchid`, and
+`mimpid` CSR identifiers.
+
+When not implemented (e.g., in virtual machines), `mnoise` can permanently
+read zero (`0x00000000`) and ignore writes.
+When available, but `NOISE_TEST = 0`, `mnoise` can return a
+nonzero constant (e.g. `0x00000001`) but no noise samples.
+
+[[crypto_scalar_es_noistest,reftext="Custom Entropy Test Mode Diagram"]]
+====
+image::es_noisetest.svg[title="Entropy source can't be read in test mode.", align="center",scaledwidth=66%]
+In `NOISE_TEST` mode, the WAIT and ES16 states are unreachable,
+and no entropy is output. Implementation of test interfaces that directly
+affect ES16 entropy output from the `seed` CSR interface is discouraged.
+Such vendor test interfaces have been exploited in attacks. For example,
+an ECDSA cite:[nist:fips:186:4] signature process without sufficient
+entropy will not only create an insecure signature but can also reveal
+the secret signing key, that can be used for authentication forgeries by
+attackers. Hence even a temporary lapse in `entropy` security may have serious
+security implications.
+====
+
+[[crypto_scalar_appx_materials]]
+=== Supplementary Materials
+
+While this document contains the specifications for the RISC-V cryptography
+extensions, numerous supplementary materials and example codes have
+also been developed.
+All of the materials related to the RISC-V Cryptography
+extension live in a GitHub Repository, located at
+https://github.com/riscv/riscv-crypto
+
+* `doc/`
+ Contains the source code for this document.
+
+* `doc/supp/`
+ Contains supplementary information and recommendations for implementers of
+ software and hardware.
+
+* `benchmarks/`
+ Example software implementations.
+
+* `rtl/`
+ Example Verilog implementations of each instruction.
+
+* `sail/`
+ Formal model implementations in Sail.
+
+[[crypto_scalar_appx_sail]]
+=== Supporting Sail Code
+
+This section contains the supporting Sail code referenced by the
+instruction descriptions throughout the specification.
+The
+link:https://alasdair.github.io/manual.html[Sail Manual]
+is recommended reading in order to best understand the supporting code.
+
+[source,sail]
+----
+/* Auxiliary function for performing GF multiplication */
+val xt2 : bits(8) -> bits(8)
+function xt2(x) = {
+ (x << 1) ^ (if bit_to_bool(x[7]) then 0x1b else 0x00)
+}
+
+val xt3 : bits(8) -> bits(8)
+function xt3(x) = x ^ xt2(x)
+
+/* Multiply 8-bit field element by 4-bit value for AES MixCols step */
+val gfmul : (bits(8), bits(4)) -> bits(8)
+function gfmul( x, y) = {
+ (if bit_to_bool(y[0]) then x else 0x00) ^
+ (if bit_to_bool(y[1]) then xt2( x) else 0x00) ^
+ (if bit_to_bool(y[2]) then xt2(xt2( x)) else 0x00) ^
+ (if bit_to_bool(y[3]) then xt2(xt2(xt2(x))) else 0x00)
+}
+
+/* 8-bit to 32-bit partial AES Mix Column - forwards */
+val aes_mixcolumn_byte_fwd : bits(8) -> bits(32)
+function aes_mixcolumn_byte_fwd(so) = {
+ gfmul(so, 0x3) @ so @ so @ gfmul(so, 0x2)
+}
+
+/* 8-bit to 32-bit partial AES Mix Column - inverse*/
+val aes_mixcolumn_byte_inv : bits(8) -> bits(32)
+function aes_mixcolumn_byte_inv(so) = {
+ gfmul(so, 0xb) @ gfmul(so, 0xd) @ gfmul(so, 0x9) @ gfmul(so, 0xe)
+}
+
+/* 32-bit to 32-bit AES forward MixColumn */
+val aes_mixcolumn_fwd : bits(32) -> bits(32)
+function aes_mixcolumn_fwd(x) = {
+ let s0 : bits (8) = x[ 7.. 0];
+ let s1 : bits (8) = x[15.. 8];
+ let s2 : bits (8) = x[23..16];
+ let s3 : bits (8) = x[31..24];
+ let b0 : bits (8) = xt2(s0) ^ xt3(s1) ^ (s2) ^ (s3);
+ let b1 : bits (8) = (s0) ^ xt2(s1) ^ xt3(s2) ^ (s3);
+ let b2 : bits (8) = (s0) ^ (s1) ^ xt2(s2) ^ xt3(s3);
+ let b3 : bits (8) = xt3(s0) ^ (s1) ^ (s2) ^ xt2(s3);
+ b3 @ b2 @ b1 @ b0 /* Return value */
+}
+
+/* 32-bit to 32-bit AES inverse MixColumn */
+val aes_mixcolumn_inv : bits(32) -> bits(32)
+function aes_mixcolumn_inv(x) = {
+ let s0 : bits (8) = x[ 7.. 0];
+ let s1 : bits (8) = x[15.. 8];
+ let s2 : bits (8) = x[23..16];
+ let s3 : bits (8) = x[31..24];
+ let b0 : bits (8) = gfmul(s0, 0xE) ^ gfmul(s1, 0xB) ^ gfmul(s2, 0xD) ^ gfmul(s3, 0x9);
+ let b1 : bits (8) = gfmul(s0, 0x9) ^ gfmul(s1, 0xE) ^ gfmul(s2, 0xB) ^ gfmul(s3, 0xD);
+ let b2 : bits (8) = gfmul(s0, 0xD) ^ gfmul(s1, 0x9) ^ gfmul(s2, 0xE) ^ gfmul(s3, 0xB);
+ let b3 : bits (8) = gfmul(s0, 0xB) ^ gfmul(s1, 0xD) ^ gfmul(s2, 0x9) ^ gfmul(s3, 0xE);
+ b3 @ b2 @ b1 @ b0 /* Return value */
+}
+
+/* Turn a round number into a round constant for AES. Note that the
+ AES64KS1I instruction is defined such that the r argument is always
+ in the range 0x0..0xA. Values of rnum outside the range 0x0..0xA
+ do not decode to the AES64KS1I instruction. The 0xA case is used
+ specifically for the AES-256 KeySchedule, and this function is never
+ called in that case. */
+val aes_decode_rcon : bits(4) -> bits(32)
+function aes_decode_rcon(r) = {
+ assert(r <_u 0xA);
+ match r {
+ 0x0 => 0x00000001,
+ 0x1 => 0x00000002,
+ 0x2 => 0x00000004,
+ 0x3 => 0x00000008,
+ 0x4 => 0x00000010,
+ 0x5 => 0x00000020,
+ 0x6 => 0x00000040,
+ 0x7 => 0x00000080,
+ 0x8 => 0x0000001b,
+ 0x9 => 0x00000036,
+ _ => internal_error(__FILE__, __LINE__, "Unexpected AES r") /* unreachable -- required to silence Sail warning */
+ }
+}
+
+/* SM4 SBox - only one sbox for forwards and inverse */
+let sm4_sbox_table : vector(256, bits(8)) = [
+0xD6, 0x90, 0xE9, 0xFE, 0xCC, 0xE1, 0x3D, 0xB7, 0x16, 0xB6, 0x14, 0xC2, 0x28,
+0xFB, 0x2C, 0x05, 0x2B, 0x67, 0x9A, 0x76, 0x2A, 0xBE, 0x04, 0xC3, 0xAA, 0x44,
+0x13, 0x26, 0x49, 0x86, 0x06, 0x99, 0x9C, 0x42, 0x50, 0xF4, 0x91, 0xEF, 0x98,
+0x7A, 0x33, 0x54, 0x0B, 0x43, 0xED, 0xCF, 0xAC, 0x62, 0xE4, 0xB3, 0x1C, 0xA9,
+0xC9, 0x08, 0xE8, 0x95, 0x80, 0xDF, 0x94, 0xFA, 0x75, 0x8F, 0x3F, 0xA6, 0x47,
+0x07, 0xA7, 0xFC, 0xF3, 0x73, 0x17, 0xBA, 0x83, 0x59, 0x3C, 0x19, 0xE6, 0x85,
+0x4F, 0xA8, 0x68, 0x6B, 0x81, 0xB2, 0x71, 0x64, 0xDA, 0x8B, 0xF8, 0xEB, 0x0F,
+0x4B, 0x70, 0x56, 0x9D, 0x35, 0x1E, 0x24, 0x0E, 0x5E, 0x63, 0x58, 0xD1, 0xA2,
+0x25, 0x22, 0x7C, 0x3B, 0x01, 0x21, 0x78, 0x87, 0xD4, 0x00, 0x46, 0x57, 0x9F,
+0xD3, 0x27, 0x52, 0x4C, 0x36, 0x02, 0xE7, 0xA0, 0xC4, 0xC8, 0x9E, 0xEA, 0xBF,
+0x8A, 0xD2, 0x40, 0xC7, 0x38, 0xB5, 0xA3, 0xF7, 0xF2, 0xCE, 0xF9, 0x61, 0x15,
+0xA1, 0xE0, 0xAE, 0x5D, 0xA4, 0x9B, 0x34, 0x1A, 0x55, 0xAD, 0x93, 0x32, 0x30,
+0xF5, 0x8C, 0xB1, 0xE3, 0x1D, 0xF6, 0xE2, 0x2E, 0x82, 0x66, 0xCA, 0x60, 0xC0,
+0x29, 0x23, 0xAB, 0x0D, 0x53, 0x4E, 0x6F, 0xD5, 0xDB, 0x37, 0x45, 0xDE, 0xFD,
+0x8E, 0x2F, 0x03, 0xFF, 0x6A, 0x72, 0x6D, 0x6C, 0x5B, 0x51, 0x8D, 0x1B, 0xAF,
+0x92, 0xBB, 0xDD, 0xBC, 0x7F, 0x11, 0xD9, 0x5C, 0x41, 0x1F, 0x10, 0x5A, 0xD8,
+0x0A, 0xC1, 0x31, 0x88, 0xA5, 0xCD, 0x7B, 0xBD, 0x2D, 0x74, 0xD0, 0x12, 0xB8,
+0xE5, 0xB4, 0xB0, 0x89, 0x69, 0x97, 0x4A, 0x0C, 0x96, 0x77, 0x7E, 0x65, 0xB9,
+0xF1, 0x09, 0xC5, 0x6E, 0xC6, 0x84, 0x18, 0xF0, 0x7D, 0xEC, 0x3A, 0xDC, 0x4D,
+0x20, 0x79, 0xEE, 0x5F, 0x3E, 0xD7, 0xCB, 0x39, 0x48
+]
+
+let aes_sbox_fwd_table : vector(256, bits(8)) = [
+0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5, 0x30, 0x01, 0x67, 0x2b, 0xfe,
+0xd7, 0xab, 0x76, 0xca, 0x82, 0xc9, 0x7d, 0xfa, 0x59, 0x47, 0xf0, 0xad, 0xd4,
+0xa2, 0xaf, 0x9c, 0xa4, 0x72, 0xc0, 0xb7, 0xfd, 0x93, 0x26, 0x36, 0x3f, 0xf7,
+0xcc, 0x34, 0xa5, 0xe5, 0xf1, 0x71, 0xd8, 0x31, 0x15, 0x04, 0xc7, 0x23, 0xc3,
+0x18, 0x96, 0x05, 0x9a, 0x07, 0x12, 0x80, 0xe2, 0xeb, 0x27, 0xb2, 0x75, 0x09,
+0x83, 0x2c, 0x1a, 0x1b, 0x6e, 0x5a, 0xa0, 0x52, 0x3b, 0xd6, 0xb3, 0x29, 0xe3,
+0x2f, 0x84, 0x53, 0xd1, 0x00, 0xed, 0x20, 0xfc, 0xb1, 0x5b, 0x6a, 0xcb, 0xbe,
+0x39, 0x4a, 0x4c, 0x58, 0xcf, 0xd0, 0xef, 0xaa, 0xfb, 0x43, 0x4d, 0x33, 0x85,
+0x45, 0xf9, 0x02, 0x7f, 0x50, 0x3c, 0x9f, 0xa8, 0x51, 0xa3, 0x40, 0x8f, 0x92,
+0x9d, 0x38, 0xf5, 0xbc, 0xb6, 0xda, 0x21, 0x10, 0xff, 0xf3, 0xd2, 0xcd, 0x0c,
+0x13, 0xec, 0x5f, 0x97, 0x44, 0x17, 0xc4, 0xa7, 0x7e, 0x3d, 0x64, 0x5d, 0x19,
+0x73, 0x60, 0x81, 0x4f, 0xdc, 0x22, 0x2a, 0x90, 0x88, 0x46, 0xee, 0xb8, 0x14,
+0xde, 0x5e, 0x0b, 0xdb, 0xe0, 0x32, 0x3a, 0x0a, 0x49, 0x06, 0x24, 0x5c, 0xc2,
+0xd3, 0xac, 0x62, 0x91, 0x95, 0xe4, 0x79, 0xe7, 0xc8, 0x37, 0x6d, 0x8d, 0xd5,
+0x4e, 0xa9, 0x6c, 0x56, 0xf4, 0xea, 0x65, 0x7a, 0xae, 0x08, 0xba, 0x78, 0x25,
+0x2e, 0x1c, 0xa6, 0xb4, 0xc6, 0xe8, 0xdd, 0x74, 0x1f, 0x4b, 0xbd, 0x8b, 0x8a,
+0x70, 0x3e, 0xb5, 0x66, 0x48, 0x03, 0xf6, 0x0e, 0x61, 0x35, 0x57, 0xb9, 0x86,
+0xc1, 0x1d, 0x9e, 0xe1, 0xf8, 0x98, 0x11, 0x69, 0xd9, 0x8e, 0x94, 0x9b, 0x1e,
+0x87, 0xe9, 0xce, 0x55, 0x28, 0xdf, 0x8c, 0xa1, 0x89, 0x0d, 0xbf, 0xe6, 0x42,
+0x68, 0x41, 0x99, 0x2d, 0x0f, 0xb0, 0x54, 0xbb, 0x16
+]
+
+let aes_sbox_inv_table : vector(256, bits(8)) = [
+0x52, 0x09, 0x6a, 0xd5, 0x30, 0x36, 0xa5, 0x38, 0xbf, 0x40, 0xa3, 0x9e, 0x81,
+0xf3, 0xd7, 0xfb, 0x7c, 0xe3, 0x39, 0x82, 0x9b, 0x2f, 0xff, 0x87, 0x34, 0x8e,
+0x43, 0x44, 0xc4, 0xde, 0xe9, 0xcb, 0x54, 0x7b, 0x94, 0x32, 0xa6, 0xc2, 0x23,
+0x3d, 0xee, 0x4c, 0x95, 0x0b, 0x42, 0xfa, 0xc3, 0x4e, 0x08, 0x2e, 0xa1, 0x66,
+0x28, 0xd9, 0x24, 0xb2, 0x76, 0x5b, 0xa2, 0x49, 0x6d, 0x8b, 0xd1, 0x25, 0x72,
+0xf8, 0xf6, 0x64, 0x86, 0x68, 0x98, 0x16, 0xd4, 0xa4, 0x5c, 0xcc, 0x5d, 0x65,
+0xb6, 0x92, 0x6c, 0x70, 0x48, 0x50, 0xfd, 0xed, 0xb9, 0xda, 0x5e, 0x15, 0x46,
+0x57, 0xa7, 0x8d, 0x9d, 0x84, 0x90, 0xd8, 0xab, 0x00, 0x8c, 0xbc, 0xd3, 0x0a,
+0xf7, 0xe4, 0x58, 0x05, 0xb8, 0xb3, 0x45, 0x06, 0xd0, 0x2c, 0x1e, 0x8f, 0xca,
+0x3f, 0x0f, 0x02, 0xc1, 0xaf, 0xbd, 0x03, 0x01, 0x13, 0x8a, 0x6b, 0x3a, 0x91,
+0x11, 0x41, 0x4f, 0x67, 0xdc, 0xea, 0x97, 0xf2, 0xcf, 0xce, 0xf0, 0xb4, 0xe6,
+0x73, 0x96, 0xac, 0x74, 0x22, 0xe7, 0xad, 0x35, 0x85, 0xe2, 0xf9, 0x37, 0xe8,
+0x1c, 0x75, 0xdf, 0x6e, 0x47, 0xf1, 0x1a, 0x71, 0x1d, 0x29, 0xc5, 0x89, 0x6f,
+0xb7, 0x62, 0x0e, 0xaa, 0x18, 0xbe, 0x1b, 0xfc, 0x56, 0x3e, 0x4b, 0xc6, 0xd2,
+0x79, 0x20, 0x9a, 0xdb, 0xc0, 0xfe, 0x78, 0xcd, 0x5a, 0xf4, 0x1f, 0xdd, 0xa8,
+0x33, 0x88, 0x07, 0xc7, 0x31, 0xb1, 0x12, 0x10, 0x59, 0x27, 0x80, 0xec, 0x5f,
+0x60, 0x51, 0x7f, 0xa9, 0x19, 0xb5, 0x4a, 0x0d, 0x2d, 0xe5, 0x7a, 0x9f, 0x93,
+0xc9, 0x9c, 0xef, 0xa0, 0xe0, 0x3b, 0x4d, 0xae, 0x2a, 0xf5, 0xb0, 0xc8, 0xeb,
+0xbb, 0x3c, 0x83, 0x53, 0x99, 0x61, 0x17, 0x2b, 0x04, 0x7e, 0xba, 0x77, 0xd6,
+0x26, 0xe1, 0x69, 0x14, 0x63, 0x55, 0x21, 0x0c, 0x7d
+]
+
+/* Lookup function - takes an index and a table, and retrieves the
+ * x'th element of that table. Note that the Sail vector literals
+ * start at index 255, and go down to 0.
+ */
+val sbox_lookup : (bits(8), vector(256, bits(8))) -> bits(8)
+function sbox_lookup(x, table) = {
+ table[255 - unsigned(x)]
+}
+
+/* Easy function to perform a forward AES SBox operation on 1 byte. */
+val aes_sbox_fwd : bits(8) -> bits(8)
+function aes_sbox_fwd(x) = sbox_lookup(x, aes_sbox_fwd_table)
+
+/* Easy function to perform an inverse AES SBox operation on 1 byte. */
+val aes_sbox_inv : bits(8) -> bits(8)
+function aes_sbox_inv(x) = sbox_lookup(x, aes_sbox_inv_table)
+
+/* AES SubWord function used in the key expansion
+ * - Applies the forward sbox to each byte in the input word.
+ */
+val aes_subword_fwd : bits(32) -> bits(32)
+function aes_subword_fwd(x) = {
+ aes_sbox_fwd(x[31..24]) @
+ aes_sbox_fwd(x[23..16]) @
+ aes_sbox_fwd(x[15.. 8]) @
+ aes_sbox_fwd(x[ 7.. 0])
+}
+
+/* AES Inverse SubWord function.
+ * - Applies the inverse sbox to each byte in the input word.
+ */
+val aes_subword_inv : bits(32) -> bits(32)
+function aes_subword_inv(x) = {
+ aes_sbox_inv(x[31..24]) @
+ aes_sbox_inv(x[23..16]) @
+ aes_sbox_inv(x[15.. 8]) @
+ aes_sbox_inv(x[ 7.. 0])
+}
+
+/* Easy function to perform an SM4 SBox operation on 1 byte. */
+val sm4_sbox : bits(8) -> bits(8)
+function sm4_sbox(x) = sbox_lookup(x, sm4_sbox_table)
+
+val aes_get_column : (bits(128), nat) -> bits(32)
+function aes_get_column(state,c) = (state >> (to_bits(7, 32 * c)))[31..0]
+
+/* 64-bit to 64-bit function which applies the AES forward sbox to each byte
+ * in a 64-bit word.
+ */
+val aes_apply_fwd_sbox_to_each_byte : bits(64) -> bits(64)
+function aes_apply_fwd_sbox_to_each_byte(x) = {
+ aes_sbox_fwd(x[63..56]) @
+ aes_sbox_fwd(x[55..48]) @
+ aes_sbox_fwd(x[47..40]) @
+ aes_sbox_fwd(x[39..32]) @
+ aes_sbox_fwd(x[31..24]) @
+ aes_sbox_fwd(x[23..16]) @
+ aes_sbox_fwd(x[15.. 8]) @
+ aes_sbox_fwd(x[ 7.. 0])
+}
+
+/* 64-bit to 64-bit function which applies the AES inverse sbox to each byte
+ * in a 64-bit word.
+ */
+val aes_apply_inv_sbox_to_each_byte : bits(64) -> bits(64)
+function aes_apply_inv_sbox_to_each_byte(x) = {
+ aes_sbox_inv(x[63..56]) @
+ aes_sbox_inv(x[55..48]) @
+ aes_sbox_inv(x[47..40]) @
+ aes_sbox_inv(x[39..32]) @
+ aes_sbox_inv(x[31..24]) @
+ aes_sbox_inv(x[23..16]) @
+ aes_sbox_inv(x[15.. 8]) @
+ aes_sbox_inv(x[ 7.. 0])
+}
+
+/*
+ * AES full-round transformation functions.
+ */
+
+val getbyte : (bits(64), int) -> bits(8)
+function getbyte(x, i) = (x >> to_bits(6, i * 8))[7..0]
+
+val aes_rv64_shiftrows_fwd : (bits(64), bits(64)) -> bits(64)
+function aes_rv64_shiftrows_fwd(rs2, rs1) = {
+ getbyte(rs1, 3) @
+ getbyte(rs2, 6) @
+ getbyte(rs2, 1) @
+ getbyte(rs1, 4) @
+ getbyte(rs2, 7) @
+ getbyte(rs2, 2) @
+ getbyte(rs1, 5) @
+ getbyte(rs1, 0)
+}
+
+val aes_rv64_shiftrows_inv : (bits(64), bits(64)) -> bits(64)
+function aes_rv64_shiftrows_inv(rs2, rs1) = {
+ getbyte(rs2, 3) @
+ getbyte(rs2, 6) @
+ getbyte(rs1, 1) @
+ getbyte(rs1, 4) @
+ getbyte(rs1, 7) @
+ getbyte(rs2, 2) @
+ getbyte(rs2, 5) @
+ getbyte(rs1, 0)
+}
+
+/* 128-bit to 128-bit implementation of the forward AES ShiftRows transform.
+ * Byte 0 of state is input column 0, bits 7..0.
+ * Byte 5 of state is input column 1, bits 15..8.
+ */
+val aes_shift_rows_fwd : bits(128) -> bits(128)
+function aes_shift_rows_fwd(x) = {
+ let ic3 : bits(32) = aes_get_column(x, 3);
+ let ic2 : bits(32) = aes_get_column(x, 2);
+ let ic1 : bits(32) = aes_get_column(x, 1);
+ let ic0 : bits(32) = aes_get_column(x, 0);
+ let oc0 : bits(32) = ic0[31..24] @ ic1[23..16] @ ic2[15.. 8] @ ic3[ 7.. 0];
+ let oc1 : bits(32) = ic1[31..24] @ ic2[23..16] @ ic3[15.. 8] @ ic0[ 7.. 0];
+ let oc2 : bits(32) = ic2[31..24] @ ic3[23..16] @ ic0[15.. 8] @ ic1[ 7.. 0];
+ let oc3 : bits(32) = ic3[31..24] @ ic0[23..16] @ ic1[15.. 8] @ ic2[ 7.. 0];
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* 128-bit to 128-bit implementation of the inverse AES ShiftRows transform.
+ * Byte 0 of state is input column 0, bits 7..0.
+ * Byte 5 of state is input column 1, bits 15..8.
+ */
+val aes_shift_rows_inv : bits(128) -> bits(128)
+function aes_shift_rows_inv(x) = {
+ let ic3 : bits(32) = aes_get_column(x, 3); /* In column 3 */
+ let ic2 : bits(32) = aes_get_column(x, 2);
+ let ic1 : bits(32) = aes_get_column(x, 1);
+ let ic0 : bits(32) = aes_get_column(x, 0);
+ let oc0 : bits(32) = ic0[31..24] @ ic3[23..16] @ ic2[15.. 8] @ ic1[ 7.. 0];
+ let oc1 : bits(32) = ic1[31..24] @ ic0[23..16] @ ic3[15.. 8] @ ic2[ 7.. 0];
+ let oc2 : bits(32) = ic2[31..24] @ ic1[23..16] @ ic0[15.. 8] @ ic3[ 7.. 0];
+ let oc3 : bits(32) = ic3[31..24] @ ic2[23..16] @ ic1[15.. 8] @ ic0[ 7.. 0];
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* Applies the forward sub-bytes step of AES to a 128-bit vector
+ * representation of its state.
+ */
+val aes_subbytes_fwd : bits(128) -> bits(128)
+function aes_subbytes_fwd(x) = {
+ let oc0 : bits(32) = aes_subword_fwd(aes_get_column(x, 0));
+ let oc1 : bits(32) = aes_subword_fwd(aes_get_column(x, 1));
+ let oc2 : bits(32) = aes_subword_fwd(aes_get_column(x, 2));
+ let oc3 : bits(32) = aes_subword_fwd(aes_get_column(x, 3));
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* Applies the inverse sub-bytes step of AES to a 128-bit vector
+ * representation of its state.
+ */
+val aes_subbytes_inv : bits(128) -> bits(128)
+function aes_subbytes_inv(x) = {
+ let oc0 : bits(32) = aes_subword_inv(aes_get_column(x, 0));
+ let oc1 : bits(32) = aes_subword_inv(aes_get_column(x, 1));
+ let oc2 : bits(32) = aes_subword_inv(aes_get_column(x, 2));
+ let oc3 : bits(32) = aes_subword_inv(aes_get_column(x, 3));
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* Applies the forward MixColumns step of AES to a 128-bit vector
+ * representation of its state.
+ */
+val aes_mixcolumns_fwd : bits(128) -> bits(128)
+function aes_mixcolumns_fwd(x) = {
+ let oc0 : bits(32) = aes_mixcolumn_fwd(aes_get_column(x, 0));
+ let oc1 : bits(32) = aes_mixcolumn_fwd(aes_get_column(x, 1));
+ let oc2 : bits(32) = aes_mixcolumn_fwd(aes_get_column(x, 2));
+ let oc3 : bits(32) = aes_mixcolumn_fwd(aes_get_column(x, 3));
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* Applies the inverse MixColumns step of AES to a 128-bit vector
+ * representation of its state.
+ */
+val aes_mixcolumns_inv : bits(128) -> bits(128)
+function aes_mixcolumns_inv(x) = {
+ let oc0 : bits(32) = aes_mixcolumn_inv(aes_get_column(x, 0));
+ let oc1 : bits(32) = aes_mixcolumn_inv(aes_get_column(x, 1));
+ let oc2 : bits(32) = aes_mixcolumn_inv(aes_get_column(x, 2));
+ let oc3 : bits(32) = aes_mixcolumn_inv(aes_get_column(x, 3));
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+----
diff --git a/src/smcdeleg.adoc b/src/smcdeleg.adoc
new file mode 100644
index 0000000..89ece6d
--- /dev/null
+++ b/src/smcdeleg.adoc
@@ -0,0 +1,147 @@
+[[smcdeleg]]
+== "Smcdeleg/Ssccfg" Counter Delegation Extensions, Version 1.0
+
+In modern “Rich OS” environments, hardware performance monitoring
+resources are managed by the kernel, kernel driver, and/or hypervisor.
+Counters may be configured with differing scopes, in some cases counting
+events system-wide, while in others counting events on behalf of a
+single virtual machine or application. In such environments, the latency
+of counter writes has a direct impact on overall profiling overhead as a
+result of frequent counter writes during:
+
+. Sample collection, to clear overflow indication, and reload overflowed
+counter(s)
+. Context switch, between processes, threads, containers, or virtual
+machines
+
+These extensions provide a means for M-mode to allow writing select
+counters and event selectors from S/HS-mode. The purpose is to avert
+transitions to and from M-mode that add latency to these performance
+critical supervisor/hypervisor code sections. These extensions also
+defines one new CSR, scountinhibit.
+
+For a Machine-level environment, extension *Smcdeleg* (‘Sm’ for
+Privileged architecture and Machine-level extension, ‘cdeleg’ for
+Counter Delegation) encompasses all added CSRs and all behavior
+modifications for a hart, over all privilege levels. For a
+Supervisor-level environment, extension *Ssccfg* (‘Ss’ for Privileged
+architecture and Supervisor-level extension, ‘ccfg’ for Counter
+Configuration) provides access to delegated counters, and to new
+supervisor-level state. For a RISC-V hardware platform, Smcdeleg and
+Ssccfg must always be implemented in tandem.
+
+=== Counter Delegation
+
+The `mcounteren` register allows M-mode to provide the next-lower
+privilege mode with read access to select counters. When the Smcdeleg/Ssccfg
+extensions are enabled (`menvcfg`.CDE=1), it further allows M-mode to delegate select
+counters to S-mode.
+
+The `siselect` (and `vsiselect`) index range 0x40-0x5F is reserved for
+delegated counter access. When a counter _i_ is delegated
+(`mcounteren`[_i_]=1 and `menvcfg`.CDE=1), the register state associated
+with counter _i_ can be read or written via `sireg*`, while `siselect` holds
+0x40+__i__. The counter state accessible via alias CSRs is shown in
+the table below.
+
+.Indirect HPM State Mappings
+[#indirect-hpm-state-mappings]
+[width="100%",cols="21%,20%,21%,18%,20%",options="header",]
+|===
+|*`siselect` value* |*`sireg*` |*`sireg4`* |*`sireg2`* |*`sireg5`*
+|0x40 |`cycle`^1^ |`cycleh`^1^ |`cyclecfg`^14^ |`cyclecfgh`^14^
+|0x41 4+^|_See below_
+|0x42 |`instret`^1^ |`instreth`^1^ |`instretcfg`^14^ |`instretcfgh`^14^
+|0x43 |`hpmcounter3`^2^ |`hpmcounter3h`^2^ |`hpmevent3`^2^ |`hpmevent3h`^23^
+|… |… |… |… |…
+|0x5F |`hpmcounter31`^2^ |`hpmcounter31h`^2^ |`hpmevent31`^2^ |`hpmevent31h`^23^
+|===
+
+^1^ Depends on Zicntr support +
+^2^ Depends on Zihpm support +
+^3^ Depends on Sscofpmf support +
+^4^ Depends on Smcntrpmf support
+
+`hpmevent__i__` may represent a subset of the state accessed by the `mhpmevent__i__` register. Specifically, if Sscofpmf is implemented, event selector bit
+62 (MINH) is read-only 0 when accessed through `sireg*`.
+
+Likewise, `cyclecfg` and `instretcfg` may represent a subset of the state accessed by the `mcyclecfg` and `minstretcfg` registers, respectively. If
+Smcntrpmf is implemented, counter configuration register bit 62 (MINH) is read-only 0 when accessed through `sireg*`.
+
+If extension Smstateen is implemented, refer to extensions Smcsrind/Sscsrind (<<indirect-csr>>) for how setting bit 60 of CSR
+`mstateen0` to zero prevents access to registers `siselect`, `sireg*`,
+`vsiselect`, and `vsireg*` from privileged modes less privileged than
+M-mode, and likewise how setting bit 60 of `hstateen0` to zero prevents
+access to `siselect` and `sireg*` (really `vsiselect` and `vsireg*`) from
+VS-mode.
+
+The remaining rules of this section apply only when access to a CSR is
+not blocked by `mstateen0`[60] = 0 or `hstateen0`[60] = 0.
+
+While the privilege mode is M or S and `siselect` holds a value in the
+range 0x40-0x5F, illegal-instruction exceptions are raised for the
+following cases:
+
+* attempts to access any `sireg*` when `menvcfg`.CDE = 0;
+* attempts to access `sireg3` or `sireg6`;
+* attempts to access `sireg4` or `sireg5` when XLEN = 64;
+* attempts to access `sireg*` when `siselect` = 0x41, or when the counter
+selected by `siselect` is not delegated to S-mode (the corresponding bit
+in `mcounteren` = 0).
+
+NOTE: _The memory-mapped `mtime` register is not a performance monitoring
+counter to be managed by supervisor software, hence the special
+treatment of `siselect` value 0x41 described above._
+
+For each `siselect` and `sireg*` combination defined in <<indirect-hpm-state-mappings>>, the table
+further indicates the extensions upon which the underlying counter state
+depends. If any extension upon which the underlying state depends is not
+implemented, an attempt from M or S mode to access the given state
+through `sireg*` raises an illegal-instruction exception.
+
+If the hypervisor (H) extension is also implemented, then as specified
+by extensions Smcsrind/Sscsrind, a virtual-instruction exception is
+raised for attempts from VS-mode or VU-mode to directly access `vsiselect`
+or `vsireg*`, or attempts from VU-mode to access `siselect` or `sireg*`. Furthermore, while `vsiselect` holds a value in the range 0x40-0x5F:
+
+* An attempt to access any `vsireg*` from M or S mode raises an illegal-instruction exception.
+* An attempt from VS-mode to access any `sireg*` (really `vsireg*`) raises an illegal-instruction exception if `menvcfg`.CDE = 0, or a
+virtual-instruction exception if `menvcfg`.CDE = 1.
+
+=== Supervisor Counter Inhibit (`scountinhibit`) Register
+
+Smcdeleg/Ssccfg defines a new `scountinhibit` register, a masked alias of
+`mcountinhibit`. For counters delegated to S-mode, the associated
+`mcountinhibit` bits can be accessed via `scountinhibit`. For counters not
+delegated to S-mode, the associated bits in `scountinhibit` are read-only
+zero.
+
+When `menvcfg`.CDE=0, attempts to access `scountinhibit` raise an illegal-instruction
+exception. When Supervisor Counter Delegation
+is enabled, attempts to access `scountinhibit` from VS-mode or VU-mode
+raise a virtual-instruction exception.
+
+=== Virtualizing `scountovf`
+
+For implementations that support Smcdeleg/Ssccfg, Sscofpmf, and the H
+extension, when `menvcfg`.CDE=1, attempts to read `scountovf` from VS-mode
+or VU-mode raise a virtual-instruction exception.
+
+=== Virtualizing Local-Counter-Overflow Interrupts
+
+For implementations that support Smcdeleg, Sscofpmf, and Smaia, the
+local-counter-overflow interrupt (LCOFI) bit (bit 13) in each of CSRs
+`mvip` and `mvien` is implemented and writable.
+
+For implementations that support Smcdeleg/Ssccfg, Sscofpmf,
+Smaia/Ssaia, and the H extension, the LCOFI bit (bit 13) in each of `hvip`
+and `hvien` is implemented and writable.
+
+[NOTE]
+====
+_The `hvip` register is defined by the hypervisor (H) extension, while the `mvien` and `hvien` registers are defined by the Smaia/Ssaia extensions._
+
+_By virtue of implementing `hvip`.LCOFI, it is implicit that the LCOFI bit (bit 13) in each of `vsie` and `vsip` is also implemented._
+
+_Requiring support for the LCOFI bits listed above ensures that virtual LCOFIs can be delivered to an OS running in S-mode, and to a guest OS running in VS-mode. It is optional whether the LCOFI bit (bit 13) in each of `mideleg` and `hideleg`, which allows all LCOFIs to be delegated to S-mode and VS-mode, respectively, is implemented and writable._
+====
diff --git a/src/smcntrpmf.adoc b/src/smcntrpmf.adoc
new file mode 100644
index 0000000..922df36
--- /dev/null
+++ b/src/smcntrpmf.adoc
@@ -0,0 +1,69 @@
+[[smcntrpmf]]
+
+== "Smcntrpmf" Cycle and Instret Privilege Mode Filtering, Version 1.0
+
+=== Introduction
+
+The cycle and instret counters serve to support user mode self-profiling usages, wherein a user can read the counter(s) twice and compute the delta(s) to evaluate user software performance and behavior. By default, these counters are not filtered by privilege mode, and thus they continue to increment while traps (e.g., page faults or interrupts) to more privileged code are handled. This causes two problems:
+
+* It introduces unpredictable noise to the counter values observed by the user.
+* It leaks information about privileged software execution to user mode.
+
+Smcntrpmf remedies these issues by introducing privilege mode filtering for the cycle and instret counters.
+
+=== CSRs
+
+==== Machine Counter Configuration (`mcyclecfg`, `minstretcfg`) Registers
+
+mcyclecfg and minstretcfg are 64-bit registers that configure privilege mode filtering for the cycle and instret counters, respectively.
+
+[cols="^1,^1,^1,^1,^1,^1,^5",stripes=even,options="header"]
+|====
+|63 |62 |61 |60 |59 |58 |57:0
+|0 |MINH |SINH |UINH |VSINH |VUINH |_WPRI_
+|====
+
+[cols="15%,85%",options="header"]
+|====
+| Field | Description
+| MINH | If set, then counting of events in M-mode is inhibited
+| SINH | If set, then counting of events in S/HS-mode is inhibited
+| UINH | If set, then counting of events in U-mode is inhibited
+| VSINH | If set, then counting of events in VS-mode is inhibited
+| VUINH | If set, then counting of events in VU-mode is inhibited
+|====
+
+When all __x__INH bits are zero, event counting is enabled in all modes.
+
+For each bit in 61:58, if the associated privilege mode is not implemented, the bit is read-only zero.
+
+For RV32, bits 63:32 of mcyclecfg can be accessed via the mcyclecfgh CSR, and bits 63:32 of minstretcfg can be accessed via the minstretcfgh CSR.
+
+The content of these registers may be accessible from Supervisor level if the Smcdeleg/Ssccfg extensions are implemented.
+
+[NOTE]
+====
+The more natural CSR number for mcyclecfg would be 0x320, but that was allocated to mcountinhibit.
+
+This register format matches that specified for programmable counters by Sscofpmf. The bit position for the OF bit (bit 63) is read-only 0, since these counters do not generate local-counter-overflow interrupts on overflow.
+====
+
+=== Counter Behavior
+
+The fundamental behavior of cycle and instret is modified in that counting does not occur while executing in an inhibited privilege mode. Further, the following defines how transitions between a non-inhibited privilege mode and an inhibited privilege mode are counted.
+
+The cycle counter will simply count CPU cycles while the CPU is in a non-inhibited privilege mode. Mode transition operations (traps and trap returns) may take multiple clock cycles, and the change of privilege mode may be reported as occurring in any one of those cycles (possibly different for each occurrence of a trap or trap return).
+
+[NOTE]
+====
+The RISC-V ISA has no requirement that the number of cycles for a trap or trap return be the same for all occurrences. Implementations are free to determine the extent to which this number may be consistent and predictable (or not), and the same is true for the specific cycle in which privilege mode changes.
+====
+
+For the instret counter, most instructions do not affect mode transitions, so for those the behavior is clear: instructions that retire in a non-inhibited mode increment instret, and instructions that retire in an inhibited mode do not. There are two types of instructions that can affect a privilege mode change: instructions that cause synchronous exceptions to a more privileged mode, and xRET instructions that return to a less privileged mode. The former are not considered to retire, and hence do not increment instret. The latter do retire, and should increment instret only if the originating privilege mode is not inhibited.
+
+[NOTE]
+====
+The instret definition above is intended to ensure that the counter increments in a predictable fashion. For example, consider a scenario where minstretcfg is configured such that all modes other than U-mode are inhibited. A user mode load should increment only once, even if it takes a page fault or other exception. With this definition, the faulting execution of the load will not increment (it does not retire), the handler instructions will not increment (they execute in an inhibited mode), including the xRET (it arguably retires in a non-inhibited mode, but it originates in an inhibited mode). Only once the load is re-executed and retires will it increment instret.
+
+In cases where an instruction is emulated by software running in a privilege mode that is inhibited in minstretcfg, the emulation routine must emulate the instret increment.
+====
diff --git a/src/smctr.adoc b/src/smctr.adoc
new file mode 100644
index 0000000..1082b23
--- /dev/null
+++ b/src/smctr.adoc
@@ -0,0 +1,760 @@
+[[smctr]]
+
+== "Smctr" Control Transfer Records Extension, Version 1.0
+
+A method for recording control flow transfer history is valuable not only for performance profiling but also for debugging. Control flow transfers refer to jump instructions (including function calls and returns), taken branch instructions, traps, and trap returns. Profiling tools, such as Linux perf, collect control transfer history when sampling software execution, thereby enabling tools, like AutoFDO, to identify hot paths for optimization.
+
+Control flow trace capabilities offer very deep transfer history, but the volume of data produced can result in significant performance overheads due to memory bandwidth consumption, buffer management, and decoder overhead. The Control Transfer Records (CTR) extension provides a method to record a limited history in register-accessible internal chip storage, with the intent of dramatically reducing the performance overhead and complexity of collecting transfer history.
+
+CTR defines a circular (FIFO) buffer. Each buffer entry holds a record for a single recorded control flow transfer. The number of records that can be held in the buffer depends upon both the implementation (the maximum supported depth) and the CTR configuration (the software selected depth).
+
+Only qualified transfers are recorded. Qualified transfers are those that meet the filtering criteria, which include the privilege mode and the transfer type.
+
+Recorded transfers are inserted at the write pointer, which is then incremented, while older recorded transfers may be overwritten once the buffer is full. Or the user can enable RAS (Return Address Stack) emulation mode, where only function calls are recorded, and function returns pop the last call record. The source PC, target PC, and some optional metadata (transfer type, elapsed cycles) are stored for each recorded transfer.
+
+The CTR buffer is accessible through an indirect CSR interface, such that software can specify which logical entry in the buffer it wishes to read or write. Logical entry 0 always corresponds to the youngest recorded transfer, followed by entry 1 as the next youngest, and so on.
+
+The machine-level extension, *Smctr*, encompasses all newly added Control Status Registers (CSRs), instructions, and behavior modifications for a hart across all privilege levels. The corresponding supervisor-level extension, *Ssctr*, is essentially identical to Smctr, except that it excludes machine-level CSRs and behaviors not intended to be directly accessible at the supervisor level.
+
+Smctr and Ssctr depend on both the implementation of S-mode and the Sscsrind extension.
+
+=== CSRs
+
+==== Machine Control Transfer Records Control Register (`mctrctl`)
+
+The `mctrctl` register is a 64-bit read/write register that enables and configures the CTR capability.
+
+.Machine Control Transfer Records Control Register Format
+[%unbreakable]
+[wavedrom, , svg]
+....
+{reg: [
+ {bits: 1, name: 'U'},
+ {bits: 1, name: 'S'},
+ {bits: 1, name: 'M'},
+ {bits: 4, name: '<i>WPRI</i>'},
+ {bits: 1, name: 'RASEMU'},
+ {bits: 1, name: 'STE'},
+ {bits: 1, name: 'MTE'},
+ {bits: 1, name: '<i>WPRI</i>'},
+ {bits: 1, name: 'BPFRZ'},
+ {bits: 1, name: 'LCOFIFRZ'},
+ {bits: 20, name: '<i>WPRI</i>'},
+ {bits: 1, name: 'EXCINH'},
+ {bits: 1, name: 'INTRINH'},
+ {bits: 1, name: 'TRETINH'},
+ {bits: 1, name: 'NTBREN'},
+ {bits: 1, name: 'TKBRINH'},
+ {bits: 2, name: '<i>WPRI</i>'},
+ {bits: 1, name: 'INDCALLINH'},
+ {bits: 1, name: 'DIRCALLINH'},
+ {bits: 1, name: 'INDJMPINH'},
+ {bits: 1, name: 'DIRJMPINH'},
+ {bits: 1, name: 'CORSWAPINH'},
+ {bits: 1, name: 'RETINH'},
+ {bits: 1, name: 'INDLJMPINH'},
+ {bits: 1, name: 'DIRLJMPINH'},
+ {bits: 12, name: '<i>WPRI</i>'},
+ {bits: 4, name: 'Custom'},
+], config:{lanes: 8, hspace:1024}}
+....
+
+.Machine Control Transfer Records Control Register Field Definitions
+[%unbreakable]
+[width="100%",cols="20%,80%",options="header",]
+|===
+|Field |Description
+|M, S, U |Enable transfer recording in the selected privileged mode(s).
+
+|RASEMU |Enables RAS (Return Address Stack) Emulation Mode. See <<RAS (Return Address Stack) Emulation Mode>>.
+
+|MTE |Enables recording of traps to M-mode when M=0. See <<External Traps>>.
+
+|STE |Enables recording of traps to S-mode when S=0. See <<External Traps>>.
+
+|BPFRZ |Set `sctrstatus`.FROZEN on a breakpoint exception that traps to M-mode or S-mode. See <<Freeze>>.
+
+|LCOFIFRZ |Set `sctrstatus`.FROZEN on local-counter-overflow interrupt (LCOFI) that traps to M-mode or S-mode. See <<Freeze>>.
+
+|EXCINH |Inhibit recording of exceptions. See <<Transfer Type Filtering>>.
+
+|INTRINH |Inhibit recording of interrupts. See <<Transfer Type Filtering>>.
+
+|TRETINH |Inhibit recording of trap returns. See <<Transfer Type Filtering>>.
+
+|NTBREN |Enable recording of not-taken branches. See <<Transfer Type Filtering>>.
+
+|TKBRINH |Inhibit recording of taken branches. See <<Transfer Type Filtering>>.
+
+|INDCALLINH |Inhibit recording of indirect calls. See <<Transfer Type Filtering>>.
+
+|DIRCALLINH |Inhibit recording of direct calls. See <<Transfer Type Filtering>>.
+
+|INDJMPINH |Inhibit recording of indirect jumps (without linkage). See <<Transfer Type Filtering>>.
+
+|DIRJMPINH |Inhibit recording of direct jumps (without linkage). See <<Transfer Type Filtering>>.
+
+|CORSWAPINH |Inhibit recording of co-routine swaps. See <<Transfer Type Filtering>>.
+
+|RETINH |Inhibit recording of function returns. See <<Transfer Type Filtering>>.
+
+|INDLJMPINH |Inhibit recording of other indirect jumps (with linkage). See <<Transfer Type Filtering>>.
+
+|DIRLJMPINH |Inhibit recording of other direct jumps (with linkage). See <<Transfer Type Filtering>>.
+|Custom[3:0] | WARL bits designated for custom use. The value 0 must correspond to standard behavior. See <<Custom Extensions>>.
+|===
+
+[%unbreakable]
+--
+All fields are optional except for M, S, U, and BPFRZ. All unimplemented fields are read-only 0, while all implemented fields are writable. If the Sscofpmf extension is implemented, LCOFIFRZ must be writable.
+--
+
+[NOTE]
+====
+_Because the ROI of CTR is perceived to be low for RV32 implementations, CTR does not fully support RV32. While control flow transfers in RV32 can be recorded, RV32 cannot access_ `x__ctrctl__` _bits 63:32. A future extension could add support for RV32 by adding 3 new CSRs (`mctrctlh`, `sctrctlh`, and `vsctrctlh`) to provide this access._
+====
+
+==== Supervisor Control Transfer Records Control Register (`sctrctl`)
+
+The `sctrctl` register provides supervisor mode access to a subset of `mctrctl`.
+
+Bits 2 and 9 in `sctrctl` are read-only 0. As a result, the M and MTE fields in `mctrctl` are not accessible through `sctrctl`. All other `mctrctl` fields are accessible through `sctrctl`.
+
+==== Virtual Supervisor Control Transfer Records Control Register (`vsctrctl`)
+
+If the H extension is implemented, the `vsctrctl` register is a 64-bit read/write register that is VS-mode's version of supervisor register `sctrctl`. When V=1, `vsctrctl` substitutes for the usual `sctrctl`, so instructions that normally read or modify `sctrctl` actually access `vsctrctl` instead.
+
+.Virtual Supervisor Control Transfer Records Control Register Format
+[%unbreakable]
+[wavedrom, , svg]
+....
+{reg: [
+ {bits: 1, name: 'U'},
+ {bits: 1, name: 'S'},
+ {bits: 5, name: '<i>WPRI</i>'},
+ {bits: 1, name: 'RASEMU'},
+ {bits: 1, name: 'STE'},
+ {bits: 2, name: '<i>WPRI</i>'},
+ {bits: 1, name: 'BPFRZ'},
+ {bits: 1, name: 'LCOFIFRZ'},
+ {bits: 20, name: '<i>WPRI</i>'},
+ {bits: 1, name: 'EXCINH'},
+ {bits: 1, name: 'INTRINH'},
+ {bits: 1, name: 'TRETINH'},
+ {bits: 1, name: 'NTBREN'},
+ {bits: 1, name: 'TKBRINH'},
+ {bits: 2, name: '<i>WPRI</i>'},
+ {bits: 1, name: 'INDCALLINH'},
+ {bits: 1, name: 'DIRCALLINH'},
+ {bits: 1, name: 'INDJMPINH'},
+ {bits: 1, name: 'DIRJMPINH'},
+ {bits: 1, name: 'CORSWAPINH'},
+ {bits: 1, name: 'RETINH'},
+ {bits: 1, name: 'INDLJMPINH'},
+ {bits: 1, name: 'DIRLJMPINH'},
+ {bits: 12, name: '<i>WPRI</i>'},
+ {bits: 4, name: 'Custom'},
+], config:{lanes: 8, hspace:1024}}
+....
+
+.Virtual Supervisor Control Transfer Records Control Register Field Definitions
+[%unbreakable]
+[width="100%",cols="20%,80%",options="header",]
+|===
+|Field |Description
+|S |Enable transfer recording in VS-mode.
+|U |Enable transfer recording in VU-mode.
+|STE |Enables recording of traps to VS-mode when S=0. See <<External Traps>>.
+|BPFRZ |Set `sctrstatus`.FROZEN on a breakpoint exception that traps to VS-mode. See <<Freeze>>.
+|LCOFIFRZ |Set `sctrstatus`.FROZEN on local-counter-overflow interrupt (LCOFI) that traps to VS-mode. See <<Freeze>>.
+2+|Other field definitions match those of `sctrctl`. The optional fields implemented in `vsctrctl` should match those implemented in `sctrctl`.
+|===
+
+[NOTE]
+[%unbreakable]
+====
+_Unlike the CTR status register or the CTR entry registers, the CTR control register has a VS-mode version. This allows a guest to manage the CTR configuration directly, without requiring traps to HS-mode, while ensuring that the guest configuration (most notably the privilege mode enable bits) do not impact CTR behavior when V=0._
+====
+
+==== Supervisor Control Transfer Records Depth Register (`sctrdepth`)
+
+The 32-bit `sctrdepth` register specifies the depth of the CTR buffer.
+
+.Supervisor Control Transfer Records Depth Register Format
+[%unbreakable]
+[wavedrom, , svg]
+....
+{reg: [
+ {bits: 3, name: 'DEPTH'},
+ {bits: 29, name: '<i>WPRI</i>'},
+], config:{lanes: 1, hspace:1024}}
+....
+
+.Supervisor Control Transfer Records Depth Register Field Definitions
+[%unbreakable]
+[width="100%",cols="15%,85%",options="header",]
+|===
+|Field |Description
+|DEPTH |WARL field that selects the depth of the CTR buffer. Encodings:
+
+‘000 - 16
+
+‘001 - 32
+
+‘010 - 64
+
+‘011 - 128
+
+‘100 - 256
+
+'11x - reserved
+
+The depth of the CTR buffer dictates the number of entries to which the hardware records transfers. For a depth of N, the hardware records transfers to entries 0..N-1. All <<_entry_registers, Entry Registers>> read as '0' and are read-only when the selected entry is in the range N to 255. When the depth is increased, the newly accessible entries contain unspecified but legal values.
+
+It is implementation-specific which DEPTH value(s) are supported.
+|===
+
+Attempts to access `sctrdepth` from VS-mode or VU-mode raise a virtual-instruction exception, unless CTR state enable access restrictions apply. See <<State Enable Access Control>>.
+
+[NOTE]
+[%unbreakable]
+====
+_It is expected that operating systems (OSs) will access `sctrdepth` only at boot, to select the maximum supported depth value. More frequent accesses may result in reduced performance in virtualization scenarios, as a result of traps from VS-mode incurred._
+
+_There may be scenarios where software chooses to operate on only a subset of the entries, to reduce overhead. In such cases tools may choose to read only the lower entries, and OSs may choose to save/restore only on the lower entries while using SCTRCLR to clear the others._
+
+_The value in configurable depth lies in supporting VM migration. It is expected that a platform spec may specify that one or more CTR depth values must be supported. A hypervisor may wish to restrict guests to using one of these required depths, in order to ensure that such guests can be migrated to any system that complies with the platform spec. The trapping behavior specified for VS-mode accesses to `sctrdepth` ensures that the hypervisor can impose such restrictions._
+====
+
+==== Supervisor Control Transfer Records Status Register (`sctrstatus`)
+
+The 32-bit `sctrstatus` register grants access to CTR status information and is updated by the hardware whenever CTR is active. CTR is active when the current privilege mode is enabled for recording and CTR is not frozen.
+
+.Supervisor Control Transfer Records Status Register Format
+[%unbreakable]
+[wavedrom, , svg]
+....
+{reg: [
+ {bits: 8, name: 'WRPTR'},
+ {bits: 23, name: '<i>WPRI</i>'},
+ {bits: 1, name: 'FROZEN'},
+], config:{lanes: 2, hspace:1024}}
+....
+
+.Supervisor Control Transfer Records Status Register Field Definitions
+[%unbreakable]
+[width="100%",cols="15%,85%",options="header",]
+|===
+|Field |Description
+|WRPTR |WARL field that indicates the physical CTR buffer entry to be written next. It is incremented after new transfers are recorded (see <<Behavior>>), though there are exceptions when `__x__ctrctl`.RASEMU=1, see <<RAS (Return Address Stack) Emulation Mode>>. For a given CTR depth (where depth = 2^(DEPTH+4)^), WRPTR wraps to 0 on an increment when the value matches depth-1, and to depth-1 on a decrement when the value is 0. Bits above those needed to represent depth-1 (e.g., bits 7:4 for a depth of 16) are read-only 0. On depth changes, WRPTR holds an unspecified but legal value.
+|FROZEN |Inhibit transfer recording. See <<Freeze>>.
+|===
+
+Undefined bits in `sctrstatus` are WPRI. Status fields may be added by future extensions,
+and software should ignore but preserve any fields that it does not recognize. Undefined bits must be implemented as read-only 0, unless a custom extension is implemented and enabled (see <<Custom Extensions>>).
+
+[NOTE]
+[%unbreakable]
+====
+_Logical entry 0, accessed via `sireg*` when `siselect`=0x200, is always the physical buffer entry preceding the WRPTR entry. More generally, the physical buffer entry Y associated with logical entry X (X < depth) can be determined using the formula Y = (WRPTR - X - 1) % depth, where depth = 2^(DEPTH+4)^. Logical entries >= depth are read-only 0._
+====
+[NOTE]
+[%unbreakable]
+====
+_Because the `sctrstatus` register is updated by hardware, writes should be performed with caution. If a multi-instruction read-modify-write to `sctrstatus` is performed while CTR is active, and between the read and write a qualified transfer or trap that causes CTR freeze completes, a hardware update could be lost. Software may wish to ensure that CTR is inactive before performing a read-modify-write, by ensuring that either `sctrstatus`.FROZEN=1, or that the current privilege mode is not enabled for recording._
+
+_When restoring CTR state, `sctrstatus` should be written before CTR entry state is restored. This ensures that the software writes to logical CTR entries modify the proper physical entries._
+====
+
+[NOTE]
+[%unbreakable]
+====
+_Exposing the WRPTR provides a more efficient means for synthesizing CTR entries. If a qualified control transfer is emulated, the emulator can simply increment the WRPTR, then write the synthesized record to logical entry 0. If a qualified function return is emulated while RASEMU=1, the emulator can clear `ctrsource`.V for logical entry 0, then decrement the WRPTR._
+
+_Exposing the WRPTR may also allow support for Linux perf's https://lwn.net/Articles/802821[[.underline]#stack stitching#] capability._
+====
+
+[NOTE]
+[%unbreakable]
+====
+_Smctr/Ssctr depends upon implementation of S-mode because much of CTR state is accessible only through S-mode CSRs. If, in the future, it becomes desirable to remove this dependency, an extension could add `mctrdepth` and `mctrstatus` CSRs that reflect the same state as `sctrdepth` and `sctrstatus`, respectively. Further, such an extension should make CTR entries accessible via `miselect`/`mireg*`. See <<Entry Registers>>._
+====
+
+=== Entry Registers
+
+Control transfer records are stored in a CTR buffer, such that each buffer entry stores information about a single transfer. The CTR buffer entries are logically accessed via the indirect register access mechanism defined by the Sscsrind extension. The `siselect` index range 0x200 through 0x2FF is reserved for CTR logical entries 0 through 255. When `siselect` holds a value in this range, `sireg` provides access to `ctrsource`, `sireg2` provides access to `ctrtarget`, and `sireg3` provides access to `ctrdata`. `sireg4`, `sireg5`, and `sireg6` are read-only 0.
+
+When `vsiselect` holds a value in 0x200..0x2FF, the `vsireg*` registers provide access to the same CTR entry register state as the analogous `sireg*` registers. There is not a separate set of entry registers for V=1.
+
+See <<State Enable Access Control>> for cases where CTR accesses from S-mode and VS-mode may be restricted.
+
+==== Control Transfer Record Source Register (`ctrsource`)
+
+The `ctrsource` register contains the source program counter, which is the `pc` of the recorded control transfer instruction, or the epc of the recorded trap. The valid (V) bit is set by the hardware when a transfer is recorded in the selected CTR buffer entry, and implies that data in `ctrsource`, `ctrtarget`, and `ctrdata` is valid for this entry.
+
+`ctrsource` is an MXLEN-bit WARL register that must be able to hold all valid virtual or physical addresses that can serve as a `pc`. It need not be able to hold any invalid addresses; implementations may convert an invalid address into a valid address that the register is capable of holding. When XLEN < MXLEN, both explicit writes (by software) and implicit writes (for recorded transfers) will be zero-extended.
+
+.Control Transfer Record Source Register Format for MXLEN=64
+[%unbreakable]
+[wavedrom, , svg]
+....
+{reg: [
+ {bits: 1, name: 'V'},
+ {bits: 63, name: 'PC[63:1]'},
+], config:{lanes: 1, hspace: 1024}}
+....
+
+[NOTE]
+[%unbreakable]
+====
+_CTR entry registers are defined as MXLEN, despite the_ `x__ireg*__` _CSRs used to access them being XLEN, to ensure that entries recorded in RV64 are not truncated, as a result of CSR Width Modulation, on a transition to RV32._
+====
+
+==== Control Transfer Record Target Register (`ctrtarget`)
+
+The `ctrtarget` register contains the target (destination) program counter
+of the recorded transfer. The optional MISP bit is set by the hardware
+when the recorded transfer is an instruction whose target or
+taken/not-taken direction was mispredicted by the branch predictor. MISP
+is read-only 0 when not implemented.
+
+`ctrtarget` is an MXLEN-bit WARL register that must be able to hold all valid virtual or physical addresses that can serve as a `pc`. It need not be able to hold any invalid addresses; implementations may convert an invalid address into a valid address that the register is capable of holding. When XLEN < MXLEN, both explicit writes (by software) and implicit writes (by recorded transfers) will be zero-extended.
+
+.Control Transfer Record Target Register Format for MXLEN=64
+[%unbreakable]
+[wavedrom, , svg]
+....
+{reg: [
+ {bits: 1, name: 'MISP'},
+ {bits: 31, name: 'PC[31:1]'},
+ {bits: 32, name: 'PC[63:32]'},
+], config:{lanes: 2, hspace: 1024}}
+....
+
+==== Control Transfer Record Metadata Register (`ctrdata`)
+
+The `ctrdata` register contains metadata for the recorded transfer. This
+register must be implemented, though all fields within it are optional.
+Unimplemented fields are read-only 0. `ctrdata` is a 64-bit register.
+
+.Control Transfer Record Metadata Register Format
+[%unbreakable]
+[wavedrom, , svg]
+....
+{reg: [
+ {bits: 4, name: 'TYPE'},
+ {bits: 11, name: '<i>WPRI</i>'},
+ {bits: 1, name: 'CCV'},
+ {bits: 16, name: 'CC'},
+ {bits: 32, name: '<i>WPRI</i>'},
+], config:{lanes: 2, hspace: 1024}}
+....
+
+.Control Transfer Record Metadata Register Field Definitions
+[%unbreakable]
+[width="100%",cols="15%,75%,10%",options="header",]
+|===
+|Field |Description |Access
+|TYPE[3:0] a|
+Identifies the type of the control flow transfer recorded in the entry, using the encodings listed in xref:transfer-type-defs[xrefstyle=short]. Implementations that do not support this field will report 0.
+|WARL
+
+|CCV |Cycle Count Valid. See <<Cycle Counting>>. |WARL
+
+|CC[15:0] |Cycle Count, composed of the Cycle Count Exponent (CCE, in
+CC[15:12]) and Cycle Count Mantissa (CCM, in CC[11:0]). See
+<<Cycle Counting>>. |WARL
+|===
+
+Undefined bits in `ctrdata` are WPRI. Undefined bits must be implemented as read-only 0, unless a <<_custom_extensions, custom extension>> is implemented and enabled.
+
+[NOTE]
+[%unbreakable]
+====
+_Like the <<_transfer_type_filtering, Transfer Type Filtering>> bits in `mctrctl`, the `ctrdata`.TYPE bits leverage the E-trace itype encodings._
+====
+
+=== Instructions
+==== Supervisor CTR Clear Instruction
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['7', 'SYSTEM'], type: 8},
+ {bits: 5, name: 'rd', attr: ['5', '0'], type: 2},
+ {bits: 3, name: 'funct3', attr: ['3', '0'], type: 8},
+ {bits: 5, name: 'rs1', attr: ['5', '0'], type: 4},
+ {bits: 12, name: 'func12', attr: ['12', 'SCTRCLR (0x104)'], type: 8},
+]}
+....
+
+The SCTRCLR instruction performs the following operations:
+
+* Zeroes all CTR <<_entry_registers, Entry Registers>>, for all DEPTH values
+* Zeroes the CTR cycle counter and CCV (see <<Cycle Counting>>)
+
+Any read of `ctrsource`, `ctrtarget`, or `ctrdata` that follows SCTRCLR, such that it precedes the next qualified control transfer, will return the value 0. Further, the first recorded transfer following SCTRCLR will have `ctrdata`.CCV=0.
+
+SCTRCLR raises an illegal-instruction exception in U-mode, and a virtual-instruction exception in VU-mode, unless CTR state enable access restrictions apply. See <<State Enable Access Control>>.
+
+=== State Enable Access Control
+
+When Smstateen is implemented, the `mstateen0`.CTR bit controls access to CTR register state from privilege modes less privileged than M-mode. When `mstateen0`.CTR=1, accesses to CTR register state behave as described in <<CSRs>> and <<Entry Registers>> above, while SCTRCLR behaves as described in <<Supervisor CTR Clear Instruction>>. When `mstateen0`.CTR=0 and the privilege mode is less privileged than M-mode, the following operations raise an illegal-instruction exception:
+
+* Attempts to access `sctrctl`, `vsctrctl`, `sctrdepth`, or `sctrstatus`
+* Attempts to access `sireg*` when `siselect` is in 0x200..0x2FF, or `vsireg*` when `vsiselect` is in 0x200..0x2FF
+* Execution of the SCTRCLR instruction
+
+When `mstateen0`.CTR=0, qualified control transfers executed in privilege modes less privileged than M-mode will continue to implicitly update entry registers and `sctrstatus`.
+
+If the H extension is implemented and `mstateen0`.CTR=1, the `hstateen0`.CTR bit controls access to supervisor CTR state when V=1. This state includes `sctrctl` (really `vsctrctl`), `sctrstatus`, and `sireg*` (really `vsireg*`) when `siselect` (really `vsiselect`) is in 0x200..0x2FF. `hstateen0`.CTR is read-only 0 when `mstateen0`.CTR=0.
+
+When `mstateen0`.CTR=1 and `hstateen0`.CTR=1, VS-mode accesses to supervisor CTR state behave as described in <<CSRs>> and <<Entry Registers>> above, while SCTRCLR behaves as described in <<Supervisor CTR Clear Instruction>>. When `mstateen0`.CTR=1 and `hstateen0`.CTR=0, both VS-mode accesses to supervisor CTR state and VS-mode execution of SCTRCLR raise a virtual-instruction exception.
+
+[NOTE]
+[%unbreakable]
+====
+`__sctrdepth__` _is not included in the above list of supervisor CTR state controlled by `hstateen0`.CTR since accesses to `sctrdepth` from VS-mode raise a virtual-instruction exception regardless of the value of `hstateen0`.CTR._
+====
+
+When `hstateen0`.CTR=0, qualified control transfers executed while V=1 will continue to implicitly update entry registers and `sctrstatus`.
+
+[NOTE]
+[%unbreakable]
+====
+_See <<indirect-csr>> for how bit 60 in `mstateen0` and `hstateen0` can also restrict access to `sireg*`/`siselect` and `vsireg*`/`vsiselect` from privilege modes less privileged than M-mode._
+====
+
+[NOTE]
+[%unbreakable]
+====
+_Implementations that support Smctr/Ssctr but not Smstateen/Ssstateen may observe reduced performance. Because Smctr/Ssctr introduces a significant number of new CSRs, it is desirable to avoid save/restore of CTR state when possible. A hypervisor is likely to leverage State Enable to trap on the initial guest access to CTR state, delegating CTR and enabling save/restore of guest CTR state only once the guest has begun to use it. Without Smstateen/Ssstateen, a hypervisor is required to save/restore guest CTR state on every context switch._
+====
+
+=== Behavior
+
+CTR records qualified control transfers. Control transfers are qualified if they meet the following criteria:
+
+* The current privilege mode is enabled
+* The transfer type is not inhibited
+* `sctrstatus`.FROZEN is not set
+* The transfer completes/retires
+
+Such qualified transfers update the <<_entry_registers, Entry Registers>> at logical entry 0. As a result, older entries are pushed down the stack; the record previously in logical entry 0 moves to logical entry 1, the record in logical entry 1 moves to logical entry 2, and so on. If the CTR buffer is full, the oldest recorded entry (previously at entry depth-1) is lost.
+
+Recorded transfers will set the `ctrsource`.V bit to 1, and will update all implemented record fields.
+
+[NOTE]
+[%unbreakable]
+====
+_In order to collect accurate and representative performance profiles while using CTR, it is recommended that hardware recording of control transfers incurs no added performance overhead, e.g., in the form of retirement or instruction execution restrictions that are not present when CTR is not active._
+====
+
+==== Privilege Mode Transitions
+
+Transfers that change the privilege mode are a special case. What is
+recorded, if anything, depends on whether the source privilege mode
+and/or target privilege mode are enabled for recording, and on the transfer type (trap
+or trap return).
+
+Traps between enabled privilege modes are recorded as normal. Traps from a disabled privilege mode to an enabled privilege mode are partially recorded, such that the `ctrsource`.PC is 0. Traps from an enabled mode to a disabled mode, known as external traps, are not recorded by default. See <<External Traps>> for how they can be recorded.
+
+Trap returns have similar treatment. Trap returns between enabled privilege modes are recorded as normal. Trap returns from an enabled mode back to a disabled mode are partially recorded, such that `ctrtarget`.PC is 0. Trap returns from a disabled mode to an enabled mode are not recorded.
+
+[NOTE]
+====
+_If privileged software is configuring CTR on behalf of less privileged software, it should ensure that its privilege mode enable bit (e.g., `sctrctl`.S for Supervisor software) is cleared before a trap return to the less privileged mode. Otherwise the trap return will be recorded, leaking the privileged source `pc`._
+====
+
+Recording in Debug Mode is always inhibited. Transfers into and out of Debug Mode are never recorded.
+
+The table below provides details on recording of privilege mode transitions. Standard dependencies on FROZEN and transfer type inhibits also apply, but are not covered by the table.
+
+.Trap and Trap Return Recording
+[%unbreakable]
+[width="100%",cols="18%,17%,30%,35%",]
+|===
+.2+|*Transfer Type* .2+| *Source Mode* 2+|*Target Mode*
+|*Enabled* |*Disabled*
+.2+|*Trap* |*Enabled* |Recorded. | External trap. Not recorded by default, but see <<External Traps>>.
+
+|*Disabled* |Recorded, `ctrsource`.PC is 0. |Not recorded.
+
+.2+|*Trap Return* |*Enabled* |Recorded. |Recorded, `ctrtarget`.PC is 0.
+
+|*Disabled* |Not recorded. |Not recorded.
+|===
+
+===== Virtualization Mode Transitions
+
+Transitions between VS/VU-mode and M/HS-mode are unique in that they effect a change in the active CTR control register, and hence the CTR configuration. What is recorded, if anything, on these virtualization mode transitions depends upon fields from both `[ms]ctrctl` and `vsctrctl`.
+
+* `mctrctl`.M, `sctrctl`.S, and `vsctrctl`.{S,U} are used to determine whether the source and target modes are enabled;
+* `mctrctl`.MTE, `sctrctl`.STE, and `vsctrctl`.STE are used to determine whether an external trap is recorded (see <<External Traps>>);
+* `sctrctl`.LCOFIFRZ and `sctrctl`.BPFRZ determine whether CTR becomes frozen (see <<Freeze>>)
+* For all other `__x__ctrctl` fields, the value in `vsctrctl` is used.
+
+[NOTE]
+====
+_Consider an exception that traps from VU-mode to HS-mode, with `vsctrctl`.U=1 and `sctrctl`.S=1. Because both the source mode and target mode are enabled for recording, whether the trap is recorded then depends on the CTR configuration (e.g., the <<_transfer_type_filtering, transfer type filter>> bits) in `vsctrctl`, not in `sctrctl`._
+====
+
+===== External Traps
+
+External traps are traps from a privilege mode enabled for CTR recording to a privilege mode that is not enabled for CTR recording. By default external traps are not recorded, but privileged software running in the target mode of the trap can opt-in to allowing CTR to record external traps into that mode. The `__x__ctrctl`.__x__TE bits allow M-mode, S-mode, and VS-mode to opt-in separately.
+
+External trap recording depends not only on the target mode, but on any intervening modes, which are modes that are more privileged than the source mode but less privileged than the target mode. Not only must the external trap enable bit for the target mode be set, but the external trap enable bit(s) for any intervening modes must also be set. See the table below for details.
+
+[NOTE]
+[%unbreakable]
+====
+_Requiring intervening modes to be enabled for external traps simplifies software management of CTR. Consider a scenario where S-mode software is configuring CTR for U-mode contexts A and B, such that external traps (to any mode) are enabled for A but not for B. When switching between the two contexts, S-mode can simply toggle `sctrctl`.STE, rather than requiring a trap to M-mode to additionally toggle `mctrctl`.MTE._
+
+_This method does not provide the flexibility to record external traps to a more privileged mode but not to all intervening mode(s). Because it is expected that profiling tools generally wish to observe all external traps or none, this is not considered a meaningful limitation._
+====
+
+.External Trap Enable Requirements
+[%unbreakable]
+[options="header", width="85%", cols="23%,23%,54%"]
+|===
+|Source Mode |Target Mode |External Trap Enable(s) Required
+.2+|U-mode | S-mode | `sctrctl`.STE
+|M-mode | `mctrctl`.MTE, `sctrctl`.STE
+|S-mode | M-mode | `mctrctl`.MTE
+.3+|VU-mode | VS-mode | `vsctrctl`.STE
+| HS-mode | `sctrctl`.STE, `vsctrctl`.STE
+| M-mode | `mctrctl`.MTE, `sctrctl`.STE, `vsctrctl`.STE
+.2+| VS-mode | HS-mode | `sctrctl`.STE
+| M-mode | `mctrctl`.MTE, `sctrctl`.STE
+|===
+
+In records for external traps, the `ctrtarget`.PC is 0.
+
+[NOTE]
+[%unbreakable]
+====
+_No mechanism exists for recording external trap returns, because
+the external trap record includes all relevant information, and gives
+the trap handler (e.g., an emulator) the opportunity to modify the
+record._
+====
+
+[NOTE]
+[%unbreakable]
+====
+_Note that external trap recording does not depend on EXCINH/INTRINH. Thus, when external traps are enabled, both external interrupts and external exceptions are recorded._
+
+_STE allows recording of traps from U-mode to S-mode as well as from VS/VU-mode to HS-mode. The hypervisor can flip `sctrctl`.STE before entering a guest if it wants different behavior for U-to-S vs VS/VU-to-HS._
+====
+
+If external trap recording is implemented, `mctrctl`.MTE and `sctrctl`.STE must be implemented, while `vsctrctl`.STE must be implemented if the H extension is implemented.
+
+==== Transfer Type Filtering
+
+Default CTR behavior, when all transfer type filter bits (`__x__ctrctl`[47:32]) are unimplemented or 0, is to record all control transfers within enabled privileged modes. By setting transfer type filter bits, software can opt out of recording select transfer types, or opt into recording non-default operations. All transfer type filter bits are optional.
+
+[NOTE]
+[%unbreakable]
+====
+_Because not-taken branches are not recorded by default, the polarity of the associated enable bit (NTBREN) is the opposite of other bits associated with transfer type filtering (TKBRINH, RETINH, etc). Non-default operations require opt-in rather than opt-out._
+====
+
+The transfer type filter bits leverage the type definitions specified
+in the
+https://github.com/riscv-non-isa/riscv-trace-spec/releases/download/v2.0rc2/riscv-trace-spec.pdf[[.underline]#RISC-V Efficient Trace Spec v2.0#] (Table 4.4 and Section 4.1.1). For completeness, the definitions are reproduced below.
+
+[NOTE]
+====
+_Here "indirect" is used interchangeably with "uninferrable", which is used in the trace spec. Both imply that the target of the jump is not encoded in the opcode._
+====
+
+.Control Transfer Type Definitions
+[#transfer-type-defs]
+[%unbreakable]
+[width="60%", cols="22%,78%", options="header",]
+|===
+| Encoding | Transfer Type Name
+| 0 | _Not used by CTR_
+| 1 | Exception
+| 2 | Interrupt
+| 3 | Trap return
+| 4 | Not-taken branch
+| 5 | Taken branch
+| 6 | _reserved_
+| 7 | _reserved_
+| 8 | Indirect call
+| 9 | Direct call
+| 10 | Indirect jump (without linkage)
+| 11 | Direct jump (without linkage)
+| 12 | Co-routine swap
+| 13 | Function return
+| 14 | Other indirect jump (with linkage)
+| 15 | Other direct jump (with linkage)
+|===
+
+Encodings 8 through 15 refer to various encodings of jump instructions. The types are distinguished as described below.
+
+.Control Transfer Type Definitions
+[%unbreakable]
+[cols="37%,63%", options="header",]
+|===
+| Transfer Type Name | Associated Opcodes
+.3+| Indirect call | JALR _x1_, _rs_ where _rs_ != _x5_
+| JALR _x5_, _rs_ where _rs_ != _x1_
+| C.JALR _rs1_ where _rs1_ != _x5_
+.4+| Direct call | JAL _x1_
+| JAL _x5_
+| C.JAL
+| CM.JALT _index_
+.2+| Indirect jump (without linkage) | JALR _x0_, _rs_ where _rs_ != (_x1_ or _x5_)
+| C.JR _rs1_ where _rs1_ != (_x1_ or _x5_)
+.3+| Direct jump (without linkage) | JAL _x0_
+| C.J
+| CM.JT _index_
+.3+| Co-routine swap | JALR _x1_, _x5_
+| JALR _x5_, _x1_
+| C.JALR _x5_
+.3+| Function return | JALR _rd_, _rs_ where _rs_ == (_x1_ or _x5_) and _rd_ != (_x1_ or _x5_)
+| C.JR _rs1_ where _rs1_ == (_x1_ or _x5_)
+| CM.POPRET(Z)
+| Other indirect jump (with linkage) | JALR _rd_, _rs_ where _rs_ != (_x1_ or _x5_) and _rd_ != (_x0_, _x1_, or _x5_)
+| Other direct jump (with linkage) | JAL _rd_ where _rd_ != (_x0_, _x1_, or _x5_)
+|===
+
+
+[NOTE]
+[%unbreakable]
+====
+_If implementation of any transfer type filter bit results in reduced software performance, perhaps due to additional retirement restrictions, it is strongly recommended that this reduced performance apply only when the bit is set. Alternatively, support for the bit may be omitted. Maintaining software performance for the default CTR configuration, when all transfer type bits are cleared, is recommended._
+====
+
+==== Cycle Counting
+
+The `ctrdata` register may optionally include a count of CPU cycles elapsed since the prior CTR record. The elapsed cycle count value is represented by the CC field, which has a 12-bit mantissa component (Cycle Count Mantissa, or CCM) and a 4-bit exponent component (Cycle Count Exponent, or CCE).
+
+The elapsed cycle counter (CtrCycleCounter) increments at the same rate as the `mcycle` counter. Only cycles while CTR is active are counted, where active implies that the current privilege mode is enabled for recording and CTR is not frozen. The CC field is encoded such that CCE holds 0 if the CtrCycleCounter value is less than 4096, otherwise it holds the index of the most significant one bit in the CtrCycleCounter value, minus 11. CCM holds CtrCycleCounter bits CCE+10:CCE-1.
+
+The elapsed cycle count can then be calculated by software using the following formula:
+
+[subs="specialchars,quotes"]
+[%unbreakable]
+----
+if (CCE==0):
+ return CCM
+else:
+ return (2^12^ + CCM) << CCE-1
+endif
+----
+
+The CtrCycleCounter is reset on writes to `__x__ctrctl`, and on execution of SCTRCLR, to ensure that any accumulated cycle counts do not persist across a context switch.
+
+An implementation that supports cycle counting must implement CCV and all
+CCM bits, but may implement 0..4 exponent bits in CCE. Unimplemented CCE
+bits are read-only 0. For implementations that support transfer type
+filtering, it is recommended to implement at least 3 exponent bits. This
+allows capturing the full latency of most functions, when recording only
+calls and returns.
+
+The size of the CtrCycleCounter required to support each CCE width is given in the table below.
+
+.Cycle Counter Size Options
+[%unbreakable]
+[width="70%", cols="20%,38%,42%", options="header",]
+|===
+| CCE bits | CtrCycleCounter bits | Max elapsed cycle value
+| 0 | 12 | 4095
+| 1 | 13 | 8191
+| 2 | 15 | 32764
+| 3 | 19 | 524224
+| 4 | 27 | 134201344
+|===
+
+[NOTE]
+[%unbreakable]
+====
+_When CCE>1, the granularity of the reported cycle count is reduced. For example, when CCE=3, the bottom 2 bits of the cycle counter are not reported, and thus the reported value increments only every 4 cycles. As a result, the reported value represents an undercount of elapsed cycles for most cases (when the unreported bits are non-zero). On average, the undercount will be (2^CCE-1^-1)/2. Software can reduce the average undercount to 0 by adding (2^CCE-1^-1)/2 to each computed cycle count value when CCE>1._
+
+_Though this compressed method of representation results in some imprecision for larger cycle count values, it produces meaningful area savings, reducing storage per entry from 27 bits to 16._
+====
+
+The CC value saturates when all implemented bits in CCM and CCE are 1.
+
+The CC value is valid only when the Cycle Count Valid (CCV) bit is set. If CCV=0, the CC value might not hold the correct count of elapsed active cycles since the last recorded transfer. The next record will have CCV=0 after a write to `__x__ctrctl`, or execution of SCTRCLR, since CtrCycleCounter is reset. CCV should additionally be cleared after any other implementation-specific scenarios where active cycles might not be counted in CtrCycleCounter.
+
+==== RAS (Return Address Stack) Emulation Mode
+
+When the optional `__x__ctrctl`.RASEMU bit is implemented and set to 1, transfer recording behavior is altered to emulate the behavior of a return-address stack (RAS).
+
+* Indirect and direct calls are recorded as normal
+* Function returns pop the most recent call, by decrementing the WRPTR then invalidating the WRPTR entry (by setting ctrsource.V=0). As a result, logical entry 0 is invalidated and moves to logical entry depth-1, while logical entries 1..depth-1 move to 0..depth-2.
+* Co-routine swaps affect both a return and a call. Logical entry 0 is
+overwritten, and WRPTR is not modified.
+* Other transfer types are inhibited
+* Transfer type filtering bits (`__x__ctrctl`[47:32]) and external trap enable bits (`__x__ctrctl`.__x__TE) are ignored
+
+[NOTE]
+[%unbreakable]
+====
+_Profiling tools often collect call stacks along with each sample. Stack
+walking, however, is a complex and often slow process that may require
+recompilation (e.g., -fno-omit-frame-pointer) to work reliably. With RAS
+emulation, tools can ask CTR hardware to save call stacks even for
+unmodified code._
+
+_CTR RAS emulation has limitations. The CTR buffer will contain only partial stacks in cases where the call stack depth was greater than the CTR depth, CTR recording was enabled at a lower point in the call stack than main(), or where the CTR buffer was cleared since main()._
+
+_The CTR stack may be corrupted in cases where calls and returns are not symmetric, such as with stack unwinding (e.g., setjmp/longjmp, C++ exceptions), where stale call entries may be left on the CTR stack, or user stack switching, where calls from multiple stacks may be intermixed._
+====
+
+[NOTE]
+[%unbreakable]
+====
+_As described in <<Cycle Counting>>,
+when CCV=1, the CC field provides the elapsed cycles since the prior CTR
+entry was recorded. This introduces implementation challenges when
+RASEMU=1 because, for each recorded call, there may have been several
+recorded calls (and returns which “popped” them) since the prior
+remaining call entry was recorded (see <<RAS (Return Address Stack) Emulation Mode>>). The implication is that returns that
+pop a call entry not only do not reset the cycle counter, but instead
+add the CC field from the popped entry to the counter. For simplicity,
+an implementation may opt to record CCV=0 for all calls, or those whose parent call was popped, when RASEMU=1._
+====
+
+==== Freeze
+
+When `sctrstatus`.FROZEN=1, transfer recording is inhibited. This bit can be set by hardware, as described below, or by software.
+
+When `sctrctl`.LCOFIFRZ=1 and a local-counter-overflow interrupt
+(LCOFI) traps (as a result of an HPM counter overflow) to M-mode or to S-mode, `sctrstatus`.FROZEN is set by hardware. This inhibits CTR recording until software clears FROZEN. The LCOFI trap itself is not recorded.
+[NOTE]
+[%unbreakable]
+====
+_Freeze on LCOFI ensures that the execution path leading to the sampled
+instruction (`__x__epc`) is preserved, and that the local-counter-overflow
+interrupt (LCOFI) and associated Interrupt Service Routine (ISR) do not
+displace any recorded transfer history state. It is the responsibility
+of the ISR to clear FROZEN before __x__RET, if continued control transfer
+recording is desired._
+
+_LCOFI refers only to architectural traps directly caused by a local counter overflow. If a local-counter-overflow interrupt is recognized without a trap, FROZEN is not automatically set. For instance, no freeze occurs if the LCOFI is pended while interrupts are masked, and software recognizes the LCOFI (perhaps by reading `stopi` or `sip`) and clears `sip`.LCOFIP before the trap is raised. As a result, some or all CTR history may be overwritten while handling the LCOFI. Such cases are expected to be very rare; for most usages (e.g., application profiling) privilege mode filtering is sufficient to ensure that CTR updates are inhibited while interrupts are handled in a more privileged mode._
+====
+Similarly, on a breakpoint exception that traps to M-mode or S-mode with `sctrctl`.BPFRZ=1, FROZEN is set by hardware. The breakpoint exception itself is not recorded.
+
+[NOTE]
+[%unbreakable]
+====
+_Breakpoint exception refers to synchronous exceptions with a cause value of Breakpoint (3), regardless of source (ebreak, c.ebreak, Sdtrig); it does not include entry into Debug Mode, even in cores where this is implemented as an exception._
+====
+
+If the H extension is implemented, freeze behavior for LCOFIs and breakpoint exceptions that trap to VS-mode is determined by the LCOFIFRZ and BPFRZ values, respectively, in `vsctrctl`. This includes virtual LCOFIs pended by a hypervisor.
+
+[NOTE]
+[%unbreakable]
+====
+_When a guest uses the SBI Supervisor Software Events (SSE) extension, the LCOFI will trap to HS-mode, which will then invoke a registered VS-mode LCOFI handler routine. If `vsctrctl`.LCOFIFRZ=1, the HS-mode handler will need to emulate the freeze by setting `sctrstatus`.FROZEN=1 before invoking the registered handler routine._
+====
+
+
+=== Custom Extensions
+
+Any custom CTR extension must be associated with a non-zero value within the designated custom bits in `__x__ctrctl`. When the custom bits hold a non-zero value that enables a custom extension, the extension may alter standard CTR behavior, and may define new custom status fields within `sctrstatus` or the CTR <<_entry_registers, Entry Registers>>. All custom status fields, and standard status fields whose behavior is altered by the custom extension, must revert to standard behavior when the custom bits hold zero. This includes read-only 0 behavior for any bits undefined by any implemented standard extensions.
diff --git a/src/smdbltrp.adoc b/src/smdbltrp.adoc
new file mode 100644
index 0000000..84df99f
--- /dev/null
+++ b/src/smdbltrp.adoc
@@ -0,0 +1,17 @@
+[[smdbltrp]]
+== "Smdbltrp" Double Trap Extension, Version 1.0
+
+The Smdbltrp extension addresses a double trap (See <<machine-double-trap>>) in
+M-mode. When the Smrnmi extension (<<rnmi>>) is implemented, it enables
+invocation of the RNMI handler on a double trap in M-mode to handle the
+critical error. If the Smrnmi extension is not implemented or if a double trap
+occurs during the RNMI handler's execution, this extension helps transition the
+hart to a critical error state and enables signaling the critical error to the
+platform.
+
+To improve error diagnosis and resolution, this extension supports debugging
+harts in a critical error state. The extension introduces a mechanism to enter
+Debug Mode instead of asserting a critical-error signal to the platform when the
+hart is in a critical error state. See cite:[DEBUG_SPEC] for details.
+
+See <<machine-double-trap>> for the operational details.
diff --git a/src/smepmp.adoc b/src/smepmp.adoc
new file mode 100644
index 0000000..f23bcf8
--- /dev/null
+++ b/src/smepmp.adoc
@@ -0,0 +1,176 @@
+[[smepmp]]
+== "Smepmp" Extension for PMP Enhancements for memory access and execution prevention in Machine mode, Version 1.0
+=== Introduction
+
+Being able to access the memory of a process running at a high privileged execution mode, such as the Supervisor or Machine mode, from a lower privileged mode such as the User mode, introduces an obvious attack vector since it allows for an attacker to perform privilege escalation, and tamper with the code and/or data of that process. A less obvious attack vector exists when the reverse happens, in which case an attacker instead of tampering with code and/or data that belong to a high-privileged process, can tamper with the memory of an unprivileged / less-privileged process and trick the high-privileged process to use or execute it.
+
+Two mechanisms combine to prevent this attack vector.
+The first one prevents the OS from accessing the memory of an unprivileged
+process unless a specific code path is followed, and the second one prevents
+the OS from executing the memory of an unprivileged process at all times.
+RISC-V already includes support for the former through the ``sstatus.SUM`` bit,
+and for the latter by always denying supervisor execution of virtual memory
+pages marked with the U bit.
+
+
+[NOTE]
+====
+Terms:
+
+* *PMP Entry*: A pair of ``pmpcfg[i]`` / ``pmpaddr[i]`` registers.
+* *PMP Rule*: The contents of a pmpcfg register and its associated pmpaddr register(s), that encode a valid protected physical memory region, where ``pmpcfg[i].A != OFF``, and if ``pmpcfg[i].A == TOR``, ``pmpaddr[i-1] < pmpaddr[i]``.
+* *Ignored*: Any permissions set by a matching PMP rule are ignored, and _all_ accesses to the requested address range are allowed.
+* *Enforced*: Only access types configured in the PMP rule matching the requested address range are allowed; failures will cause an access-fault exception.
+* *Denied*: Any permissions set by a matching PMP rule are ignored, and _no_ accesses to the requested address range are allowed.; failures will cause an access-fault exception.
+* *Locked*: A PMP rule/entry where the ``pmpcfg.L`` bit is set.
+* *PMP reset*: A reset process where all PMP settings of the hart, including locked rules/settings, are re-initialized to a set of safe defaults, before releasing the hart (back) to the firmware / OS / application.
+====
+
+==== Threat model
+
+However, there are no such mechanisms available on Machine mode in the current (v1.11) Privileged Spec. It is not possible for a PMP rule to be *enforced* only on non-Machine modes and *denied* on Machine mode, to only allow access to a memory region by less-privileged modes. It is only possible to have a *locked* rule that will be *enforced* on all modes, or a rule that will be *enforced* on non-Machine modes and be *ignored* by Machine mode. So for any physical memory region which is not protected with a Locked rule, Machine mode has unlimited access, including the ability to execute it.
+
+Without being able to protect less-privileged modes from Machine mode, it is not possible to prevent the mentioned attack vector. This becomes even more important for RISC-V than on other architectures, since implementations are allowed where a hart only has Machine and User modes available, so the whole OS will run on Machine mode instead of the non-existent Supervisor mode. In such implementations the attack surface is greatly increased, and the same kind of attacks performed on Supervisor mode and mitigated through the virtual-memory system, can be performed on Machine mode without any available mitigations. Even on implementations with Supervisor mode present attacks are still possible against the Firmware and/or the Secure Monitor running on Machine mode.
+
+[[mseccfg_csr]]
+=== mseccfg CSR
+
+. *Machine Security Configuration (mseccfg)* is a new RW Machine mode CSR, used for configuring various security mechanisms present on the hart, and only accessible to Machine mode. It is 64 bits wide, and is at address *0x747 on RV64* and *0x747 (low 32bits), 0x757 (high 32bits) on RV32*. All mseccfg fields defined on this extension are WARL, and the remaining bits are reserved for future standard use and should always read zero. The reset value of mseccfg is implementation-specific, otherwise if backwards compatibility is a requirement it should reset to zero on hard reset.
+
+. On ``mseccfg`` we introduce a field on bit 2 called *Rule Locking Bypass (mseccfg.RLB)* with the following functionality:
++
+.. When ``mseccfg.RLB`` is 1 *locked* PMP rules may be removed/modified and *locked* PMP entries may be edited.
+
+.. When ``mseccfg.RLB`` is 0 and ``pmpcfg.L`` is 1 in any rule or entry (including disabled entries), then ``mseccfg.RLB`` remains 0 and any further modifications to ``mseccfg.RLB`` are ignored until a *PMP reset*.
++
+[CAUTION]
+====
+Note that this feature is intended to be used as a debug mechanism, or as a temporary workaround during the boot process for simplifying software, and optimizing the allocation of memory and PMP rules. Using this functionality under normal operation, after the boot process is completed, should be avoided since it weakens the protection of _M-mode-only_ rules. Vendors who don’t need this functionality may hardwire this field to 0.
+====
+
+. On ``mseccfg`` we introduce a field in bit 1 called *Machine-Mode Allowlist Policy (mseccfg.MMWP)*. This is a sticky bit, meaning that once set it cannot be unset until a *PMP reset*. When set it changes the default PMP policy for M-mode when accessing memory regions that don’t have a matching PMP rule, to *denied* instead of *ignored*.
+
+. On ``mseccfg`` we introduce a field in bit 0 called *Machine Mode Lockdown (mseccfg.MML)*. This is a sticky bit, meaning that once set it cannot be unset until a *PMP reset*. When ``mseccfg.MML`` is set the system's behavior changes in the following way:
+
+.. The meaning of ``pmpcfg.L`` changes: Instead of marking a rule as *locked* and *enforced* in all modes, it now marks a rule as *M-mode-only* when set and *S/U-mode-only* when unset. The formerly reserved encoding of ``pmpcfg.RW=01``, and the encoding ``pmpcfg.LRWX=1111``, now encode a *Shared-Region*.
++
+An _M-mode-only_ rule is *enforced* on Machine mode and *denied* in Supervisor or User mode. It also remains *locked* so that any further modifications to its associated configuration or address registers are ignored until a *PMP reset*, unless ``mseccfg.RLB`` is set.
++
+An _S/U-mode-only_ rule is *enforced* on Supervisor and User modes and *denied* on Machine mode.
++
+A _Shared-Region_ rule is *enforced* on all modes, with restrictions depending on the ``pmpcfg.L`` and ``pmpcfg.X`` bits:
++
+* A _Shared-Region_ rule where ``pmpcfg.L`` is not set can be used for sharing data between M-mode and S/U-mode, so is not executable. M-mode has read/write access to that region, and S/U-mode has read access if ``pmpcfg.X`` is not set, or read/write access if ``pmpcfg.X`` is set.
++
+* A _Shared-Region_ rule where ``pmpcfg.L`` is set can be used for sharing code between M-mode and S/U-mode, so is not writable. Both M-mode and S/U-mode have execute access on the region, and M-mode also has read access if ``pmpcfg.X`` is set. The rule remains *locked* so that any further modifications to its associated configuration or address registers are ignored until a *PMP reset*, unless ``mseccfg.RLB`` is set.
++
+* The encoding ``pmpcfg.LRWX=1111`` can be used for sharing data between M-mode and S/U mode, where both modes only have read-only access to the region. The rule remains *locked* so that any further modifications to its associated configuration or address registers are ignored until a *PMP reset*, unless ``mseccfg.RLB`` is set.
+
+
+.. Adding a rule with executable privileges that either is *M-mode-only* or a *locked* *Shared-Region* is not possible and such ``pmpcfg`` writes are ignored, leaving ``pmpcfg`` unchanged. This restriction can be temporarily lifted by setting ``mseccfg.RLB`` e.g. during the boot process.
+
+.. Executing code with Machine mode privileges is only possible from memory regions with a matching *M-mode-only* rule or a *locked* *Shared-Region* rule with executable privileges. Executing code from a region without a matching rule or with a matching _S/U-mode-only_ rule is *denied*.
+
+.. If ``mseccfg.MML`` is not set, the combination of ``pmpcfg.RW=01`` remains reserved for future standard use.
+
+
+==== Truth table when mseccfg.MML is set
+
+[cols="^1,^1,^1,^1,^3,^3",stripes=even,options="header"]
+|===
+4+|Bits on _pmpcfg_ register {set:cellbgcolor:green} 2+|Result
+|L|R|W|X|M Mode|S/U Mode
+|{set:cellbgcolor:!} 0|0|0|0 2+|Inaccessible region (Access Exception)
+|0|0|0|1|Access Exception|Execute-only region
+|0|0|1|0 2+|Shared data region: Read/write on M mode, read-only on S/U mode
+|0|0|1|1 2+|Shared data region: Read/write for both M and S/U mode
+|0|1|0|0|Access Exception|Read-only region
+|0|1|0|1|Access Exception|Read/Execute region
+|0|1|1|0|Access Exception|Read/Write region
+|0|1|1|1|Access Exception|Read/Write/Execute region
+|1|0|0|0 2+|Locked inaccessible region* (Access Exception)
+|1|0|0|1|Locked Execute-only region*|Access Exception
+|1|0|1|0 2+|Locked Shared code region: Execute only on both M and S/U mode.*
+|1|0|1|1 2+|Locked Shared code region: Execute only on S/U mode, read/execute on M mode.*
+|1|1|0|0|Locked Read-only region*|Access Exception
+|1|1|0|1|Locked Read/Execute region*|Access Exception
+|1|1|1|0|Locked Read/Write region*|Access Exception
+|1|1|1|1 2+|Locked Shared data region: Read only on both M and S/U mode.*
+|===
+
+*: *Locked* rules cannot be removed or modified until a *PMP reset*, unless ``mseccfg.RLB`` is set.
+
+==== Visual representation
+
+image::smepmp-visual-representation.png[]
+
+=== Smepmp software discovery
+
+Since all fields defined on ``mseccfg`` as part of this extension are locked when set (``MMWP``/``MML``) or locked when cleared (``RLB``), software can't poll them for determining the presence of Smepmp. It is expected that BootROM will set ``mseccfg.MMWP`` and/or ``mseccfg.MML`` during early boot, before jumping to the firmware, so that the firmware will be able to determine the presence of Smepmp by reading ``mseccfg`` and checking the state of ``mseccfg.MMWP`` and ``mseccfg.MML``.
+
+[[rationale]]
+=== Rationale
+
+. Since a CSR for security and / or global PMP behavior settings is not available with the current spec, we needed to define a new one. This new CSR will allow us to add further security configuration options in the future and also allow developers to verify the existence of the new mechanisms defined on this extension.
+
+. There are use cases where developers want to enforce PMP rules in M-mode during the boot process, that are also able to modify, merge, and / or remove later on. Since a rule that is enforced in M-mode also needs to be locked (or else badly written or malicious M-mode software can remove it at any time), the only way for developers to approach this is to keep adding PMP rules to the chain and rely on rule priority. This is a waste of PMP rules and since it’s only needed during boot, ``mseccfg.RLB`` is a simple workaround that can be used temporarily and then disabled and locked down.
++
+Also when ``mseccfg.MML`` is set, according to 4b it’s not possible to add a _Shared-Region_ rule with executable privileges. So RLB can be set temporarily during the boot process to register such regions. Note that it’s still possible to register executable _Shared-Region_ rules using initial register settings (that may include ``mseccfg.MML`` being set and the rule being set on PMP registers) on *PMP reset*, without using RLB.
++
+[WARNING]
+====
+*Be aware that RLB introduces a security vulnerability if left set after the boot process is over and in general it should be used with caution, even when used temporarily.* Having editable PMP rules in M-mode gives a false sense of security since it only takes a few malicious instructions to lift any PMP restrictions this way. It doesn’t make sense to have a security control in place and leave it unprotected. Rule Locking Bypass is only meant as a way to optimize the allocation of PMP rules, catch errors during debugging, and allow the bootrom/firmware to register executable _Shared-Region_ rules. If developers / vendors have no use for such functionality, they should never set ``mseccfg.RLB`` and if possible hard-wire it to 0. In any case *RLB should be disabled and locked as soon as possible*.
+====
++
+[NOTE]
+====
+If ``mseccfg.RLB`` is not used and left unset, it will be locked as soon as a PMP rule/entry with the ``pmpcfg.L`` bit set is configured.
+====
++
+[IMPORTANT]
+====
+Since PMP rules with a higher priority override rules with a lower priority, locked rules must precede non-locked rules.
+====
+
+. With the current spec M-mode can access any memory region unless restricted by a PMP rule with the ``pmpcfg.L`` bit set. There are cases where this approach is overly permissive, and although it’s possible to restrict M-mode by adding PMP rules during the boot process, this can also be seen as a waste of PMP rules. Having the option to block anything by default, and use PMP as an allowlist for M-mode is considered a safer approach. This functionality may be used during the boot process or upon *PMP reset*, using initial register settings. +
+
+. The current dual meaning of the ``pmpcfg.L`` bit that marks a rule as Locked and *enforced* on all modes is neither flexible nor clean. With the introduction of _Machine Mode Lock-down_ the ``pmpcfg.L`` bit distinguishes between rules that are *enforced* *only* in M-mode (_M-mode-only_) or *only* in S/U-modes (_S/U-mode-only_). The rule locking becomes part of the definition of an _M-mode-only_ rule, since when a rule is added in M mode, if not locked, can be modified or removed in a few instructions. On the other hand, S/U modes can’t modify PMP rules anyway so locking them doesn’t make sense.
+
+.. This separation between _M-mode-only_ and _S/U-mode-only_ rules also allows us to distinguish which regions are to be used by processes in Machine mode (``pmpcfg.L == 1``) and which by Supervisor or User mode processes (``pmpcfg.L == 0``), in the same way the U bit on the Virtual Memory’s PTEs marks which Virtual Memory pages are to be used by User mode applications (U=1) and which by the Supervisor / OS (U=0). With this distinction in place we are able to implement memory access and execution prevention in M-mode for any physical memory region that is not _M-mode-only_.
++
+An attacker that manages to tamper with a memory region used by S/U mode, even after successfully tricking a process running in M-mode to use or execute that region, will fail to perform a successful attack since that region will be _S/U-mode-only_ hence any access when in M-mode will trigger an access exception.
++
+[NOTE]
+====
+In order to support zero-copy transfers between M-mode and S/U-mode we need to either allow shared memory regions, or introduce a mechanism similar to the ``sstatus.SUM`` bit to temporary allow the high-privileged mode (in this case M-mode) to be able to perform loads and stores on the region of a less-privileged process (in this case S/U-mode). In our case after discussion within the group it seemed a better idea to follow the first approach and have this functionality encoded on a per-rule basis to avoid the risk of leaving a temporary, global bypass active when exiting M-mode, hence rendering memory access prevention useless.
+====
++
+
+[NOTE]
+====
+Although it’s possible to use ``mstatus.MPRV`` in M-mode to read/write data on an _S/U-mode-only_ region using general purpose registers for copying, this will happen with S/U-mode permissions, honoring any MMU restrictions put in place by S-mode. Of course it’s still possible for M-mode to tamper with the page tables and / or add _S/U-mode-only_ rules and bypass the protections put in place by S-mode but if an attacker has managed to compromise M-mode to such extent, no security guarantees are possible in any way. *Also note that the threat model we present here assumes buggy software in M-mode, not compromised software*. We considered disabling ``mstatus.MPRV`` but it seemed too much and out of scope.
+====
++
+_Shared-region_ rules can be used both for zero-copy data transfers and for sharing code segments. The latter may be used for example to allow S/U-mode to execute code by the vendor, that makes use of some vendor-specific ISA extension, without having to go through the firmware with an ecall. This is similar to the vDSO approach followed on Linux, that allows user space code to execute kernel code without having to perform a system call.
++
+To make sure that shared data regions can’t be executed and shared code regions can’t be modified, the encoding changes the meaning of the ``pmpcfg.X bit``. In case of shared data regions, with the exception of the ``pmpcfg.LRWX=1111`` encoding, the ``pmpcfg.X`` bit marks the capability of S/U-mode to write to that region, so it’s not possible to encode an executable shared data region. In case of shared code regions, the ``pmpcfg.X`` bit marks the capability of M-mode to read from that region, and since ``pmpcfg.RW=01`` is used for encoding the shared region, it’s not possible to encode a shared writable code region.
++
+[NOTE]
+====
+For adding _Shared-region_ rules with executable privileges to share code segments between M-mode and S/U-mode, ``mseccfg.RLB`` needs to be implemented, or else such rules can only be added together with ``mseccfg.MML`` being set on *PMP Reset*. That's because the reserved encoding ``pmpcfg.RW=01`` being used for _Shared-region_ rules is only defined when ``mseccfg.MML`` is set, and 4b prevents the addition of rules with executable privileges on M-mode after ``mseccfg.MML`` is set unless ``mseccfg.RLB`` is also set.
+====
++
+[NOTE]
+====
+Using the ``pmpcfg.LRWX=1111`` encoding for a locked shared read-only data region was decided later on, its initial meaning was an M-mode-only read/write/execute region. The reason for that change was that the already defined shared data regions were not locked, so r/w access to M-mode couldn’t be restricted. In the same way we have execute-only shared code regions for both modes, it was decided to also be able to allow a least-privileged shared data region for both modes. This approach allows for example to share the .text section of an ELF with a shared code region and the .rodata section with a locked shared data region, without allowing M-mode to modify .rodata. We also decided that having a locked read/write/execute region in M-mode doesn’t make much sense and could be dangerous, since M-mode won’t be able to add further restrictions there (as in the case of S/U-mode where S-mode can further limit access to an ``pmpcfg.LWRX=0111`` region through the MMU), leaving the possibility of modifying an executable region in M-mode open.
+====
++
+[NOTE]
+====
+For encoding Shared-region rules initially we used one of the two reserved bits on pmpcfg (bit 5) but in order to avoid allocating an extra bit, since those bits are a very limited resource, it was decided to use the reserved R=0,W=1 combination.
+====
+.. The idea with this restriction is that after the Firmware or the OS running in M-mode is initialized and ``mseccfg.MML`` is set, no new code regions are expected to be added since nothing else is expected to run in M-mode (everything else will run in S/U mode). Since we want to limit the attack surface of the system as much as possible, it makes sense to disallow any new code regions which may include malicious code, to be added/executed in M-mode.
+
+.. In case ``mseccfg.MMWP`` is not set, M-mode can still access and execute any region not covered by a PMP rule. Since we try to prevent M-mode from executing malicious code and since an attacker may manage to place code on some region not covered by PMP (e.g. a directly-addressable flash memory), we need to ensure that M-mode can only execute the code segments initialized during firmware / OS initialization.
+
+.. We are only using the encoding ``pmpcfg.RW=01`` together with ``mseccfg.MML``, if ``mseccfg.MML`` is not set the encoding remains usable for future use.
diff --git a/src/smstateen.adoc b/src/smstateen.adoc
new file mode 100644
index 0000000..81a503d
--- /dev/null
+++ b/src/smstateen.adoc
@@ -0,0 +1,373 @@
+[[smstateen]]
+== "Smstateen/Ssstateen" Extensions, Version 1.0
+
+The implementation of optional RISC-V extensions has the potential to open
+covert channels between separate user threads, or between separate guest OSes
+running under a hypervisor. The problem occurs when an extension adds processor
+state -- usually explicit registers, but possibly other forms of state -- that
+the main OS or hypervisor is unaware of (and hence won't context-switch) but
+that can be modified/written by one user thread or guest OS and
+perceived/examined/read by another.
+
+For example, the Advanced Interrupt Architecture (AIA) for RISC-V adds
+to a hart as many as ten supervisor-level CSRs (`siselect`, `sireg`, `stopi`,
+`sseteipnum`, `sclreipnum`, `sseteienum`, `sclreienum`, `sclaimei`, `sieh`, and `siph`) and
+provides also the option for hardware to be backward-compatible with older,
+pre-AIA software. Because an older hypervisor that is oblivious to the AIA will
+not know to swap any of the AIA's new CSRs on context switches, the registers may
+then be used as a covert channel between multiple guest OSes that run atop this
+hypervisor. Although traditional practices might consider such a communication
+channel harmless, the intense focus on security today argues that a means be
+offered to plug such channels.
+
+The `f` registers of the RISC-V floating-point extensions and the `v` registers of
+the vector extension would similarly be potential covert channels between user
+threads, except for the existence of the FS and VS fields in the `sstatus`
+register. Even if an OS is unaware of, say, the vector extension and its `v`
+registers, access to those registers is blocked when the VS field is
+initialized to zero, either at machine level or by the OS itself initializing
+`sstatus`.
+
+Obviously, one way to prevent the use of new user-level CSRs as covert channels
+would be to add to `mstatus` or `sstatus` an "XS" field for each relevant
+extension, paralleling the V extension's VS field. However, this is not
+considered a general solution to the problem due to the number of potential
+future extensions that may add small amounts of state. Even with a 64-bit
+`sstatus` (necessitating adding `sstatush` for RV32), it is not certain there are
+enough remaining bits in `sstatus` to accommodate all future user-level
+extensions. In any event, there is no need to strain `sstatus` (and add `sstatush`)
+for this purpose. The "enable" flags that are needed to plug covert channels
+are not generally expected to require swapping on context switches of user
+threads, making them a less-than-compelling candidate for inclusion in `sstatus`.
+Hence, a new place is provided for them instead.
+
+=== State Enable Extensions
+
+The Smstateen and Ssstateen extensions collectively specify machine-mode and
+supervisor-mode features. The Smstateen extension specification comprises the
+mstateen*, sstateen*, and hstateen* CSRs and their functionality. The Ssstateen
+extension specification comprises only the sstateen* and hstateen* CSRs and their
+functionality.
+
+For RV64 harts, this extension adds four new 64-bit CSRs at machine level:
+`mstateen0` (Machine State Enable 0), `mstateen1`, `mstateen2`, and `mstateen3`.
+
+If supervisor mode is implemented, another four CSRs are defined at supervisor
+level:
+`sstateen0`, `sstateen1`, `sstateen2`, and `sstateen3`.
+
+And if the hypervisor extension is implemented, another set of CSRs is added:
+`hstateen0`, `hstateen1`, `hstateen2`, and `hstateen3`.
+
+For RV32, there are CSR addresses for accessing the upper 32 bits of
+corresponding machine-level and hypervisor CSRs:
+`mstateen0h`, `mstateen1h`, `mstateen2h`, `mstateen3h`,
+`hstateen0h`, `hstateen1h`, `hstateen2h`, and `hstateen3h`.
+
+For the supervisor-level `sstateen` registers, high-half CSRs are not added at
+this time because it is expected the upper 32 bits of these registers will
+always be zeros, as explained later below.
+
+Each bit of a `stateen` CSR controls less-privileged access to an extension's
+state, for an extension that was not deemed "worthy" of a full XS field in
+`sstatus` like the FS and VS fields for the F and V extensions. The number of
+registers provided at each level is four because it is believed that 4 * 64 =
+256 bits for machine and hypervisor levels, and 4 * 32 = 128 bits for
+supervisor level, will be adequate for many years to come, perhaps for as long
+as the RISC-V ISA is in use. The exact number four is an attempted compromise
+between providing too few bits on the one hand and going overboard with CSRs
+that will never be used on the other. A possible future doubling of the number
+of `stateen` CSRs is covered later.
+
+The `stateen` registers at each level control access to state at all
+less-privileged levels, but not at its own level. This is analogous to how the
+existing `counteren` CSRs control access to performance counter registers. Just
+as with the `counteren` CSRs, when a `stateen` CSR prevents access to state by
+less-privileged levels, an attempt in one of those privilege modes to execute
+an instruction that would read or write the protected state raises an illegal-instruction
+exception, or, if executing in VS or VU mode and the circumstances
+for a virtual-instruction exception apply, raises a virtual-instruction
+exception instead of an illegal-instruction exception.
+
+When this extension is not implemented, all state added by an extension is
+accessible as defined by that extension.
+
+When a `stateen` CSR prevents access to state for a privilege mode, attempting to
+execute in that privilege mode an instruction that _implicitly_ updates the
+state without reading it may or may not raise an illegal-instruction or virtual-instruction
+exception. Such cases must be disambiguated by being explicitly
+specified one way or the other.
+
+In some cases, the bits of the `stateen` CSRs will have a dual purpose as enables
+for the ISA extensions that introduce the controlled state.
+
+Each bit of a supervisor-level `sstateen` CSR controls user-level access (from
+U-mode or VU-mode) to an extension's state. The intention is to allocate the
+bits of `sstateen` CSRs starting at the least-significant end, bit 0, through to
+bit 31, and then on to the next-higher-numbered `sstateen` CSR.
+
+For every bit with a defined purpose in an `sstateen` CSR, the same bit is
+defined in the matching `mstateen` CSR to control access below machine level to
+the same state. The upper 32 bits of an `mstateen` CSR (or for RV32, the
+corresponding high-half CSR) control access to state that is inherently
+inaccessible to user level, so no corresponding enable bits in the
+supervisor-level `sstateen` CSR are applicable. The intention is to allocate bits
+for this purpose starting at the most-significant end, bit 63, through to bit
+32, and then on to the next-higher `mstateen` CSR. If the rate that bits are
+being allocated from the least-significant end for `sstateen` CSRs is
+sufficiently low, allocation from the most-significant end of `mstateen` CSRs may
+be allowed to encroach on the lower 32 bits before jumping to the next-higher
+`mstateen` CSR. In that case, the bit positions of "encroaching" bits will remain
+forever read-only zeros in the matching `sstateen` CSRs.
+
+With the hypervisor extension, the `hstateen` CSRs have identical encodings to
+the `mstateen` CSRs, except controlling accesses for a virtual machine (from VS
+and VU modes).
+
+Each standard-defined bit of a `stateen` CSR is WARL and may be read-only zero or
+one, subject to the following conditions.
+
+Bits in any `stateen` CSR that are defined to control state that a hart doesn't
+implement are read-only zeros for that hart. Likewise, all reserved bits not
+yet given a defined meaning are also read-only zeros. For every bit in an
+`mstateen` CSR that is zero (whether read-only zero or set to zero), the same bit
+appears as read-only zero in the matching `hstateen` and `sstateen` CSRs. For every
+bit in an `hstateen` CSR that is zero (whether read-only zero or set to zero),
+the same bit appears as read-only zero in `sstateen` when accessed in VS-mode.
+
+A bit in a supervisor-level `sstateen` CSR cannot be read-only one unless the
+same bit is read-only one in the matching `mstateen` CSR and, if it exists, in
+the matching `hstateen` CSR. A bit in an `hstateen` CSR cannot be read-only one
+unless the same bit is read-only one in the matching `mstateen` CSR.
+
+On reset, all writable `mstateen` bits are initialized by the hardware to zeros.
+If machine-level software changes these values, it is responsible for
+initializing the corresponding writable bits of the `hstateen` and `sstateen` CSRs
+to zeros too. Software at each privilege level should set its respective
+`stateen` CSRs to indicate the state it is prepared to allow less-privileged
+software to access. For OSes and hypervisors, this usually means the state that
+the OS or hypervisor is prepared to swap on a context switch, or to manage in
+some other way.
+
+For each `mstateen` CSR, bit 63 is defined to control access to the
+matching `sstateen` and `hstateen` CSRs. That is, bit 63 of `mstateen0` controls
+access to `sstateen0` and `hstateen0`; bit 63 of `mstateen1` controls access to
+`sstateen1` and `hstateen1`; etc. Likewise, bit 63 of each `hstateen`
+correspondingly controls access to the matching `sstateen` CSR.
+
+A hypervisor may need this control over accesses to the `sstateen` CSRs if it
+ever must emulate for a virtual machine an extension that is supposed to be
+affected by a bit in an `sstateen` CSR. Even if such emulation is uncommon,
+it should not be excluded.
+
+Machine-level software needs identical control to be able to emulate the
+hypervisor extension. That is, machine level needs control over accesses to the
+supervisor-level `sstateen` CSRs in order to emulate the `hstateen` CSRs, which
+have such control.
+
+Bit 63 of each `mstateen` CSR may be read-only zero only if the hypervisor
+extension is not implemented and the matching supervisor-level `sstateen` CSR is
+all read-only zeros. In that case, machine-level software should emulate
+attempts to access the affected `sstateen` CSR from S-mode, ignoring writes and
+returning zero for reads. Bit 63 of each `hstateen` CSR is always writable (not
+read-only).
+
+=== State Enable 0 Registers
+
+.Machine State Enable 0 Register (`mstateen0`)
+[wavedrom, ,svg]
+....
+{reg: [
+{bits: 1, name: 'C'},
+{bits: 1, name: 'FCSR'},
+{bits: 1, name: 'JVT'},
+{bits: 51, name: 'WPRI'},
+{bits: 1, name: 'CTR'},
+{bits: 1, name: 'SRMCFG'},
+{bits: 1, name: 'P1P13'},
+{bits: 1, name: 'CONTEXT'},
+{bits: 1, name: 'IMSIC'},
+{bits: 1, name: 'AIA'},
+{bits: 1, name: 'CSRIND'},
+{bits: 1, name: 'WPRI'},
+{bits: 1, name: 'ENVCFG'},
+{bits: 1, name: 'SE0'},
+], config: {bits: 64, lanes: 4, hspace:1024}}
+....
+
+.Hypervisor State Enable 0 Register (`hstateen0`)
+[wavedrom, ,svg]
+....
+{reg: [
+{bits: 1, name: 'C'},
+{bits: 1, name: 'FCSR'},
+{bits: 1, name: 'JVT'},
+{bits: 51, name: 'WPRI'},
+{bits: 1, name: 'CTR'},
+{bits: 2, name: 'WPRI'},
+{bits: 1, name: 'CONTEXT'},
+{bits: 1, name: 'IMSIC'},
+{bits: 1, name: 'AIA'},
+{bits: 1, name: 'CSRIND'},
+{bits: 1, name: 'WPRI'},
+{bits: 1, name: 'ENVCFG'},
+{bits: 1, name: 'SE0'},
+], config: {bits: 64, lanes: 4, hspace:1024}}
+....
+
+.Supervisor State Enable 0 Register (`sstateen0`)
+[wavedrom, ,svg]
+....
+{reg: [
+{bits: 1, name: 'C'},
+{bits: 1, name: 'FCSR'},
+{bits: 1, name: 'JVT'},
+{bits: 29, name: 'WPRI'}
+], config:{bits: 32, lanes: 2, hspace:1024}}
+....
+
+The C bit controls access to any and all custom state.
+The C bit of these registers is not custom state itself; it is a
+standard field of a standard CSR, either `mstateen0`, `hstateen0`, or
+`sstateen0`.
+
+[NOTE]
+====
+The requirements that non-standard extensions must meet to be conforming are not
+relaxed due solely to changes in the value of this bit. In particular, if
+software sets this bit but does not execute any custom instructions or access
+any custom state, the software must continue to execute as specified by all
+relevant RISC-V standards, or the hardware is not standard-conforming.
+====
+
+The FCSR bit controls access to `fcsr` for the case when floating-point
+instructions operate on `x` registers instead of `f` registers as specified by
+the Zfinx and related extensions (Zdinx, etc.). Whenever `misa.F` = 1, FCSR bit
+of `mstateen0` is read-only zero (and hence read-only zero in `hstateen0` and
+`sstateen0` too). For convenience, when the `stateen` CSRs are implemented and
+`misa.F` = 0, then if the FCSR bit of a controlling `stateen0` CSR is zero, all
+floating-point instructions cause an illegal-instruction exception (or virtual-instruction
+exception, if relevant), as though they all access `fcsr`, regardless of
+whether they really do.
+
+The JVT bit controls access to the `jvt` CSR provided by the Zcmt extension.
+
+The SE0 bit in `mstateen0` controls access to the `hstateen0`, `hstateen0h`,
+and the `sstateen0` CSRs. The SE0 bit in `hstateen0` controls access to the
+`sstateen0` CSR.
+
+The ENVCFG bit in `mstateen0` controls access to the `henvcfg`, `henvcfgh`,
+and the `senvcfg` CSRs. The ENVCFG bit in `hstateen0` controls access to the
+`senvcfg` CSRs.
+
+The CSRIND bit in `mstateen0` controls access to the `siselect`, `sireg*`,
+`vsiselect`, and the `vsireg*` CSRs provided by the Sscsrind extensions.
+The CSRIND bit in `hstateen0` controls access to the `siselect` and the
+`sireg*`, (really `vsiselect` and `vsireg*`) CSRs provided by the Sscsrind
+extensions.
+
+The IMSIC bit in `mstateen0` controls access to the IMSIC state, including
+CSRs `stopei` and `vstopei`, provided by the Ssaia extension. The IMSIC bit in
+`hstateen0` controls access to the guest IMSIC state, including CSRs `stopei`
+(really `vstopei`), provided by the Ssaia extension.
+
+[NOTE]
+====
+Setting the IMSIC bit in `hstateen0` to zero prevents a virtual machine from
+accessing the hart's IMSIC the same as setting `hstatus`.VGEIN = 0.
+====
+
+The AIA bit in `mstateen0` controls access to all state introduced by the
+Ssaia extension and not controlled by either the CSRIND or the IMSIC
+bits. The AIA bit in `hstateen0` controls access to all state introduced by the
+Ssaia extension and not controlled by either the CSRIND or the IMSIC
+bits of `hstateen0`.
+
+The CONTEXT bit in `mstateen0` controls access to the `scontext` and
+`hcontext` CSRs provided by the Sdtrig extension. The CONTEXT bit in
+`hstateen0` controls access to the `scontext` CSR provided by the Sdtrig
+extension.
+
+The P1P13 bit in `mstateen0` controls access to the `hedelegh` introduced by
+Privileged Specification Version 1.13.
+
+The SRMCFG bit in `mstateen0` controls access to the `srmcfg` CSR introduced by
+the Ssqosid <<ssqosid>> extension.
+
+=== Usage
+
+After the writable bits of the machine-level `mstateen` CSRs are initialized to
+zeros on reset, machine-level software can set bits in these registers to
+enable less-privileged access to the controlled state. This may be either
+because machine-level software knows how to swap the state or, more likely,
+because machine-level software isn't swapping supervisor-level environments.
+(Recall that the main reason the `mstateen` CSRs must exist is so machine level
+can emulate the hypervisor extension. When machine level isn't emulating the
+hypervisor extension, it is likely there will be no need to keep any
+implemented `mstateen` bits zero.)
+
+If machine level sets any writable `mstateen` bits to nonzero, it must initialize
+the matching `hstateen` CSRs, if they exist, by writing zeros to them. And if any
+`mstateen` bits that are set to one have matching bits in the `sstateen` CSRs,
+machine-level software must also initialize those `sstateen` CSRs by writing
+zeros to them. Ordinarily, machine-level software will want to set bit 63 of
+all `mstateen` CSRs, necessitating that it write zero to all `hstateen` CSRs.
+
+Software should ensure that all writable bits of `sstateen` CSRs are initialized
+to zeros when an OS at supervisor level is first entered. The OS can then set
+bits in these registers to enable user-level access to the controlled state,
+presumably because it knows how to context-swap the state.
+
+For the `sstateen` CSRs whose access by a guest OS is permitted by bit 63 of the
+corresponding `hstateen` CSRs, a hypervisor must include the `sstateen` CSRs in the
+context it swaps for a guest OS. When it starts a new guest OS, it must ensure
+the writable bits of those `sstateen` CSRs are initialized to zeros, and it must
+emulate accesses to any other `sstateen` CSRs.
+
+If software at any privilege level does not support multiple contexts for
+less-privilege levels, then it may choose to maximize less-privileged access to
+all state by writing a value of all ones to the `stateen` CSRs at its level (the
+`mstateen` CSRs for machine level, the `sstateen` CSRs for an OS, and the `hstateen`
+CSRs for a hypervisor), without knowing all the state to which it is granting
+access. This is justified because there is no risk of a covert channel between
+execution contexts at the less-privileged level when only one context exists
+at that level. This situation is expected to be common for machine level, and
+it might also arise, for example, for a type-1 hypervisor that hosts only a
+single guest virtual machine.
+
+[NOTE]
+====
+If a need is anticipated, the set of `stateen` CSRs could in the future be
+doubled by adding these:
+
+* `0x38C mstateen4`, `0x39C mstateen4h`
+
+* `0x38D mstateen5`, `0x39D mstateen5h`
+
+* `0x38E mstateen6`, `0x39E mstateen6h`
+
+* `0x38F mstateen7`, `0x39F mstateen7h`
+
+* `0x18C sstateen4`
+
+* `0x18D sstateen5`
+
+* `0x18E sstateen6`
+
+* `0x18F sstateen7`
+
+* `0x68C hstateen4`, `0x69C hstateen4h`
+
+* `0x68D hstateen5`, `0x69D hstateen5h`
+
+* `0x68E hstateen6`, `0x69E hstateen6h`
+
+* `0x68F hstateen7`, `0x69F hstateen7h`
+
+These additional CSRs are not a definite part of the original proposal because
+it is unclear whether they will ever be needed, and it is believed the rate of
+consumption of bits in the first group, registers numbered 0-3, will be slow
+enough that any looming shortage will be perceptible many years in advance. At
+the moment, it is not known even how many years it may take to exhaust just
+`mstateen0`, `sstateen0`, and `hstateen0`.
+====
diff --git a/src/sscofpmf.adoc b/src/sscofpmf.adoc
new file mode 100644
index 0000000..db1a45e
--- /dev/null
+++ b/src/sscofpmf.adoc
@@ -0,0 +1,126 @@
+[[Sscofpmf]]
+== "Sscofpmf" Extension for Count Overflow and Mode-Based Filtering, Version 1.0
+
+The current Privileged specification defines mhpmevent CSRs to select and
+control event counting by the associated hpmcounter CSRs, but provides no
+standardization of any fields within these CSRs. For at least Linux-class
+rich-OS systems it is desirable to standardize certain basic features that are
+broadly desired (and have come up over the past year plus on RISC-V lists, as
+well as have been the subject of past proposals). This enables there to be
+standard upstream software support that eliminates the need for implementations
+to provide their own custom software support.
+
+This extension serves to accomplish exactly this within the existing mhpmevent
+CSRs (and correspondingly avoids the unnecessary creation of whole new sets of
+CSRs - past just one new CSR).
+
+This extension sticks to addressing two basic well-understood needs that have
+been requested by various people. To make it easy to understand the deltas from
+the current Priv 1.11/1.12 specs, this is written as the actual exact changes
+to be made to existing paragraphs of Priv spec text (or additional paragraphs
+within the existing text).
+
+The extension name is "Sscofpmf" ('Ss' for Privileged arch and Supervisor-level
+extensions, and 'cofpmf' for Count OverFlow and Privilege Mode Filtering).
+
+Note that the new count overflow interrupt will be treated as a standard local
+interrupt that is assigned to bit 13 in the mip/mie/sip/sie registers.
+
+=== Count Overflow Control
+
+The following bits are added to `mhpmevent`:
+
+[cols="^1,^1,^1,^1,^1,^1,^1,^1",stripes=even,options="header"]
+|====
+|63 |62 |61 |60 |59 |58 |57 |56
+|OF |MINH |SINH |UINH |VSINH |VUINH |_WPRI_ |_WPRI_
+|====
+
+[cols="15%,85%",options="header"]
+|====
+| Field | Description
+| OF | Overflow status and interrupt disable bit that is set when counter overflows
+| MINH | If set, then counting of events in M-mode is inhibited
+| SINH | If set, then counting of events in S/HS-mode is inhibited
+| UINH | If set, then counting of events in U-mode is inhibited
+| VSINH | If set, then counting of events in VS-mode is inhibited
+| VUINH | If set, then counting of events in VU-mode is inhibited
+| _WPRI_ | Reserved
+| _WPRI_ | Reserved
+|====
+
+For each ``x``INH bit, if the associated privilege mode is not implemented,
+the bit is read-only zero.
+
+Each of the five ``x``INH bits, when set, inhibit counting of events while in
+privilege mode ``x``. All-zeroes for these bits results in counting of events in
+all modes.
+
+The OF bit is set when the corresponding hpmcounter overflows, and remains set
+until written by software. Since hpmcounter values are unsigned values,
+overflow is defined as unsigned overflow of the implemented counter bits. Note
+that there is no loss of information after an overflow since the counter wraps
+around and keeps counting while the sticky OF bit remains set.
+
+If supervisor mode is implemented, the 32-bit scountovf register contains
+read-only shadow copies of the OF bits in all 32 mhpmevent registers.
+
+If an hpmcounter overflows while the associated OF bit is zero, then a "count
+overflow interrupt request" is generated. If the OF bit is one, then no
+interrupt request is generated. Consequently the OF bit also functions as a
+count overflow interrupt disable for the associated hpmcounter.
+
+Count overflow never results from writes to the mhpmcounter__n__ or
+mhpmevent__n__ registers, only from hardware increments of counter registers.
+
+This count-overflow-interrupt-request signal is treated as a standard local
+interrupt that corresponds to bit 13 in the `mip`/`mie`/`sip`/`sie` registers.
+The `mip`/`sip` LCOFIP and `mie`/`sie` LCOFIE bits are, respectively, the
+interrupt-pending and interrupt-enable bits for this interrupt.
+('LCOFI' represents 'Local Count Overflow Interrupt'.)
+
+Generation of a count-overflow-interrupt request by an `hpmcounter` sets the
+associated OF bit.
+When an OF bit is set, it eventually, but not necessarily immediately, sets
+the LCOFIP bit in the `mip`/`sip` registers.
+The LCOFIP bit is cleared by software before servicing the count overflow
+interrupt resulting from one or more count overflows.
+The `mideleg` register controls the delegation of this interrupt to S-mode
+versus M-mode.
+
+[NOTE]
+====
+There are not separate overflow status and overflow interrupt enable bits. In
+practice, enabling overflow interrupt generation (by clearing the OF bit) is
+done in conjunction with initializing the counter to a starting value. Once a
+counter has overflowed, it and the OF bit must be reinitialized before another
+overflow interrupt can be generated.
+====
+
+[NOTE]
+====
+Software can distinguish newly overflowed counters (yet to be serviced by an
+overflow interrupt handler) from overflowed counters that have already been
+serviced or that are configured to not generate an interrupt on overflow, by
+maintaining a bit mask reflecting which counters are active and due to
+eventually overflow.
+====
+
+=== Supervisor Count Overflow (`scountovf`) Register
+
+This extension adds the `scountovf` CSR,
+a 32-bit read-only register that contains shadow copies of
+the OF bits in the 29 mhpmevent CSRs (mhpmevent__3__ - mhpmevent__31__) - where
+scountovf bit _X_ corresponds to mhpmevent__X__.
+
+This register enables supervisor-level overflow interrupt handler software to
+quickly and easily determine which counter(s) have overflowed (without needing
+to make an execution environment call or series of calls ultimately up to
+M-mode).
+
+Read access to bit _X_ is subject to the same mcounteren (or mcounteren and
+hcounteren) CSRs that mediate access to the hpmcounter CSRs by S-mode (or
+VS-mode). In M-mode, scountovf bit _X_ is always readable. In S/HS-mode, scountovf bit _X_ is readable when mcounteren bit
+_X_ is set, and otherwise reads as zero. Similarly, in VS mode, scountovf bit
+_X_ is readable when mcounteren bit _X_ and hcounteren bit _X_ are both set,
+and otherwise reads as zero.
diff --git a/src/ssdbltrp.adoc b/src/ssdbltrp.adoc
new file mode 100644
index 0000000..83a98bd
--- /dev/null
+++ b/src/ssdbltrp.adoc
@@ -0,0 +1,15 @@
+[[ssdbltrp]]
+== "Ssdbltrp" Double Trap Extension, Version 1.0
+
+The Ssdbltrp extension addresses a double trap (See <<machine-double-trap>>)
+privilege modes lower than M. It enables HS-mode to invoke a critical error
+handler in a virtual machine on a double trap in VS-mode. It also allows M-mode
+to invoke a critical error handler in the OS/Hypervisor on a double trap in
+S/HS-mode.
+
+The Ssdbltrp extension adds the `menvcfg`.DTE (See <<sec:menvcfg>>) and the
+`sstatus`.SDT fields (See <<sstatus>>). If the hypervisor extension is
+additionally implemented, then the extension adds the `henvcfg`.DTE (See
+<<sec:henvcfg>>) and the `vsstatus`.SDT fields (See <<vsstatus>>).
+
+See <<supv-double-trap>> for the operational details.
diff --git a/src/sstc.adoc b/src/sstc.adoc
new file mode 100644
index 0000000..7b735da
--- /dev/null
+++ b/src/sstc.adoc
@@ -0,0 +1,187 @@
+[[Sstc]]
+== "Sstc" Extension for Supervisor-mode Timer Interrupts, Version 1.0
+
+The current Privileged arch specification only defines a hardware mechanism for
+generating machine-mode timer interrupts (based on the mtime and mtimecmp
+registers). With the resultant requirement that timer services for
+S-mode/HS-mode (and for VS-mode) have to all be provided by M-mode - via SBI
+calls from S/HS-mode up to M-mode (or VS-mode calls to HS-mode and then to
+M-mode). M-mode software then multiplexes these multiple logical timers onto
+its one physical M-mode timer facility, and the M-mode timer interrupt handler
+passes timer interrupts back down to the appropriate lower privilege mode.
+
+This extension serves to provide supervisor mode with its own CSR-based timer
+interrupt facility that it can directly manage to provide its own timer service
+(in the form of having its own stimecmp register) - thus eliminating the large
+overheads for emulating S/HS-mode timers and timer interrupt generation up in
+M-mode. Further, this extension adds a similar facility to the Hypervisor
+extension for VS-mode.
+
+The extension name is "Sstc" ('Ss' for Privileged arch and Supervisor-level
+extensions, and 'tc' for timecmp). This extension adds the S-level stimecmp CSR
+and the VS-level vstimecmp CSR.
+
+=== Machine and Supervisor Level Additions
+
+==== Supervisor Timer (`stimecmp`) Register
+
+This extension adds this new CSR.
+
+The `stimecmp` CSR is a 64-bit register and has 64-bit precision on all RV32 and
+RV64 systems. In RV32 only, accesses to the `stimecmp` CSR access the low 32
+bits, while accesses to the `stimecmph` CSR access the high 32 bits of `stimecmp`.
+
+The CSR numbers for `stimecmp` / `stimecmph` are 0x14D / 0x15D (within the
+Supervisor Trap Setup block of CSRs).
+
+A supervisor timer interrupt becomes pending, as reflected in the STIP bit in
+the `mip` and `sip` registers whenever `time` contains a value greater than or
+equal to `stimecmp`, treating the values as unsigned integers.
+If the result of this comparison changes, it is guaranteed to be reflected in
+STIP eventually, but not necessarily immediately.
+The interrupt remains posted until `stimecmp` becomes greater than `time`,
+typically as a result of writing `stimecmp`.
+The interrupt will be taken based on the standard interrupt enable and
+delegation rules.
+
+[NOTE]
+====
+A spurious timer interrupt might occur if an interrupt handler advances
+`stimecmp` then immediately returns, because STIP might not yet have fallen in
+the interim. All software should be written to assume this event is possible,
+but most software should assume this event is extremely unlikely. It is almost
+always more performant to incur an occasional spurious timer interrupt than to
+poll STIP until it falls.
+====
+
+[NOTE]
+====
+In systems in which a supervisor execution environment (SEE) provides timer
+facilities via an SBI function call, this SBI call will continue to support
+requests to schedule a timer interrupt. The SEE will simply make use of
+stimecmp, changing its value as appropriate. This ensures compatibility with
+existing S-mode software that uses this SEE facility, while new S-mode software
+takes advantage of stimecmp directly.)
+====
+
+==== Machine Interrupt (`mip` and `mie`) Registers
+
+This extension modifies the description of the STIP/STIE bits in these
+registers as follows:
+
+If supervisor mode is implemented, its mip.STIP and mie.STIE are the
+interrupt-pending and interrupt-enable bits for supervisor-level timer
+interrupts. If the stimecmp register is not implemented, STIP is writable in
+mip, and may be written by M-mode software to deliver timer interrupts to
+S-mode. If the `stimecmp` (supervisor-mode timer compare) register is
+implemented, STIP is read-only in mip and reflects the supervisor-level timer
+interrupt signal resulting from stimecmp. This timer interrupt signal is
+cleared by writing `stimecmp` with a value greater than the current time value.
+
+==== Supervisor Interrupt (`sip` and `sie`) Registers
+
+This extension modifies the description of the STIP/STIE bits in these
+registers as follows:
+
+Bits `sip`.STIP and `sie`.STIE are the interrupt-pending and interrupt-enable bits
+for supervisor-level timer interrupts. If implemented, STIP is read-only in
+sip, and is either set and cleared by the execution environment (if `stimecmp` is
+not implemented), or reflects the timer interrupt signal resulting from
+`stimecmp` (if `stimecmp` is implemented). The `sip`.STIP bit, in response to timer
+interrupts generated by `stimecmp`, is set and cleared by writing `stimecmp` with a
+value that respectively is less than or equal to, or greater than, the current
+time value.
+
+==== Machine Counter-Enable (`mcounteren`) Register
+
+This extension adds to the description of the TM bit in this register as
+follows:
+
+In addition, when the TM bit in the mcounteren register is clear, attempts to
+access the `stimecmp` or `vstimecmp` register while executing in a mode less
+privileged than M will cause an illegal-instruction exception. When this bit
+is set, access to the `stimecmp` or `vstimecmp` register is permitted in S-mode if
+implemented, and access to the `vstimecmp` register (via `stimecmp`) is permitted
+in VS-mode if implemented and not otherwise prevented by the TM bit in
+`hcounteren`.
+
+=== Hypervisor Extension Additions
+
+==== Virtual Supervisor Timer (`vstimecmp`) Register
+
+This extension adds this new CSR.
+
+The `vstimecmp` CSR is a 64-bit register and has 64-bit precision on all RV32 and
+RV64 systems. In RV32 only, accesses to the `vstimecmp` CSR access the low 32
+bits, while accesses to the `vstimecmph` CSR access the high 32 bits of
+vstimecmp.
+
+The CSR numbers for `vstimecmp` / `vstimecmph` are 0x24D / 0x25D (within
+the Virtual Supervisor Registers block of CSRs, and mirroring the CSR numbers
+for stimecmp/stimecmph).
+
+A virtual supervisor timer interrupt becomes pending, as reflected in the
+VSTIP bit in the `hip` register, whenever (`time` + `htimedelta`), truncated
+to 64 bits, contains a value greater than or equal to `vstimecmp`, treating
+the values as unsigned integers.
+If the result of this comparison changes, it is guaranteed to be reflected in
+VSTIP eventually, but not necessarily immediately.
+The interrupt remains posted until `vstimecmp` becomes greater than (`time`
++ `htimedelta`), typically as a result of writing `vstimecmp`.
+The interrupt will be taken based on the standard interrupt enable and
+delegation rules while V=1.
+
+[NOTE]
+====
+In systems in which a supervisor execution environment (SEE) implemented by an
+HS-mode hypervisor provides timer facilities via an SBI function call, this SBI
+call will continue to support requests to schedule a timer interrupt. The SEE
+will simply make use of vstimecmp, changing its value as appropriate. This
+ensures compatibility with existing guest VS-mode software that uses this SEE
+facility, while new VS-mode software takes advantage of vstimecmp directly.)
+====
+
+==== Hypervisor Interrupt (`hvip`, `hip`, and `hie`) Registers
+
+This extension modifies the description of the VSTIP/VSTIE bits in the hip/hie
+registers as follows:
+
+Bits hip.VSTIP and hie.VSTIE are the interrupt-pending and interrupt-enable
+bits for VS-level timer interrupts. VSTIP is read-only in hip, and is the
+logical-OR of hvip.VSTIP and the timer interrupt signal resulting from
+`vstimecmp` (if `vstimecmp` is implemented). The `hip`.VSTIP bit, in response to
+timer interrupts generated by `vstimecmp`, is set and cleared by writing
+`vstimecmp` with a value that respectively is less than or equal to, or greater
+than, the current (`time` + `htimedelta`) value. The `hip`.VSTIP bit remains defined
+while V=0 as well as V=1.
+
+==== Hypervisor Counter-Enable (`hcounteren`) Register
+
+This extension adds to the description of the TM bit in this register as
+follows:
+
+In addition, when the TM bit in the `hcounteren` register is clear, attempts to
+access the `vstimecmp` register (via stimecmp) while executing in VS-mode will
+cause a virtual-instruction exception if the same bit in `mcounteren` is set.
+When this bit and the same bit in `mcounteren` are both set, access to the
+`vstimecmp` register (if implemented) is permitted in VS-mode.
+
+=== Environment Config (`menvcfg` and `henvcfg`) Support
+
+Enable/disable bits for this extension are provided in the new `menvcfg` /
+`henvcfg` CSRs.
+
+Bit 63 of `menvcfg` (or bit 31 of `menvcfgh`) - named STCE (STimecmp Enable) -
+enables `stimecmp` for S-mode when set to one, and the same bit of henvcfg
+enables `vstimecmp` for VS-mode. These STCE bits are WARL and are hard-wired to 0
+when this extension is not implemented.
+
+When this extension is implemented and STCE in `menvcfg` is zero, an attempt to access `stimecmp` or `vstimecmp` in a
+mode other than M-mode raises an illegal-instruction exception, STCE in `henvcfg`
+is read-only zero, and STIP in `mip` and `sip` reverts to its defined behavior as
+if this extension is not implemented. Further, if the H extension is implemented, then hip.VSTIP also reverts its defined behavior as if this extension is not implemented.
+
+But when STCE in `menvcfg` is one and STCE in `henvcfg` is zero, an attempt to access
+`stimecmp` (really `vstimecmp`) when V = 1 raises a virtual-instruction exception,
+and VSTIP in hip reverts to its defined behavior as if this extension is not
+implemented.
diff --git a/src/supervisor.adoc b/src/supervisor.adoc
new file mode 100644
index 0000000..fe4737d
--- /dev/null
+++ b/src/supervisor.adoc
@@ -0,0 +1,2457 @@
+[[supervisor]]
+== Supervisor-Level ISA, Version 1.13
+
+This chapter describes the RISC-V supervisor-level architecture, which
+contains a common core that is used with various supervisor-level
+address translation and protection schemes.
+
+[NOTE]
+====
+Supervisor mode is deliberately restricted in terms of interactions with
+underlying physical hardware, such as physical memory and device
+interrupts, to support clean virtualization. In this spirit, certain
+supervisor-level facilities, including requests for timer and
+interprocessor interrupts, are provided by implementation-specific
+mechanisms. In some systems, a supervisor execution environment (SEE)
+provides these facilities in a manner specified by a supervisor binary
+interface (SBI). Other systems supply these facilities directly, through
+some other implementation-defined mechanism.
+====
+
+=== Supervisor CSRs
+
+A number of CSRs are provided for the supervisor.
+
+[NOTE]
+====
+The supervisor should only view CSR state that should be visible to a
+supervisor-level operating system. In particular, there is no
+information about the existence (or non-existence) of higher privilege
+levels (machine level or other) visible in the CSRs accessible by the
+supervisor.
+
+Many supervisor CSRs are a subset of the equivalent machine-mode CSR,
+and the machine-mode chapter should be read first to help understand the
+supervisor-level CSR descriptions.
+====
+
+[[sstatus]]
+==== Supervisor Status (`sstatus`) Register
+
+The `sstatus` register is an SXLEN-bit read/write register formatted as
+shown in <<sstatusreg-rv32>> when SXLEN=32
+and <<sstatusreg>> when SXLEN=64. The `sstatus`
+register keeps track of the processor's current operating state.
+
+[[sstatusreg-rv32]]
+.Supervisor-mode status (`sstatus`) register when SXLEN=32.
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SIE'},
+ {bits: 3, name: 'WPRI'},
+ {bits: 1, name: 'SPIE'},
+ {bits: 1, name: 'UBE'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SPP'},
+ {bits: 2, name: 'VS[1:0]'},
+ {bits: 2, name: 'WPRI'},
+ {bits: 2, name: 'FS[1:0]'},
+ {bits: 2, name: 'XS[1:0]'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SUM'},
+ {bits: 1, name: 'MXR'},
+ {bits: 3, name: 'WPRI'},
+ {bits: 1, name: 'SPELP'},
+ {bits: 1, name: 'SDT'},
+ {bits: 6, name: 'WPRI'},
+ {bits: 1, name: 'SD'},
+], config:{lanes: 2, hspace:1024}}
+....
+
+[[sstatusreg]]
+.Supervisor-mode status (`sstatus`) register when SXLEN=64.
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SIE'},
+ {bits: 3, name: 'WPRI'},
+ {bits: 1, name: 'SPIE'},
+ {bits: 1, name: 'UBE'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SPP'},
+ {bits: 2, name: 'VS[1:0]'},
+ {bits: 2, name: 'WPRI'},
+ {bits: 2, name: 'FS[1:0]'},
+ {bits: 2, name: 'XS[1:0]'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'SUM'},
+ {bits: 1, name: 'MXR'},
+ {bits: 3, name: 'WPRI'},
+ {bits: 1, name: 'SPELP'},
+ {bits: 1, name: 'SDT'},
+ {bits: 7, name: 'WPRI'},
+ {bits: 2, name: 'UXL[1:0]'},
+ {bits: 29, name: 'WPRI'},
+ {bits: 1, name: 'SD'},
+], config:{lanes: 4, hspace:1024}}
+....
+
+The SPP bit indicates the privilege level at which a hart was executing
+before entering supervisor mode. When a trap is taken, SPP is set to 0
+if the trap originated from user mode, or 1 otherwise. When an SRET
+instruction (see <<otherpriv>>) is executed to
+return from the trap handler, the privilege level is set to user mode if
+the SPP bit is 0, or supervisor mode if the SPP bit is 1; SPP is then
+set to 0.
+
+The SIE bit enables or disables all interrupts in supervisor mode. When
+SIE is clear, interrupts are not taken while in supervisor mode. When
+the hart is running in user-mode, the value in SIE is ignored, and
+supervisor-level interrupts are enabled. The supervisor can disable
+individual interrupt sources using the `sie` CSR.
+
+The SPIE bit indicates whether supervisor interrupts were enabled prior
+to trapping into supervisor mode. When a trap is taken into supervisor
+mode, SPIE is set to SIE, and SIE is set to 0. When an SRET instruction
+is executed, SIE is set to SPIE, then SPIE is set to 1.
+
+The `sstatus` register is a subset of the `mstatus` register.
+
+[NOTE]
+====
+In a straightforward implementation, reading or writing any field in
+`sstatus` is equivalent to reading or writing the homonymous field in
+`mstatus`.
+====
+
+===== Base ISA Control in `sstatus` Register
+
+The UXL field controls the value of XLEN for U-mode, termed _UXLEN_,
+which may differ from the value of XLEN for S-mode, termed _SXLEN_. The
+encoding of UXL is the same as that of the MXL field of `misa`, shown in
+<<misabase>>.
+
+When SXLEN=32, the UXL field does not exist, and UXLEN=32. When
+SXLEN=64, it is a *WARL* field that encodes the current value of UXLEN. In
+particular, an implementation may make UXL be a read-only field whose
+value always ensures that UXLEN=SXLEN.
+
+If UXLEN≠SXLEN, instructions executed in the narrower
+mode must ignore source register operand bits above the configured XLEN,
+and must sign-extend results to fill the widest supported XLEN in the
+destination register.
+
+If UXLEN < SXLEN, user-mode instruction-fetch addresses
+and load and store effective addresses are taken modulo
+2^UXLEN^. For example, when UXLEN=32 and SXLEN=64,
+user-mode memory accesses reference the lowest 4 GiB of the address space.
+
+Some HINT instructions are encoded as integer computational instructions that
+overwrite their destination register with its current value, e.g.,
+`c.addi x8, 0`.
+When such a HINT is executed with XLEN < SXLEN and bits SXLEN..XLEN of the
+destination register not all equal to bit XLEN-1, it is implementation-defined
+whether bits SXLEN..XLEN of the destination register are unchanged or are
+overwritten with copies of bit XLEN-1.
+
+NOTE: This definition allows implementations to elide register write-back for
+some HINTs, while allowing them to execute other HINTs in the same manner as
+other integer computational instructions.
+The implementation choice is observable only by S-mode with SXLEN > UXLEN; it
+is invisible to U-mode.
+
+[[sum]]
+===== Memory Privilege in `sstatus` Register
+
+The MXR (Make eXecutable Readable) bit modifies the privilege with which
+loads access virtual memory. When MXR=0, only loads from pages marked
+readable (R=1 in <<sv32pte>>) will succeed. When
+MXR=1, loads from pages marked either readable or executable (R=1 or
+X=1) will succeed. MXR has no effect when page-based virtual memory is
+not in effect.
+
+The SUM (permit Supervisor User Memory access) bit modifies the
+privilege with which S-mode loads and stores access virtual memory. When
+SUM=0, S-mode memory accesses to pages that are accessible by U-mode
+(U=1 in <<sv32pte>>) will fault. When SUM=1, these
+accesses are permitted. SUM has no effect when page-based virtual memory
+is not in effect, nor when executing in U-mode. Note that S-mode can
+never execute instructions from user pages, regardless of the state of
+SUM.
+
+SUM is read-only 0 if `satp`.MODE is read-only 0.
+
+[NOTE]
+====
+The SUM mechanism prevents supervisor software from inadvertently
+accessing user memory. Operating systems can execute the majority of
+code with SUM clear; the few code segments that should access user
+memory can temporarily set SUM.
+
+The SUM mechanism does not avail S-mode software of permission to
+execute instructions in user code pages. Legitimate use cases for
+execution from user memory in supervisor context are rare in general and
+nonexistent in POSIX environments. However, bugs in supervisors that
+lead to arbitrary code execution are much easier to exploit if the
+supervisor exploit code can be stored in a user buffer at a virtual
+address chosen by an attacker.
+
+Some non-POSIX single address space operating systems do allow certain
+privileged software to partially execute in supervisor mode, while most
+programs run in user mode, all in a shared address space. This use case
+can be realized by mapping the physical code pages at multiple virtual
+addresses with different permissions, possibly with the assistance of
+the instruction page-fault handler to direct supervisor software to use
+the alternate mapping.
+====
+
+===== Endianness Control in `sstatus` Register
+
+The UBE bit is a *WARL* field that controls the endianness of explicit memory
+accesses made from U-mode, which may differ from the endianness of
+memory accesses in S-mode. An implementation may make UBE be a read-only
+field that always specifies the same endianness as for S-mode.
+
+UBE controls whether explicit load and store memory accesses made from
+U-mode are little-endian (UBE=0) or big-endian (UBE=1).
+
+UBE has no effect on instruction fetches, which are _implicit_ memory
+accesses that are always little-endian.
+
+For _implicit_ accesses to supervisor-level memory management data
+structures, such as page tables, S-mode endianness always applies and
+UBE is ignored.
+
+[NOTE]
+====
+Standard RISC-V ABIs are expected to be purely little-endian-only or
+big-endian-only, with no accommodation for mixing endianness.
+Nevertheless, endianness control has been defined so as to permit an OS
+of one endianness to execute user-mode programs of the opposite
+endianness.
+====
+
+===== Previous Expected Landing Pad (ELP) State in `sstatus` Register
+
+Access to the `SPELP` field, added by Zicfilp, accesses the homonymous
+fields of `mstatus` when `V=0`, and the homonymous fields of `vsstatus`
+when `V=1`.
+
+[[supv-double-trap]]
+===== Double Trap Control in `sstatus` Register
+
+The S-mode-disable-trap (`SDT`) bit is a WARL field introduced by the Ssdbltrp
+extension to address double trap (See <<machine-double-trap>>) at privilege
+modes lower than M.
+
+When the `SDT` bit is set to 1 by an explicit CSR write, the `SIE` (Supervisor
+Interrupt Enable) bit is cleared to 0. This clearing occurs regardless of the
+value written, if any, to the `SIE` bit by the same write. The `SIE` bit can
+only be set to 1 by an explicit CSR write if the `SDT` bit is being set to 0 by
+the same write or is already 0.
+
+When a trap is to be taken into S-mode, if the `SDT` bit is currently 0,
+it is then set to 1, and the trap is delivered as expected. However, if `SDT` is
+already set to 1, then this is an _unexpected trap_. In the event of an
+_unexpected trap_, a double-trap exception trap is delivered into M-mode. To
+deliver this trap, the hart writes registers, except `mcause` and `mtval2`, with
+the same information that the _unexpected trap_ would have written if it was
+taken into M-mode. The `mtval2` register is then set to what would be otherwise
+written into the `mcause` register by the _unexpected trap_. The `mcause`
+register is set to 16, the double-trap exception code.
+
+An `SRET` instruction sets the `SDT` bit to 0.
+
+[NOTE]
+====
+After a trap handler has saved the state, such as `scause`, `sepc`,
+and `stval`, needed for resuming from the trap and is reentrant, it
+should clear the `SDT` bit.
+
+Resetting the `SDT` by an `SRET` enables the trap handler to detect a double
+trap that may occur during the tail phase, where it restores critical state
+to return from a trap.
+
+The consequence of this specification is that if a critical error condition was
+caused by a guest-page fault, then the GPA will not be available in `mtval2`
+when the double trap is delivered to M-mode. This condition arises if the
+HS-mode invokes a hypervisor virtual-machine load or store instruction when
+`SDT` is 1 and the instruction raises a guest-page fault. The use of such an
+instruction in this phase of trap handling is not common. However, not recording
+the GPA is considered benign because, if required, it can still be obtained
+-- albeit with added effort -- through the process of walking the page tables.
+
+For a double trap that originates in VS-mode, M-mode should redirect the exception
+to HS-mode by copying the values of M-mode CSRs updated by the trap to HS-mode
+CSRs and should use an `MRET` to resume execution at the address in `stvec`.
+
+Supervisor Software Events (SSE), an extension to the SBI, provide a
+mechanism for supervisor software to register and service system events
+emanating from an SBI implementation, such as firmware or a hypervisor. In the
+event of a double trap, HS-mode and M-mode can utilize the SSE mechanism to
+invoke a critical-error handler in VS-mode or S/HS-mode, respectively.
+Additionally, the implementation of an SSE protocol can be considered as an
+optional measure to aid in the recovery from such critical errors.
+====
+
+==== Supervisor Trap Vector Base Address (`stvec`) Register
+
+The `stvec` register is an SXLEN-bit read/write register that holds trap
+vector configuration, consisting of a vector base address (BASE) and a
+vector mode (MODE).
+
+.Supervisor trap vector base address (`stvec`) register.
+include::images/bytefield/stvec.edn[]
+
+The BASE field in `stvec` is a  field that can hold any valid virtual or
+physical address, subject to the following alignment constraints: the
+address must be 4-byte aligned, and MODE settings other than Direct
+might impose additional alignment constraints on the value in the BASE
+field.
+Note that the CSR contains only bits XLEN-1 through 2 of the address BASE.
+When used as an address, the lower two bits are filled with zeroes to obtain
+an XLEN-bit address that is always aligned on a 4-byte boundary.
+
+[[stvec-mode]]
+.Encoding of `stvec` MODE field.
+[%autowidth,float="center",align="center",cols=">,^,<",options="header",]
+|===
+|Value |Name |Description
+|0 +
+1 +
+&#8805;2
+|Direct +
+Vectored
+|All exceptions set `pc` to BASE. +
+Asynchronous interrupts set `pc` to BASE+4&#215;cause. +
+_Reserved_
+|===
+
+The encoding of the MODE field is shown in
+<<stvec-mode>>. When MODE=Direct, all traps into
+supervisor mode cause the `pc` to be set to the address in the BASE
+field. When MODE=Vectored, all synchronous exceptions into supervisor
+mode cause the `pc` to be set to the address in the BASE field, whereas
+interrupts cause the `pc` to be set to the address in the BASE field
+plus four times the interrupt cause number. For example, a
+supervisor-mode timer interrupt (see <<scauses>>)
+causes the `pc` to be set to BASE+`0x14`. Setting MODE=Vectored may
+impose a stricter alignment constraint on BASE.
+
+==== Supervisor Interrupt (`sip` and `sie`) Registers
+
+The `sip` register is an SXLEN-bit read/write register containing
+information on pending interrupts, while `sie` is the corresponding
+SXLEN-bit read/write register containing interrupt enable bits.
+Interrupt cause number _i_ (as reported in CSR `scause`,
+<<scause>>) corresponds with bit _i_ in both `sip` and
+`sie`. Bits 15:0 are allocated to standard interrupt causes only, while
+bits 16 and above are designated for platform use.
+
+.Supervisor interrupt-pending register (`sip`).
+include::images/bytefield/sip.edn[]
+
+.Supervisor interrupt-enable register (`sie`).
+include::images/bytefield/sie.edn[]
+
+An interrupt _i_ will trap to S-mode if both of the following are true:
+(a) either the current privilege mode is S and the SIE bit in the
+`sstatus` register is set, or the current privilege mode has less
+privilege than S-mode; and (b) bit _i_ is set in both `sip` and `sie`.
+
+These conditions for an interrupt trap to occur must be evaluated in a
+bounded amount of time from when an interrupt becomes, or ceases to be,
+pending in `sip`, and must also be evaluated immediately following the
+execution of an SRET instruction or an explicit write to a CSR on which
+these interrupt trap conditions expressly depend (including `sip`, `sie`
+and `sstatus`).
+
+Interrupts to S-mode take priority over any interrupts to lower
+privilege modes.
+
+Each individual bit in register `sip` may be writable or may be
+read-only. When bit _i_ in `sip` is writable, a pending interrupt _i_
+can be cleared by writing 0 to this bit. If interrupt _i_ can become
+pending but bit _i_ in `sip` is read-only, the implementation must
+provide some other mechanism for clearing the pending interrupt (which
+may involve a call to the execution environment).
+
+A bit in `sie` must be writable if the corresponding interrupt can ever
+become pending. Bits of `sie` that are not writable are read-only zero.
+
+The standard portions (bits 15:0) of registers `sip` and `sie` are
+formatted as shown in Figures <<sipreg-standard>>
+and <<siereg-standard>> respectively.
+
+[[sipreg-standard]]
+.Standard portion (bits 15:0) of `sip`.
+include::images/bytefield/sipreg-standard.edn[]
+
+[[siereg-standard]]
+.Standard portion (bits 15:0) of `sie`.
+include::images/bytefield/siereg-standard.edn[]
+
+
+Bits `sip`.SEIP and `sie`.SEIE are the interrupt-pending and
+interrupt-enable bits for supervisor-level external interrupts. If
+implemented, SEIP is read-only in `sip`, and is set and cleared by the
+execution environment, typically through a platform-specific interrupt
+controller.
+
+Bits `sip`.STIP and `sie`.STIE are the interrupt-pending and
+interrupt-enable bits for supervisor-level timer interrupts. If
+implemented, STIP is read-only in `sip`, and is set and cleared by the
+execution environment.
+
+Bits `sip`.SSIP and `sie`.SSIE are the interrupt-pending and
+interrupt-enable bits for supervisor-level software interrupts. If
+implemented, SSIP is writable in `sip` and may also be set to 1 by a
+platform-specific interrupt controller.
+
+If the Sscofpmf extension is implemented, bits `sip`.LCOFIP and `sie`.LCOFIE
+are the interrupt-pending and interrupt-enable bits for local-counter-overflow
+interrupts.
+LCOFIP is read-write in `sip` and reflects the occurrence of a local
+counter-overflow overflow interrupt request resulting from any of the
+`mhpmevent__n__`.OF bits being set.
+If the Sscofpmf extension is not implemented, `sip`.LCOFIP and `sie`.LCOFIE are
+read-only zeros.
+
+[NOTE]
+====
+Interprocessor interrupts are sent to other harts by
+implementation-specific means, which will ultimately cause the SSIP bit
+to be set in the recipient hart’s `sip` register.
+====
+
+Each standard interrupt type (SEI, STI, SSI, or LCOFI) may not be implemented,
+in which case the corresponding interrupt-pending and interrupt-enable
+bits are read-only zeros. All bits in `sip` and `sie` are *WARL* fields. The
+implemented interrupts may be found by writing one to every bit location
+in `sie`, then reading back to see which bit positions hold a one.
+
+[NOTE]
+====
+The `sip` and `sie` registers are subsets of the `mip` and `mie`
+registers. Reading any implemented field, or writing any writable field,
+of `sip`/`sie` effects a read or write of the homonymous field of
+`mip`/`mie`.
+
+Bits 3, 7, and 11 of `sip` and `sie` correspond to the machine-mode
+software, timer, and external interrupts, respectively. Since most
+platforms will choose not to make these interrupts delegatable from
+M-mode to S-mode, they are shown as 0 in
+<<sipreg-standard>> and <<siereg-standard>>.
+====
+
+Multiple simultaneous interrupts destined for supervisor mode are
+handled in the following decreasing priority order: SEI, SSI, STI, LCOFI.
+
+==== Supervisor Timers and Performance Counters
+
+Supervisor software uses the same hardware performance monitoring
+facility as user-mode software, including the `time`, `cycle`, and
+`instret` CSRs. The implementation should provide a mechanism to modify
+the counter values.
+
+The implementation must provide a facility for scheduling timer
+interrupts in terms of the real-time counter, `time`.
+
+==== Counter-Enable (`scounteren`) Register
+
+.Counter-enable (`scounteren`) register
+include::images/bytefield/scounteren.edn[]
+
+The counter-enable (`scounteren`) CSR is a 32-bit register that
+controls the availability of the hardware performance monitoring
+counters to U-mode.
+
+When the CY, TM, IR, or HPM__n__ bit in the `scounteren` register is
+clear, attempts to read the `cycle`, `time`, `instret`, or `hpmcountern`
+register while executing in U-mode will cause an illegal-instruction
+exception. When one of these bits is set, access to the corresponding
+register is permitted.
+
+`scounteren` must be implemented. However, any of the bits may be
+read-only zero, indicating reads to the corresponding counter will cause
+an exception when executing in U-mode. Hence, they are effectively
+*WARL* fields.
+
+[NOTE]
+====
+The setting of a bit in `mcounteren` does not affect whether the
+corresponding bit in `scounteren` is writable. However, U-mode may only
+access a counter if the corresponding bits in `scounteren` and
+`mcounteren` are both set.
+====
+
+==== Supervisor Scratch (`sscratch`) Register
+
+The `sscratch` CSR is an SXLEN-bit read/write register, dedicated
+for use by the supervisor. Typically, `sscratch` is used to hold a
+pointer to the hart-local supervisor context while the hart is executing
+user code.
+At the beginning of a trap handler, software normally uses a CSRRW
+instruction to swap `sscratch` with an integer register to obtain an
+initial working register.
+
+.Supervisor Scratch Register
+include::images/bytefield/sscratch.edn[]
+
+==== Supervisor Exception Program Counter (`sepc`) Register
+
+`sepc` is an SXLEN-bit read/write CSR formatted as shown in
+<<epcreg>>. The low bit of `sepc` (`sepc[0]`) is always zero. On implementations that support only IALIGN=32, the two low bits (`sepc[1:0]`) are always zero.
+
+If an implementation allows IALIGN to be either 16 or 32 (by changing
+CSR `misa`, for example), then, whenever IALIGN=32, bit `sepc[1]` is
+masked on reads so that it appears to be 0. This masking occurs also for
+the implicit read by the SRET instruction. Though masked, `sepc[1]`
+remains writable when IALIGN=32.
+
+`sepc` is a *WARL* register that must be able to hold all valid virtual
+addresses. It need not be capable of holding all possible invalid
+addresses. Prior to writing `sepc`, implementations may convert an
+invalid address into some other invalid address that `sepc` is capable
+of holding.
+
+When a trap is taken into S-mode, `sepc` is written with the virtual
+address of the instruction that was interrupted or that encountered the
+exception. Otherwise, `sepc` is never written by the implementation,
+though it may be explicitly written by software.
+
+[[epcreg]]
+.Supervisor exception program counter register.
+include::images/bytefield/epcreg.edn[]
+
+[[scause]]
+==== Supervisor Cause (`scause`) Register
+
+The `scause` CSR is an SXLEN-bit read-write register formatted as
+shown in <<scausereg>>. When a trap is taken into
+S-mode, `scause` is written with a code indicating the event that
+caused the trap. Otherwise, `scause` is never written by the
+implementation, though it may be explicitly written by software.
+
+The Interrupt bit in the `scause` register is set if the trap was caused
+by an interrupt. The Exception Code field contains a code identifying
+the last exception or interrupt. <<scauses>> lists
+the possible exception codes for the current supervisor ISAs. The
+Exception Code is a *WLRL* field. It is required to hold the values 0–31
+(i.e., bits 4–0 must be implemented), but otherwise it is only
+guaranteed to hold supported exception codes.
+
+[[scausereg]]
+.Supervisor Cause (`scause`) register.
+include::images/bytefield/scausereg.edn[]
+
+[[scauses]]
+.Supervisor cause (`scause`) register values after trap. Synchronous exception priorities are given by <<exception-priority>>.
+[%autowidth,float="center",align="center",cols=">,>,3",options="header"]
+|===
+|Interrupt |Exception Code |Description
+|1 +
+1 +
+1 +
+1 +
+1 +
+1 +
+1 +
+1 +
+1 +
+1
+|0 +
+1 +
+2-4 +
+5 +
+6-8 +
+9 +
+10-12 +
+13 +
+14-15 +
+&#8805;16
+|_Reserved_ +
+Supervisor software interrupt +
+_Reserved_ +
+Supervisor timer interrupt +
+_Reserved_ +
+Supervisor external interrupt +
+_Reserved_ +
+Counter-overflow interrupt +
+_Reserved_ +
+_Designated for platform use_
+
+|0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0 +
+0
+|0 +
+1 +
+2 +
+3 +
+4 +
+5 +
+6 +
+7 +
+8 +
+9 +
+10-11 +
+12 +
+13 +
+14 +
+15 +
+16-17 +
+18 +
+19 +
+20-23 +
+24-31 +
+32-47 +
+48-63 +
+&#8805;64
+|Instruction address misaligned +
+Instruction access fault +
+Illegal instruction +
+Breakpoint +
+Load address misaligned +
+Load access fault +
+Store/AMO address misaligned +
+Store/AMO access fault +
+Environment call from U-mode +
+Environment call from S-mode +
+_Reserved_ +
+Instruction page fault +
+Load page fault +
+_Reserved_ +
+Store/AMO page fault +
+_Reserved_ +
+Software check +
+Hardware error +
+_Reserved_ +
+_Designated for custom use_ +
+_Reserved_ +
+_Designated for custom use_ +
+_Reserved_
+|===
+
+==== Supervisor Trap Value (`stval`) Register
+
+The `stval` CSR is an SXLEN-bit read-write register formatted as
+shown in <<stvalreg>>. When a trap is taken into
+S-mode, `stval` is written with exception-specific information to assist
+software in handling the trap. Otherwise, `stval` is never written by
+the implementation, though it may be explicitly written by software. The
+hardware platform will specify which exceptions must set `stval`
+informatively, which may unconditionally set it to zero, and which may
+exhibit either behavior, depending on the underlying event that caused the
+exception.
+
+If `stval` is written with a nonzero value when a breakpoint,
+address-misaligned, access-fault, page-fault, or hardware-error exception
+occurs on an
+instruction fetch, load, or store, then `stval` will contain the
+faulting virtual address.
+
+On a breakpoint exception raised by an EBREAK or C.EBREAK instruction, `stval`
+is written with either zero or the virtual address of the instruction.
+
+[[stvalreg]]
+.Supervisor Trap Value register.
+include::images/bytefield/stvalreg.edn[]
+
+If `stval` is written with a nonzero value when a misaligned load or
+store causes an access-fault, page-fault, or hardware-error exception,
+then `stval` will
+contain the virtual address of the portion of the access that caused the
+fault.
+
+If `stval` is written with a nonzero value when an instruction
+access-fault, page-fault, or hardware-error exception occurs on a hart with
+variable-length instructions, then `stval` will contain the virtual
+address of the portion of the instruction that caused the fault, while
+`sepc` will point to the beginning of the instruction.
+
+The `stval` register can optionally also be used to return the faulting
+instruction bits on an illegal-instruction exception (`sepc` points to
+the faulting instruction in memory). If `stval` is written with a
+nonzero value when an illegal-instruction exception occurs, then `stval`
+will contain the shortest of:
+
+* the actual faulting instruction
+* the first ILEN bits of the faulting instruction
+* the first SXLEN bits of the faulting instruction
+
+The value loaded into `stval` on an illegal-instruction exception is
+right-justified and all unused upper bits are cleared to zero.
+
+On a trap caused by a software-check exception, the `stval` register holds the
+cause for the exception. The following encodings are defined:
+
+* 0 - No information provided.
+* 2 - Landing Pad Fault. Defined by the Zicfilp extension (<<priv-forward>>).
+* 3 - Shadow Stack Fault. Defined by the Zicfiss extension (<<priv-backward>>).
+
+For other traps, `stval` is set to zero, but a future standard may
+redefine `stval`’s setting for other traps.
+
+`stval` is a *WARL* register that must be able to hold all valid virtual
+addresses and the value 0. It need not be capable of holding all
+possible invalid addresses. Prior to writing `stval`, implementations
+may convert an invalid address into some other invalid address that
+`stval` is capable of holding. If the feature to return the faulting
+instruction bits is implemented, `stval` must also be able to hold all
+values less than 2^_N_^, where _N_ is the smaller
+of SXLEN and ILEN.
+
+[[sec:senvcfg]]
+==== Supervisor Environment Configuration (`senvcfg`) Register
+
+The `senvcfg` CSR is an SXLEN-bit read/write register, formatted as
+shown in <<senvcfg>>, that controls certain
+characteristics of the U-mode execution environment.
+
+[[senvcfg]]
+.Supervisor environment configuration register (`senvcfg`) for RV64.
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'FIOM'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'LPE'},
+ {bits: 1, name: 'SSE'},
+ {bits: 2, name: 'CBIE'},
+ {bits: 1, name: 'CBCFE'},
+ {bits: 1, name: 'CBZE'},
+ {bits: 24, name: 'WPRI'},
+ {bits: 2, name: 'PMM'},
+ {bits: 30, name: 'WPRI'},
+], config:{lanes: 4, hspace:1024}}
+....
+
+.Supervisor environment configuration register (`senvcfg`) for RV32.
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 1, name: 'FIOM'},
+ {bits: 1, name: 'WPRI'},
+ {bits: 1, name: 'LPE'},
+ {bits: 1, name: 'SSE'},
+ {bits: 2, name: 'CBIE'},
+ {bits: 1, name: 'CBCFE'},
+ {bits: 1, name: 'CBZE'},
+ {bits: 24, name: 'WPRI'},
+], config:{lanes: 2, hspace:1024}}
+....
+
+If bit FIOM (Fence of I/O implies Memory) is set to one in `senvcfg`,
+FENCE instructions executed in U-mode are modified so the requirement to
+order accesses to device I/O implies also the requirement to order main
+memory accesses. <<senvcfg-FIOM>> details the modified
+interpretation of FENCE instruction bits PI, PO, SI, and SO in U-mode
+when FIOM=1.
+
+Similarly, for U-mode when FIOM=1, if an atomic instruction that
+accesses a region ordered as device I/O has its _aq_ and/or _rl_ bit
+set, then that instruction is ordered as though it accesses both device
+I/O and memory.
+
+If `satp`.MODE is read-only zero (always Bare), the implementation may
+make FIOM read-only zero.
+
+[[senvcfg-FIOM]]
+.Modified interpretation of FENCE predecessor and successor sets in U-mode when FIOM=1.
+[%autowidth,float="center",align="center",cols="^,<",options="header"]
+|===
+|Instruction bit |Meaning when set
+|PI +
+PO
+|Predecessor device input and memory reads (PR implied) +
+Predecessor device output and memory writes (PW implied)
+|SI +
+SO
+|Successor device input and memory reads (SR implied) +
+Successor device output and memory writes (SW implied)
+|===
+
+[NOTE]
+====
+Bit FIOM exists for a specific circumstance when an I/O device is being
+emulated for U-mode and both of the following are true: (a) the emulated
+device has a memory buffer that should be I/O space but is actually
+mapped to main memory via address translation, and (b) multiple physical
+harts are involved in accessing this emulated device from U-mode.
+
+A hypervisor running in S-mode without the benefit of the hypervisor
+extension of <<hypervisor>> may need to emulate
+a device for U-mode if paravirtualization cannot be employed. If the
+same hypervisor provides a virtual machine (VM) with multiple virtual
+harts, mapped one-to-one to real harts, then multiple harts may
+concurrently access the emulated device, perhaps because: (a) the guest
+OS within the VM assigns device interrupt handling to one hart while the
+device is also accessed by a different hart outside of an interrupt
+handler, or (b) control of the device (or partial control) is being
+migrated from one hart to another, such as for interrupt load balancing
+within the VM. For such cases, guest software within the VM is expected
+to properly coordinate access to the (emulated) device across multiple
+harts using mutex locks and/or interprocessor interrupts as usual, which
+in part entails executing I/O fences. But those I/O fences may not be
+sufficient if some of the device ``I/O'' is actually main memory,
+unknown to the guest. Setting FIOM=1 modifies those fences (and all
+other I/O fences executed in U-mode) to include main memory, too.
+
+Software can always avoid the need to set FIOM by never using main
+memory to emulate a device memory buffer that should be I/O space.
+However, this choice usually requires trapping all U-mode accesses to
+the emulated buffer, which might have a noticeable impact on
+performance. The alternative offered by FIOM is sufficiently inexpensive
+to implement that we consider it worth supporting even if only rarely
+enabled.
+====
+
+The definition of the CBZE field is furnished by the Zicboz extension.
+
+The definitions of the CBCFE and CBIE fields are furnished by the Zicbom
+extension.
+
+The definition of the PMM field is furnished by the Ssnpm extension.
+
+The Zicfilp extension adds the `LPE` field in `senvcfg`. When the `LPE` field is
+set to 1, the Zicfilp extension is enabled in VU/U-mode. When the `LPE` field is
+0, the Zicfilp extension is not enabled in VU/U-mode and the following rules
+apply to VU/U-mode:
+
+* The hart does not update the `ELP` state; it remains as `NO_LP_EXPECTED`.
+* The `LPAD` instruction operates as a no-op.
+
+The Zicfiss extension adds the `SSE` field in `senvcfg`. When the `SSE` field is
+set to 1, the Zicfiss extension is activated in VU/U-mode. When the `SSE` field
+is 0, the Zicfiss extension remains inactive in VU/U-mode, and the following
+rules apply:
+
+* 32-bit Zicfiss instructions will revert to their behavior as defined by Zimop.
+* 16-bit Zicfiss instructions will revert to their behavior as defined by Zcmop.
+* When `menvcfg.SSE` is one, `SSAMOSWAP.W/D` raises an illegal-instruction
+ exception in U-mode and a virtual-instruction exception in VU-mode.
+
+[[satp]]
+==== Supervisor Address Translation and Protection (`satp`) Register
+
+The `satp` CSR is an SXLEN-bit read/write register, formatted as
+shown in <<rv32satp>> for SXLEN=32 and
+<<rv64satp>> for SXLEN=64, which controls
+supervisor-mode address translation and protection. This register holds
+the physical page number (PPN) of the root page table, i.e., its
+supervisor physical address divided by 4 KiB; an address space identifier
+(ASID), which facilitates address-translation fences on a
+per-address-space basis; and the MODE field, which selects the current
+address-translation scheme. Further details on the access to this
+register are described in <<virt-control>>.
+
+[[rv32satp]]
+.Supervisor address translation and protection (`satp`) register when SXLEN=32.
+include::images/bytefield/rv32satp.edn[]
+
+[NOTE]
+====
+Storing a PPN in `satp`, rather than a physical address, supports a
+physical address space larger than 4 GiB for RV32.
+
+The `satp`.PPN field might not be capable of holding all physical page
+numbers. Some platform standards might place constraints on the values
+`satp`.PPN may assume, e.g., by requiring that all physical page numbers
+corresponding to main memory be representable.
+====
+
+[[rv64satp]]
+.Supervisor address translation and protection (`satp`) register when SXLEN=64, for MODE values Bare, Sv39, Sv48, and Sv57.
+include::images/bytefield/rv64satp.edn[]
+
+[NOTE]
+====
+We store the ASID and the page table base address in the same CSR to
+allow the pair to be changed atomically on a context switch. Swapping
+them non-atomically could pollute the old virtual address space with new
+translations, or vice-versa. This approach also slightly reduces the
+cost of a context switch.
+====
+
+<<satp-mode>> shows the encodings of the MODE field when
+SXLEN=32 and SXLEN=64. When MODE=Bare, supervisor virtual addresses are
+equal to supervisor physical addresses, and there is no additional
+memory protection beyond the physical memory protection scheme described
+in <<pmp>>. To select MODE=Bare, software must write
+zero to the remaining fields of `satp` (bits 30–0 when SXLEN=32, or bits
+59–0 when SXLEN=64). Attempting to select MODE=Bare with a nonzero
+pattern in the remaining fields has an UNSPECIFIED effect on the value that the
+remaining fields assume and an UNSPECIFIED effect on address translation and
+protection behavior.
+
+When SXLEN=32, the `satp` encodings corresponding to MODE=Bare and
+ASID[8:7]=3 are designated for custom use, whereas the encodings
+corresponding to MODE=Bare and ASID[8:7]≠3 are reserved
+for future standard use. When SXLEN=64, all `satp` encodings
+corresponding to MODE=Bare are reserved for future standard use.
+
+[NOTE]
+====
+Version 1.11 of this standard stated that the remaining fields in `satp`
+had no effect when MODE=Bare. Making these fields reserved facilitates
+future definition of additional translation and protection modes,
+particularly in RV32, for which all patterns of the existing MODE field
+have already been allocated.
+====
+
+When SXLEN=32, the only other valid setting for MODE is Sv32, a paged
+virtual-memory scheme described in <<sv32>>.
+
+When SXLEN=64, three paged virtual-memory schemes are defined: Sv39,
+Sv48, and Sv57, described in <<sv39>>, <<sv48>>,
+and <<sv57>>, respectively. One additional scheme, Sv64, will be
+defined in a later version of this specification. The remaining MODE
+settings are reserved for future use and may define different
+interpretations of the other fields in `satp`.
+
+Implementations are not required to support all MODE settings, and if
+`satp` is written with an unsupported MODE, the entire write has no
+effect; no fields in `satp` are modified.
+
+The number of ASID bits is UNSPECIFIED and may be zero. The number of implemented
+ASID bits, termed _ASIDLEN_, may be determined by writing one to every
+bit position in the ASID field, then reading back the value in `satp` to
+see which bit positions in the ASID field hold a one. The
+least-significant bits of ASID are implemented first: that is, if
+ASIDLEN > 0, ASID[ASIDLEN-1:0] is writable. The maximal
+value of ASIDLEN, termed ASIDMAX, is 9 for Sv32 or 16 for Sv39, Sv48,
+and Sv57.
+
+<<<
+
+[[satp-mode]]
+.Encoding of `satp` MODE field.
+[%autowidth,float="center",align="center",cols="^,^,<",options="header"]
+|===
+3+|SXLEN=32
+|Value |Name |Description
+|0 +
+1
+|Bare +
+Sv32
+|No translation or protection. +
+Page-based 32-bit virtual addressing (see <<sv32>>).
+3+|*SXLEN=64*
+|Value |Name |Description
+|0 +
+1-7 +
+8 +
+9 +
+10 +
+11 +
+12-13 +
+14-15
+|Bare +
+- +
+Sv39 +
+Sv48 +
+Sv57 +
+Sv64 +
+- +
+-
+|No translation or protection. +
+_Reserved for standard use_ +
+Page-based 39-bit virtual addressing (see <<sv39>>). +
+Page-based 48-bit virtual addressing (see <<sv48>>). +
+Page-based 57-bit virtual addressing (see <<sv57>>). +
+_Reserved for page-based 64-bit virtual addressing._ +
+_Reserved for standard use_ +
+_Designated for custom use_
+|===
+
+[NOTE]
+====
+For many applications, the choice of page size has a substantial
+performance impact. A large page size increases TLB reach and loosens
+the associativity constraints on virtually indexed, physically tagged
+caches. At the same time, large pages exacerbate internal fragmentation,
+wasting physical memory and possibly cache capacity.
+
+After much deliberation, we have settled on a conventional page size of
+4 KiB for both RV32 and RV64. We expect this decision to ease the
+porting of low-level runtime software and device drivers. The TLB reach
+problem is ameliorated by transparent superpage support in modern
+operating systems. cite:[transparent-superpages] Additionally, multi-level TLB hierarchies are quite
+inexpensive relative to the multi-level cache hierarchies whose address
+space they map.
+====
+
+The `satp` CSR is considered _active_ when the effective privilege
+mode is S-mode or U-mode. Executions of the address-translation
+algorithm may only begin using a given value of `satp` when `satp` is
+active.
+
+[NOTE]
+====
+Translations that began while `satp` was active are not required to
+complete or terminate when `satp` is no longer active, unless an
+SFENCE.VMA instruction matching the address and ASID is executed. The
+SFENCE.VMA instruction must be used to ensure that updates to the
+address-translation data structures are observed by subsequent implicit
+reads to those structures by a hart.
+====
+
+Note that writing `satp` does not imply any ordering constraints between
+page-table updates and subsequent address translations, nor does it
+imply any invalidation of address-translation caches. If the new address
+space’s page tables have been modified, or if an ASID is reused, it may
+be necessary to execute an SFENCE.VMA instruction (see
+<<sfence.vma>>) after, or in some cases before, writing
+`satp`.
+
+[NOTE]
+====
+Not imposing upon implementations to flush address-translation caches
+upon `satp` writes reduces the cost of context switches, provided a
+sufficiently large ASID space.
+====
+
+=== Supervisor Instructions
+
+In addition to the SRET instruction defined in <<otherpriv>>, one new supervisor-level instruction is provided.
+
+[[sfence.vma]]
+==== Supervisor Memory-Management Fence Instruction
+include::images/wavedrom/sfencevma.edn[]
+
+
+The supervisor memory-management fence instruction SFENCE.VMA is used to
+synchronize updates to in-memory memory-management data structures with
+current execution. Instruction execution causes implicit reads and
+writes to these data structures; however, these implicit references are
+ordinarily not ordered with respect to explicit loads and stores.
+Executing an SFENCE.VMA instruction guarantees that any previous stores
+already visible to the current RISC-V hart are ordered before certain
+implicit references by subsequent instructions in that hart to the
+memory-management data structures. The specific set of operations
+ordered by SFENCE.VMA is determined by _rs1_ and _rs2_, as described
+below. SFENCE.VMA is also used to invalidate entries in the
+address-translation cache associated with a hart (see <<sv32algorithm>>). Further details on the behavior of this instruction are described in <<virt-control>> and <<pmp-vmem>>.
+
+[NOTE]
+====
+The SFENCE.VMA is used to flush any local hardware caches related to
+address translation. It is specified as a fence rather than a TLB flush
+to provide cleaner semantics with respect to which instructions are
+affected by the flush operation and to support a wider variety of
+dynamic caching structures and memory-management schemes. SFENCE.VMA is
+also used by higher privilege levels to synchronize page table writes
+and the address translation hardware.
+====
+
+SFENCE.VMA orders only the local hart’s implicit references to the
+memory-management data structures.
+
+[NOTE]
+====
+Consequently, other harts must be notified separately when the
+memory-management data structures have been modified. One approach is to
+use 1) a local data fence to ensure local writes are visible globally,
+then 2) an interprocessor interrupt to the other thread, then 3) a local
+SFENCE.VMA in the interrupt handler of the remote thread, and finally 4)
+signal back to originating thread that operation is complete. This is,
+of course, the RISC-V analog to a TLB shootdown.
+====
+
+For the common case that the translation data structures have only been
+modified for a single address mapping (i.e., one page or superpage),
+_rs1_ can specify a virtual address within that mapping to effect a
+translation fence for that mapping only. Furthermore, for the common
+case that the translation data structures have only been modified for a
+single address-space identifier, _rs2_ can specify the address space.
+The behavior of SFENCE.VMA depends on _rs1_ and _rs2_ as follows:
+
+* If __rs1__=`x0` and __rs2__=`x0`, the fence orders all reads and writes
+made to any level of the page tables, for all address spaces. The fence
+also invalidates all address-translation cache entries, for all address
+spaces.
+* If __rs1__=`x0` and __rs2__{ne}``x0``, the fence orders all
+reads and writes made to any level of the page tables, but only for the
+address space identified by integer register _rs2_. Accesses to _global_
+mappings (see <<translation>>) are not ordered. The
+fence also invalidates all address-translation cache entries matching
+the address space identified by integer register _rs2_, except for
+entries containing global mappings.
+* If __rs1__{ne}``x0`` and __rs2__=`x0`, the fence orders only
+reads and writes made to leaf page table entries corresponding to the
+virtual address in __rs1__, for all address spaces. The fence also
+invalidates all address-translation cache entries that contain leaf page
+table entries corresponding to the virtual address in _rs1_, for all
+address spaces.
+* If __rs1__{ne}``x0`` and __rs2__{ne}``x0``, the
+fence orders only reads and writes made to leaf page table entries
+corresponding to the virtual address in _rs1_, for the address space
+identified by integer register _rs2_. Accesses to global mappings are
+not ordered. The fence also invalidates all address-translation cache
+entries that contain leaf page table entries corresponding to the
+virtual address in _rs1_ and that match the address space identified by
+integer register _rs2_, except for entries containing global mappings.
+
+If the value held in _rs1_ is not a valid virtual address, then the
+SFENCE.VMA instruction has no effect. No exception is raised in this
+case.
+
+[NOTE]
+====
+It is always legal to over-fence, e.g., by fencing only based on a
+subset of the bits in _rs1_ and/or _rs2_, and/or by simply treating all
+SFENCE.VMA instructions as having _rs1_=`x0` and/or _rs2_=`x0`. For
+example, simpler implementations can ignore the virtual address in _rs1_
+and the ASID value in _rs2_ and always perform a global fence. The
+choice not to raise an exception when an invalid virtual address is held
+in _rs1_ facilitates this type of simplification.
+====
+
+When __rs2__{ne}``x0``, bits SXLEN-1:ASIDMAX of the value held
+in _rs2_ are reserved for future standard use. Until their use is
+defined by a standard extension, they should be zeroed by software and
+ignored by current implementations. Furthermore, if
+ASIDLEN<ASIDMAX, the implementation shall ignore bits
+ASIDMAX-1:ASIDLEN of the value held in _rs2_.
+
+An implicit read of the memory-management data structures may return any
+translation for an address that was valid at any time since the most
+recent SFENCE.VMA that subsumes that address. The ordering implied by
+SFENCE.VMA does not place implicit reads and writes to the
+memory-management data structures into the global memory order in a way
+that interacts cleanly with the standard RVWMO ordering rules. In
+particular, even though an SFENCE.VMA orders prior explicit accesses
+before subsequent implicit accesses, and those implicit accesses are
+ordered before their associated explicit accesses, SFENCE.VMA does not
+necessarily place prior explicit accesses before subsequent explicit
+accesses in the global memory order. These implicit loads also need not
+otherwise obey normal program order semantics with respect to prior
+loads or stores to the same address.
+
+[NOTE]
+====
+A consequence of this specification is that an implementation may use
+any translation for an address that was valid at any time since the most
+recent SFENCE.VMA that subsumes that address.
+
+For example, if a leaf PTE is modified and the corresponding virtual address
+is accessed without a subsuming SFENCE.VMA having been executed in between,
+then either the new translation or any older translation since the last
+subsuming SFENCE.VMA was executed will be used.
+It is unpredictable which translation will be chosen from that set, and
+subsequent accesses to the same virtual address might use different
+translations from that set.
+But the behavior of such accesses is otherwise well defined.
+
+This property applies even if the virtual-address width for that translation
+differs from the width currently specified by `satp`.MODE.
+For a given virtual address and ASID, any translation since the last subsuming
+SFENCE.VMA might be used, even if that translation used a virtual address of a
+different width.
+Similarly, for a given virtual address, any global translation since the
+last subsuming SFENCE.VMA might be used, regardless of both ASID and
+virtual-address width.
+
+In a conventional TLB design, it is possible for multiple entries to
+match a single address if, for example, a page is upgraded to a
+superpage without first clearing the original non-leaf PTE’s valid bit
+and executing an SFENCE.VMA with __rs1__=`x0`. In this case, a similar
+remark applies: it is unpredictable whether the old non-leaf PTE or the
+new leaf PTE is used, but the behavior is otherwise well defined.
+
+Another consequence of this specification is that it is generally unsafe
+to update a PTE using a set of stores of a width less than the width of
+the PTE, as it is legal for the implementation to read the PTE at any
+time, including when only some of the partial stores have taken effect.
+
+***
+
+This specification permits the caching of PTEs whose V (Valid) bit is
+clear. Operating systems must be written to cope with this possibility,
+but implementers are reminded that eagerly caching invalid PTEs will
+reduce performance by causing additional page faults.
+====
+
+Implementations must only perform implicit reads of the translation data
+structures pointed to by the current contents of the `satp` register or
+a subsequent valid (V=1) translation data structure entry, and must only
+raise exceptions for implicit accesses that are generated as a result of
+instruction execution, not those that are performed speculatively.
+
+Changes to the `sstatus` fields SUM and MXR take effect immediately,
+without the need to execute an SFENCE.VMA instruction. Changing
+`satp`.MODE from Bare to other modes and vice versa also takes effect
+immediately, without the need to execute an SFENCE.VMA instruction.
+Likewise, changes to `satp`.ASID take effect immediately.
+
+[NOTE]
+====
+The following common situations typically require executing an
+SFENCE.VMA instruction:
+
+* When software recycles an ASID (i.e., reassociates it with a different
+page table), it should _first_ change `satp` to point to the new page
+table using the recycled ASID, _then_ execute SFENCE.VMA with __rs1__=`x0`
+and _rs2_ set to the recycled ASID. Alternatively, software can execute
+the same SFENCE.VMA instruction while a different ASID is loaded into
+`satp`, provided the next time `satp` is loaded with the recycled ASID,
+it is simultaneously loaded with the new page table.
+* If the implementation does not provide ASIDs, or software chooses to
+always use ASID 0, then after every `satp` write, software should
+execute SFENCE.VMA with __rs1__=`x0`. In the common case that no global
+translations have been modified, _rs2_ should be set to a register other
+than `x0` but which contains the value zero, so that global translations
+are not flushed.
+* If software modifies a non-leaf PTE, it should execute SFENCE.VMA with
+__rs1__=`x0`. If any PTE along the traversal path had its G bit set, _rs2_
+must be `x0`; otherwise, _rs2_ should be set to the ASID for which the
+translation is being modified.
+* If software modifies a leaf PTE, it should execute SFENCE.VMA with
+_rs1_ set to a virtual address within the page. If any PTE along the
+traversal path had its G bit set, _rs2_ must be `x0`; otherwise, _rs2_
+should be set to the ASID for which the translation is being modified.
+* For the special cases of increasing the permissions on a leaf PTE and
+changing an invalid PTE to a valid leaf, software may choose to execute
+the SFENCE.VMA lazily. After modifying the PTE but before executing
+SFENCE.VMA, either the new or old permissions will be used. In the
+latter case, a page-fault exception might occur, at which point software
+should execute SFENCE.VMA in accordance with the previous bullet point.
+====
+
+If a hart employs an address-translation cache, that cache must appear
+to be private to that hart. In particular, the meaning of an ASID is
+local to a hart; software may choose to use the same ASID to refer to
+different address spaces on different harts.
+
+[NOTE]
+====
+A future extension could redefine ASIDs to be global across the SEE,
+enabling such options as shared translation caches and hardware support
+for broadcast TLB shootdown. However, as OSes have evolved to
+significantly reduce the scope of TLB shootdowns using novel
+ASID-management techniques, we expect the local-ASID scheme to remain
+attractive for its simplicity and possibly better scalability.
+====
+
+For implementations that make `satp`.MODE read-only zero (always Bare),
+attempts to execute an SFENCE.VMA instruction might raise an
+illegal-instruction exception.
+
+[[sv32]]
+=== Sv32: Page-Based 32-bit Virtual-Memory Systems
+
+When Sv32 is written to the MODE field in the `satp` register (see
+<<satp>>), the supervisor operates in a 32-bit paged
+virtual-memory system. In this mode, supervisor and user virtual
+addresses are translated into supervisor physical addresses by
+traversing a radix-tree page table. Sv32 is supported when SXLEN=32 and
+is designed to include mechanisms sufficient for supporting modern
+Unix-based operating systems.
+
+[NOTE]
+====
+The initial RISC-V paged virtual-memory architectures have been designed
+as straightforward implementations to support existing operating
+systems. We have architected page table layouts to support a hardware
+page-table walker. Software TLB refills are a performance bottleneck on
+high-performance systems, and are especially troublesome with decoupled
+specialized coprocessors. An implementation can choose to implement
+software TLB refills using a machine-mode trap handler as an extension
+to M-mode.
+
+***
+
+Some ISAs architecturally expose _virtually indexed, physically tagged_
+caches, in that accesses to the same physical address via different
+virtual addresses might not be coherent unless the virtual addresses lie
+within the same cache set. Implicitly, this specification does not
+permit such behavior to be architecturally exposed.
+====
+
+[[translation]]
+==== Addressing and Memory Protection
+
+Sv32 implementations support a 32-bit virtual address space, divided
+into pages. An Sv32 virtual address is partitioned into a virtual page
+number (VPN) and page offset, as shown in <<sv32va>>.
+When Sv32 virtual memory mode is selected in the MODE field of the
+`satp` register, supervisor virtual addresses are translated into
+supervisor physical addresses via a two-level page table. The 20-bit VPN
+is translated into a 22-bit physical page number (PPN), while the 12-bit
+page offset is untranslated. The resulting supervisor-level physical
+addresses are then checked using any physical memory protection
+structures (<<pmp>>), before being directly
+converted to machine-level physical addresses. If necessary,
+supervisor-level physical addresses are zero-extended to the number of
+physical address bits found in the implementation.
+
+[NOTE]
+====
+For example, consider an RV32 system supporting 34 bits of physical
+address. When the value of `satp`.MODE is Sv32, a 34-bit physical
+address is produced directly, and therefore no zero extension is needed.
+When the value of `satp`.MODE is Bare, the 32-bit virtual address is
+translated (unmodified) into a 32-bit physical address, and then that
+physical address is zero-extended into a 34-bit machine-level physical
+address.
+====
+[[sv32va]]
+.Sv32 virtual address.
+include::images/bytefield/sv32va.edn[]
+
+Sv32 page tables consist of 2^10^ page-table entries
+(PTEs), each of four bytes. A page table is exactly the size of a page
+and must always be aligned to a page boundary. The physical page number
+of the root page table is stored in the `satp` register.
+
+[[sv32pa]]
+.SV32 physical address.
+include::images/bytefield/sv32pa.edn[]
+
+[[sv32pte]]
+.Sv32 page table entry.
+include::images/bytefield/sv32pte.edn[]
+
+The PTE format for Sv32 is shown in <<sv32pte>>.
+The V bit indicates whether the PTE is valid; if it is 0, all other bits
+in the PTE are don’t-cares and may be used freely by software. The
+permission bits, R, W, and X, indicate whether the page is readable,
+writable, and executable, respectively. When all three are zero, the PTE
+is a pointer to the next level of the page table; otherwise, it is a
+leaf PTE. Writable pages must also be marked readable; the contrary
+combinations are reserved for future use. <<pteperm>>
+summarizes the encoding of the permission bits.
+
+[[pteperm]]
+.Encoding of PTE R/W/X fields.
+[%autowidth,float="center",align="center",cols="^,^,^,<",options="header"]
+|===
+|X |W |R |Meaning
+|0 +
+0 +
+0 +
+0 +
+1 +
+1 +
+1 +
+1
+|0 +
+0 +
+1 +
+1 +
+0 +
+0 +
+1 +
+1
+|0 +
+1 +
+0 +
+1 +
+0 +
+1 +
+0 +
+1
+|Pointer to next level of page table. +
+Read-only page. +
+_Reserved for future use._ +
+Read-write page. +
+Execute-only page. +
+Read-execute page. +
+_Reserved for future use._ +
+Read-write-execute page.
+|===
+
+Attempting to fetch an instruction from a page that does not have
+execute permissions raises a fetch page-fault exception. Attempting to
+execute a load or load-reserved instruction whose effective address lies
+within a page without read permissions raises a load page-fault
+exception. Attempting to execute a store, store-conditional, or AMO
+instruction whose effective address lies within a page without write
+permissions raises a store page-fault exception.
+
+[NOTE]
+====
+AMOs never raise load page-fault exceptions. Since any unreadable page
+is also unwritable, attempting to perform an AMO on an unreadable page
+always raises a store page-fault exception.
+====
+
+The U bit indicates whether the page is accessible to user mode. U-mode
+software may only access the page when U=1. If the SUM bit in the
+`sstatus` register is set, supervisor mode software may also access
+pages with U=1. However, supervisor code normally operates with the SUM
+bit clear, in which case, supervisor code will fault on accesses to
+user-mode pages. Irrespective of SUM, the supervisor may not execute
+code on pages with U=1.
+
+[NOTE]
+====
+An alternative PTE format would support different permissions for
+supervisor and user. We omitted this feature because it would be largely
+redundant with the SUM mechanism (see <<sum>>) and would require more encoding space in the PTE.
+====
+
+The G bit designates a _global_ mapping. Global mappings are those that
+exist in all address spaces. For non-leaf PTEs, the global setting
+implies that all mappings in the subsequent levels of the page table are
+global. Note that failing to mark a global mapping as global merely
+reduces performance, whereas marking a non-global mapping as global is a
+software bug that, after switching to an address space with a different
+non-global mapping for that address range, can unpredictably result in
+either mapping being used.
+
+[NOTE]
+====
+Global mappings need not be stored redundantly in address-translation
+caches for multiple ASIDs. Additionally, they need not be flushed from
+local address-translation caches when an SFENCE.VMA instruction is
+executed with __rs2__{ne}``x0``.
+====
+
+The RSW field is reserved for use by supervisor software; the
+implementation shall ignore this field.
+
+Each leaf PTE contains an accessed (A) and dirty (D) bit. The A bit
+indicates the virtual page has been read, written, or fetched from since
+the last time the A bit was cleared. The D bit indicates the virtual
+page has been written since the last time the D bit was cleared.
+
+Two schemes to manage the A and D bits are defined:
+
+* The _Svade_ extension: when a virtual page is accessed and the A bit is
+ clear, or is written and the D bit is clear, a page-fault exception is
+ raised.
+
+* When the Svade extension is not implemented, the following scheme applies. +
+ +
+ When a virtual page is accessed and the A bit is clear, the PTE is
+ updated to set the A bit. When the virtual page is written and the D
+ bit is clear, the PTE is updated to set the D bit. When G-stage address
+ translation is in use and is not Bare, the G-stage virtual pages may be
+ accessed or written by implicit accesses to VS-level memory management
+ data structures, such as page tables. +
+ +
+ When two-stage address translation is in use, an explicit access may
+ cause both VS-stage and G-stage PTEs to be updated. The following rules
+ apply to all PTE updates caused by an explicit or an implicit memory
+ accesses. +
+ +
+ The PTE update must be atomic with respect to other accesses to the
+ PTE, and must atomically perform all page-table walk checks for that leaf
+ PTE as part of, and before, conditionally updating the PTE value.
+ Updates of the A bit may be performed as a result of speculation, even
+ if the associated memory access ultimately is not performed
+ architecturally. However, updates to the D bit, resulting from an
+ explicit store, must be exact (i.e., non-speculative), and observed in
+ program order by the local hart. When two-stage address translation is
+ active, updates to the D bit in G-stage PTEs may be performed by an
+ implicit access to a VS-stage PTE, if the G-stage PTE provides write
+ permission, before any speculative access to the VS-stage PTE. +
+ +
+ The PTE update must appear in the global memory order before the
+ memory access that caused the PTE update and before any subsequent
+ explicit memory access to that virtual page by the local hart. The
+ ordering on loads and stores provided by FENCE instructions and the
+ acquire/release bits on atomic instructions also orders the PTE updates
+ associated with those loads and stores as observed by remote harts. +
+ +
+ The PTE update is not required to be atomic with respect to the memory
+ access that caused the update and a trap may occur between the PTE
+ update and the memory access that caused the PTE update. If a trap
+ occurs then the A and/or D bit may be updated but the memory access
+ that caused the PTE update might not occur. The hart must not perform
+ the memory access that caused the PTE update before the PTE update is
+ globally visible. +
+ +
+ The page tables must be located in memory with hardware page-table
+ write access and _RsrvEventual_ PMA.
+
+All harts in a system must employ the same PTE-update scheme as each
+other.
+
+[NOTE]
+====
+The PTE updates due to memory accesses ordered-after a FENCE are not
+themselves ordered by the FENCE.
+
+Simpler implementations may order the Page Table Entry (PTE) update
+to precede all subsequent explicit memory accesses, as opposed to
+ensuring that the PTE update is precisely sequenced before subsequent
+explicit memory accesses to the associated virtual page.
+
+Prior versions of this specification required PTE A bit updates to be
+exact, but allowing the A bit to be updated as a result of speculation
+simplifies the implementation of address translation prefetchers. System
+software typically uses the A bit as a page replacement policy hint, but
+does not require exactness for functional correctness. On the other
+hand, D bit updates are still required to be exact and performed in
+program order, as the D bit affects the functional correctness of page
+eviction.
+
+Implementations are of course still permitted to perform both A and D
+bit updates only in an exact manner.
+
+In both cases, requiring atomicity ensures that the PTE update will not
+be interrupted by other intervening writes to the page table, as such
+interruptions could lead to A/D bits being set on PTEs that have been
+reused for other purposes, on memory that has been reclaimed for other
+purposes, and so on. Simple implementations may instead generate
+page-fault exceptions.
+
+The A and D bits are never cleared by the implementation. If the
+supervisor software does not rely on accessed and/or dirty bits, e.g. if
+it does not swap memory pages to secondary storage or if the pages are
+being used to map I/O space, it should always set them to 1 in the PTE
+to improve performance.
+====
+
+Any level of PTE may be a leaf PTE, so in addition to 4 KiB pages, Sv32
+supports 4 MiB _megapages_. A megapage must be virtually and physically
+aligned to a 4 MiB boundary; a page-fault exception is raised if the
+physical address is insufficiently aligned.
+
+For non-leaf PTEs, the D, A, and U bits are reserved for future standard
+use. Until their use is defined by a standard extension, they must be
+cleared by software for forward compatibility.
+
+For implementations with both page-based virtual memory and the "A"
+standard extension, the LR/SC reservation set must lie completely within
+a single base physical page (i.e., a naturally aligned 4 KiB physical-memory
+region).
+
+On some implementations, misaligned loads, stores, and instruction
+fetches may also be decomposed into multiple accesses, some of which may
+succeed before a page-fault exception occurs. In particular, a
+portion of a misaligned store that passes the exception check may become
+visible, even if another portion fails the exception check. The same behavior
+may manifest for stores wider than XLEN bits (e.g., the FSD instruction
+in RV32D), even when the store address is naturally aligned.
+
+
+[[sv32algorithm]]
+==== Virtual Address Translation Process
+
+A virtual address _va_ is translated into a physical address _pa_ as follows:
+
+. Let _a_ be ``satp``.__ppn__×PAGESIZE, and let __i__=LEVELS-1. (For Sv32, PAGESIZE=2^12^ and LEVELS=2.) The `satp` register must be
+_active_, i.e., the effective privilege mode must be S-mode or U-mode.
+
+. Let _pte_ be the value of the PTE at address __a__+__va__.__vpn__[__i__]×PTESIZE. (For Sv32, PTESIZE=4.) If accessing _pte_ violates a PMA or PMP check, raise an access-fault exception corresponding to the original access type.
+
+. If _pte_._v_=0, or if _pte_._r_=0 and _pte_._w_=1, or if any bits or encodings that are reserved for future standard use are set within _pte_, stop and raise a page-fault exception corresponding to the original access type.
+
+. Otherwise, the PTE is valid. If __pte__.__r__=1 or __pte__.__x__=1, go to step 5. Otherwise, this PTE is a pointer to the next level of the page table. Let __i=i__-1. If __i__<0, stop and raise a page-fault exception corresponding to the original access type. Otherwise, let
+__a__=__pte__.__ppn__×PAGESIZE and go to step 2.
+
+. A leaf PTE has been reached. If _i>0_ and _pte_._ppn_[__i__-1:0] ≠ 0, this is a misaligned superpage; stop and raise a page-fault exception corresponding to the original access type.
+
+. Determine if the requested memory access is allowed by the _pte_._u_ bit, given the current privilege mode and the value of the SUM and MXR fields of the *mstatus* register. If not, stop and raise a page-fault exception corresponding to the original access type.
+
+. Determine if the requested memory access is allowed by the _pte_._r_, _pte_._w_, and _pte_._x_ bits, given the Shadow Stack Memory Protection rules. If not, stop and raise an access-fault exception.
+
+. Determine if the requested memory access is allowed by the _pte_._r_, _pte_._w_, and _pte_._x_ bits. If not, stop and raise a page-fault exception corresponding to the original access type.
+
+. If _pte_._a_=0, or if the original memory access is a store and _pte_._d_=0:
+
+* If the Svade extension is implemented, stop and raise a page-fault exception corresponding to the original access type.
+* If a store to the PTE at address __a__+__va.vpn__[__i__]×PTESIZE would violate a PMA or PMP check,
+raise an access-fault exception corresponding to the original access
+type.
+* Perform the following steps atomically:
+** Compare _pte_ to the value of the PTE at address __a__+__va.vpn__[__i__]×PTESIZE.
+** If the values match, set _pte_._a_ to 1 and, if the
+original memory access is a store, also set _pte_._d_ to 1. Then store _pte_ to the PTE at address __a__+__va.vpn__[__i__]×PTESIZE.
+** If the comparison fails, return to step 2.
+
+. The translation is successful. The translated physical address is
+given as follows:
+* _pa.pgoff_ = _va.pgoff_.
+* If _i_>0, then this is a superpage translation and __pa.ppn__[__i__-1:0] = __va.vpn__[__i__-1:0].
+* _pa.ppn_[LEVELS-1:__i__] = _pte_._ppn_[LEVELS-1:__i__].
+
+All implicit accesses to the address-translation data structures in this
+algorithm are performed using width PTESIZE.
+
+[NOTE]
+====
+This implies, for example, that an Sv48 implementation may not use two
+separate 4{nbsp}B reads to non-atomically access a single 8{nbsp}B PTE, and that A/D
+bit updates performed by the implementation are treated as atomically
+updating the entire PTE, rather than just the A and/or D bit alone (even
+though the PTE value does not otherwise change).
+====
+
+The results of implicit address-translation reads in step 2 may be held
+in a read-only, incoherent _address-translation cache_ but not shared
+with other harts. The address-translation cache may hold an arbitrary
+number of entries, including an arbitrary number of entries for the same
+address and ASID. Entries in the address-translation cache may then
+satisfy subsequent step 2 reads if the ASID associated with the entry
+matches the ASID loaded in step 0 or if the entry is associated with a
+_global_ mapping. To ensure that implicit reads observe writes to the
+same memory locations, an SFENCE.VMA instruction must be executed after
+the writes to flush the relevant cached translations.
+
+The address-translation cache cannot be used in step 9; accessed and
+dirty bits may only be updated in memory directly.
+[NOTE]
+====
+It is permitted for multiple address-translation cache entries to
+co-exist for the same address. This represents the fact that in a
+conventional TLB hierarchy, it is possible for multiple entries to match
+a single address if, for example, a page is upgraded to a superpage
+without first clearing the original non-leaf PTE’s valid bit and
+executing an SFENCE.VMA with _rs1_=`x0`, or if multiple TLBs exist in
+parallel at a given level of the hierarchy. In this case, just as if an
+SFENCE.VMA is not executed between a write to the memory-management
+tables and subsequent implicit read of the same address: it is
+unpredictable whether the old non-leaf PTE or the new leaf PTE is used,
+but the behavior is otherwise well defined.
+====
+
+Implementations may also execute the address-translation algorithm
+speculatively at any time, for any virtual address, as long as `satp` is
+active (as defined in <<satp>>). Such speculative
+executions have the effect of pre-populating the address-translation
+cache.
+
+Speculative executions of the address-translation algorithm behave as
+non-speculative executions of the algorithm do, except that they must
+not set the dirty bit for a PTE, they must not trigger an exception, and
+they must not create address-translation cache entries if those entries
+would have been invalidated by any SFENCE.VMA instruction executed by
+the hart since the speculative execution of the algorithm began.
+
+[NOTE]
+====
+For instance, it is illegal for both non-speculative and speculative
+executions of the translation algorithm to begin, read the level 2 page
+table, pause while the hart executes an SFENCE.VMA with
+_rs1_=_rs2_=`x0`, then resume using the now-stale level 2 PTE, as
+subsequent implicit reads could populate the address-translation cache
+with stale PTEs.
+
+In many implementations, an SFENCE.VMA instruction with _rs1_=`x0` will
+therefore either terminate all previously-launched speculative
+executions of the address-translation algorithm (for the specified ASID,
+if applicable), or simply wait for them to complete (in which case any
+address-translation cache entries created will be invalidated by the
+SFENCE.VMA as appropriate). Likewise, an SFENCE.VMA instruction with
+__rs1__≠``x0`` generally must either ensure that
+previously-launched speculative executions of the address-translation
+algorithm (for the specified ASID, if applicable) are prevented from
+creating new address-translation cache entries mapping leaf PTEs, or
+wait for them to complete.
+
+A consequence of implementations being permitted to read the translation
+data structures arbitrarily early and speculatively is that at any time,
+all page table entries reachable by executing the algorithm may be
+loaded into the address-translation cache.
+
+Although it would be uncommon to place page tables in non-idempotent
+memory, there is no explicit prohibition against doing so. Since the
+algorithm may only touch page tables reachable from the root page table
+indicated in `satp`, the range of addresses that an implementation's
+page-table walker will touch is fully under supervisor control.
+
+***
+
+The algorithm does not admit the possibility of ignoring high-order PPN
+bits for implementations with narrower physical addresses.
+====
+
+[[sv39]]
+=== Sv39: Page-Based 39-bit Virtual-Memory System
+
+This section describes a simple paged virtual-memory system for
+SXLEN=64, which supports 39-bit virtual address spaces. The design of
+Sv39 follows the overall scheme of Sv32, and this section details only
+the differences between the schemes.
+
+[NOTE]
+====
+We specified multiple virtual memory systems for RV64 to relieve the
+tension between providing a large address space and minimizing
+address-translation cost. For many systems, 39 bits of virtual-address space is
+ample, and so Sv39 suffices. Sv48 increases the virtual address space to
+48 bits, but increases the physical memory capacity dedicated to page tables,
+the latency of page-table traversals, and the size of hardware
+structures that store virtual addresses. Sv57 increases the virtual
+address space, page table capacity requirement, and translation latency
+even further.
+====
+
+[[addressing-and-memory-protection]]
+==== Addressing and Memory Protection
+
+Sv39 implementations support a 39-bit virtual address space, divided
+into pages. An Sv39 address is partitioned as shown in
+<<sv39va>>. Instruction fetch addresses and load and
+store effective addresses, which are 64 bits, must have bits 63–39 all
+equal to bit 38, or else a page-fault exception will occur. The 27-bit
+VPN is translated into a 44-bit PPN via a three-level page table, while
+the 12-bit page offset is untranslated.
+
+[NOTE]
+====
+When mapping between narrower and wider addresses, RISC-V zero-extends a
+narrower physical address to a wider size. The mapping between 64-bit
+virtual addresses and the 39-bit usable address space of Sv39 is not
+based on zero extension but instead follows an entrenched convention
+that allows an OS to use one or a few of the most-significant bits of a
+full-size (64-bit) virtual address to quickly distinguish user and
+supervisor address regions.
+====
+
+[[sv39va]]
+.Sv39 virtual address.
+include::images/bytefield/sv39va.edn[]
+
+[[sv39pa]]
+.Sv39 physical address.
+include::images/bytefield/sv39pa.edn[]
+
+[[sv39pte]]
+.Sv39 page table entry.
+include::images/bytefield/sv39pte.edn[]
+
+Sv39 page tables contain 2^9^ page table entries (PTEs),
+eight bytes each. A page table is exactly the size of a page and must
+always be aligned to a page boundary. The physical page number of the
+root page table is stored in the `satp` register's PPN field.
+
+The PTE format for Sv39 is shown in <<sv39pte>>.
+Bits 9-0 have the same meaning as for Sv32. Bit 63 is reserved for use
+by the Svnapot extension in <<svnapot>>. If Svnapot is not
+implemented, bit 63 remains reserved and must be zeroed by software for
+forward compatibility, or else a page-fault exception is raised. Bits
+62-61 are reserved for use by the Svpbmt extension in
+<<svpbmt>>. If Svpbmt is not implemented, bits 62-61 remain
+reserved and must be zeroed by software for forward compatibility, or
+else a page-fault exception is raised. Bits 60-54 are reserved for
+future standard use and, until their use is defined by some standard
+extension, must be zeroed by software for forward compatibility. If any
+of these bits are set, a page-fault exception is raised.
+
+[NOTE]
+====
+We reserved several PTE bits for a possible extension that improves
+support for sparse address spaces by allowing page-table levels to be
+skipped, reducing memory usage and TLB refill latency. These reserved
+bits may also be used to facilitate research experimentation. The cost
+is reducing the physical address space, but is presently ample. When it
+no longer suffices, the reserved bits that remain unallocated could be
+used to expand the physical address space.
+====
+
+Any level of PTE may be a leaf PTE, so in addition to 4 KiB pages, Sv39
+supports 2 MiB _megapages_ and 1 GiB _gigapages_, each of which must be virtually and physically aligned to a boundary equal to its size. A page-fault exception is raised if the physical address is insufficiently aligned.
+
+The algorithm for virtual-to-physical address translation is the same as
+in <<sv32algorithm>>, except LEVELS equals 3 and PTESIZE equals 8.
+
+[[sv48]]
+=== Sv48: Page-Based 48-bit Virtual-Memory System
+
+This section describes a simple paged virtual-memory system for
+SXLEN=64, which supports 48-bit virtual address spaces. Sv48 is intended
+for systems for which a 39-bit virtual address space is insufficient. It
+closely follows the design of Sv39, simply adding an additional level of
+page table, and so this chapter only details the differences between the
+two schemes.
+
+Implementations that support Sv48 must also support Sv39.
+
+[NOTE]
+====
+Systems that support Sv48 can also support Sv39 at essentially no cost,
+and so should do so to maintain compatibility with supervisor software
+that assumes Sv39.
+====
+
+[[addressing-and-memory-protection-1]]
+==== Addressing and Memory Protection
+
+Sv48 implementations support a 48-bit virtual address space, divided
+into pages. An Sv48 address is partitioned as shown in
+<<sv48va>>. Instruction fetch addresses and load and
+store effective addresses, which are 64 bits, must have bits 63–48 all
+equal to bit 47, or else a page-fault exception will occur. The 36-bit
+VPN is translated into a 44-bit PPN via a four-level page table, while
+the 12-bit page offset is untranslated.
+
+[[sv48va]]
+.Sv48 virtual address.
+include::images/bytefield/sv48va.edn[]
+
+[[sv48pa]]
+.Sv48 physical address.
+include::images/bytefield/sv48pa.edn[]
+
+[[sv48pte]]
+.Sv48 page table entry.
+include::images/bytefield/sv48pte.edn[]
+
+The PTE format for Sv48 is shown in <<sv48pte>>.
+Bits 63-54 and 9-0 have the same meaning as for Sv39. Any level of PTE
+may be a leaf PTE, so in addition to 4 KiB pages, Sv48 supports 2 MiB _megapages_,
+1 GiB _gigapages_, and 512 GiB _terapages_, each of which must be virtually and
+physically aligned to a boundary equal to its size. A page-fault
+exception is raised if the physical address is insufficiently aligned.
+
+The algorithm for virtual-to-physical address translation is the same as
+in <<sv32algorithm>>, except LEVELS equals 4 and
+PTESIZE equals 8.
+
+[[sv57]]
+=== Sv57: Page-Based 57-bit Virtual-Memory System
+
+This section describes a simple paged virtual-memory system designed for
+RV64 systems, which supports 57-bit virtual address spaces. Sv57 is
+intended for systems for which a 48-bit virtual address space is
+insufficient. It closely follows the design of Sv48, simply adding an
+additional level of page table, and so this chapter only details the
+differences between the two schemes.
+
+Implementations that support Sv57 must also support Sv48.
+
+[NOTE]
+====
+Systems that support Sv57 can also support Sv48 at essentially no cost,
+and so should do so to maintain compatibility with supervisor software
+that assumes Sv48.
+====
+
+[[addressing-and-memory-protection-2]]
+==== Addressing and Memory Protection
+
+Sv57 implementations support a 57-bit virtual address space, divided
+into pages. An Sv57 address is partitioned as shown in
+<<sv57va>>. Instruction fetch addresses and load and
+store effective addresses, which are 64 bits, must have bits 63–57 all
+equal to bit 56, or else a page-fault exception will occur. The 45-bit
+VPN is translated into a 44-bit PPN via a five-level page table, while
+the 12-bit page offset is untranslated.
+
+[[sv57va]]
+.Sv57 virtual address.
+include::images/bytefield/sv57va.edn[]
+
+[[sv57pa]]
+.Sv57 physical address.
+include::images/bytefield/sv57pa.edn[]
+
+[[sv57pte]]
+.Sv57 page table entry.
+include::images/bytefield/sv57pte.edn[]
+
+The PTE format for Sv57 is shown in <<sv57pte>>.
+Bits 63–54 and 9–0 have the same meaning as for Sv39. Any level of PTE
+may be a leaf PTE, so in addition to 4 KiB pages, Sv57 supports 2 MiB _megapages_,
+1 GiB _gigapages_, 512 GiB _terapages_, and 256 TiB _petapages_, each of which must be
+virtually and physically aligned to a boundary equal to its size. A
+page-fault exception is raised if the physical address is insufficiently
+aligned.
+
+The algorithm for virtual-to-physical address translation is the same as
+in <<sv32algorithm>>, except LEVELS equals 5 and
+PTESIZE equals 8.
+
+[[svnapot]]
+== "Svnapot" Extension for NAPOT Translation Contiguity, Version 1.0
+
+In Sv39, Sv48, and Sv57, when a PTE has N=1, the PTE represents a
+translation that is part of a range of contiguous virtual-to-physical
+translations with the same values for PTE bits 5–0. Such ranges must be
+of a naturally aligned power-of-2 (NAPOT) granularity larger than the
+base page size.
+
+The Svnapot extension depends on the Sv39 extension.
+
+[[ptenapot]]
+.Page table entry encodings when __pte__.N=1
+[%autowidth,float="center",align="center",cols="^,^,<,^",options="header"]
+|===
+|i |_pte_._ppn_[_i_] |Description |_pte_.__napot_bits__
+|0 +
+0 +
+0 +
+0 +
+0 +
+&#8805;1
+|`x xxxx xxx1` +
+`x xxxx xx1x` +
+`x xxxx x1xx` +
+`x xxxx 1000` +
+`x xxxx 0xxx` +
+`x xxxx xxxx`
+|_Reserved_ +
+_Reserved_ +
+_Reserved_ +
+64 KiB contiguous region +
+_Reserved_ +
+_Reserved_
+| - +
+- +
+- +
+4 +
+- +
+-
+|===
+
+NAPOT PTEs behave identically to non-NAPOT PTEs within the
+address-translation algorithm in <<sv32algorithm>>,
+except that:
+
+* If the encoding in _pte_ is valid according to
+<<ptenapot>>, then instead of returning the original
+value of _pte_, implicit reads of a NAPOT PTE return a copy
+of _pte_ in which __pte__.__ppn__[__i__][__pte__.__napot_bits__-1:0] is replaced by
+__vpn__[__i__][__pte__.__napot_bits__-1:0]. If the encoding in _pte_ is reserved according to
+<<ptenapot>>, then a page-fault exception must be raised.
+* Implicit reads of NAPOT page table entries may create
+address-translation cache entries mapping
+_a_ + _j_×PTESIZE to a copy of _pte_ in which _pte_._ppn_[_i_][_pte_.__napot_bits__-1:0]
+is replaced by _vpn[i][pte.napot_bits_-1:0], for any or all _j_ such that
+__j__ >> __napot_bits__ = __vpn__[__i__] >> __napot_bits__, all for the address space identified in _satp_ as loaded by step 1.
+
+[NOTE]
+====
+The motivation for a NAPOT PTE is that it can be cached in a TLB as one
+or more entries representing the contiguous region as if it were a
+single (large) page covered by a single translation. This compaction can
+help relieve TLB pressure in some scenarios. The encoding is designed to
+fit within the pre-existing Sv39, Sv48, and Sv57 PTE formats so as not
+to disrupt existing implementations or designs that choose not to
+implement the scheme. It is also designed so as not to complicate the
+definition of the address-translation algorithm.
+
+The address translation cache abstraction captures the behavior that
+would result from the creation of a single TLB entry covering the entire
+NAPOT region. It is also designed to be consistent with implementations
+that support NAPOT PTEs by splitting the NAPOT region into TLB entries
+covering any smaller power-of-two region sizes. For example, a 64 KiB
+NAPOT PTE might trigger the creation of 16 standard 4 KiB TLB entries,
+all with contents generated from the NAPOT PTE (even if the PTEs for the
+other 4 KiB regions have different contents).
+
+In typical usage scenarios, NAPOT PTEs in the same region will have the
+same attributes, same PPNs, and same values for bits 5-0. RSW remains
+reserved for supervisor software control. It is the responsibility of
+the OS and/or hypervisor to configure the page tables in such a way that
+there are no inconsistencies between NAPOT PTEs and other NAPOT or
+non-NAPOT PTEs that overlap the same address range. If an update needs
+to be made, the OS generally should first mark all of the PTEs invalid,
+then issue SFENCE.VMA instruction(s) covering all 4 KiB regions within
+the range (either via a single SFENCE.VMA with _rs1_=`x0`, or with
+multiple SFENCE.VMA instructions with _rs1_≠`x0`), then update the PTE(s), as described in <<sfence.vma>>, unless any inconsistencies are known to be benign. If any inconsistencies do exist, then the effect is the same as when SFENCE.VMA
+is used incorrectly: one of the translations will be chosen, but the
+choice is unpredictable.
+
+If an implementation chooses to use a NAPOT PTE (or cached version
+thereof), it might not consult the PTE directly specified by the
+algorithm in <<sv32algorithm>> at all. Therefore, the D
+and A bits may not be identical across all mappings of the same address
+range even in typical use cases The operating system must query all
+NAPOT aliases of a page to determine whether that page has been accessed
+and/or is dirty. If the OS manually sets the A and/or D bits for a page,
+it is recommended that the OS also set the A and/or D bits for other
+NAPOT aliases as appropriate in order to avoid unnecessary traps.
+
+Just as with normal PTEs, TLBs are permitted to cache NAPOT PTEs whose V
+(Valid) bit is clear.
+
+Depending on need, the NAPOT scheme may be extended to other
+intermediate page sizes and/or to other levels of the page table in the
+future. The encoding is designed to accommodate other NAPOT sizes should
+that need arise. For example:
+
+__
+
+[%autowidth,float="center",align="center",cols="^,^,<,^",options="header"]
+|===
+|i |_pte_._ppn_[_i_] |Description |_pte_.__napot_bits__
+|0 +
+0 +
+0 +
+0 +
+0 +
+... +
+1 +
+1 +
+...
+|`x xxxx xxx1` +
+`x xxxx xx10` +
+`x xxxx x100` +
+`x xxxx 1000` +
+`x xxx1 0000` +
+... +
+`x xxxx xxx1` +
+`x xxxx xx10` +
+...
+|8 KiB contiguous region +
+16 KiB contiguous region +
+32 KiB contiguous region +
+64 KiB contiguous region +
+128 KiB contiguous region +
+... +
+4 MiB contiguous region +
+8 MiB contiguous region +
+...
+| 1 +
+2 +
+3 +
+4 +
+5 +
+... +
+1 +
+2 +
+...
+|===
+
+In such a case, an implementation may or may not support all options.
+The discoverability mechanism for this extension would be extended to
+allow system software to determine which sizes are supported.
+
+Other sizes may remain deliberately excluded, so that PPN bits not being
+used to indicate a valid NAPOT region size (e.g., the least-significant
+bit of _pte_._ppn_[_i_]) may be repurposed for other uses in the
+future.
+
+However, in case finer-grained intermediate page size support proves not
+to be useful, we have chosen to standardize only 64 KiB support as a
+first step.
+====
+
+[[svpbmt]]
+== "Svpbmt" Extension for Page-Based Memory Types, Version 1.0
+
+In Sv39, Sv48, and Sv57, bits 62-61 of a leaf page table entry indicate
+the use of page-based memory types that override the PMA(s) for the
+associated memory pages. The encoding for the PBMT bits is captured in
+<<pbmt>>.
+
+The Svpbmt extension depends on the Sv39 extension.
+
+[[pbmt]]
+.Encodings for PBMT field in Sv39, Sv48, and Sv57 PTEs.
+[%autowidth,float="center",align="center",cols="^,^,<",options="header"]
+|===
+|Mode |Value |Requested Memory Attributes
+|PMA +
+NC +
+IO +
+-
+|0 +
+1 +
+2 +
+3
+|None +
+Non-cacheable, idempotent, weakly-ordered (RVWMO), main memory +
+Non-cacheable, non-idempotent, strongly-ordered (I/O ordering), I/O +
+_Reserved for future standard use_
+|===
+
+Implementations may override additional PMAs not explicitly listed in
+<<pbmt>>.
+For example, to be consistent with the characteristics of a typical I/O region,
+a misaligned memory access to a page with PBMT=IO might raise an exception,
+even if the underlying region were main memory and the same access would have
+succeeded for PBMT=PMA.
+
+[NOTE]
+====
+Future extensions may provide more and/or finer-grained control over
+which PMAs can be overridden.
+====
+
+For non-leaf PTEs, bits 62-61 are reserved for future standard use.
+Until their use is defined by a standard extension, they must be cleared
+by software for forward compatibility, or else a page-fault exception is
+raised.
+
+For leaf PTEs, setting bits 62-61 to the value 3 is reserved for future
+standard use. Until this value is defined by a standard extension, using
+this reserved value in a leaf PTE raises a page-fault exception.
+
+When PBMT settings override a main memory page into I/O or vice versa,
+memory accesses to such pages obey the memory ordering rules of the
+final effective attribute, as follows.
+
+If the underlying physical memory attribute for a page is I/O, and the
+page has PBMT=NC, then accesses to that page obey RVWMO. However,
+accesses to such pages are considered to be _both_ I/O and main memory
+accesses for the purposes of FENCE, _.aq_, and _.rl_.
+
+If the underlying physical memory attribute for a page is main memory,
+and the page has PBMT=IO, then accesses to that page obey strong channel
+0 I/O ordering rules.
+However, accesses to
+such pages are considered to be _both_ I/O and main memory accesses for
+the purposes of FENCE, _.aq_, and _.rl_.
+
+[NOTE]
+====
+A device driver written to rely on I/O strong ordering rules will not
+operate correctly if the address range is mapped with PBMT=NC. As such,
+this configuration is discouraged.
+
+It will often still be useful to map physical I/O regions using PBMT=NC
+so that write combining and speculative accesses can be performed. Such
+optimizations will likely improve performance when applied with adequate
+care.
+====
+
+When Svpbmt is used with non-zero PBMT encodings, it is possible for
+multiple virtual aliases of the same physical page to exist
+simultaneously with different memory attributes. It is also possible for
+a U-mode or S-mode mapping through a PTE with Svpbmt enabled to observe
+different memory attributes for a given region of physical memory than a
+concurrent access to the same page performed by M-mode or when
+MODE=Bare. In such cases, the behaviors dictated by the attributes
+(including coherence, which is otherwise unaffected) may be violated.
+
+Accessing the same location using different attributes that are both
+non-cacheable (e.g., NC and IO) does not cause loss of coherence, but
+might result in weaker memory ordering than the stricter attribute
+ordinarily guarantees. Executing a `fence iorw, iorw` instruction
+between such accesses suffices to prevent loss of memory ordering.
+
+Accessing the same location using different cacheability attributes may
+cause loss of coherence. Executing the following sequence between such
+accesses prevents both loss of coherence and loss of memory ordering:
+`fence iorw, iorw`, followed by `cbo.flush` to an address of that
+location, followed by a `fence iorw, iorw`.
+
+[NOTE]
+====
+It follows that, if the same location might later be referenced using
+the original attributes, then this sequence must be repeated beforehand.
+
+***
+
+In certain cases, a weaker sequence might suffice to prevent loss of
+coherence. These situations will be detailed following the forthcoming
+formalization of the interaction of the RVWMO memory model with the
+instructions in the Zicbom extension.
+====
+
+When two-stage address translation is enabled within the H extension,
+the page-based memory types are also applied in two stages. First, if
+`hgatp`.MODE is not equal to zero, non-zero G-stage PTE PBMT bits
+override the attributes in the PMA to produce an intermediate set of
+attributes. Otherwise, the PMAs serve as the intermediate attributes.
+Second, if `vsatp`.MODE is not equal to zero, non-zero VS-stage PTE PBMT
+bits override the intermediate attributes to produce the final set of
+attributes used by accesses to the page in question. Otherwise, the
+intermediate attributes are used as the final set of attributes.
+
+NOTE: These final attributes apply to implicit and explicit accesses that
+are subject to both stages of address translation.
+For accesses that are not subject to the first stage of address translation,
+e.g. VS-stage page-table accesses, the intermediate attributes apply instead.
+
+[[svinval]]
+== "Svinval" Extension for Fine-Grained Address-Translation Cache Invalidation, Version 1.0
+
+The Svinval extension splits SFENCE.VMA, HFENCE.VVMA, and HFENCE.GVMA
+instructions into finer-grained invalidation and ordering operations
+that can be more efficiently batched or pipelined on certain classes of
+high-performance implementation.
+
+include::images/wavedrom/sinvalvma.edn[]
+
+The SINVAL.VMA instruction invalidates any address-translation cache
+entries that an SFENCE.VMA instruction with the same values of _rs1_ and
+_rs2_ would invalidate. However, unlike SFENCE.VMA, SINVAL.VMA
+instructions are only ordered with respect to SFENCE.VMA,
+SFENCE.W.INVAL, and SFENCE.INVAL.IR instructions as defined below.
+
+include::images/wavedrom/sfencewinval.edn[]
+
+include::images/wavedrom/sfenceinvalir.edn[]
+
+The SFENCE.W.INVAL instruction guarantees that any previous stores
+already visible to the current RISC-V hart are ordered before subsequent
+SINVAL.VMA instructions executed by the same hart. The SFENCE.INVAL.IR
+instruction guarantees that any previous SINVAL.VMA instructions
+executed by the current hart are ordered before subsequent implicit
+references by that hart to the memory-management data structures.
+
+When executed in order (but not necessarily consecutively) by a single
+hart, the sequence SFENCE.W.INVAL, SINVAL.VMA, and SFENCE.INVAL.IR has
+the same effect as a hypothetical SFENCE.VMA instruction in which:
+
+* the values of _rs1_ and _rs2_ for the SFENCE.VMA are the same as those
+used in the SINVAL.VMA,
+* reads and writes prior to the SFENCE.W.INVAL are considered to be
+those prior to the SFENCE.VMA, and
+* reads and writes following the SFENCE.INVAL.IR are considered to be
+those subsequent to the SFENCE.VMA.
+
+include::images/wavedrom/hinvalvvma.edn[]
+
+include::images/wavedrom/hinvalgvma.edn[]
+
+If the hypervisor extension is implemented, the Svinval extension also
+provides two additional instructions: HINVAL.VVMA and HINVAL.GVMA. These
+have the same semantics as SINVAL.VMA, except that they combine with
+SFENCE.W.INVAL and SFENCE.INVAL.IR to replace HFENCE.VVMA and
+HFENCE.GVMA, respectively, instead of SFENCE.VMA. In addition,
+HINVAL.GVMA uses VMIDs instead of ASIDs.
+
+SINVAL.VMA, HINVAL.VVMA, and HINVAL.GVMA require the same permissions
+and raise the same exceptions as SFENCE.VMA, HFENCE.VVMA, and
+HFENCE.GVMA, respectively. In particular, an attempt to execute any of
+these instructions in U-mode always raises an illegal-instruction
+exception, and an attempt to execute SINVAL.VMA or HINVAL.GVMA in S-mode
+or HS-mode when `mstatus`.TVM=1 also raises an illegal-instruction
+exception. An attempt to execute HINVAL.VVMA or HINVAL.GVMA in VS-mode
+or VU-mode, or to execute SINVAL.VMA in VU-mode, raises a
+virtual-instruction exception. When `hstatus`.VTVM=1, an attempt to execute
+SINVAL.VMA in VS-mode also raises a virtual-instruction exception.
+
+Attempting to execute SFENCE.W.INVAL or SFENCE.INVAL.IR in U-mode
+raises an illegal-instruction exception.
+Doing so in VU-mode raises a virtual-instruction exception.
+SFENCE.W.INVAL and SFENCE.INVAL.IR are unaffected by the `mstatus`.TVM and
+`hstatus`.VTVM fields and hence are always permitted in S-mode and VS-mode.
+
+[NOTE]
+====
+SFENCE.W.INVAL and SFENCE.INVAL.IR instructions do not need to be
+trapped when `mstatus`.TVM=1 or when `hstatus`.VTVM=1, as they only have
+ordering effects but no visible side effects. Trapping of the SINVAL.VMA
+instruction is sufficient to enable emulation of the intended overall
+TLB maintenance functionality.
+
+In typical usage, software will invalidate a range of virtual addresses
+in the address-translation caches by executing an SFENCE.W.INVAL
+instruction, executing a series of SINVAL.VMA, HINVAL.VVMA, or
+HINVAL.GVMA instructions to the addresses (and optionally ASIDs or
+VMIDs) in question, and then executing an SFENCE.INVAL.IR instruction.
+
+High-performance implementations will be able to pipeline the
+address-translation cache invalidation operations, and will defer any
+pipeline stalls or other memory ordering enforcement until an
+SFENCE.W.INVAL, SFENCE.INVAL.IR, SFENCE.VMA, HFENCE.GVMA, or HFENCE.VVMA
+instruction is executed.
+
+Simpler implementations may implement SINVAL.VMA, HINVAL.VVMA, and
+HINVAL.GVMA identically to SFENCE.VMA, HFENCE.VVMA, and HFENCE.GVMA,
+respectively, while implementing SFENCE.W.INVAL and SFENCE.INVAL.IR
+instructions as no-ops.
+====
+
+[[sec:svadu]]
+== "Svadu" Extension for Hardware Updating of A/D Bits, Version 1.0
+
+The Svadu extension adds support and CSR controls for hardware updating of PTE A/D bits.
+
+If the Svadu extension is implemented, the `menvcfg`.ADUE field is writable.
+If the hypervisor extension is additionally implemented, the `henvcfg`.ADUE
+field is also writable.
+See <<sec:menvcfg>> and <<sec:henvcfg>> for the definitions of those fields.
+
+<<translation>> defines the semantics of hardware updating of A/D bits. When
+hardware updating of A/D bits is disabled, the Svade extension, which mandates
+exceptions when A/D bits need be set, instead takes effect.
+The Svade extension is also defined in <<translation>>.
+
+[[sec:svvptc]]
+== "Svvptc" Extension for Obviating Memory-Management Instructions after Marking PTEs Valid, Version 1.0
+
+When the Svvptc extension is implemented, explicit stores by a hart that update
+the Valid bit of leaf and/or non-leaf PTEs from 0 to 1 and are visible to a hart
+will eventually become visible within a bounded timeframe to subsequent implicit
+accesses by that hart to such PTEs.
+
+[NOTE]
+====
+Svvptc relieves an operating system from executing certain memory-management
+instructions, such as `SFENCE.VMA` or `SINVAL.VMA`, which would normally be used
+to synchronize the hart's address-translation caches when a memory-resident PTE
+is changed from Invalid to Valid. Synchronizing the hart's address-translation
+caches with other forms of updates to a memory-resident PTE, including when a
+PTE is changed from Valid to Invalid, requires the use of suitable
+memory-management instructions. Svvptc guarantees that a change to a PTE from
+Invalid to Valid is made visible within a bounded time, thereby making the
+execution of these memory-management instructions redundant. The performance
+benefit of eliding these instructions outweighs the cost of an occasional
+gratuitous additional page fault that may occur.
+
+Depending on the microarchitecture, some possible ways to facilitate
+implementation of Svvptc include: not having any address-translation caches, not
+storing Invalid PTEs in the address-translation caches, automatically evicting
+Invalid PTEs using a bounded timer, or making address-translation caches
+coherent with store instructions that modify PTEs.
+====
+
+[[sec:svrsw60t59b]]
+== "Svrsw60t59b" Extension for PTE Reserved-for-Software Bits 60-59, Version 1.0
+
+If the Svrsw60t59b extension is implemented, then bits 60-59 of the page table
+entries (PTEs) are reserved for use by supervisor software and are ignored by
+the implementation.
+
+If the Hypervisor (H) extension is also implemented, then bits 60-59 of the
+G-stage PTEs are reserved for use by supervisor software and are ignored by the
+implementation.
+
+The Svrsw60t59b extension depends on Sv39.
+
+[NOTE]
+====
+Operating systems frequently use reserved bits within PTEs to store metadata for
+advanced memory management features. Embedding these metadata bits directly within
+the PTEs allows for fast access with minimal overhead, avoiding costly lookups in
+auxiliary data structures. By default, Sv39 and Sv39x4 require a page fault and
+a guest-page fault exception, respectively, to be raised if bits 60–59 are not
+zero.
+====
+
+[[ssqosid]]
+== "Ssqosid" Extension for Quality-of-Service (QoS) Identifiers, Version 1.0
+
+Quality of Service (QoS) is defined as the minimal end-to-end performance
+guaranteed in advance by a service level agreement (SLA) to a workload.
+Performance metrics might include measures such as instructions per cycle (IPC),
+latency of service, etc.
+
+When multiple workloads execute concurrently on modern processors—equipped with
+large core counts, multiple cache hierarchies, and multiple memory
+controllers—the performance of any given workload becomes less deterministic, or
+even non-deterministic, due to shared resource contention.
+
+To manage performance variability, system software needs resource allocation and
+monitoring capabilities. These capabilities allow for the reservation of
+resources like cache and bandwidth, thus meeting individual performance targets
+while minimizing interference. For resource management, hardware should provide
+monitoring features that allow system software to profile workload resource
+consumption and allocate resources accordingly.
+
+To facilitate this, the QoS Identifiers extension (Ssqosid) introduces the
+`srmcfg` register, which configures a hart with two identifiers: a Resource
+Control ID (`RCID`) and a Monitoring Counter ID (`MCID`). These identifiers
+accompany each request issued by the hart to shared resource controllers.
+
+Additional metadata, like the nature of the memory access and the ID of the
+originating supervisor domain, can accompany `RCID` and `MCID`. Resource
+controllers may use this metadata for differentiated service such as a different
+capacity allocation for code storage vs. data storage. Resource controllers can
+use this data for security policies such as not exposing statistics of one
+security domain to another.
+
+These identifiers are crucial for the RISC-V Capacity and Bandwidth Controller
+QoS Register Interface (CBQRI) specification, which provides methods for setting
+resource usage limits and monitoring resource consumption. The `RCID` controls
+resource allocations, while the `MCID` is used for tracking resource usage.
+
+NOTE: The Ssqosid extension does not require that S-mode mode be implemented.
+
+=== Supervisor Resource Management Configuration (`srmcfg`) register
+
+The `srmcfg` register is an SXLEN-bit read/write register used to configure a
+Resource Control ID (`RCID`) and a Monitoring Counter ID (`MCID`). Both `RCID`
+and `MCID` are WARL fields. The register is formatted as shown in <<SRMCFG64>>
+when SXLEN=64 and <<SRMCFG32>> when SXLEN=32.
+
+The `RCID` and `MCID` accompany each request made by the hart to shared resource
+controllers. The `RCID` is used to determine the resource allocations (e.g.,
+cache occupancy limits, memory bandwidth limits, etc.) to enforce. The `MCID` is
+used to identify a counter to monitor resource usage.
+
+[[SRMCFG64]]
+.Supervisor Resource Management Configuration (`srmcfg`) register for SXLEN=64
+
+[wavedrom, , ]
+....
+{reg: [
+ {bits: 12, name: 'RCID'},
+ {bits: 4, name: 'WPRI'},
+ {bits: 12, name: 'MCID'},
+ {bits: 36, name: 'WPRI'},
+], config:{lanes: 2, hspace:1024}}
+....
+
+[[SRMCFG32]]
+.Supervisor Resource Management Configuration (`srmcfg`) register for SXLEN=32
+
+[wavedrom, , ]
+....
+{reg: [
+ {bits: 12, name: 'RCID'},
+ {bits: 4, name: 'WPRI'},
+ {bits: 12, name: 'MCID'},
+ {bits: 4, name: 'WPRI'},
+], config:{lanes: 1, hspace:1024}}
+....
+
+The `RCID` and `MCID` configured in the `srmcfg` CSR apply to all privilege
+modes of software execution on that hart by default, but this behavior may be
+overridden by future extensions.
+
+If extension Smstateen is implemented together with Ssqosid, then Ssqosid also
+requires the SRMCFG bit in `mstateen0` to be implemented.
+If `mstateen0`.SRMCFG is 0, attempts to access `srmcfg` in privilege modes
+less privileged than M-mode raise an illegal-instruction exception.
+If `mstateen0`.SRMCFG is 1 or if extension Smstateen is not implemented,
+attempts to access `srmcfg` when `V=1` raise a virtual-instruction exception.
+
+[NOTE]
+====
+A reset value of 0 is suggested for the `RCID` field matching resource
+controllers' default behavior of associating all capacity with `RCID=0`. The
+`MCID` reset value does not affect functionality and may be
+implementation-defined.
+
+Typically, fewer bits are allocated for `RCID` (e.g., to support tens of RCIDs)
+than for `MCID` (e.g., to support hundreds of MCIDs). A common `RCID` is usually
+used to group apps or VMs, pooling resource allocations to meet collective SLAs.
+If an SLA breach occurs, unique MCIDs enable granular monitoring, aiding
+decisions on resource adjustment, associating a different `RCID` with a subset
+of members, or migrating members to other machines. The larger pool of MCIDs
+speeds up this analysis.
+
+The `RCID` and `MCID` in `srmcfg` apply across all privilege levels on the hart.
+Typically, higher-privilege modes don't modify `srmcfg`, as they often serve
+lower-privileged tasks. If differentiation is needed, higher privilege code can
+update `srmcfg` and restore it before returning to a lower privilege level.
+
+In VM environments, hypervisors usually manage resource allocations, keeping
+the Guest OS out of QoS flows. If needed, the hypervisor can virtualize
+`srmcfg` CSR for a VM using the virtual-instruction exceptions triggered upon
+Guest access. If the direct selection of `RCID` and `MCID` by the VM becomes
+common and emulation overhead is an issue, future extensions may allow VS-mode
+to use a selector for a hypervisor-configured set of CSRs holding `RCID` and
+`MCID` values designated for that Guest OS use.
+
+During context switches, the supervisor may choose to execute with the `srmcfg`
+of the outgoing context to attribute the execution to it. Prior to restoring
+the new context, it switches to the new VM's `srmcfg`. The supervisor can also
+use a separate configuration for execution not to be attributed to either
+contexts.
+====
diff --git a/src/supervisor.tex b/src/supervisor.tex
deleted file mode 100644
index f461d75..0000000
--- a/src/supervisor.tex
+++ /dev/null
@@ -1,1571 +0,0 @@
-\chapter{Supervisor-Level ISA, Version \privrev}
-\label{supervisor}
-
-This chapter describes the RISC-V supervisor-level architecture, which
-contains a common core that is used with various supervisor-level
-address translation and protection schemes.
-Supervisor-level code relies on a supervisor execution environment to
-initialize the environment and enter the supervisor code at an entry
-point defined by the supervisor binary interface (SBI). The SBI also
-defines function entry points that provide supervisor environment
-services for supervisor-level code.
-
-\begin{commentary}
-Supervisor mode is deliberately restricted in terms of interactions
-with underlying physical hardware, such as physical memory and device
-interrupts, to support clean virtualization.
-\end{commentary}
-
-\section{Supervisor CSRs}
-
-A number of CSRs are provided for the supervisor.
-
-\begin{commentary}
-The supervisor should only view CSR state that should be visible to a
-supervisor-level operating system. In particular, there is no
-information about the existence (or non-existence) of higher privilege
-levels (hypervisor or machine) visible in the CSRs accessible by the
-supervisor.
-
-Many supervisor CSRs are a subset of the equivalent machine-mode CSR,
-and the machine-mode chapter should be read first to help understand
-the supervisor-level CSR descriptions.
-\end{commentary}
-
-\subsection{Supervisor Status Register (\tt sstatus)}
-\label{sstatus}
-
-
-The {\tt sstatus} register is an SXLEN-bit read/write register
-formatted as shown in Figure~\ref{sstatusreg-rv32} for RV32 and
-Figure~\ref{sstatusreg} for RV64 and RV128. The {\tt sstatus}
-register keeps track of the processor's current operating state.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{cWcccccWcWccWcc}
-\\
-\instbit{31} &
-\instbitrange{30}{20} &
-\instbit{19} &
-\instbit{18} &
-\instbit{17} &
-\instbitrange{16}{15} &
-\instbitrange{14}{13} &
-\instbitrange{12}{9} &
-\instbit{8} &
-\instbitrange{7}{6} &
-\instbit{5} &
-\instbit{4} &
-\instbitrange{3}{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{SD} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{MXR} &
-\multicolumn{1}{c|}{SUM} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{XS[1:0]} &
-\multicolumn{1}{c|}{FS[1:0]} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPP} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPIE} &
-\multicolumn{1}{c|}{UPIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SIE} &
-\multicolumn{1}{c|}{UIE}
-\\
-\hline
-1 & 11 & 1 & 1 & 1 & 2 & 2 & 4 & 1 & 2 & 1 & 1 & 2 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Supervisor-mode status register ({\tt sstatus}) for RV32.}
-\label{sstatusreg-rv32}
-\end{figure*}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{cScScccc}
-\\
-\instbit{SXLEN-1} &
-\instbitrange{SXLEN-2}{34} &
-\instbitrange{33}{32} &
-\instbitrange{31}{20} &
-\instbit{19} &
-\instbit{18} &
-\instbit{17} &
- \\
-\hline
-\multicolumn{1}{|c|}{SD} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{UXL} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{MXR} &
-\multicolumn{1}{c|}{SUM} &
-\multicolumn{1}{c|}{\wpri} &
- \\
-\hline
-1 & SXLEN-35 & 2 & 12 & 1 & 1 & 1 & \\
-\end{tabular}
-\begin{tabular}{ccccccccccc}
-\\
-&
-\instbitrange{16}{15} &
-\instbitrange{14}{13} &
-\instbitrange{12}{9} &
-\instbit{8} &
-\instbitrange{7}{6} &
-\instbit{5} &
-\instbit{4} &
-\instbitrange{3}{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
- &
-\multicolumn{1}{c|}{XS[1:0]} &
-\multicolumn{1}{|c|}{FS[1:0]} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPP} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SPIE} &
-\multicolumn{1}{c|}{UPIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SIE} &
-\multicolumn{1}{c|}{UIE} \\
-\hline
- & 2 & 2 & 4 & 1 & 2 & 1 & 1 & 2 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Supervisor-mode status register ({\tt sstatus}) for RV64 and RV128.}
-\label{sstatusreg}
-\end{figure*}
-
-The SPP bit indicates the privilege level at which a hart was executing before
-entering supervisor mode. When a trap is taken, SPP is set to 0 if the trap
-originated from user mode, or 1 otherwise. When an SRET instruction
-(see Section~\ref{otherpriv}) is executed to return from the trap handler, the
-privilege level is set to user mode if the SPP bit is 0, or supervisor mode if
-the SPP bit is 1; SPP is then set to 0.
-
-The SIE bit enables or disables all interrupts in supervisor mode.
-When SIE is clear, interrupts are not taken while in supervisor mode.
-When the hart is running in user-mode, the value in SIE is ignored, and
-supervisor-level interrupts are enabled. The supervisor can disable
-individual interrupt sources using the {\tt sie} register.
-
-The SPIE bit indicates whether supervisor interrupts were enabled prior to
-trapping into supervisor mode. When a trap is taken into supervisor
-mode, SPIE is set to SIE, and SIE is set to 0. When an SRET instruction is
-executed, SIE is set to SPIE, then SPIE is set to 1.
-
-The UIE bit enables or disables user-mode interrupts. User-level interrupts
-are enabled only if UIE is set and the hart is running in user-mode. The UPIE
-bit indicates whether user-level interrupts were enabled prior to taking
-a user-level trap. When a URET instruction is executed, UIE is
-set to UPIE, and UPIE is set to 1. User-level interrupts are optional. If
-omitted, the UIE and UPIE bits are hardwired to zero.
-
-\begin{commentary}
-The {\tt sstatus} register is a subset of the {\tt mstatus} register. In
-a straightforward implementation, reading or writing any field in {\tt
-sstatus} is equivalent to reading or writing the homonymous field in
-{\tt mstatus}.
-\end{commentary}
-
-\subsection{Base ISA Control in {\tt sstatus} Register}
-
-The UXL field controls the value of XLEN for U-mode, termed {\em UXLEN},
-which may differ from the value of XLEN for S-mode, termed {\em SXLEN}. The
-encoding of UXL is the same as that of the MXL field of {\tt misa}, shown in
-Table~\ref{misabase}.
-
-For RV32 systems, the UXL field does not exist, and UXLEN=32. For RV64 and
-RV128 systems, it is a \warl\ field that encodes the current value of UXLEN.
-In particular, the implementation may hardwire UXL so that UXLEN=SXLEN.
-
-If UXLEN~$\ne$~SXLEN, instructions executed in the narrower mode must ignore
-source register operand bits above the configured XLEN, and must sign-extend
-results to fill the widest supported XLEN in the destination register.
-
-If UXLEN~$<$~SXLEN, user-mode instruction-fetch addresses and load and store
-effective addresses are taken modulo $2^{UXLEN}$. For example, when UXLEN=32
-and SXLEN=64, user-mode memory accesses reference the lowest \wunits{4}{GiB}
-of the address space.
-
-\subsection{Memory Privilege in {\tt sstatus} Register}
-\label{sec:sum}
-
-The MXR (Make eXecutable Readable) bit modifies the privilege with which loads
-access virtual memory. When MXR=0, only loads from pages marked readable (R=1
-in Figure~\ref{sv32pte}) will succeed. When MXR=1, loads from pages marked
-either readable or executable (R=1 or X=1) will succeed. MXR has no effect
-when page-based virtual memory is not in effect.
-
-The SUM (permit Supervisor User Memory access) bit modifies the privilege with
-which S-mode loads and stores access virtual memory.
-When SUM=0, S-mode memory accesses to pages that are accessible by U-mode (U=1
-in Figure~\ref{sv32pte}) will fault. When SUM=1, these accesses are permitted.
-SUM has no effect when page-based virtual memory is not in effect, nor when
-executing in U-mode. Note that S-mode can never execute instructions from user
-pages, regardless of the state of SUM.
-
-\begin{commentary}
-The SUM mechanism prevents supervisor software from inadvertently accessing
-user memory. Operating systems can execute the majority of code with SUM clear;
-the few code segments that should access user memory can temporarily set
-SUM.
-
-The SUM mechanism does not avail S-mode software of permission to execute
-instructions in user code pages. Legitimate uses cases for execution from
-user memory in supervisor context are rare in general and nonexistent in POSIX
-environments. However, bugs in supervisors that lead to arbitrary code
-execution are much easier to exploit if the supervisor exploit code can be
-stored in a user buffer at a virtual address chosen by an attacker.
-
-Some non-POSIX single address space operating systems do allow certain
-privileged software to partially execute in supervisor mode, while most
-programs run in user mode, all in a shared address space. This use case can
-be realized by mapping the physical code pages at multiple virtual addresses
-with different permissions, possibly with the assistance of the
-instruction page-fault handler to direct supervisor software to use the
-alternate mapping.
-\end{commentary}
-
-\subsection{Supervisor Trap Vector Base Address Register ({\tt stvec})}
-
-The {\tt stvec} register is an SXLEN-bit read/write register that holds
-trap vector configuration, consisting of a vector base address (BASE) and a
-vector mode (MODE).
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{J@{}R}
-\instbitrange{SXLEN-1}{2} &
-\instbitrange{1}{0} \\
-\hline
-\multicolumn{1}{|c|}{BASE[SXLEN-1:2] (\warl)} &
-\multicolumn{1}{c|}{MODE (\warl)} \\
-\hline
-SXLEN-2 & 2 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Supervisor trap vector base address register ({\tt stvec}).}
-\label{stvecreg}
-\end{figure*}
-
-The BASE field in {\tt stvec} is a \warl\ field that can hold any valid virtual
-or physical address, subject to the following alignment constraints: the
-address must always be at least 4-byte aligned, and the MODE
-setting may impose additional alignment constraints on the value in the BASE
-field.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|r|c|l|}
-\hline
-Value & Name & Description \\
-\hline
-0 & Direct & All exceptions set {\tt pc} to BASE. \\
-1 & Vectored & Asynchronous interrupts set {\tt pc} to BASE+4$\times$cause. \\
-$\ge$2 & --- & {\em Reserved} \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Encoding of {\tt stvec} MODE field.}
-\label{stvec-mode}
-\end{table*}
-
-The encoding of the MODE field is shown in Table~\ref{stvec-mode}. When
-MODE=Direct, all traps into supervisor mode cause the {\tt pc} to be set to the
-address in the BASE field. When MODE=Vectored, all synchronous exceptions
-into supervisor mode cause the {\tt pc} to be set to the address in the BASE
-field, whereas interrupts cause the {\tt pc} to be set to the address in
-the BASE field plus four times the interrupt cause number. For example,
-a supervisor-mode timer interrupt (see Table~\ref{scauses}) causes the {\tt pc}
-to be set to BASE+{\tt 0x14}.
-Setting MODE=Vectored may impose a stricter alignment constraint on BASE.
-
-\begin{commentary}
-When vectored interrupts are enabled, interrupt cause 0, which corresponds to
-user-mode software interrupts, are vectored to the same location as
-synchronous exceptions. This ambiguity does not arise in practice for
-supervisor software, since user-mode software interrupts are either disabled
-or delegated to user mode.
-\end{commentary}
-
-\subsection{Supervisor Interrupt Registers ({\tt sip} and {\tt sie})}
-
-The {\tt sip} register is an SXLEN-bit read/write register containing
-information on pending interrupts, while {\tt sie} is the corresponding
-SXLEN-bit read/write register containing interrupt enable bits.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{EccFccFcc}
-\instbitrange{SXLEN-1}{10} &
-\instbit{9} &
-\instbit{8} &
-\instbitrange{7}{6} &
-\instbit{5} &
-\instbit{4} &
-\instbitrange{3}{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{\wpri} &
-\multicolumn{1}{c|}{SEIP} &
-\multicolumn{1}{c|}{UEIP} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{STIP} &
-\multicolumn{1}{c|}{UTIP} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SSIP} &
-\multicolumn{1}{c|}{USIP} \\
-\hline
-SXLEN-10 & 1 & 1 & 2 & 1 & 1 & 2 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Supervisor interrupt-pending register ({\tt sip}).}
-\label{sipreg}
-\end{figure*}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{EccFccFcc}
-\instbitrange{SXLEN-1}{10} &
-\instbit{9} &
-\instbit{8} &
-\instbitrange{7}{6} &
-\instbit{5} &
-\instbit{4} &
-\instbitrange{3}{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{\wpri} &
-\multicolumn{1}{c|}{SEIE} &
-\multicolumn{1}{c|}{UEIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{STIE} &
-\multicolumn{1}{c|}{UTIE} &
-\multicolumn{1}{c|}{\wpri} &
-\multicolumn{1}{c|}{SSIE} &
-\multicolumn{1}{c|}{USIE} \\
-\hline
-SXLEN-10 & 1 & 1 & 2 & 1 & 1 & 2 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Supervisor interrupt-enable register ({\tt sie}).}
-\label{siereg}
-\end{figure*}
-
-Three types of interrupts are defined: software interrupts, timer interrupts,
-and external interrupts. A supervisor-level software interrupt is triggered
-on the current hart by writing 1 to its supervisor software interrupt-pending
-(SSIP) bit in the {\tt sip} register. A pending supervisor-level software
-interrupt can be cleared by writing 0 to the SSIP bit in {\tt sip}.
-Supervisor-level software interrupts are disabled when the SSIE bit in the
-{\tt sie} register is clear.
-
-Interprocessor interrupts are sent to other harts by means of SBI
-calls, which will ultimately cause the SSIP bit to be set in the
-recipient hart's {\tt sip} register.
-
-A user-level software interrupt is triggered on the current hart by writing
-1 to its user software interrupt-pending (USIP) bit in the {\tt sip} register.
-A pending user-level software interrupt can be cleared by writing 0 to the
-USIP bit in {\tt sip}. User-level software interrupts are disabled when the
-USIE bit in the {\tt sie} register is clear. If user-level interrupts are not
-supported, USIP and USIE are hardwired to zero.
-
-All bits besides SSIP, USIP, and UEIP in the {\tt sip} register are read-only.
-
-A supervisor-level timer interrupt is pending if the STIP bit in the {\tt sip}
-register is set. Supervisor-level timer interrupts are disabled when the STIE
-bit in the {\tt sie} register is clear. An SBI call to the SEE may be used to
-clear the pending timer interrupt.
-
-A user-level timer interrupt is pending if the UTIP bit in the {\tt sip}
-register is set. User-level timer interrupts are disabled when the UTIE bit
-in the {\tt sie} register is clear. If user-level interrupts are supported,
-the ABI should provide a facility for scheduling timer interrupts in terms of
-real-time counter values. If user-level interrupts are not supported, UTIP
-and UTIE are hardwired to zero.
-
-A supervisor-level external interrupt is pending if the SEIP bit in the
-{\tt sip} register is set. Supervisor-level external interrupts are disabled
-when the SEIE bit in the {\tt sie} register is clear. The SBI should provide
-facilities to mask, unmask, and query the cause of external interrupts.
-
-The UEIP field in {\tt sip} contains a single read-write bit. UEIP
-may be written by S-mode software to indicate to U-mode that an
-external interrupt is pending. Additionally, the platform-level
-interrupt controller may generate user-level external interrupts. The
-logical-OR of the software-writable bit and the signal from the
-external interrupt controller are used to generate external interrupts
-for user mode. When the UEIP bit is read with a CSRRW, CSRRS, or
-CSRRC instruction, the value returned in the {\tt rd} destination
-register contains the logical-OR of the software-writable bit and the
-interrupt signal from the interrupt controller. However, the value
-used in the read-modify-write sequence of a CSRRS or CSRRC instruction
-is only the software-writable UEIP bit, ignoring the interrupt value
-from the external interrupt controller.
-
-\begin{commentary}
- Analogous to SEIP, the UEIP field behavior is designed to allow a
- higher privilege layer to mimic external interrupts without losing
- any real external interrupts.
-\end{commentary}
-
-User-level external interrupts are disabled when the UEIE bit in the {\tt sie}
-register is clear. If the N extension for user-level interrupts is not
-implemented, UEIP and UEIE are hardwired to zero.
-
-\begin{commentary}
-The {\tt sip} and {\tt sie} registers are subsets of the {\tt mip} and {\tt
-mie} registers. Reading any field, or writing any writable field, of {\tt
-sip}/{\tt sie} effects a read or write of the homonymous field of {\tt
-mip}/{\tt mie}.
-
-Bits 3, 7, and 11 of {\tt sip} and {\tt sie} correspond to the machine-mode
-software, timer, and external interrupts, respectively. Since most platforms
-will choose not to make these interrupts delegatable from M-mode to S-mode,
-they are marked \wpri\ in Figures~\ref{sipreg} and \ref{siereg}.
-\end{commentary}
-
-\subsection{Supervisor Timers and Performance Counters}
-
-Supervisor software uses the same hardware performance monitoring facility
-as user-mode software, including the {\tt time}, {\tt cycle}, and {\tt instret}
-CSRs. The SBI should provide a mechanism to modify the
-counter values.
-
-The SBI must provide a facility for scheduling timer interrupts in terms
-of the real-time counter, {\tt time}.
-
-\subsection{Counter-Enable Register ({\tt scounteren})}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{cccMcccccc}
-\instbit{31} &
-\instbit{30} &
-\instbit{29} &
-\instbitrange{28}{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{HPM31} &
-\multicolumn{1}{c|}{HPM30} &
-\multicolumn{1}{c|}{HPM29} &
-\multicolumn{1}{c|}{...} &
-\multicolumn{1}{c|}{HPM5} &
-\multicolumn{1}{c|}{HPM4} &
-\multicolumn{1}{c|}{HPM3} &
-\multicolumn{1}{c|}{IR} &
-\multicolumn{1}{c|}{TM} &
-\multicolumn{1}{c|}{CY} \\
-\hline
-1 & 1 & 1 & 23 & 1 & 1 & 1 & 1 & 1 & 1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Counter-enable register ({\tt scounteren}).}
-\label{scounteren}
-\end{figure*}
-
-The counter-enable register {\tt scounteren} is a 32-bit register that
-controls the availability of the hardware performance monitoring counters to
-U-mode.
-
-When the CY, TM, IR, or HPM{\em n} bit in the {\tt scounteren} register is
-clear, attempts to read the {\tt cycle}, {\tt time}, {\tt instret}, or
-{\tt hpmcounter{\em n}} register while executing in U-mode
-will cause an illegal instruction exception. When one of these bits is set,
-access to the corresponding register is permitted.
-
-{\tt scounteren} must be implemented. However, any of the bits may contain
-a hardwired value of zero, indicating reads to the corresponding counter will
-cause an exception when executing in U-mode.
-Hence, they are effectively \warl\ fields.
-
-\subsection{Supervisor Scratch Register ({\tt sscratch})}
-
-The {\tt sscratch} register is an SXLEN-bit read/write register,
-dedicated for use by the supervisor. Typically, {\tt sscratch} is
-used to hold a pointer to the hart-local supervisor context while the
-hart is executing user code. At the beginning of a trap handler, {\tt
- sscratch} is swapped with a user register to provide an initial
-working register.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{SXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt sscratch} \\
-\hline
-SXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Supervisor Scratch Register.}
-\label{kregs}
-\end{figure}
-
-\subsection{Supervisor Exception Program Counter ({\tt sepc})}
-
-{\tt sepc} is an SXLEN-bit read/write register formatted as shown in
-Figure~\ref{epcreg}. The low bit of {\tt sepc} ({\tt sepc[0]}) is
-always zero. On implementations that support only IALIGN=32, the two low bits
-({\tt sepc[1:0]}) are always zero.
-
-If an implementation allows IALIGN to be either 16 or 32 (by
-changing CSR {\tt misa}, for example), then, whenever IALIGN=32, bit
-{\tt sepc[1]} is masked on reads so that it appears to be 0. This
-masking occurs also for the implicit read by the SRET instruction.
-Though masked, {\tt sepc[1]} remains writable when IALIGN=32.
-
-{\tt sepc} is a \warl\ register that must be able to hold all valid physical
-and virtual addresses. It need not be capable of holding all possible invalid
-addresses. Implementations may convert some invalid address patterns into
-other invalid addresses prior to writing them to {\tt sepc}.
-
-When a trap is taken into S-mode, {\tt sepc} is written with the
-virtual address of the instruction that was interrupted or that
-encountered the exception. Otherwise, {\tt sepc} is never written by
-the implementation, though it may be explicitly written by software.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{SXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt sepc} \\
-\hline
-SXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Supervisor exception program counter register.}
-\label{epcreg}
-\end{figure}
-
-\subsection{Supervisor Cause Register ({\tt scause})}
-
-The {\tt scause} register is an SXLEN-bit read-write register formatted as
-shown in Figure~\ref{scausereg}. When a trap is taken into S-mode, {\tt
-scause} is written with a code indicating the event that caused the trap.
-Otherwise, {\tt scause} is never written by the implementation, though it may be
-explicitly written by software.
-
-The Interrupt bit in the {\tt scause} register is set if the
-trap was caused by an interrupt. The Exception Code field
-contains a code identifying the last exception. Table~\ref{scauses}
-lists the possible exception codes for the current supervisor ISAs, in
-descending order of priority. The Exception Code is an \wlrl\ field,
-so is only guaranteed to hold supported exception codes.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{c@{}U}
-\instbit{SXLEN-1} &
-\instbitrange{SXLEN-2}{0} \\
-\hline
-\multicolumn{1}{|c|}{Interrupt} &
-\multicolumn{1}{c|}{Exception Code (\wlrl)} \\
-\hline
-1 & SXLEN-1 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Supervisor Cause register {\tt scause}.}
-\label{scausereg}
-\end{figure*}
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|r|r|l|l|}
-
- \hline
- Interrupt & Exception Code & Description \\
- \hline
- 1 & 0 & User software interrupt \\
- 1 & 1 & Supervisor software interrupt \\
- 1 & 2--3 & {\em Reserved} \\
- 1 & 4 & User timer interrupt \\
- 1 & 5 & Supervisor timer interrupt \\
- 1 & 6--7 & {\em Reserved} \\
- 1 & 8 & User external interrupt \\
- 1 & 9 & Supervisor external interrupt \\
- 1 & $\ge$10 & {\em Reserved} \\ \hline
- 0 & 0 & Instruction address misaligned \\
- 0 & 1 & Instruction access fault \\
- 0 & 2 & Illegal instruction \\
- 0 & 3 & Breakpoint \\
- 0 & 4 & Load address misaligned \\
- 0 & 5 & Load access fault \\
- 0 & 6 & Store/AMO address misaligned \\
- 0 & 7 & Store/AMO access fault \\
- 0 & 8 & Environment call from U-mode \\
- 0 & 9 & Environment call from S-mode \\
- 0 & 10--11 & {\em Reserved} \\
- 0 & 12 & Instruction page fault \\
- 0 & 13 & Load page fault \\
- 0 & 14 & {\em Reserved} \\
- 0 & 15 & Store/AMO page fault \\
- 0 & $\ge$16 & {\em Reserved} \\
- \hline
-\end{tabular}
-\end{center}
-\caption{Supervisor cause register ({\tt scause}) values after trap.}
-\label{scauses}
-\end{table*}
-
-\subsection{Supervisor Trap Value ({\tt stval}) Register}
-
-The {\tt stval} register is an SXLEN-bit read-write register formatted as shown
-in Figure~\ref{stvalreg}. When a trap is taken into S-mode, {\tt stval} is
-written with exception-specific information to assist software in handling the
-trap. Otherwise, {\tt stval} is never written by the implementation, though
-it may be explicitly written by software. The hardware platform will specify
-which exceptions must set {\tt stval} informatively and which may
-unconditionally set it to zero.
-
-
-When a hardware breakpoint is triggered, or an instruction-fetch, load, or
-store address-misaligned, access, or page-fault exception occurs, {\tt stval}
-is written with the faulting virtual address. On an illegal instruction trap,
-{\tt stval} may be written with the first XLEN or ILEN bits of the faulting
-instruction as described below. For other exceptions, {\tt stval} is set to
-zero, but a future standard may redefine {\tt stval}'s setting for other
-exceptions.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}J}
-\instbitrange{SXLEN-1}{0} \\
-\hline
-\multicolumn{1}{|c|}{\tt stval} \\
-\hline
-SXLEN \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Supervisor Trap Value register.}
-\label{stvalreg}
-\end{figure}
-
-For misaligned loads and stores that cause access or page-fault
-exceptions, {\tt stval} will contain the virtual address of the
-portion of the access that caused the fault. For
-instruction-fetch access or page-fault exceptions on systems
-with variable-length instructions, {\tt stval} will contain the
-virtual address of the portion of the instruction that caused
-the fault while {\tt sepc} will point to the beginning of the
-instruction.
-
-The {\tt stval} register can optionally also be used to return the
-faulting instruction bits on an illegal instruction exception ({\tt
- sepc} points to the faulting instruction in memory).
-
-If this feature is not provided, then {\tt stval} is set to zero on
-an illegal instruction fault.
-
-If this feature is provided, after an illegal instruction trap, {\tt stval}
-will contain the shortest of:
-\begin{compactitem}
-\item the actual faulting instruction
-\item the first ILEN bits of the faulting instruction
-\item the first XLEN bits of the faulting instruction
-\end{compactitem}
-The value loaded into {\tt stval} is right-justified and all unused upper
-bits are cleared to zero.
-
-{\tt stval} is a \warl\ register that must be able to hold all valid physical
-and virtual addresses and the value 0. It need not be capable of holding all
-possible invalid addresses. Implementations may convert some invalid address
-patterns into other invalid addresses prior to writing them to {\tt stval}.
-If the feature to return the faulting instruction bits is implemented, {\tt
-stval} must also be able to hold all values less than $2^N$, where $N$ is the
-smaller of XLEN and the width of the longest supported instruction.
-
-\subsection{Supervisor Address Translation and Protection ({\tt satp}) Register}
-\label{sec:satp}
-
-The {\tt satp} register is an SXLEN-bit read/write register, formatted as shown
-in Figure~\ref{rv32satp} for SXLEN=32 and Figure~\ref{rv64satp} for SXLEN=64, which
-controls supervisor-mode address translation and protection.
-This register holds the physical page number (PPN) of the root page
-table, i.e., its supervisor physical address divided by \wunits{4}{KiB};
-an address space identifier (ASID), which facilitates address-translation
-fences on a per-address-space basis; and the MODE field, which selects the
-current address-translation scheme. Further details on the access to this
-register are described in Section~\ref{virt-control}.
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{c@{}E@{}K}
-\instbit{31} &
-\instbitrange{30}{22} &
-\instbitrange{21}{0} \\
-\hline
-\multicolumn{1}{|c|}{{\tt MODE} (\warl)} &
-\multicolumn{1}{|c|}{{\tt ASID} (\warl)} &
-\multicolumn{1}{|c|}{{\tt PPN} (\warl)} \\
-\hline
-1 & 9 & 22 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{RV32 Supervisor address translation and protection register {\tt satp}.}
-\label{rv32satp}
-\end{figure}
-
-\begin{commentary}
-Storing a PPN in {\tt satp}, rather than a physical address, supports
-a physical address space larger than \wunits{4}{GiB} for RV32.
-\end{commentary}
-
-\begin{figure}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}S@{}T@{}U}
-\instbitrange{63}{60} &
-\instbitrange{59}{44} &
-\instbitrange{43}{0} \\
-\hline
-\multicolumn{1}{|c|}{{\tt MODE} (\warl)} &
-\multicolumn{1}{|c|}{{\tt ASID} (\warl)} &
-\multicolumn{1}{|c|}{{\tt PPN} (\warl)} \\
-\hline
-4 & 16 & 44 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{RV64 Supervisor address translation and protection register {\tt satp}, for MODE
-values Bare, Sv39, and Sv48.}
-\label{rv64satp}
-\end{figure}
-
-\begin{samepage-commentary}
-We store the ASID and the page table base address in the same CSR to allow the
-pair to be changed atomically on a context switch. Swapping them
-non-atomically could pollute the old virtual address space with new
-translations, or vice-versa. This approach also slightly reduces the cost of
-a context switch.
-\end{samepage-commentary}
-
-Table~\ref{tab:satp-mode} shows the encodings of the MODE field for RV32 and
-RV64. When MODE=Bare, supervisor virtual addresses are equal to
-supervisor physical addresses, and there is no additional memory protection
-beyond the physical memory protection scheme described in
-Section~\ref{sec:pmp}. In this case, the remaining fields in {\tt satp}
-have no effect.
-
-For RV32, the only other valid setting for MODE is Sv32, a paged
-virtual-memory scheme described in Section~\ref{sec:sv32}.
-
-For RV64, two paged virtual-memory schemes are defined: Sv39 and Sv48,
-described in Sections~\ref{sec:sv39} and \ref{sec:sv48}, respectively.
-Two additional schemes, Sv57 and Sv64, will be defined in a later version
-of this specification. The remaining MODE settings are reserved
-for future use and may define different interpretations of the other fields in
-{\tt satp}.
-
-Implementations are not required to support all MODE settings,
-and if {\tt satp} is written with an unsupported MODE, the entire write has
-no effect; no fields in {\tt satp} are modified.
-
-\begin{table}[h]
-\begin{center}
-\begin{tabular}{|c|c|l|}
-\hline
-\multicolumn{3}{|c|}{RV32} \\
-\hline
-Value & Name & Description \\
-\hline
-0 & Bare & No translation or protection. \\
-1 & Sv32 & Page-based 32-bit virtual addressing (see Section~\ref{sec:sv32}). \\
-\hline \hline
-\multicolumn{3}{|c|}{RV64} \\
-\hline
-Value & Name & Description \\
-\hline
-0 & Bare & No translation or protection. \\
-1--7 & --- & {\em Reserved} \\
-8 & Sv39 & Page-based 39-bit virtual addressing (see Section~\ref{sec:sv39}). \\
-9 & Sv48 & Page-based 48-bit virtual addressing (see Section~\ref{sec:sv48}). \\
-10 & {\em Sv57} & {\em Reserved for page-based 57-bit virtual addressing.} \\
-11 & {\em Sv64} & {\em Reserved for page-based 64-bit virtual addressing.} \\
-12--15 & --- & {\em Reserved} \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Encoding of {\tt satp} MODE field.}
-\label{tab:satp-mode}
-\end{table}
-
-The number of supervisor physical address bits is implementation-defined; any
-unimplemented address bits are hardwired to zero in the {\tt satp} register.
-The number of ASID bits is also implementation-defined and may be zero. The
-number of implemented ASID bits, termed {\mbox {\em ASIDLEN}}, may be
-determined by writing one to every bit position in the ASID field, then
-reading back the value in {\tt satp} to see which bit positions in the ASID
-field hold a one. The least-significant bits of ASID are implemented first:
-that is, if ASIDLEN~$>$~0, ASID[ASIDLEN-1:0] is writable. The maximal value
-of ASIDLEN, termed ASIDMAX, is 9 for Sv32 or 16 for Sv39 and Sv48.
-
-
-\begin{commentary}
-For many applications, the choice of page size has a substantial
-performance impact. A large page size increases TLB reach and loosens
-the associativity constraints on virtually-indexed, physically-tagged
-caches. At the same time, large pages exacerbate internal
-fragmentation, wasting physical memory and possibly cache capacity.
-
-After much deliberation, we have settled on a conventional page size
-of 4 KiB for both RV32 and RV64. We expect this decision to ease the
-porting of low-level runtime software and device drivers. The TLB
-reach problem is ameliorated by transparent superpage support in
-modern operating systems~\cite{transparent-superpages}. Additionally,
-multi-level TLB hierarchies are quite inexpensive relative to the
-multi-level cache hierarchies whose address space they map.
-\end{commentary}
-
-Note that writing {\tt satp} does not imply any ordering constraints
-between page-table updates and subsequent address translations.
-If the new address space's page tables have been modified, it may be
-necessary to execute an SFENCE.VMA instruction
-(see Section~\ref{sec:sfence.vma}) prior to writing {\tt satp}.
-
-\begin{commentary}
-Not imposing upon implementations to flush address-translation caches
-upon {\tt satp} writes reduces the cost of context switches, provided
-a sufficiently large ASID space.
-\end{commentary}
-
-\section{Supervisor Instructions}
-
-In addition to the SRET instruction defined in
-Section~\ref{otherpriv}, one new supervisor-level instruction is
-provided.
-
-\subsection{Supervisor Memory-Management Fence Instruction}
-\label{sec:sfence.vma}
-
-\vspace{-0.2in}
-\begin{center}
-\begin{tabular}{O@{}R@{}R@{}F@{}R@{}S}
-\\
-\instbitrange{31}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{funct7} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-7 & 5 & 5 & 3 & 5 & 7 \\
-SFENCE.VMA & asid & vaddr & PRIV & 0 & SYSTEM \\
-\end{tabular}
-\end{center}
-
-The supervisor memory-management fence instruction SFENCE.VMA is used to
-synchronize updates to in-memory memory-management data structures with
-current execution. Instruction execution causes implicit reads and writes to
-these data structures; however, these implicit references are ordinarily not
-ordered with respect to loads and stores in the instruction stream. Executing
-an SFENCE.VMA instruction guarantees that any stores in the instruction stream
-prior to the SFENCE.VMA are ordered before all implicit references subsequent
-to the SFENCE.VMA. Further details on the behavior of this instruction are
-described in Section~\ref{virt-control} and Section~\ref{pmp-vmem}.
-
-\begin{commentary}
-The SFENCE.VMA is used to flush any local hardware caches related to
-address translation. It is specified as a fence rather than a TLB
-flush to provide cleaner semantics with respect to which instructions
-are affected by the flush operation and to support a wider variety of
-dynamic caching structures and memory-management schemes. SFENCE.VMA
-is also used by higher privilege levels to synchronize page table
-writes and the address translation hardware.
-\end{commentary}
-
-\begin{commentary}
-Note the instruction has no effect on the translations of other harts,
-which must be notified separately. One approach is to use 1)
-a local data fence to ensure local writes are visible globally, then
-2) an interprocessor interrupt to the other thread, then 3) a local
-SFENCE.VMA in the interrupt handler of the remote thread, and finally
-4) signal back to originating thread that operation is complete. This
-is, of course, the RISC-V analog to a TLB shootdown. Alternatively,
-implementations might provide direct hardware support for remote TLB
-invalidation. TLB shootdowns are handled by an SBI call to hide
-implementation details.
-\end{commentary}
-
-For the common case that the translation data structures have only been
-modified for a single address mapping (i.e., one page or superpage), {\em rs1}
-can specify a virtual address within that mapping to effect a translation
-fence for that mapping only. Furthermore, for the common case that the
-translation data structures have only been modified for a single address-space
-identifier, {\em rs2} can specify the address space. The behavior of
-SFENCE.VMA depends on {\em rs1} and {\em rs2} as follows:
-
-\begin{itemize}
-\item If {\em rs1}={\tt x0} and {\em rs2}={\tt x0}, the fence orders all
- reads and writes made to any level of the page tables, for all
- address spaces.
-\item If {\em rs1}={\tt x0} and {\em rs2}$\neq${\tt x0}, the fence orders
- all reads and writes made to any level of the page tables, but only
- for the address space identified by integer register {\em rs2}.
- Accesses to {\em global} mappings (see Section~\ref{sec:translation})
- are not ordered.
-\item If {\em rs1}$\neq${\tt x0} and {\em rs2}={\tt x0}, the fence orders
- only reads and writes made to the leaf page table entry corresponding
- to the virtual address in {\em rs1}, for all address spaces.
-\item If {\em rs1}$\neq${\tt x0} and {\em rs2}$\neq${\tt x0}, the fence
- orders only reads and writes made to the leaf page table entry
- corresponding to the virtual address in {\em rs1}, for the address
- space identified by integer register {\em rs2}.
- Accesses to global mappings are not ordered.
-\end{itemize}
-
-When {\em rs2}$\neq${\tt x0}, bits SXLEN-1:ASIDMAX of the value held in {\em
-rs2} are reserved for future use and should be zeroed by software and ignored
-by current implementations. Furthermore, if ASIDLEN~$<$~ASIDMAX, the
-implementation shall ignore bits ASIDMAX-1:ASIDLEN of the value held in {\em
-rs2}.
-
-\begin{commentary}
-Simpler implementations can ignore the virtual address in {\em rs1} and
-the ASID value in {\em rs2} and always perform a global fence.
-\end{commentary}
-
-\section{Sv32: Page-Based 32-bit Virtual-Memory Systems}
-\label{sec:sv32}
-
-When Sv32 is written to the MODE field in the {\tt satp} register (see
-Section~\ref{sec:satp}), the supervisor operates in a 32-bit paged
-virtual-memory system. In this mode, supervisor and user virtual addresses
-are translated into supervisor physical addresses by traversing a radix-tree
-page table. Sv32 is supported on RV32 systems and is designed to include
-mechanisms sufficient for supporting modern Unix-based operating systems.
-
-\begin{commentary}
-The initial RISC-V paged virtual-memory architectures have been
-designed as straightforward implementations to support existing
-operating systems. We have architected page table layouts to support
-a hardware page-table walker. Software TLB refills are a performance
-bottleneck on high-performance systems, and are especially troublesome
-with decoupled specialized coprocessors. An implementation can choose
-to implement software TLB refills using a machine-mode trap handler as
-an extension to M-mode.
-\end{commentary}
-
-\subsection{Addressing and Memory Protection}
-\label{sec:translation}
-
-Sv32 implementations support a 32-bit virtual address space, divided
-into \wunits{4}{KiB} pages. An Sv32 virtual address is partitioned
-into a virtual page number (VPN) and page offset, as shown in
-Figure~\ref{sv32va}. When Sv32 virtual memory mode is selected in the
-MODE field of the {\tt satp} register, supervisor virtual addresses
-are translated into supervisor physical addresses via a two-level page
-table. The 20-bit VPN is translated into a 22-bit physical page
-number (PPN), while the 12-bit page offset is untranslated. The
-resulting supervisor-level physical addresses are then checked using
-any physical memory protection structures (Sections~\ref{sec:pmp}),
-before being directly converted to machine-level physical addresses.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}O@{}O@{}E}
-\instbitrange{31}{22} &
-\instbitrange{21}{12} &
-\instbitrange{11}{0} \\
-\hline
-\multicolumn{1}{|c|}{VPN[1]} &
-\multicolumn{1}{c|}{VPN[0]} &
-\multicolumn{1}{c|}{page offset} \\
-\hline
-10 & 10 & 12 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv32 virtual address.}
-\label{sv32va}
-\end{figure*}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}E@{}O@{}E}
-\instbitrange{33}{22} &
-\instbitrange{21}{12} &
-\instbitrange{11}{0} \\
-\hline
-\multicolumn{1}{|c|}{PPN[1]} &
-\multicolumn{1}{c|}{PPN[0]} &
-\multicolumn{1}{c|}{page offset} \\
-\hline
-12 & 10 & 12 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv32 physical address.}
-\label{rv32va}
-\end{figure*}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}E@{}O@{}Fcccccccc}
-\instbitrange{31}{20} &
-\instbitrange{19}{10} &
-\instbitrange{9}{8} &
-\instbit{7} &
-\instbit{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{PPN[1]} &
-\multicolumn{1}{c|}{PPN[0]} &
-\multicolumn{1}{c|}{RSW} &
-\multicolumn{1}{c|}{D} &
-\multicolumn{1}{c|}{A} &
-\multicolumn{1}{c|}{G} &
-\multicolumn{1}{c|}{U} &
-\multicolumn{1}{c|}{X} &
-\multicolumn{1}{c|}{W} &
-\multicolumn{1}{c|}{R} &
-\multicolumn{1}{c|}{V} \\
-\hline
-12 & 10 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv32 page table entry.}
-\label{sv32pte}
-\end{figure*}
-
-Sv32 page tables consist of $2^{10}$ page-table entries (PTEs), each
-of four bytes. A page table is exactly the size of a page and must
-always be aligned to a page boundary. The physical page number of the
-root page table is stored in the {\tt satp} register.
-
-The PTE format for Sv32 is shown in Figures~\ref{sv32pte}. The V bit
-indicates whether the PTE is valid; if it is 0, all other bits in the PTE are
-don't-cares and may be used freely by software. The permission bits, R, W,
-and X, indicate whether the page is readable, writable, and executable,
-respectively. When all three are zero, the PTE is a pointer to the next level
-of the page table; otherwise, it is a leaf PTE. Writable pages must also be
-marked readable; the contrary combinations are reserved for future use.
-Table~\ref{pteperm} summarizes the encoding of the permission bits.
-
-\begin{table*}[h!]
-\begin{center}
-\begin{tabular}{|c|c|c||l|}
-\hline
-X & W & R & Meaning \\
-\hline
-0 & 0 & 0 & Pointer to next level of page table. \\
-0 & 0 & 1 & Read-only page. \\
-0 & 1 & 0 & {\em Reserved for future use.} \\
-0 & 1 & 1 & Read-write page. \\
-1 & 0 & 0 & Execute-only page. \\
-1 & 0 & 1 & Read-execute page. \\
-1 & 1 & 0 & {\em Reserved for future use.} \\
-1 & 1 & 1 & Read-write-execute page. \\
-\hline
-\end{tabular}
-\end{center}
-\caption{Encoding of PTE R/W/X fields.}
-\label{pteperm}
-\end{table*}
-
-Attempting to fetch an instruction from a page that does not have execute
-permissions raises a fetch page-fault exception. Attempting to execute
-a load or load-reserved instruction whose effective address lies within
-a page without read permissions raises a load page-fault exception.
-Attempting to execute a store, store-conditional (regardless of success),
-or AMO instruction whose effective address lies within a page without
-write permissions raises a store page-fault exception.
-\begin{commentary}
-AMOs never raise load page-fault exceptions. Since any unreadable page is
-also unwritable, attempting to perform an AMO on an unreadable page always
-raises a store page-fault exception.
-\end{commentary}
-
-The U bit indicates whether the page is accessible to user mode.
-U-mode software may only access the page when U=1. If the SUM bit
-in the {\tt sstatus} register is
-set, supervisor mode software may also access pages with U=1.
-However, supervisor code normally operates with the SUM bit clear, in
-which case, supervisor code will fault on accesses to user-mode pages.
-Irrespective of SUM, the supervisor may not execute code on pages with U=1.
-
-\begin{commentary}
-An alternative PTE format would support different permissions for supervisor
-and user. We omitted this feature because it would be largely redundant with
-the SUM mechanism (see Section~\ref{sec:sum}) and would require more encoding
-space in the PTE.
-\end{commentary}
-
-The G bit designates a {\em global} mapping. Global mappings are those that
-exist in all address spaces. For non-leaf PTEs, the global setting implies
-that all mappings in the subsequent levels of the page table are global. Note
-that failing to mark a global mapping as global merely reduces performance,
-whereas marking a non-global mapping as global is an error.
-
-\begin{commentary}
-Global mappings need not be stored redundantly in address-translation caches
-for multiple ASIDs. Additionally, they need not be flushed from local
-address-translation caches when an SFENCE.VMA instruction is executed with
-{\em rs2}$\neq${\tt x0}.
-\end{commentary}
-
-The RSW field is reserved for use by supervisor software; the implementation
-shall ignore this field.
-
-Each leaf PTE contains an accessed (A) and dirty (D) bit. The A bit indicates
-the virtual page has been read, written, or fetched from since the last time
-the A bit was cleared. The D bit indicates the virtual page has been written
-since the last time the D bit was cleared.
-
-Two schemes to manage the A and D bits are permitted:
-\begin{itemize}
-\item When a virtual page is accessed and the A bit is clear, or is
- written and the D bit is clear, the implementation sets the
- corresponding bit in the PTE. The PTE update must be atomic with
- respect to other accesses to the PTE, and must atomically check
- that the PTE is valid and grants sufficient permissions. The
- PTE update must be exact (i.e., not speculative), and observed
- in program order by the local hart. The ordering on loads and stores
- provided by FENCE instructions and the acquire/release bits on atomic
- instructions also orders the PTE updates associated with those loads
- and stores as observed by remote harts.
-\item When a virtual page is accessed and the A bit is clear, or is
- written and the D bit is clear, a page-fault exception is raised.
-\end{itemize}
-All harts in a system must employ the same PTE-update scheme as each other.
-
-\begin{commentary}
-Mandating that the PTE updates to be exact, atomic, and in program order
-simplifies the specification, and makes the feature more useful for system
-software. Simple implementations may instead generate page-fault exceptions.
-
-The A and D bits are never cleared by the implementation. If the
-supervisor software does not rely on accessed and/or dirty bits,
-e.g. if it does not swap memory pages to secondary storage or if the
-pages are being used to map I/O space, it should always set them to 1
-in the PTE to improve performance.
-\end{commentary}
-
-Any level of PTE may be a leaf PTE, so in addition to 4 KiB pages, Sv32
-supports 4 MiB {\em megapages}. A megapage must be virtually and
-physically aligned to a 4 MiB boundary; a page-fault exception is raised
-if the physical address is insufficiently aligned.
-
-For non-leaf PTEs, the D, A, and U bits are reserved for future use and
-must be cleared by software for forward compatibility.
-
-\subsection{Virtual Address Translation Process}
-\label{sv32algorithm}
-
-A virtual address $va$ is translated into a physical address $pa$ as
-follows:
-
-\begin{enumerate}
-
-\item Let $a$ be ${\tt satp}.ppn \times \textrm{PAGESIZE}$, and let $i=\textrm{LEVELS} - 1$. (For Sv32, PAGESIZE=$2^{12}$ and LEVELS=2.)
-
-\item Let $pte$ be the value of the PTE at address
- $a+va.vpn[i]\times \textrm{PTESIZE}$. (For Sv32, PTESIZE=4.)
- If accessing $pte$ violates a PMA or PMP check, raise an
- access exception corresponding to the original access type.
-
-\item If $pte.v=0$, or if $pte.r=0$ and $pte.w=1$, stop and raise a
- page-fault exception corresponding to the original access type.
-
-\item Otherwise, the PTE is valid.
- If $pte.r=1$ or $pte.x=1$, go to step 5.
- Otherwise, this PTE is a pointer to the next level of the page table. Let
- $i=i-1$. If $i<0$, stop and raise a page-fault exception
- corresponding to the original access type. Otherwise, let
- $a=pte.ppn \times \textrm{PAGESIZE}$ and go to step 2.
-
-\item A leaf PTE has been found. Determine if the requested memory access is
- allowed by the $pte.r$, $pte.w$, $pte.x$, and $pte.u$ bits, given the
- current privilege mode and the value of the SUM and MXR fields of
- the {\tt mstatus} register. If not, stop and raise a page-fault
- exception corresponding to the original access type.
-
-\item If $i>0$ and $pte.ppn[i-1:0]\neq 0$, this is a misaligned superpage;
- stop and raise a page-fault exception corresponding to the original access type.
-
-\item If $pte.a=0$, or if the memory access is a store and $pte.d=0$, either
- raise a page-fault exception corresponding to the original access type, or:
- \begin{itemize}
- \item Set $pte.a$ to 1 and, if the memory access is a store, also set
- $pte.d$ to 1.
- \item If this access violates a PMA or PMP check, raise an access exception
- corresponding to the original access type.
- \item This update and the loading of $pte$ in step 2 must be atomic; in
- particular, no intervening store to the PTE may be perceived to have
- occurred in-between.
- \end{itemize}
-
-\item The translation is successful. The translated physical address is
- given as follows:
-\begin{itemize}
-\item $\textit{pa.pgoff} = \textit{va.pgoff}$.
-\item If $i>0$, then this is a superpage translation and $pa.ppn[i-1:0]=va.vpn[i-1:0]$.
-\item $pa.ppn[\textrm{LEVELS} - 1:i] = pte.ppn[\textrm{LEVELS} - 1:i]$.
-\end{itemize}
-
-\end{enumerate}
-
-\section{Sv39: Page-Based 39-bit Virtual-Memory System}
-\label{sec:sv39}
-
-This section describes a simple paged virtual-memory system designed
-for RV64 systems, which supports 39-bit virtual address spaces. The
-design of Sv39 follows the overall scheme of Sv32, and this section
-details only the differences between the schemes.
-
-\begin{commentary}
-We specified multiple virtual memory systems for RV64 to relieve the tension
-between providing a large address space and minimizing address-translation
-cost. For many systems, \wunits{512}{GiB} of virtual-address space is ample,
-and so Sv39 suffices. Sv48 increases the virtual address space to
-\wunits{256}{TiB}, but increases the physical memory
-capacity dedicated to page tables, the latency of page-table traversals, and
-the size of hardware structures that store virtual addresses.
-\end{commentary}
-
-\subsection{Addressing and Memory Protection}
-
-Sv39 implementations support a 39-bit virtual address space, divided
-into \wunits{4}{KiB} pages. An Sv39 address is partitioned as
-shown in Figure~\ref{sv39va}.
-Instruction fetch addresses and load and store effective addresses,
-which are 64 bits, must have bits 63--39 all equal to bit 38, or else
-a page-fault exception will occur. The 27-bit VPN is translated into a
-44-bit PPN via a three-level page table, while the 12-bit page offset
-is untranslated.
-
-\begin{commentary}
-When mapping between narrower and wider addresses, RISC-V usually
-zero-extends a narrower address to a wider size. The mapping
-between 64-bit virtual addresses and the 39-bit usable address
-space of Sv39 is not based on zero-extension but instead follows an
-entrenched convention that allows an OS to use one or a few of the
-most-significant bits of a full-size (64-bit) virtual address to
-quickly distinguish user and supervisor address regions.
-\end{commentary}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}O@{}O@{}O@{}O}
-\instbitrange{38}{30} &
-\instbitrange{29}{21} &
-\instbitrange{20}{12} &
-\instbitrange{11}{0} \\
-\hline
-\multicolumn{1}{|c|}{VPN[2]} &
-\multicolumn{1}{c|}{VPN[1]} &
-\multicolumn{1}{c|}{VPN[0]} &
-\multicolumn{1}{c|}{page offset} \\
-\hline
-9 & 9 & 9 & 12 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv39 virtual address.}
-\label{sv39va}
-\end{figure*}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}T@{}O@{}O@{}O}
-\instbitrange{55}{30} &
-\instbitrange{29}{21} &
-\instbitrange{20}{12} &
-\instbitrange{11}{0} \\
-\hline
-\multicolumn{1}{|c|}{PPN[2]} &
-\multicolumn{1}{c|}{PPN[1]} &
-\multicolumn{1}{c|}{PPN[0]} &
-\multicolumn{1}{c|}{page offset} \\
-\hline
-26 & 9 & 9 & 12 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv39 physical address.}
-\label{sv39pa}
-\end{figure*}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}Y@{}Y@{}Y@{}Y@{}Fcccccccc}
-\instbitrange{63}{54} &
-\instbitrange{53}{28} &
-\instbitrange{27}{19} &
-\instbitrange{18}{10} &
-\instbitrange{9}{8} &
-\instbit{7} &
-\instbit{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{\it Reserved} &
-\multicolumn{1}{c|}{PPN[2]} &
-\multicolumn{1}{c|}{PPN[1]} &
-\multicolumn{1}{c|}{PPN[0]} &
-\multicolumn{1}{c|}{RSW} &
-\multicolumn{1}{c|}{D} &
-\multicolumn{1}{c|}{A} &
-\multicolumn{1}{c|}{G} &
-\multicolumn{1}{c|}{U} &
-\multicolumn{1}{c|}{X} &
-\multicolumn{1}{c|}{W} &
-\multicolumn{1}{c|}{R} &
-\multicolumn{1}{c|}{V} \\
-\hline
-10 & 26 & 9 & 9 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv39 page table entry.}
-\label{sv39pte}
-\end{figure*}
-
-Sv39 page tables contain $2^9$ page table entries (PTEs), eight
-bytes each. A page table is exactly the size of a page and must
-always be aligned to a page boundary. The physical page number of the
-root page table is stored in the {\tt satp} register's PPN field.
-
-The PTE format for Sv39 is shown in Figure~\ref{sv39pte}. Bits 9--0
-have the same meaning as for Sv32. Bits 63--54 are reserved
-for future use and must be zeroed by software for forward compatibility.
-
-\begin{commentary}
-We reserved several PTE bits for a possible extension that improves
-support for sparse address spaces by allowing page-table levels to be
-skipped, reducing memory usage and TLB refill latency. These reserved
-bits may also be used to facilitate research experimentation. The
-cost is reducing the physical address space, but \wunits{64}{PiB} is
-presently ample. When it no longer suffices, the reserved
-bits that remain unallocated could be used to expand the physical
-address space.
-\end{commentary}
-
-Any level of PTE may be a leaf PTE, so in addition to \wunits{4}{KiB}
-pages, Sv39 supports \wunits{2}{MiB} {\em megapages} and
-\wunits{1}{GiB} {\em gigapages}, each of which must be virtually and
-physically aligned to a boundary equal to its size.
-A page-fault exception is raised if the physical address is insufficiently
-aligned.
-
-The algorithm for virtual-to-physical address translation is the same as in
-Section~\ref{sv32algorithm}, except LEVELS equals 3 and PTESIZE equals 8.
-
-\section{Sv48: Page-Based 48-bit Virtual-Memory System}
-\label{sec:sv48}
-
-This section describes a simple paged virtual-memory system designed
-for RV64 systems, which supports 48-bit virtual address spaces. Sv48
-is intended for systems for which a 39-bit virtual address space is
-insufficient. It closely follows the design of Sv39, simply adding an
-additional level of page table, and so this chapter only details the
-differences between the two schemes.
-
-Implementations that support Sv48 must also support Sv39.
-
-\begin{commentary}
-Systems that support Sv48 can also support Sv39 at essentially no cost, and so
-should do so to maintain compatibility with supervisor software that assumes
-Sv39.
-\end{commentary}
-
-\subsection{Addressing and Memory Protection}
-
-Sv48 implementations support a 48-bit virtual address space, divided
-into \wunits{4}{KiB} pages. An Sv48 address is partitioned as
-shown in Figure~\ref{sv48va}.
-Instruction fetch addresses and load and store effective addresses,
-which are 64 bits, must have bits 63--48 all equal to bit 47, or else
-a page-fault exception will occur. The 36-bit VPN is translated into a
-44-bit PPN via a four-level page table, while the 12-bit page offset
-is untranslated.
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}O@{}O@{}O@{}O@{}O}
-\instbitrange{47}{39} &
-\instbitrange{38}{30} &
-\instbitrange{29}{21} &
-\instbitrange{20}{12} &
-\instbitrange{11}{0} \\
-\hline
-\multicolumn{1}{|c|}{VPN[3]} &
-\multicolumn{1}{c|}{VPN[2]} &
-\multicolumn{1}{c|}{VPN[1]} &
-\multicolumn{1}{c|}{VPN[0]} &
-\multicolumn{1}{c|}{page offset} \\
-\hline
-9 & 9 & 9 & 9 & 12 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv48 virtual address.}
-\label{sv48va}
-\end{figure*}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}E@{}O@{}O@{}O@{}O}
-\instbitrange{55}{39} &
-\instbitrange{38}{30} &
-\instbitrange{29}{21} &
-\instbitrange{20}{12} &
-\instbitrange{11}{0} \\
-\hline
-\multicolumn{1}{|c|}{PPN[3]} &
-\multicolumn{1}{c|}{PPN[2]} &
-\multicolumn{1}{c|}{PPN[1]} &
-\multicolumn{1}{c|}{PPN[0]} &
-\multicolumn{1}{c|}{page offset} \\
-\hline
-17 & 9 & 9 & 9 & 12 \\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv48 physical address.}
-\label{sv48pa}
-\end{figure*}
-
-\begin{figure*}[h!]
-{\footnotesize
-\begin{center}
-\begin{tabular}{@{}Y@{}Y@{}Y@{}Y@{}Y@{}Fcccccccc}
-\instbitrange{63}{54} &
-\instbitrange{53}{37} &
-\instbitrange{36}{28} &
-\instbitrange{27}{19} &
-\instbitrange{18}{10} &
-\instbitrange{9}{8} &
-\instbit{7} &
-\instbit{6} &
-\instbit{5} &
-\instbit{4} &
-\instbit{3} &
-\instbit{2} &
-\instbit{1} &
-\instbit{0} \\
-\hline
-\multicolumn{1}{|c|}{\it Reserved} &
-\multicolumn{1}{c|}{PPN[3]} &
-\multicolumn{1}{c|}{PPN[2]} &
-\multicolumn{1}{c|}{PPN[1]} &
-\multicolumn{1}{c|}{PPN[0]} &
-\multicolumn{1}{c|}{RSW} &
-\multicolumn{1}{c|}{D} &
-\multicolumn{1}{c|}{A} &
-\multicolumn{1}{c|}{G} &
-\multicolumn{1}{c|}{U} &
-\multicolumn{1}{c|}{X} &
-\multicolumn{1}{c|}{W} &
-\multicolumn{1}{c|}{R} &
-\multicolumn{1}{c|}{V} \\
-\hline
-10 & 17 & 9 & 9 & 9 & 2 & 1 & 1 & 1 & 1 & 1 & 1 & 1 & 1\\
-\end{tabular}
-\end{center}
-}
-\vspace{-0.1in}
-\caption{Sv48 page table entry.}
-\label{sv48pte}
-\end{figure*}
-
-The PTE format for Sv48 is shown in Figure~\ref{sv48pte}. Bits 9--0
-have the same meaning as for Sv32. Any level of PTE may be a leaf
-PTE, so in addition to \wunits{4}{KiB} pages, Sv48 supports
-\wunits{2}{MiB} {\em megapages}, \wunits{1}{GiB} {\em gigapages}, and
-\wunits{512}{GiB} {\em terapages}, each of which must be virtually and
-physically aligned to a boundary equal to its size.
-A page-fault exception is raised if the physical address is insufficiently
-aligned.
-
-The algorithm for virtual-to-physical address translation is the same
-as in Section~\ref{sv32algorithm}, except LEVELS equals 4 and PTESIZE
-equals 8.
diff --git a/src/svgnam.def b/src/svgnam.def
index a947636..dcd8115 100644
--- a/src/svgnam.def
+++ b/src/svgnam.def
@@ -5,17 +5,17 @@
%% The original source files were:
%%
%% xcolor.dtx (with options: `svgnames')
-%%
+%%
%% IMPORTANT NOTICE:
-%%
+%%
%% For the copyright see the source file.
-%%
+%%
%% Any modified versions of this file must be renamed
%% with new filenames distinct from svgnam.def.
-%%
+%%
%% For distribution of the original source see the terms
%% for copying and modification in the file xcolor.dtx.
-%%
+%%
%% This generated file may be distributed as long as the
%% original source files, as listed above, are part of the
%% same distribution. (The sources need not necessarily be
diff --git a/src/t.tex b/src/t.tex
deleted file mode 100644
index d7f8efa..0000000
--- a/src/t.tex
+++ /dev/null
@@ -1,16 +0,0 @@
-\chapter{``T'' Standard Extension for Transactional Memory, Version 0.0}
-\label{sec:tm}
-
-This chapter is a placeholder for a future standard extension to
-provide transactional memory operations.
-
-\begin{commentary}
-Despite much research over the last twenty years, and initial
-commercial implementations, there is still much debate on the best way
-to support atomic operations involving multiple addresses.
-
-Our current thoughts are to include a small limited-capacity
-transactional memory buffer along the lines of the original
-transactional memory proposals.
-\end{commentary}
-
diff --git a/src/unpriv-cfi.adoc b/src/unpriv-cfi.adoc
new file mode 100644
index 0000000..c76a935
--- /dev/null
+++ b/src/unpriv-cfi.adoc
@@ -0,0 +1,877 @@
+== Control-flow Integrity (CFI)
+
+Control-flow Integrity (CFI) capabilities help defend against Return-Oriented
+Programming (ROP) and Call/Jump-Oriented Programming (COP/JOP) style
+control-flow subversion attacks. These attack methodologies use code sequences
+in authorized modules, with at least one instruction in the sequence being a
+control transfer instruction that depends on attacker-controlled data either in
+the return stack or in memory used to obtain the target address for a call or
+jump. Attackers stitch these sequences together by diverting the control flow
+instructions (e.g., `JALR`, `C.JR`, `C.JALR`), from their original target
+address to a new target via modification in the return stack or in the memory
+used to obtain the jump/call target address.
+
+RV32/RV64 provides two types of control transfer instructions - unconditional
+jumps and conditional branches. Conditional branches encode an offset in the
+immediate field of the instruction and are thus direct branches that are not
+susceptible to control-flow subversion. Unconditional direct jumps using `JAL`
+transfer control to a target that is in a +/- 1 MiB range from the current `pc`.
+Unconditional indirect jumps using the `JALR` obtain their branch target by
+adding the sign extended 12-bit immediate encoded in the instruction to the
+`rs1` register.
+
+The RV32I/RV64I does not have a dedicated instruction for calling a procedure or
+returning from a procedure. A `JAL` or `JALR` may be used to perform a procedure
+call and `JALR` to return from a procedure. The RISC-V ABI however defines the
+convention that a `JAL`/`JALR` where `rd` (i.e. the link register) is `x1` or
+`x5` is a procedure call, and a `JALR` where `rs1` is the conventional
+link register (i.e. `x1` or `x5`) is a return from procedure. The architecture
+allows for using these hints and conventions to support return address
+prediction (See <<rashints>>).
+
+The RVC standard extension for compressed instructions provides unconditional
+jump and conditional branch instructions. The `C.J` and `C.JAL` instructions
+encode an offset in the immediate field of the instruction and thus are not
+susceptible to control-flow subversion. The `C.JR` and `C.JALR` RVC instructions
+perform an unconditional control transfer to the address in register `rs1`. The
+`C.JALR` additionally writes the address of the instruction following the jump
+(`pc+2`) to the link register `x1` and is a procedure call. The `C.JR` is a
+return from procedure if `rs1` is a conventional link register (i.e. `x1` or
+`x5`); else it is an indirect jump.
+
+The term _call_ is used to refer to a `JAL` or `JALR` instruction with a link
+register as destination, i.e., _rd_≠`x0`. Conventionally, the link register is
+`x1` or `x5`. A _call_ using `JAL` or `C.JAL` is termed a direct call. A
+`C.JALR` expands to `JALR x1, 0(rs1)` and is a _call_. A _call_ using `JALR` or
+`C.JALR` is termed an _indirect-call_.
+
+The term _return_ is used to refer to a `JALR` instruction with _rd_=`x0` and
+with _rs1_=`x1` or _rs1_=`x5`. A `C.JR` instruction expands to
+`JALR x0, 0(rs1)` and is a _return_ if _rs1_=`x1` or _rs1_=`x5`.
+
+The term _indirect-jump_ is used to refer to a `JALR` instruction with _rd_=`x0`
+and where the _rs1_ is not `x1` or `x5` (i.e., not a return). A `C.JR`
+instruction where _rs1_ is not `x1` or `x5` (i.e., not a return) is an
+_indirect-jump_.
+
+The Zicfiss and Zicfilp extensions build on these conventions and hints and
+provide backward-edge and forward-edge control flow integrity respectively.
+
+The Unprivileged ISA for Zicfilp extension is specified in <<unpriv-forward>>
+and for the Unprivileged ISA for Zicfiss extension is specified in
+<<unpriv-backward>>. The Privileged ISA for these extensions is specified in the
+Privileged ISA specification.
+
+[[unpriv-forward]]
+=== Landing Pad (Zicfilp)
+
+To enforce forward-edge control-flow integrity, the Zicfilp extension introduces
+a landing pad (`LPAD`) instruction. The `LPAD` instruction must be placed at the
+program locations that are valid targets of indirect jumps or calls. The `LPAD`
+instruction (See <<LP_INST>>) is encoded using the `AUIPC` major opcode with
+_rd_=`x0`.
+
+Compilers emit a landing pad instruction as the first instruction of an
+address-taken function, as well as at any indirect jump targets. A landing pad
+instruction is not required in functions that are only reached using a direct
+call or direct jump.
+
+The landing pad is designed to provide integrity to control transfers performed
+using indirect calls and jumps, and this is referred to as forward-edge
+protection. When the Zicfilp is active, the hart tracks an expected landing pad
+(`ELP`) state that is updated by an _indirect_call_ or _indirect_jump_ to
+require a landing pad instruction at the target of the branch. If the
+instruction at the target is not a landing pad, then a software-check exception
+is raised.
+
+A landing pad may be optionally associated with a 20-bit label. With labeling
+enabled, the number of landing pads that can be reached from an indirect call
+or jump sites can be defined using programming language-based policies. Labeling
+of the landing pads enables software to achieve greater precision in pairing up
+indirect call/jump sites with valid targets. When labeling of landing pads
+is used, indirect call or indirect jump site can specify the expected label of
+the landing pad and thereby constrain the set of landing pads that may be
+reached from each indirect call or indirect jump site in the program.
+
+In the simplest form, a program can be built with a single label value to
+implement a coarse-grained version of forward-edge control-flow integrity. By
+constraining gadgets to be preceded by a landing pad instruction that marks
+the start of indirect callable functions, the program can significantly reduce
+the available gadget space. A second form of label generation may generate a
+signature, such as a MAC, using the prototype of the function. Programs that use
+this approach would further constrain the gadgets accessible from a call site to
+only indirectly callable functions that match the prototype of the called
+functions. Another approach to label generation involves analyzing the
+control-flow-graph (CFG) of the program, which can lead to even more stringent
+constraints on the set of reachable gadgets. Such programs may further use
+multiple labels per function, which means that if a function is called from two
+or more call sites, the functions can be labeled as being reachable from each of
+the call sites. For instance, consider two call sites A and B, where A calls the
+functions X and Y, and B calls the functions Y and Z. In a single label scheme,
+functions X, Y, and Z would need to be assigned the same label so that both call
+sites A and B can invoke the common function Y. This scheme would allow call
+site A to also call function Z and call site B to also call function X. However,
+if function Y was assigned two labels - one corresponding to call site A and the
+other to call site B, then Y can be invoked by both call sites, but X can only be
+invoked by call site A and Z can only be invoked by call site B. To support
+multiple labels, the compiler could generate a call-site-specific entry point
+for shared functions, with each entry point having its own landing pad
+instruction followed by a direct branch to the start of the function. This would
+allow the function to be labeled with multiple labels, each corresponding to a
+specific call site. A portion of the label space may be dedicated to labeled
+landing pads that are only valid targets of an indirect jump (and not an
+indirect call).
+
+The `LPAD` instruction uses the code points defined as HINTs for the `AUIPC`
+opcode. When Zicfilp is not active at a privilege level or when the extension
+is not implemented, the landing pad instruction executes as a no-op. A program
+that is built with `LPAD` instructions can thus continue to operate correctly,
+but without forward-edge control-flow integrity, on processors that do not
+support the Zicfilp extension or if the Zicfilp extension is not active.
+
+Compilers and linkers should provide an attribute flag to indicate if the
+program has been compiled with the Zicfilp extension and use that to determine
+if the Zicfilp extension should be activated. The dynamic loader should activate
+the use of Zicfilp extension for an application only if all executables (the
+application and the dependent dynamically linked libraries) used by that
+application use the Zicfilp extension.
+
+When Zicfilp extension is not active or not implemented, the hart does not
+require landing pad instructions at the targets of indirect calls/jumps, and the
+landing instructions revert to being no-ops. This allows a program compiled
+with landing pad instructions to operate correctly but without forward-edge
+control-flow integrity.
+
+The Zicfilp extensions may be activated for use individually and independently
+for each privilege mode.
+
+The Zicfilp extension depends on the Zicsr extension.
+
+==== Landing Pad Enforcement
+
+To enforce that the target of an indirect call or indirect jump must be a valid
+landing pad instruction, the hart maintains an expected landing pad (`ELP`) state
+to determine if a landing pad instruction is required at the target of an
+indirect call or an indirect jump. The `ELP` state can be one of:
+
+* 0 - `NO_LP_EXPECTED`
+* 1 - `LP_EXPECTED`
+
+The `ELP` state is initialized to `NO_LP_EXPECTED` by the hart upon reset.
+
+The Zicfilp extension, when enabled, determines if an indirect call or an
+indirect jump must land on a landing pad, as specified in <<IND_CALL_JMP>>. If
+`is_lp_expected` is 1, then the hart updates the `ELP` to `LP_EXPECTED`.
+
+[[IND_CALL_JMP]]
+.Landing pad expected determination
+[listing]
+----
+ is_lp_expected = ( (JALR || C.JR || C.JALR) &&
+ (rs1 != x1) && (rs1 != x5) && (rs1 != x7) ) ? 1 : 0;
+----
+
+An indirect branch using `JALR`, `C.JALR`, or `C.JR` with `rs1` as `x7` is
+termed a software guarded branch. Such branches do not need to land on a
+`LPAD` instruction and thus do not set `ELP` to `LP_EXPECTED`.
+
+[NOTE]
+====
+When the register source is a link register and the register destination is
+`x0`, then it's a return from a procedure and does not require a landing pad at
+the target.
+
+When the register source and register destination are both link registers, then
+it is a semantically-direct-call. For example, the `call offset`
+pseudoinstruction may expand to a two instruction sequence composed of a
+`lui ra, imm20` or a `auipc ra, imm20` instruction followed by a
+`jalr ra, imm12(ra)` instruction where `ra` is the link register (either `x1` or
+`x5`). Since the address of the procedure was not explicitly taken and the
+computed address is not obtained from mutable memory, such semantically-direct
+calls do not require a landing pad to be placed at the target. Compilers and
+JITers must use the semantically-direct calls only if the `rs1` was computed as
+a PC-relative or an absolute offset to the symbol.
+
+The `tail offset` pseudoinstruction used to tail call a far-away procedure may
+also be expanded to a two instruction sequence composed of a `lui x7, imm20` or
+`auipc x7, imm20` followed by a `jalr x0, x7`. Since the address of the
+procedure was not explicitly taken and the computed address is not obtained from
+mutable memory, such semantically-direct tail-calls do not require a landing pad
+to be placed at the target.
+
+Software guarded branches may also be used by compilers to generate code for
+constructs like switch-cases. When using the software guarded branches, the
+compiler is required to ensure it has full control on the possible jump
+targets (e.g., by obtaining the targets from a read-only table in memory and
+performing bounds checking on the index into the table, etc.).
+====
+
+The landing pad may be labeled. Zicfilp extension designates the register `x7`
+for use as the landing pad label register. To support labeled landing pads, the
+indirect call/jump sites establish an expected landing pad label (e.g., using
+the `LUI` instruction) in the bits 31:12 of the `x7` register. The `LPAD`
+instruction is encoded with a 20-bit immediate value called the landing-pad-label
+(`LPL`) that is matched to the expected landing pad label. When `LPL` is encoded
+as zero, the `LPAD` instruction does not perform the label check and in programs
+built with this single label mode of operation the indirect call/jump sites do
+not need to establish an expected landing pad label value in `x7`.
+
+When `ELP` is set to `LP_EXPECTED`, if the next instruction in the instruction
+stream is not 4-byte aligned, or is not `LPAD`, or if the landing pad label
+encoded in `LPAD` is not zero and does not match the expected landing pad label
+in bits 31:12 of the `x7` register, then a software-check exception (cause=18)
+with `__x__tval` set to "landing pad fault (code=2)" is raised else the `ELP` is
+updated to `NO_LP_EXPECTED`.
+
+[NOTE]
+====
+The tracking of `ELP` and the requirement for a landing pad instruction
+at the target of indirect call and jump enables a processor implementation to
+significantly reduce or to prevent speculation to non-landing-pad instructions.
+Constraining speculation using this technique, greatly reduces the gadget space
+and increases the difficulty of using techniques such as branch-target-injection,
+also known as Spectre variant 2, which use speculative execution to leak data
+through side channels.
+
+The `LPAD` requires a 4-byte alignment to address the concatenation of two
+instructions `A` and `B` accidentally forming an unintended landing pad in the
+program. For example, consider a 32-bit instruction where the bytes 3 and 2 have
+a pattern of `?017h` (for example, the immediate fields of a `LUI`, `AUIPC`, or
+a `JAL` instruction), followed by a 16-bit or a 32-bit instruction. When
+patterns that can accidentally form a valid landing pad are detected, the
+assembler or linker can force instruction `A` to be aligned to a 4-byte
+boundary to force the unintended `LPAD` pattern to become misaligned, and thus
+not a valid landing pad, or may use an alternate register allocation to prevent
+the accidental landing pad.
+====
+
+<<<
+
+[[LP_INST]]
+==== Landing Pad Instruction
+
+When Zicfilp is enabled, `LPAD` is the only instruction allowed to execute when
+the `ELP` state is `LP_EXPECTED`. If Zicfilp is not enabled then the instruction
+is a no-op. If Zicfilp is enabled, the `LPAD` instruction causes a
+software-check exception with `__x__tval` set to "landing pad fault (code=2)" if
+any of the following conditions are true:
+
+* The `pc` is not 4-byte aligned and `ELP` is `LP_EXPECTED`.
+* The `ELP` is `LP_EXPECTED` and the `LPL` is not zero and the `LPL` does not
+ match the expected landing pad label in bits 31:12 of the `x7` register.
+
+If a software-check exception is not caused then the `ELP` is updated to
+`NO_LP_EXPECTED`.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr:'AUIPC'},
+ {bits: 5, name: 'rd', attr:'00000'},
+ {bits: 20, name: 'LPL'},
+], config:{lanes: 1, hspace:1024}}
+....
+
+The operation of the `LPAD` instruction is as follows:
+
+.`LPAD` operation
+[listing]
+----
+if (xLPE == 1 && ELP == LP_EXPECTED)
+ // If PC not 4-byte aligned then software-check exception
+ if pc[1:0] != 0
+ raise software-check exception
+ // If landing pad label not matched -> software-check exception
+ else if (inst.LPL != x7[31:12] && inst.LPL != 0)
+ raise software-check exception
+ else
+ ELP = NO_LP_EXPECTED
+else
+ no-op
+endif
+----
+
+<<<
+
+[[unpriv-backward]]
+=== Shadow Stack (Zicfiss)
+
+The Zicfiss extension introduces a shadow stack to enforce backward-edge
+control-flow integrity. A shadow stack is a second stack used to store a
+shadow copy of the return address in the link register if it needs to be
+spilled.
+
+The shadow stack is designed to provide integrity to control transfers performed
+using a _return_, where the return may be from a procedure invoked using an
+indirect call or a direct call, and this is referred to as backward-edge
+protection.
+
+A program using backward-edge control-flow integrity has two stacks: a regular
+stack and a shadow stack. The shadow stack is used to spill the link register,
+if required, by non-leaf functions. An additional register, shadow-stack-pointer
+(`ssp`), is introduced in the architecture to hold the address of the top of the
+active shadow stack.
+
+The shadow stack, similar to the regular stack, grows downwards, from
+higher addresses to lower addresses. Each entry on the shadow stack is `XLEN`
+wide and holds the link register value. The `ssp` points to the top of the
+shadow stack, which is the address of the last element stored on the shadow
+stack.
+
+The shadow stack is architecturally protected from inadvertent corruptions and
+modifications, as detailed in the Privileged specification.
+
+The Zicfiss extension provides instructions to store and load the link register
+to/from the shadow stack and to check the integrity of the return address. The
+extension provides instructions to support common stack maintenance operations
+such as stack unwinding and stack switching.
+
+When Zicfiss is enabled, each function that needs to spill the link register,
+typically non-leaf functions, store the link register value to the regular stack
+and a shadow copy of the link register value to the shadow stack when the
+function is entered (the prologue). When such a function returns (the
+epilogue), the function loads the link register from the regular stack and
+the shadow copy of the link register from the shadow stack. Then, the link
+register value from the regular stack and the shadow link register value from
+the shadow stack are compared. A mismatch of the two values is indicative of a
+subversion of the return address control variable and causes a software-check
+exception.
+
+The Zicfiss instructions, except `SSAMOSWAP.W/D`, are encoded using a subset of
+May-Be-Operation instructions defined by the Zimop and Zcmop extensions.
+This subset of instructions revert to their Zimop/Zcmop defined behavior when
+the Zicfiss extension is not implemented or if the extension has not been
+activated. A program that is built with Zicfiss instructions can thus continue
+to operate correctly, but without backward-edge control-flow integrity, on
+processors that do not support the Zicfiss extension or if the Zicfiss extension
+is not active. The Zicfiss extension may be activated for use individually and
+independently for each privilege mode.
+
+Compilers should flag each object file (for example, using flags in the ELF
+attributes) to indicate if the object file has been compiled with the Zicfiss
+instructions. The linker should flag (for example, using flags in the ELF
+attributes) the binary/executable generated by linking objects as being
+compiled with the Zicfiss instructions only if all the object files that are
+linked have the same Zicfiss attributes.
+
+The dynamic loader should activate the use of Zicfiss extension for an
+application only if all executables (the application and the dependent
+dynamically-linked libraries) used by that application use the Zicfiss
+extension.
+
+<<<
+
+An application that has the Zicfiss extension active may request the dynamic
+loader at runtime to load a new dynamic shared object (using dlopen() for
+example). If the requested object does not have the Zicfiss attribute then
+the dynamic loader, based on its policy (e.g., established by the operating
+system or the administrator) configuration, could either deny the request or
+deactivate the Zicfiss extension for the application. It is strongly recommended
+that the policy enforces a strict security posture and denies the request.
+
+The Zicfiss extension depends on the Zicsr and Zimop extensions. Furthermore,
+if the Zcmop extension is implemented, the Zicfiss extension also provides the
+`C.SSPUSH` and `C.SSPOPCHK` instructions. Moreover, use of Zicfiss in U-mode
+requires S-mode to be implemented. Use of Zicfiss in M-mode is not supported.
+
+==== Zicfiss Instructions Summary
+
+The Zicfiss extension introduces the following instructions:
+
+* Push to the shadow stack (See <<SS_PUSH>>)
+** `SSPUSH x1` and `SSPUSH x5` - encoded using `MOP.RR.7`
+** `C.SSPUSH x1` - encoded using `C.MOP.1`
+
+* Pop from the shadow stack (See <<SS_POP>>)
+** `SSPOPCHK x1` and `SSPOPCHK x5` - encoded using `MOP.R.28`
+** `C.SSPOPCHK x5` - encoded using `C.MOP.5`
+
+* Read the value of `ssp` into a register (See <<SSP_READ>>)
+** `SSRDP` - encoded using `MOP.R.28`
+
+* Perform an atomic swap from a shadow stack location (See <<SSAMOSWAP>>)
+** `SSAMOSWAP.W` and `SSAMOSWAP.D`
+
+Zicfiss does not use all encodings of `MOP.RR.7` or `MOP.R.28`. When a
+`MOP.RR.7` or `MOP.R.28` encoding is not used by the Zicfiss extension, the
+corresponding instruction adheres to its Zimop-defined behavior, unless
+redefined by another extension.
+
+==== Shadow Stack Pointer (`ssp`)
+
+The `ssp` CSR is an unprivileged read-write (URW) CSR that reads and writes
+`XLEN` low order bits of the shadow stack pointer (`ssp`). The CSR address is
+0x011. There is no high CSR defined as the `ssp` is always as wide as the `XLEN`
+of the current privilege mode. The bits 1:0 of `ssp` are read-only zero. If the
+UXLEN or SXLEN may never be 32, then the bit 2 is also read-only zero.
+
+<<<
+
+==== Zicfiss Instructions
+
+[[SS_PUSH]]
+==== Push to the Shadow Stack
+A shadow stack push operation is defined as decrement of the `ssp` by `XLEN/8`
+followed by a store of the value in the link register to memory at the new top
+of the shadow stack.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr:'SYSTEM'},
+ {bits: 5, name: 'rd', attr:['00000']},
+ {bits: 3, name: 'funct3', attr:['100']},
+ {bits: 5, name: 'rs1', attr:['00000']},
+ {bits: 5, name: 'rs2', attr:['00001', '00101']},
+ {bits: 7, name: '1100111', attr:['SSPUSH x1','SSPUSH x5']},
+], config:{lanes: 1, hspace:1024}}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr:'C1'},
+ {bits: 5, name: '00000'},
+ {bits: 1, name: '1'},
+ {bits: 3, name: 'n[3:1]', attr:['000']},
+ {bits: 1, name: '0'},
+ {bits: 1, name: '0'},
+ {bits: 3, name: '011', attr:['C.SSPUSH x1']},
+], config:{lanes: 1, hspace:1024}}
+....
+
+Only `x1` and `x5` registers are supported as `rs2` for `SSPUSH`. Zicfiss
+provides a 16-bit version of the `SSPUSH x1` instruction using the Zcmop
+defined `C.MOP.1` encoding. The `C.SSPUSH x1` expands to `SSPUSH x1`.
+
+The `SSPUSH` instruction and its compressed form `C.SSPUSH` can be used to push
+a link register on the shadow stack. The `SSPUSH` and `C.SSPUSH` instructions
+perform a store identically to the existing store instructions, with the
+difference that the base is implicitly `ssp` and the width is implicitly `XLEN`.
+
+The operation of the `SSPUSH` and `C.SSPUSH` instructions is as follows:
+
+.`SSPUSH` and `C.SSPUSH` operation
+[listing]
+----
+if (xSSE == 1)
+ mem[ssp - (XLEN/8)] = X(src) # Store src value to ssp - XLEN/8
+ ssp = ssp - (XLEN/8) # decrement ssp by XLEN/8
+endif
+----
+
+The `ssp` is decremented by `SSPUSH` and `C.SSPUSH` only if the store to the
+shadow stack completes successfully.
+
+<<<
+
+[[SS_POP]]
+==== Pop from the Shadow Stack
+
+A shadow stack pop operation is defined as an `XLEN` wide read from the
+current top of the shadow stack followed by an increment of the `ssp` by
+`XLEN/8`.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr:'SYSTEM'},
+ {bits: 5, name: 'rd', attr:['00000','00000']},
+ {bits: 3, name: 'funct3', attr:['100']},
+ {bits: 5, name: 'rs1', attr:['00001','00101']},
+ {bits: 12, name: '110011011100', attr:['SSPOPCHK x1','SSPOPCHK x5']},
+], config:{lanes: 1, hspace:1024}}
+....
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 'op', attr:'C1'},
+ {bits: 5, name: '00000'},
+ {bits: 1, name: '1'},
+ {bits: 3, name: 'n[3:1]', attr:['010']},
+ {bits: 1, name: '0'},
+ {bits: 1, name: '0'},
+ {bits: 3, name: '011', attr:['C.SSPOPCHK x5']},
+], config:{lanes: 1, hspace:1024}}
+....
+
+Only `x1` and `x5` registers are supported as `rs1` for `SSPOPCHK`. Zicfiss
+provides a 16-bit version of the `SSPOPCHK x5` using the Zcmop defined `C.MOP.5`
+encoding. The `C.SSPOPCHK x5` expands to `SSPOPCHK x5`.
+
+Programs with a shadow stack push the return address onto the regular stack as
+well as the shadow stack in the prologue of non-leaf functions. When returning
+from these non-leaf functions, such programs pop the link register from the
+regular stack and pop a shadow copy of the link register from the shadow stack.
+The two values are then compared. If the values do not match, it is indicative
+of a corruption of the return address variable on the regular stack.
+
+The `SSPOPCHK` instruction, and its compressed form `C.SSPOPCHK`, can be used to
+pop the shadow return address value from the shadow stack and check that the
+value matches the contents of the link register, and if not cause a
+software-check exception with `__x__tval` set to "shadow stack fault (code=3)".
+
+While any register may be used as link register, conventionally the `x1` or `x5`
+registers are used. The shadow stack instructions are designed to be most
+efficient when the `x1` and `x5` registers are used as the link register.
+
+[NOTE]
+====
+Return-address prediction stacks are a common feature of high-performance
+instruction-fetch units, but they require accurate detection of instructions
+used for procedure calls and returns to be effective. For RISC-V, hints as to
+the instructions' usage are encoded implicitly via the register numbers used.
+The return-address stack (RAS) actions to pop and/or push onto the RAS are
+specified in <<rashints>>.
+
+Using `x1` or `x5` as the link register allows a program to benefit from the
+return-address prediction stacks. Additionally, since the shadow stack
+instructions are designed around the use of `x1` or `x5` as the link register,
+using any other register as a link register would incur the cost of additional
+register movements.
+
+Compilers, when generating code with backward-edge CFI, must protect the link
+register, e.g., `x1` and/or `x5`, from arbitrary modification by not emitting
+unsafe code sequences.
+====
+
+<<<
+
+[NOTE]
+====
+Storing the return address on both stacks preserves the call stack layout and
+the ABI, while also allowing for the detection of corruption of the return
+address on the regular stack. The prologue and epilogue of a non-leaf function
+that uses shadow stacks is as follows:
+
+[listing]
+----
+ function_entry:
+ addi sp,sp,-8 # push link register x1
+ sd x1,(sp) # on regular stack
+ sspush x1 # push link register x1 on shadow stack
+ :
+ ld x1,(sp) # pop link register x1 from regular stack
+ addi sp,sp,8
+ sspopchk x1 # fault if x1 not equal to shadow
+ # return address
+ ret
+----
+
+This example illustrates the use of `x1` register as the link register.
+Alternatively, the `x5` register may also be used as the link register.
+
+A leaf function, a function that does not itself make function calls, does
+not need to spill the link register. Consequently, the return value may be held
+in the link register itself for the duration of the leaf function's execution.
+====
+
+The `C.SSPOPCHK`, and `SSPOPCHK` instructions perform a load identically to the
+existing load instructions, with the difference that the base is implicitly
+`ssp` and the width is implicitly `XLEN`.
+
+The operation of the `SSPOPCHK` and `C.SSPOPCHK` instructions is as follows:
+
+.`SSPOPCHK` and `C.SSPOPCHK` operation
+[listing]
+----
+if (xSSE == 1)
+ temp = mem[ssp] # Load temp from address in ssp and
+ if temp != X(src) # Compare temp to value in src and
+ # cause an software-check exception
+ # if they are not bitwise equal.
+ # Only x1 and x5 may be used as src
+ raise software-check exception
+ else
+ ssp = ssp + (XLEN/8) # increment ssp by XLEN/8.
+ endif
+endif
+----
+
+If the value loaded from the address in `ssp` does not match the value in `rs1`,
+a software-check exception (cause=18) is raised with `__x__tval` set to "shadow
+stack fault (code=3)". The software-check exception caused by `SSPOPCHK`/
+`C.SSPOPCHK` is lower in priority than a load/store/AMO access-fault exception.
+
+The `ssp` is incremented by `SSPOPCHK` and `C.SSPOPCHK` only if the load from
+the shadow stack completes successfully and no software-check exception is
+raised.
+
+<<<
+
+[NOTE]
+====
+The use of the compressed instruction `C.SSPUSH x1` to push on the shadow stack
+is most efficient when the ABI uses `x1` as the link register, as the link
+register may then be pushed without needing a register-to-register move in the
+function prologue. To use the compressed instruction `C.SSPOPCHK x5`, the
+function should pop the return address from regular stack into the alternate
+link register `x5` and use the `C.SSPOPCHK x5` to compare the return address to
+the shadow copy stored on the shadow stack. The function then uses `C.JR x5` to
+jump to the return address.
+
+[listing]
+----
+ function_entry:
+ c.addi sp,sp,-8 # push link register x1
+ c.sd x1,(sp) # on regular stack
+ c.sspush x1 # push link register x1 on shadow stack
+ :
+ c.ld x5,(sp) # pop link register x5 from regular stack
+ c.addi sp,sp,8
+ c.sspopchk x5 # fault if x5 not equal to shadow return address
+ c.jr x5
+----
+
+====
+
+[NOTE]
+====
+Store-to-load forwarding is a common technique employed by high-performance
+processor implementations. Zicfiss implementations may prevent forwarding from
+a non-shadow-stack store to the `SSPOPCHK` or the `C.SSPOPCHK` instructions. A
+non-shadow-stack store causes a fault if done to a page mapped as a shadow
+stack. However, such determination may be delayed till the PTE has been examined
+and thus may be used to transiently forward the data from such stores to
+`SSPOPCHK` or to `C.SSPOPCHK`.
+====
+
+<<<
+
+[[SSP_READ]]
+==== Read `ssp` into a Register
+
+The `SSRDP` instruction is provided to move the contents of `ssp` to a destination
+register.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr:'SYSTEM'},
+ {bits: 5, name: 'rd', attr:['dst']},
+ {bits: 3, name: 'funct3', attr:['100']},
+ {bits: 5, name: '00000'},
+ {bits: 12, name: '110011011100', attr:['SSRDP']},
+], config:{lanes: 1, hspace:1024}}
+....
+
+Encoding _rd_ as `x0` is not supported for `SSRDP`.
+
+The operation of the `SSRDP` instructions is as follows:
+
+.`SSRDP` operation
+[listing]
+----
+if (xSSE == 1)
+ X(dst) = ssp
+else
+ X(dst) = 0
+endif
+----
+
+[NOTE]
+====
+The property of Zimop writing 0 to the `rd` when the extension using Zimop is
+not implemented or not active may be used by to determine if Zicfiss extension
+is active. For example, functions that unwind shadow stacks may skip over the
+unwind actions by dynamically detecting if the Zicfiss extension is active.
+
+An example sequence such as the following may be used:
+
+[listing]
+ ssrdp t0 # mv ssp to t0
+ beqz t0, zicfiss_not_active # zero is not a valid shadow stack
+ # pointer by convention
+ # Zicfiss is active
+ :
+ :
+zicfiss_not_active:
+
+To assist with the use of such code sequences, operating systems and runtimes
+must not locate shadow stacks at address 0.
+====
+
+<<<
+
+[NOTE]
+====
+A common operation performed on stacks is to unwind them to support constructs
+like `setjmp`/`longjmp`, C++ exception handling, etc. A program that uses shadow
+stacks must unwind the shadow stack in addition to the stack used to store data.
+The unwind function must verify that it does not accidentally unwind past the
+bounds of the shadow stack. Shadow stacks are expected to be bounded on each end
+using guard pages. A guard page for a stack is a page that is not accessible by
+the process that owns the stack. To detect if the unwind occurs past the bounds
+of the shadow stack, the unwind may be done in maximal increments of 4 KiB,
+testing whether the `ssp` is still pointing to a shadow stack page or has
+unwound into the guard page. The following examples illustrate the use of shadow
+stack instructions to unwind a shadow stack. This example assumes that the
+`setjmp` function itself does not push on to the shadow stack (being a leaf
+function, it is not required to).
+
+[source,c]
+----
+setjmp() {
+ :
+ :
+ // read and save the shadow stack pointer to jmp_buf
+ asm("ssrdp %0" : "=r"(cur_ssp):);
+ jmp_buf->saved_ssp = cur_ssp;
+ :
+ :
+}
+longjmp() {
+ :
+ // Read current shadow stack pointer and
+ // compute number of call frames to unwind
+ asm("ssrdp %0" : "=r"(cur_ssp):);
+ // Skip the unwind if backward-edge CFI not active
+ asm("beqz %0, back_cfi_not_active" : "=r"(cur_ssp):);
+ // Unwind the frames in a loop
+ while ( jmp_buf->saved_ssp > cur_ssp ) {
+ // advance by a maximum of 4K at a time to avoid
+ // unwinding past bounds of the shadow stack
+ cur_ssp = ( (jmp_buf->saved_ssp - cur_ssp) >= 4096 ) ?
+ (cur_ssp + 4096) : jmp_buf->saved_ssp;
+ asm("csrw ssp, %0" : : "r" (cur_ssp));
+ // Test if unwound past the shadow stack bounds
+ asm("sspush x5");
+ asm("sspopchk x5");
+ }
+back_cfi_not_active:
+ :
+}
+----
+====
+
+<<<
+
+[[SSAMOSWAP]]
+==== Atomic Swap from a Shadow Stack Location
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr:'AMO'},
+ {bits: 5, name: 'rd', attr:'dest'},
+ {bits: 3, name: 'funct3', attr:['010', '011']},
+ {bits: 5, name: 'rs1', attr:'addr'},
+ {bits: 5, name: 'rs2', attr:'src'},
+ {bits: 1, name: 'rl'},
+ {bits: 1, name: 'aq'},
+ {bits: 5, name: '01001', attr:['SSAMOSWAP.W', 'SSAMOSWAP.D']},
+], config:{lanes: 1, hspace:1024}}
+....
+
+For RV32, `SSAMOSWAP.W` atomically loads a 32-bit data value from address of a
+shadow stack location in `rs1`, puts the loaded value into register `rd`, and
+stores the 32-bit value held in `rs2` to the original address in `rs1`.
+`SSAMOSWAP.D` (RV64 only) is similar to `SSAMOSWAP.W` but operates on 64-bit
+data values.
+
+.`SSAMOSWAP.W` for RV32 and `SSAMOSWAP.D` (RV64 only) operation
+[listing]
+----
+ if privilege_mode != M && menvcfg.SSE == 0
+ raise illegal-instruction exception
+ else if S-mode not implemented
+ raise illegal-instruction exception
+ else if privilege_mode == U && senvcfg.SSE == 0
+ raise illegal-instruction exception
+ else if privilege_mode == VS && henvcfg.SSE == 0
+ raise virtual-instruction exception
+ else if privilege_mode == VU && senvcfg.SSE == 0
+ raise virtual-instruction exception
+ else
+ X(rd) = mem[X(rs1)]
+ mem[X(rs1)] = X(rs2)
+ endif
+----
+
+For RV64, `SSAMOSWAP.W` atomically loads a 32-bit data value from address of a
+shadow stack location in `rs1`, sign-extends the loaded value and puts it in
+`rd`, and stores the lower 32 bits of the value held in `rs2` to the original
+address in `rs1`.
+
+.`SSAMOSWAP.W` for RV64
+[listing]
+----
+ if privilege_mode != M && menvcfg.SSE == 0
+ raise illegal-instruction exception
+ else if S-mode not implemented
+ raise illegal-instruction exception
+ else if privilege_mode == U && senvcfg.SSE == 0
+ raise illegal-instruction exception
+ else if privilege_mode == VS && henvcfg.SSE == 0
+ raise virtual-instruction exception
+ else if privilege_mode == VU && senvcfg.SSE == 0
+ raise virtual-instruction exception
+ else
+ temp[31:0] = mem[X(rs1)]
+ X(rd) = SignExtend(temp[31:0])
+ mem[X(rs1)] = X(rs2)[31:0]
+ endif
+----
+
+Just as for AMOs in the A extension, `SSAMOSWAP.W/D` requires that the address
+held in `rs1` be naturally aligned to the size of the operand (i.e., eight-byte
+aligned for __doublewords__, and four-byte aligned for __words__). The same
+exception options apply if the address is not naturally aligned.
+
+Just as for AMOs in the A extension, `SSAMOSWAP.W/D` optionally provides release
+consistency semantics, using the `aq` and `rl` bits, to help implement
+multiprocessor synchronization. An `SSAMOSWAP.W/D` operation has acquire
+semantics if `aq=1` and release semantics if `rl=1`.
+
+[NOTE]
+====
+Stack switching is a common operation in user programs as well as supervisor
+programs. When a stack switch is performed the stack pointer of the currently
+active stack is saved into a context data structure and the new stack is made
+active by loading a new stack pointer from a context data structure.
+
+When shadow stacks are active for a program, the program needs to additionally
+switch the shadow stack pointer. If the pointer to the top of the deactivated
+shadow stack is held in a context data structure, then it may be susceptible to
+memory corruption vulnerabilities. To protect the pointer value, the program may
+store it at the top of the deactivated shadow stack itself and thereby create a
+checkpoint. A legal checkpoint is defined as one that holds a value of `X`,
+where `X` is the address at which the checkpoint is positioned on the shadow
+stack.
+====
+
+[NOTE]
+====
+An example sequence to restore the shadow stack pointer from the new shadow
+stack and save the old shadow stack pointer on the old shadow stack is as
+follows:
+
+[listing]
+----
+# a0 hold pointer to top of new shadow stack to switch to
+stack_switch:
+ ssrdp ra
+ beqz ra, 2f # skip if Zicfiss not active
+ ssamoswap.d ra, x0, (a0) # ra=*[a0] and *[a0]=0
+ beq ra, a0, 1f # [a0] must be == [ra]
+ unimp # else crash
+1: addi ra, ra, XLEN/8 # pop the checkpoint
+ csrrw ra, ssp, ra # swap ssp: ra=ssp, ssp=ra
+ addi ra, ra, -(XLEN/8) # checkpoint = "old ssp - XLEN/8"
+ ssamoswap.d x0, ra, (ra) # Save checkpoint at "old ssp - XLEN/8"
+2:
+----
+
+This sequence uses the `ra` register. If the privilege mode at which this
+sequence is executed can be interrupted, then the trap handler should save the
+`ra` on the shadow stack itself. There it is guarded against tampering and
+can be restored prior to returning from the trap.
+
+When a new shadow stack is created by the supervisor, it needs to store a
+checkpoint at the highest address on that stack. This enables the shadow stack
+pointer to be switched using the process outlined in this note. The
+`SSAMOSWAP.W/D` instruction can be used to store this checkpoint. When the old
+value at the memory location operated on by `SSAMOSWAP.W/D` is not required,
+`rd` can be set to `x0`.
+====
diff --git a/src/v-instr-table.tex b/src/v-instr-table.tex
deleted file mode 100644
index 5a15c54..0000000
--- a/src/v-instr-table.tex
+++ /dev/null
@@ -1,733 +0,0 @@
-
-\newpage
-
-\begin{table}[p]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.4in}p{0.1in}p{0.3in}p{0.5in}p{0.5in}p{0.1in}p{0.3in}p{0.5in}p{0.7in}l}
-& & & & & & & & & \\
- &
-\instbitrange{31}{28} &
-\instbit{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbit{14} &
-\instbitrange{13}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\cline{2-10}
-
-
-&
-\multicolumn{9}{c}{} & \\
-&
-\multicolumn{9}{c}{\bf RV32V Standard Extension} & \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1000} &
-\multicolumn{2}{c|}{000} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VADD \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1000} &
-\multicolumn{2}{c|}{001} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSUB \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1001} &
-\multicolumn{2}{c|}{000} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSL \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1101} &
-\multicolumn{2}{c|}{000} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSR \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1111} &
-\multicolumn{2}{c|}{000} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VAND \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1110} &
-\multicolumn{2}{c|}{000} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VOR \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1100} &
-\multicolumn{2}{c|}{000} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VXOR \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1001} &
-\multicolumn{2}{c|}{100} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSEQ \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1001} &
-\multicolumn{2}{c|}{101} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSNE \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1001} &
-\multicolumn{2}{c|}{110} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSLT \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1001} &
-\multicolumn{2}{c|}{111} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSGE \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1011} &
-\multicolumn{2}{c|}{000} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VCLIP \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1011} &
-\multicolumn{2}{c|}{001} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VCVT \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1010} &
-\multicolumn{2}{c|}{111} &
-\multicolumn{1}{c|}{00001} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1100111} & VMPOP \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1010} &
-\multicolumn{2}{c|}{111} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1100111} & VMFIRST \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1010} &
-\multicolumn{2}{c|}{000} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{1100111} & VEXTRACT \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1011} &
-\multicolumn{2}{c|}{100} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VINSERT \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1100} &
-\multicolumn{2}{c|}{001} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VMERGE \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1100} &
-\multicolumn{2}{c|}{010} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSELECT \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1011} &
-\multicolumn{2}{c|}{010} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSLIDE \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1000} &
-\multicolumn{2}{c|}{100} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VDIV \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1000} &
-\multicolumn{2}{c|}{101} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VREM \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1000} &
-\multicolumn{2}{c|}{110} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VMUL \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1000} &
-\multicolumn{2}{c|}{111} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VMULH \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1000} &
-\multicolumn{2}{c|}{010} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VMIN \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1000} &
-\multicolumn{2}{c|}{011} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VMAX \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1001} &
-\multicolumn{2}{c|}{010} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSGNJ \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1001} &
-\multicolumn{2}{c|}{011} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSGNJN \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1001} &
-\multicolumn{2}{c|}{001} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSGNJX \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1100} &
-\multicolumn{2}{c|}{111} &
-\multicolumn{1}{c|}{00010} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSQRT \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1100} &
-\multicolumn{2}{c|}{111} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VCLASS \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{1100} &
-\multicolumn{2}{c|}{111} &
-\multicolumn{1}{c|}{00001} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VPOPC \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{0000} &
-\multicolumn{3}{c|}{imm[7:0]} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VADDI \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{0001} &
-\multicolumn{3}{c|}{imm[7:0]} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSLI \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{0101} &
-\multicolumn{3}{c|}{imm[7:0]} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VSRI \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{0111} &
-\multicolumn{3}{c|}{imm[7:0]} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VANDI \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{0110} &
-\multicolumn{3}{c|}{imm[7:0]} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VORI \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{0100} &
-\multicolumn{3}{c|}{imm[7:0]} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VXORI \\
-\cline{2-10}
-
-
-&
-\multicolumn{1}{|c|}{0011} &
-\multicolumn{3}{c|}{imm[7:0]} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VCLIPI \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{00} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VMADD \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{01} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VMSUB \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{11} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VNMADD \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{10} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{vs1} &
-\multicolumn{1}{c|}{0} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{1100111} & VNMSUB \\
-\cline{2-10}
-
-
-\end{tabular}
-\end{center}
-\end{small}
-
-\end{table}
-
-
-\newpage
-
-\begin{table}[p]
-\begin{small}
-\begin{center}
-\begin{tabular}{p{0in}p{0.4in}p{0.1in}p{0.3in}p{0.5in}p{0.5in}p{0.1in}p{0.3in}p{0.5in}p{0.7in}l}
-& & & & & & & & & \\
- &
-\instbitrange{31}{28} &
-\instbit{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbit{14} &
-\instbitrange{13}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\cline{2-10}
-
-
-&
-\multicolumn{9}{c}{} & \\
-&
-\multicolumn{9}{c}{\bf RV32V Standard Extension (cont.)} & \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{imm[4:0]} &
-\multicolumn{1}{c|}{00} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{0000111} & VLD \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{imm[4:0]} &
-\multicolumn{1}{c|}{01} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{0000111} & VLDS \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{imm[4:0]} &
-\multicolumn{1}{c|}{10} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{0000111} & VLDX \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{00} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{0100111} & VST \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{01} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{0100111} & VSTS \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{10} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{imm[4:0]} &
-\multicolumn{1}{c|}{0100111} & VSTX \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{11} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{00001} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{0100111} & VAMOSWAP \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{11} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{00000} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{0100111} & VAMOADD \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{11} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{01100} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{0100111} & VAMOAND \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{11} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{01000} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{0100111} & VAMOOR \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{11} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{00100} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{0100111} & VAMOXOR \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{11} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{10000} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{0100111} & VAMOMIN \\
-\cline{2-10}
-
-
-&
-\multicolumn{2}{|c|}{vs3} &
-\multicolumn{1}{c|}{11} &
-\multicolumn{1}{c|}{vs2} &
-\multicolumn{1}{c|}{10100} &
-\multicolumn{1}{c|}{1} &
-\multicolumn{1}{c|}{m} &
-\multicolumn{1}{c|}{vd} &
-\multicolumn{1}{c|}{0100111} & VAMOMAX \\
-\cline{2-10}
-
-
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Instruction listing for RISC-V}
-\end{table}
-
diff --git a/src/v-st-ext.adoc b/src/v-st-ext.adoc
new file mode 100644
index 0000000..c25570b
--- /dev/null
+++ b/src/v-st-ext.adoc
@@ -0,0 +1,5322 @@
+[[vector]]
+== "V" Standard Extension for Vector Operations, Version 1.0
+
+[NOTE]
+====
+_The base vector extension is intended to provide general support for
+data-parallel execution within the 32-bit instruction encoding space,
+with later vector extensions supporting richer functionality for certain
+domains._
+====
+
+=== Introduction
+
+<<sec-vector-extensions>> lists the standard
+vector extensions and which instructions and element widths are
+supported by each extension.
+
+=== Implementation-defined Constant Parameters
+
+Each hart supporting a vector extension defines two parameters:
+
+. The maximum size in bits of a vector element that any operation can produce or consume, _ELEN_ {ge} 8, which
+must be a power of 2.
+. The number of bits in a single vector register, _VLEN_ {ge} ELEN, which must be a power of 2, and must be no greater than 2^16^.
+
+Standard vector extensions (<<sec-vector-extensions>>) and
+architecture profiles may set further constraints on _ELEN_ and _VLEN_.
+
+NOTE: Future extensions may allow ELEN {gt} VLEN by holding one
+element using bits from multiple vector registers, but this
+extension does not include this option.
+
+NOTE: The upper limit on VLEN allows software to know that indices
+will fit into 16 bits (largest VLMAX of 65,536 occurs for LMUL=8 and
+SEW=8 with VLEN=65,536). Any future extension beyond 64Kib per vector
+register will require new configuration instructions such that
+software using the old configuration instructions does not see greater
+vector lengths.
+
+The vector extension supports writing binary code that under certain
+constraints will execute portably on harts with different values for
+the VLEN parameter, provided the harts support the required element
+types and instructions.
+
+NOTE: Code can be written that will expose differences in
+implementation parameters.
+
+NOTE: In general, thread contexts with active vector state cannot be
+migrated during execution between harts that have any difference in
+VLEN or ELEN parameters.
+
+=== Vector Extension Programmer's Model
+
+The vector extension adds 32 vector registers, and seven unprivileged
+CSRs (`vstart`, `vxsat`, `vxrm`, `vcsr`, `vtype`, `vl`, `vlenb`) to a
+base scalar RISC-V ISA.
+
+.New vector CSRs
+[cols="2,2,2,10"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+| Address | Privilege | Name | Description
+
+| 0x008 | URW | vstart | Vector start element index
+| 0x009 | URW | vxsat | Fixed-Point Saturate Flag
+| 0x00A | URW | vxrm | Fixed-Point Rounding Mode
+| 0x00F | URW | vcsr | Vector control and status register
+| 0xC20 | URO | vl | Vector length
+| 0xC21 | URO | vtype | Vector data type register
+| 0xC22 | URO | vlenb | VLEN/8 (vector register length in bytes)
+|===
+
+NOTE: The four CSR numbers `0x00B`-`0x00E` are tentatively reserved
+for future vector CSRs, some of which may be mirrored into `vcsr`.
+
+==== Vector Registers
+
+The vector extension adds 32 architectural vector registers,
+`v0`-`v31` to the base scalar RISC-V ISA.
+
+Each vector register has a fixed VLEN bits of state.
+
+==== Vector Context Status in `mstatus`
+
+A vector context status field, `VS`, is added to `mstatus[10:9]` and shadowed
+in `sstatus[10:9]`. It is defined analogously to the floating-point context
+status field, `FS`.
+
+Attempts to execute any vector instruction, or to access the vector
+CSRs, raise an illegal-instruction exception when `mstatus.VS` is
+set to Off.
+
+When `mstatus.VS` is set to Initial or Clean, executing any
+instruction that changes vector state, including the vector CSRs, will
+change `mstatus.VS` to Dirty.
+Implementations may also change `mstatus.VS` from Initial or Clean to Dirty
+at any time, even when there is no change in vector state.
+
+NOTE: Accurate setting of `mstatus.VS` is an optimization. Software
+will typically use VS to reduce context-swap overhead.
+
+If `mstatus.VS` is Dirty, `mstatus.SD` is 1;
+otherwise, `mstatus.SD` is set in accordance with existing specifications.
+
+Implementations may have a writable `misa.V` field. Analogous to the
+way in which the floating-point unit is handled, the `mstatus.VS`
+field may exist even if `misa.V` is clear.
+
+NOTE: Allowing `mstatus.VS` to exist when `misa.V` is clear, enables
+vector emulation and simplifies handling of `mstatus.VS` in systems
+with writable `misa.V`.
+
+==== Vector Context Status in `vsstatus`
+
+When the hypervisor extension is present, a vector context status field, `VS`,
+is added to `vsstatus[10:9]`.
+It is defined analogously to the floating-point context status field, `FS`.
+
+When V=1, both `vsstatus.VS` and `mstatus.VS` are in effect: attempts to
+execute any vector instruction, or to access the vector CSRs, raise an
+illegal-instruction exception when either field is set to Off.
+
+When V=1 and neither `vsstatus.VS` nor `mstatus.VS` is set to Off, executing
+any instruction that changes vector state, including the vector CSRs, will
+change both `mstatus.VS` and `vsstatus.VS` to Dirty.
+Implementations may also change `mstatus.VS` or `vsstatus.VS` from Initial or
+Clean to Dirty at any time, even when there is no change in vector state.
+
+If `vsstatus.VS` is Dirty, `vsstatus.SD` is 1;
+otherwise, `vsstatus.SD` is set in accordance with existing specifications.
+
+If `mstatus.VS` is Dirty, `mstatus.SD` is 1;
+otherwise, `mstatus.SD` is set in accordance with existing specifications.
+
+For implementations with a writable `misa.V` field,
+the `vsstatus.VS` field may exist even if `misa.V` is clear.
+
+==== Vector Type (`vtype`) Register
+
+The read-only XLEN-wide _vector_ _type_ CSR, `vtype` provides the
+default type used to interpret the contents of the vector register
+file, and can only be updated by `vset{i}vl{i}` instructions. The
+vector type determines the organization of elements in each
+vector register, and how multiple vector registers are grouped. The
+`vtype` register also indicates how masked-off elements and elements
+past the current vector length in a vector result are handled.
+
+NOTE: Allowing updates only via the `vset{i}vl{i}` instructions
+simplifies maintenance of the `vtype` register state.
+
+The `vtype` register has five fields, `vill`, `vma`, `vta`,
+`vsew[2:0]`, and `vlmul[2:0]`. Bits `vtype[XLEN-2:8]` should be
+written with zero, and non-zero values in this field are reserved.
+
+include::images/wavedrom/vtype-format.edn[]
+
+NOTE: A small implementation supporting ELEN=32 requires only seven
+bits of state in `vtype`: two bits for `ma` and `ta`, two bits for
+`vsew[1:0]` and three bits for `vlmul[2:0]`. The illegal value
+represented by `vill` can be internally encoded using the illegal 64-bit
+combination in `vsew[1:0]` without requiring an additional storage
+bit to hold `vill`.
+
+NOTE: Further standard and custom vector extensions may extend these
+fields to support a greater variety of data types.
+
+NOTE: The primary motivation for the `vtype` CSR is to allow the
+vector instruction set to fit into a 32-bit instruction encoding
+space. A separate `vset{i}vl{i}` instruction can be used to set `vl`
+and/or `vtype` fields before execution of a vector instruction, and
+implementations may choose to fuse these two instructions into a single
+internal vector microop. In many cases, the `vl` and `vtype` values
+can be reused across multiple instructions, reducing the static and
+dynamic instruction overhead from the `vset{i}vl{i}` instructions. It
+is anticipated that a future extended 64-bit instruction encoding
+would allow these fields to be specified statically in the instruction
+encoding.
+
+===== Vector Selected Element Width (`vsew[2:0]`)
+
+The value in `vsew` sets the dynamic _selected_ _element_ _width_
+(SEW). By default, a vector register is viewed as being divided into
+VLEN/SEW elements.
+
+.vsew[2:0] (selected element width) encoding
+[cols="1,1,1,1"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+3+| vsew[2:0] | SEW
+
+| 0 | 0 | 0 | 8
+| 0 | 0 | 1 | 16
+| 0 | 1 | 0 | 32
+| 0 | 1 | 1 | 64
+| 1 | X | X | Reserved
+|===
+
+NOTE: While it is anticipated the larger `vsew[2:0]` encodings
+(`100`-`111`) will be used to encode larger SEW, the encodings are
+formally _reserved_ at this point.
+
+.Example VLEN = 128 bits
+[cols=">,>"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+| SEW | Elements per vector register
+
+| 64 | 2
+| 32 | 4
+| 16 | 8
+| 8 | 16
+|===
+
+The supported element width may vary with LMUL.
+
+NOTE: The current set of standard vector extensions do not vary
+supported element width with LMUL. Some future extensions may support
+larger SEWs only when bits from multiple vector registers are combined
+using LMUL. In this case, software that relies on large SEW should
+attempt to use the largest LMUL, and hence the fewest vector register
+groups, to increase the number of implementations on which the code
+will run. The `vill` bit in `vtype` should be checked after setting
+`vtype` to see if the configuration is supported, and an alternate
+code path should be provided if it is not. Alternatively, a profile
+can mandate the minimum SEW at each LMUL setting.
+
+[[vector-register-grouping]]
+===== Vector Register Grouping (`vlmul[2:0]`)
+
+Multiple vector registers can be grouped together, so that a single
+vector instruction can operate on multiple vector registers. The term
+_vector_ _register_ _group_ is used herein to refer to one or more
+vector registers used as a single operand to a vector instruction.
+Vector register groups can be used to provide greater execution
+efficiency for longer application vectors, but the main reason for
+their inclusion is to allow double-width or larger elements to be
+operated on with the same vector length as single-width elements. The
+vector length multiplier, _LMUL_, when greater than 1, represents the
+default number of vector registers that are combined to form a vector
+register group. Implementations must support LMUL integer values of
+1, 2, 4, and 8.
+
+
+NOTE: The vector architecture includes instructions that take multiple
+source and destination vector operands with different element widths,
+but the same number of elements. The effective LMUL (EMUL) of each
+vector operand is determined by the number of registers required to
+hold the elements. For example, for a widening add operation, such as
+add 32-bit values to produce 64-bit results, a double-width result
+requires twice the LMUL of the single-width inputs.
+
+LMUL can also be a fractional value, reducing the number of bits used
+in a single vector register. Fractional LMUL is used to increase the
+number of effective usable vector register groups when operating on
+mixed-width values.
+
+NOTE: With only integer LMUL values, a loop operating on a range of
+sizes would have to allocate at least one whole vector register
+(LMUL=1) for the narrowest data type and then would consume multiple
+vector registers (LMUL>1) to form a vector register group for each
+wider vector operand. This can limit the number of vector register groups
+available. With fractional LMUL, the widest values need occupy only a
+single vector register while narrower values can occupy a fraction of
+a single vector register, allowing all 32 architectural vector
+register names to be used for different values in a vector loop even
+when handling mixed-width values. Fractional LMUL implies portions of
+vector registers are unused, but in some cases, having more shorter
+register-resident vectors improves efficiency relative to fewer longer
+register-resident vectors.
+
+Implementations must provide fractional LMUL settings that allow the
+narrowest supported type to occupy a fraction of a vector register
+corresponding to the ratio of the narrowest supported type's width to
+that of the largest supported type's width. In general, the
+requirement is to support LMUL {ge} SEW~MIN~/ELEN, where SEW~MIN~ is
+the narrowest supported SEW value and ELEN is the widest supported SEW
+value. In the standard extensions, SEW~MIN~=8. For
+standard vector extensions with ELEN=32, fractional LMULs of 1/2 and
+1/4 must be supported. For standard vector extensions with ELEN=64,
+fractional LMULs of 1/2, 1/4, and 1/8 must be supported.
+
+NOTE: When LMUL < SEW~MIN~/ELEN, there is no guarantee
+an implementation would have enough bits in the fractional vector
+register to store at least one element, as VLEN=ELEN is a
+valid implementation choice. For example, with VLEN=ELEN=32,
+and SEW~MIN~=8, an LMUL of 1/8 would only provide four bits of
+storage in a vector register.
+
+For a given supported fractional LMUL setting, implementations must support
+SEW settings between SEW~MIN~ and LMUL * ELEN, inclusive.
+
+The use of `vtype` encodings with LMUL < SEW~MIN~/ELEN is
+__reserved__, but implementations can set `vill` if they do not
+support these configurations.
+
+NOTE: Requiring all implementations to set `vill` in this case would
+prohibit future use of this case in an extension, so to allow for a
+future definition of LMUL<SEW~MIN~/ELEN behavior, we
+consider the use of this case to be __reserved__.
+
+NOTE: It is recommended that assemblers provide a warning (not an
+error) if a `vsetvli` instruction attempts to write an LMUL < SEW~MIN~/ELEN.
+
+LMUL is set by the signed `vlmul` field in `vtype` (i.e., LMUL =
+2^`vlmul[2:0]`^).
+
+The derived value VLMAX = LMUL*VLEN/SEW represents the maximum number
+of elements that can be operated on with a single vector instruction
+given the current SEW and LMUL settings as shown in the table below.
+
+[cols="1,1,1,2,2,5,5"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+ 3+| vlmul[2:0] | LMUL | #groups | VLMAX | Registers grouped with register __n__
+
+| 1 | 0 | 0 | - | - | - | reserved
+| 1 | 0 | 1 | 1/8| 32 | VLEN/SEW/8 | `v` __n__ (single register in group)
+| 1 | 1 | 0 | 1/4| 32 | VLEN/SEW/4 | `v` __n__ (single register in group)
+| 1 | 1 | 1 | 1/2| 32 | VLEN/SEW/2 | `v` __n__ (single register in group)
+| 0 | 0 | 0 | 1 | 32 | VLEN/SEW | `v` __n__ (single register in group)
+| 0 | 0 | 1 | 2 | 16 | 2*VLEN/SEW | `v` __n__, `v` __n__+1
+| 0 | 1 | 0 | 4 | 8 | 4*VLEN/SEW | `v` __n__, ..., `v` __n__+3
+| 0 | 1 | 1 | 8 | 4 | 8*VLEN/SEW | `v` __n__, ..., `v` __n__+7
+|===
+
+When LMUL=2, the vector register group contains vector register `v`
+__n__ and vector register `v` __n__+1, providing twice the vector
+length in bits. Instructions specifying an LMUL=2 vector register group
+with an odd-numbered vector register are reserved.
+
+When LMUL=4, the vector register group contains four vector registers,
+and instructions specifying an LMUL=4 vector register group using vector
+register numbers that are not multiples of four are reserved.
+
+When LMUL=8, the vector register group contains eight vector
+registers, and instructions specifying an LMUL=8 vector register group
+using register numbers that are not multiples of eight are reserved.
+
+Mask registers are always contained in a single vector register,
+regardless of LMUL.
+
+[[sec-agnostic]]
+===== Vector Tail Agnostic and Vector Mask Agnostic `vta` and `vma`
+
+These two bits modify the behavior of destination tail elements and
+destination inactive masked-off elements respectively during the
+execution of vector instructions. The tail and inactive sets contain
+element positions that are not receiving new results during a vector
+operation, as defined in <<sec-inactive-defs>>.
+
+All systems must support all four options:
+
+[cols="1,1,3,3"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+| `vta` | `vma` | Tail Elements | Inactive Elements
+
+| 0 | 0 | undisturbed | undisturbed
+| 0 | 1 | undisturbed | agnostic
+| 1 | 0 | agnostic | undisturbed
+| 1 | 1 | agnostic | agnostic
+|===
+
+Mask destination tail elements are always treated as tail-agnostic,
+regardless of the setting of `vta`.
+
+When a set is marked undisturbed, the corresponding set of destination
+elements in a vector register group retain the value they previously
+held.
+
+When a set is marked agnostic, the corresponding set of destination
+elements in any vector destination operand can either retain the value
+they previously held, or are overwritten with 1s. Within a single vector
+instruction, each destination element can be either left undisturbed
+or overwritten with 1s, in any combination, and the pattern of
+undisturbed or overwritten with 1s is not required to be deterministic
+when the instruction is executed with the same inputs.
+
+NOTE: The agnostic policy was added to accommodate machines with
+vector register renaming. With an undisturbed policy, all elements
+would have to be read from the old physical destination vector
+register to be copied into the new physical destination vector
+register. This causes an inefficiency when these inactive or tail
+values are not required for subsequent calculations.
+
+NOTE: The value of all 1s instead of all 0s was chosen for the
+overwrite value to discourage software developers from depending on
+the value written.
+
+NOTE: A simple in-order implementation can ignore the settings and
+simply execute all vector instructions using the undisturbed
+policy. The `vta` and `vma` state bits must still be provided in
+`vtype` for compatibility and to support thread migration.
+
+NOTE: An out-of-order implementation can choose to implement
+tail-agnostic + mask-agnostic using tail-agnostic + mask-undisturbed
+to reduce implementation complexity.
+
+NOTE: The definition of agnostic result policy is left loose to
+accommodate migrating application threads between harts on a small
+in-order core (which probably leaves agnostic regions undisturbed) and
+harts on a larger out-of-order core with register renaming (which
+probably overwrites agnostic elements with 1s). As it might be
+necessary to restart in the middle, we allow arbitrary mixing of
+agnostic policies within a single vector instruction. This allowed
+mixing of policies also enables implementations that might change
+policies for different granules of a vector register, for example,
+using undisturbed within a granule that is actively operated on but
+renaming to all 1s for granules in the tail.
+
+In addition, except for mask load instructions, any element in the
+tail of a mask result can also be written with the value the
+mask-producing operation would have calculated with `vl`=VLMAX.
+Furthermore, for mask-logical instructions and `vmsbf.m`, `vmsif.m`,
+`vmsof.m` mask-manipulation instructions, any element in the tail of
+the result can be written with the value the mask-producing operation
+would have calculated with `vl`=VLEN, SEW=8, and LMUL=8 (i.e., all
+bits of the mask register can be overwritten).
+
+NOTE: Mask tails are always treated as agnostic to reduce complexity
+of managing mask data, which can be written at bit granularity. There
+appears to be little software need to support tail-undisturbed for
+mask register values. Allowing mask-generating instructions to write
+back the result of the instruction avoids the need for logic to mask
+out the tail, except mask loads cannot write memory values to
+destination mask tails as this would imply accessing memory past
+software intent.
+
+The assembly syntax adds two mandatory flags to the `vsetvli` instruction:
+
+----
+ ta # Tail agnostic
+ tu # Tail undisturbed
+ ma # Mask agnostic
+ mu # Mask undisturbed
+
+ vsetvli t0, a0, e32, m4, ta, ma # Tail agnostic, mask agnostic
+ vsetvli t0, a0, e32, m4, tu, ma # Tail undisturbed, mask agnostic
+ vsetvli t0, a0, e32, m4, ta, mu # Tail agnostic, mask undisturbed
+ vsetvli t0, a0, e32, m4, tu, mu # Tail undisturbed, mask undisturbed
+----
+
+NOTE: Prior to v0.9, when these flags were not specified on a
+`vsetvli`, they defaulted to mask-undisturbed/tail-undisturbed. The
+use of `vsetvli` without these flags is deprecated, however, and
+specifying a flag setting is now mandatory. The default should
+perhaps be tail-agnostic/mask-agnostic, so software has to specify
+when it cares about the non-participating elements, but given the
+historical meaning of the instruction prior to introduction of these
+flags, it was decided to always require them in future assembly code.
+
+===== Vector Type Illegal (`vill`)
+
+The `vill` bit is used to encode that a previous `vset{i}vl{i}`
+instruction attempted to write an unsupported value to `vtype`.
+
+NOTE: The `vill` bit is held in bit XLEN-1 of the CSR to support
+checking for illegal values with a branch on the sign bit.
+
+If the `vill` bit is set, then any attempt to execute a vector instruction
+that depends upon `vtype` will raise an illegal-instruction exception.
+
+NOTE: `vset{i}vl{i}` and whole register loads and stores do not depend
+upon `vtype`.
+
+When the `vill` bit is set, the other XLEN-1 bits in `vtype` shall be
+zero.
+
+==== Vector Length (`vl`) Register
+
+The _XLEN_-bit-wide read-only `vl` CSR can only be updated by the
+`vset{i}vl{i}` instructions, and the _fault-only-first_ vector load
+instruction variants.
+
+The `vl` register holds an unsigned integer specifying the number of
+elements to be updated with results from a vector instruction, as
+further detailed in <<sec-inactive-defs>>.
+
+NOTE: The number of bits implemented in `vl` depends on the
+implementation's maximum vector length of the smallest supported
+type. The smallest vector implementation with VLEN=32 and supporting
+SEW=8 would need at least six bits in `vl` to hold the values 0-32
+(VLEN=32, with LMUL=8 and SEW=8, yields VLMAX=32).
+
+==== Vector Byte Length (`vlenb`) Register
+
+The _XLEN_-bit-wide read-only CSR `vlenb` holds the value VLEN/8,
+i.e., the vector register length in bytes.
+
+NOTE: The value in `vlenb` is a design-time constant in any
+implementation.
+
+NOTE: Without this CSR, several instructions are needed to calculate
+VLEN in bytes, and the code has to disturb current `vl` and `vtype`
+settings which require them to be saved and restored.
+
+==== Vector Start Index (`vstart`) Register
+
+The _XLEN_-bit-wide read-write `vstart` CSR specifies the index of the
+first element to be executed by a vector instruction, as described in
+<<sec-inactive-defs>>.
+
+Normally, `vstart` is only written by hardware on a trap on a vector
+instruction, with the `vstart` value representing the element on which
+the trap was taken (either a synchronous exception or an asynchronous
+interrupt), and at which execution should resume after a resumable
+trap is handled.
+
+All vector instructions are defined to begin execution with the
+element number given in the `vstart` CSR, leaving earlier elements in
+the destination vector undisturbed, and to reset the `vstart` CSR to
+zero at the end of execution.
+
+NOTE: All vector instructions, including `vset{i}vl{i}`, reset the `vstart`
+CSR to zero.
+
+`vstart` is not modified by vector instructions that raise illegal-instruction
+exceptions.
+
+The `vstart` CSR is defined to have only enough writable bits to hold
+the largest element index (one less than the maximum VLMAX).
+
+NOTE: The maximum vector length is obtained with the largest LMUL
+setting (8) and the smallest SEW setting (8), so VLMAX_max = 8*VLEN/8 = VLEN. For example, for VLEN=256, `vstart` would have 8 bits to
+represent indices from 0 through 255.
+
+The use of `vstart` values greater than the largest element index for
+the current `vtype` setting is reserved.
+
+NOTE: It is recommended that implementations trap if `vstart` is out
+of bounds. It is not required to trap, as a possible future use of
+upper `vstart` bits is to store imprecise trap information.
+
+The `vstart` CSR is writable by unprivileged code, but non-zero
+`vstart` values may cause vector instructions to run substantially
+slower on some implementations, so `vstart` should not be used by
+application programmers. A few vector instructions cannot be
+executed with a non-zero `vstart` value and will raise an
+illegal-instruction exception as defined below.
+
+NOTE: Making `vstart` visible to unprivileged code supports user-level
+threading libraries.
+
+Implementations are permitted to raise illegal-instruction exceptions when
+attempting to execute a vector instruction with a value of `vstart` that the
+implementation can never produce when executing that same instruction with
+the same `vtype` setting.
+
+NOTE: For example, some implementations will never take interrupts during
+execution of a vector arithmetic instruction, instead waiting until the
+instruction completes to take the interrupt. Such implementations are
+permitted to raise an illegal-instruction exception when attempting to execute
+a vector arithmetic instruction when `vstart` is nonzero.
+
+NOTE: When migrating a software thread between two harts with
+different microarchitectures, the `vstart` value might not be
+supported by the new hart microarchitecture. The runtime on the
+receiving hart might then have to emulate instruction execution up to the
+next supported `vstart` element position. Alternatively, migration events
+can be constrained to only occur at mutually supported `vstart`
+locations.
+
+==== Vector Fixed-Point Rounding Mode (`vxrm`) Register
+
+The vector fixed-point rounding-mode register holds a two-bit
+read-write rounding-mode field in the least-significant bits
+(`vxrm[1:0]`). The upper bits, `vxrm[XLEN-1:2]`, should be written as
+zeros.
+
+The vector fixed-point rounding-mode is given a separate CSR address
+to allow independent access, but is also reflected as a field in
+`vcsr`.
+
+NOTE: A new rounding mode can be set while saving the original
+rounding mode using a single `csrwi` instruction.
+
+The fixed-point rounding algorithm is specified as follows.
+Suppose the pre-rounding result is `v`, and `d` bits of that result are to be
+rounded off.
+Then the rounded result is `(v >> d) + r`, where `r` depends on the rounding
+mode as specified in the following table.
+
+.vxrm encoding
+//[cols="1,1,4,10,5"]
+[%autowidth,float="center",align="center",cols="<,<,<,<,<",options="header"]
+|===
+2+| `vxrm[1:0]` | Abbreviation | Rounding Mode | Rounding increment, `r`
+
+| 0 | 0 | rnu | round-to-nearest-up (add +0.5 LSB) | `v[d-1]`
+| 0 | 1 | rne | round-to-nearest-even | `v[d-1] & (v[d-2:0]{ne}0 \| v[d])`
+| 1 | 0 | rdn | round-down | `0`
+| 1 | 1 | rod | round-to-odd (OR bits into LSB, aka "jam") | `!v[d] & v[d-1:0]{ne}0`
+|===
+
+The rounding functions:
+----
+roundoff_unsigned(v, d) = (unsigned(v) >> d) + r
+roundoff_signed(v, d) = (signed(v) >> d) + r
+----
+are used to represent this operation in the instruction descriptions below.
+
+==== Vector Fixed-Point Saturation Flag (`vxsat`)
+
+The `vxsat` CSR has a single read-write least-significant bit
+(`vxsat[0]`) that indicates if a fixed-point instruction has had to
+saturate an output value to fit into a destination format.
+Bits `vxsat[XLEN-1:1]` should be written as zeros.
+
+The `vxsat` bit is mirrored in `vcsr`.
+
+==== Vector Control and Status (`vcsr`) Register
+
+The `vxrm` and `vxsat` separate CSRs can also be accessed via fields
+in the _XLEN_-bit-wide vector control and status CSR, `vcsr`.
+
+.vcsr layout
+[cols=">2,4,10"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+| Bits | Name | Description
+
+| XLEN-1:3 | | Reserved
+| 2:1 | vxrm[1:0] | Fixed-point rounding mode
+| 0 | vxsat | Fixed-point accrued saturation flag
+|===
+
+==== State of Vector Extension at Reset
+
+The vector extension must have a consistent state at reset. In
+particular, `vtype` and `vl` must have values that can be read and
+then restored with a single `vsetvl` instruction.
+
+NOTE: It is recommended that at reset, `vtype.vill` is set, the
+remaining bits in `vtype` are zero, and `vl` is set to zero.
+
+The `vstart`, `vxrm`, `vxsat` CSRs can have arbitrary values at reset.
+
+NOTE: Most uses of the vector unit will require an initial `vset{i}vl{i}`,
+which will reset `vstart`. The `vxrm` and `vxsat` fields should be
+reset explicitly in software before use.
+
+The vector registers can have arbitrary values at reset.
+
+=== Mapping of Vector Elements to Vector Register State
+
+The following diagrams illustrate how different width elements are
+packed into the bytes of a vector register depending on the current
+SEW and LMUL settings, as well as implementation VLEN. Elements are
+packed into each vector register with the least-significant byte in
+the lowest-numbered bits.
+
+The mapping was chosen to provide the simplest and most portable model
+for software, but might appear to incur large wiring cost for wider
+vector datapaths on certain operations. The vector instruction set
+was expressly designed to support implementations that internally
+rearrange vector data for different SEW to reduce datapath wiring
+costs, while externally preserving the simple software model.
+
+NOTE: For example, microarchitectures can track the EEW with which a
+vector register was written, and then insert additional scrambling
+operations to rearrange data if the register is accessed with a
+different EEW.
+
+==== Mapping for LMUL = 1
+
+When LMUL=1, elements are simply packed in order from the
+least-significant to most-significant bits of the vector register.
+
+NOTE: To increase readability, vector register layouts are drawn with
+bytes ordered from right to left with increasing byte address. Bits
+within an element are numbered in a little-endian format with
+increasing bit index from right to left corresponding to increasing
+magnitude.
+
+----
+LMUL=1 examples.
+
+The element index is given in hexadecimal and is shown placed at the
+least-significant byte of the stored element.
+
+
+ VLEN=32b
+
+ Byte 3 2 1 0
+
+ SEW=8b 3 2 1 0
+ SEW=16b 1 0
+ SEW=32b 0
+
+ VLEN=64b
+
+ Byte 7 6 5 4 3 2 1 0
+
+ SEW=8b 7 6 5 4 3 2 1 0
+ SEW=16b 3 2 1 0
+ SEW=32b 1 0
+ SEW=64b 0
+
+ VLEN=128b
+
+ Byte F E D C B A 9 8 7 6 5 4 3 2 1 0
+
+ SEW=8b F E D C B A 9 8 7 6 5 4 3 2 1 0
+ SEW=16b 7 6 5 4 3 2 1 0
+ SEW=32b 3 2 1 0
+ SEW=64b 1 0
+
+ VLEN=256b
+
+ Byte 1F1E1D1C1B1A19181716151413121110 F E D C B A 9 8 7 6 5 4 3 2 1 0
+
+ SEW=8b 1F1E1D1C1B1A19181716151413121110 F E D C B A 9 8 7 6 5 4 3 2 1 0
+ SEW=16b F E D C B A 9 8 7 6 5 4 3 2 1 0
+ SEW=32b 7 6 5 4 3 2 1 0
+ SEW=64b 3 2 1 0
+----
+
+==== Mapping for LMUL < 1
+
+When LMUL < 1, only the first LMUL*VLEN/SEW elements in the vector
+register are used. The remaining space in the vector register is
+treated as part of the tail, and hence must obey the vta setting.
+
+----
+ Example, VLEN=128b, LMUL=1/4
+
+ Byte F E D C B A 9 8 7 6 5 4 3 2 1 0
+
+ SEW=8b - - - - - - - - - - - - 3 2 1 0
+ SEW=16b - - - - - - 1 0
+ SEW=32b - - - 0
+----
+
+==== Mapping for LMUL > 1
+
+When vector registers are grouped, the elements of the vector register
+group are packed contiguously in element order beginning with the
+lowest-numbered vector register and moving to the
+next-highest-numbered vector register in the group once each vector
+register is filled.
+
+----
+ LMUL > 1 examples
+
+ VLEN=32b, SEW=8b, LMUL=2
+
+ Byte 3 2 1 0
+ v2*n 3 2 1 0
+ v2*n+1 7 6 5 4
+
+ VLEN=32b, SEW=16b, LMUL=2
+
+ Byte 3 2 1 0
+ v2*n 1 0
+ v2*n+1 3 2
+
+ VLEN=32b, SEW=16b, LMUL=4
+
+ Byte 3 2 1 0
+ v4*n 1 0
+ v4*n+1 3 2
+ v4*n+2 5 4
+ v4*n+3 7 6
+
+ VLEN=32b, SEW=32b, LMUL=4
+
+ Byte 3 2 1 0
+ v4*n 0
+ v4*n+1 1
+ v4*n+2 2
+ v4*n+3 3
+
+ VLEN=64b, SEW=32b, LMUL=2
+
+ Byte 7 6 5 4 3 2 1 0
+ v2*n 1 0
+ v2*n+1 3 2
+
+ VLEN=64b, SEW=32b, LMUL=4
+
+ Byte 7 6 5 4 3 2 1 0
+ v4*n 1 0
+ v4*n+1 3 2
+ v4*n+2 5 4
+ v4*n+3 7 6
+
+ VLEN=128b, SEW=32b, LMUL=2
+
+ Byte F E D C B A 9 8 7 6 5 4 3 2 1 0
+ v2*n 3 2 1 0
+ v2*n+1 7 6 5 4
+
+ VLEN=128b, SEW=32b, LMUL=4
+
+ Byte F E D C B A 9 8 7 6 5 4 3 2 1 0
+ v4*n 3 2 1 0
+ v4*n+1 7 6 5 4
+ v4*n+2 B A 9 8
+ v4*n+3 F E D C
+----
+
+[[sec-mapping-mixed]]
+==== Mapping across Mixed-Width Operations
+
+The vector ISA is designed to support mixed-width operations without
+requiring additional explicit rearrangement instructions. The
+recommended software strategy when operating on multiple vectors with
+different precision values is to modify `vtype` dynamically to keep
+SEW/LMUL constant (and hence VLMAX constant).
+
+The following example shows four different packed element widths (8b,
+16b, 32b, 64b) in a VLEN=128b implementation. The vector register
+grouping factor (LMUL) is increased by the relative element size such
+that each group can hold the same number of vector elements (VLMAX=8
+in this example) to simplify strip-mining code.
+
+----
+Example VLEN=128b, with SEW/LMUL=16
+
+Byte F E D C B A 9 8 7 6 5 4 3 2 1 0
+vn - - - - - - - - 7 6 5 4 3 2 1 0 SEW=8b, LMUL=1/2
+
+vn 7 6 5 4 3 2 1 0 SEW=16b, LMUL=1
+
+v2*n 3 2 1 0 SEW=32b, LMUL=2
+v2*n+1 7 6 5 4
+
+v4*n 1 0 SEW=64b, LMUL=4
+v4*n+1 3 2
+v4*n+2 5 4
+v4*n+3 7 6
+----
+
+The following table shows each possible constant SEW/LMUL operating
+point for loops with mixed-width operations. Each column represents a
+constant SEW/LMUL operating point. Entries in table are the LMUL
+values that yield that column's SEW/LMUL value for the data width on
+that row. In each column, an LMUL setting for a data width indicates
+that it can be aligned with the other data widths in the same column
+that also have an LMUL setting, such that all have the same VLMAX.
+
+|===
+| 7+^| SEW/LMUL
+| | 1 | 2 | 4 | 8 | 16 | 32 | 64
+
+| SEW= 8 | 8 | 4 | 2 | 1 | 1/2 | 1/4 | 1/8
+| SEW= 16 | | 8 | 4 | 2 | 1 | 1/2 | 1/4
+| SEW= 32 | | | 8 | 4 | 2 | 1 | 1/2
+| SEW= 64 | | | | 8 | 4 | 2 | 1
+|===
+
+Larger LMUL settings can also used to simply increase vector length to
+reduce instruction fetch and dispatch overheads in cases where fewer
+vector register groups are needed.
+
+[[sec-mask-register-layout]]
+==== Mask Register Layout
+
+A vector mask occupies only one vector register regardless of SEW and
+LMUL.
+
+Each element is allocated a single mask bit in a mask vector register.
+The mask bit for element _i_ is located in bit _i_ of the mask
+register, independent of SEW or LMUL.
+
+=== Vector Instruction Formats
+
+The instructions in the vector extension fit under two existing major
+opcodes (LOAD-FP and STORE-FP) and one new major opcode (OP-V).
+
+Vector loads and stores are encoded within the scalar floating-point
+load and store major opcodes (LOAD-FP/STORE-FP). The vector load and
+store encodings repurpose a portion of the standard scalar
+floating-point load/store 12-bit immediate field to provide further
+vector instruction encoding, with bit 25 holding the standard vector
+mask bit (see <<sec-vector-mask-encoding>>).
+
+include::images/wavedrom/vmem-format.edn[]
+
+include::images/wavedrom/valu-format.edn[]
+
+include::images/wavedrom/vcfg-format.edn[]
+
+Vector instructions can have scalar or vector source operands and
+produce scalar or vector results, and most vector instructions can be
+performed either unconditionally or conditionally under a mask.
+
+Vector loads and stores move bit patterns between vector register
+elements and memory. Vector arithmetic instructions operate on values
+held in vector register elements.
+
+==== Scalar Operands
+
+Scalar operands can be immediates, or taken from the `x` registers,
+the `f` registers, or element 0 of a vector register. Scalar results
+are written to an `x` or `f` register or to element 0 of a vector
+register. Any vector register can be used to hold a scalar regardless
+of the current LMUL setting.
+
+NOTE: Zfinx ("F in X") is a new ISA extension where
+floating-point instructions take their arguments from the integer
+register file. The vector extension is also compatible with Zfinx,
+where the Zfinx vector extension has vector-scalar floating-point
+instructions taking their scalar argument from the `x` registers.
+
+NOTE: We considered but did not pursue overlaying the `f` registers on
+`v` registers. The adopted approach reduces vector register pressure,
+avoids interactions with the standard calling convention, simplifies
+high-performance scalar floating-point design, and provides
+compatibility with the Zfinx ISA option. Overlaying `f` with `v`
+would provide the advantage of lowering the number of state bits in
+some implementations, but complicates high-performance designs and
+would prevent compatibility with the Zfinx ISA option.
+
+[[sec-vec-operands]]
+==== Vector Operands
+
+Each vector operand has an _effective_ _element_ _width_ (EEW) and an
+_effective_ LMUL (EMUL) that is used to determine the size and
+location of all the elements within a vector register group. By
+default, for most operands of most instructions, EEW=SEW and
+EMUL=LMUL.
+
+Some vector instructions have source and destination vector operands
+with the same number of elements but different widths, so that EEW and
+EMUL differ from SEW and LMUL respectively but EEW/EMUL = SEW/LMUL.
+For example, most widening arithmetic instructions have a source group
+with EEW=SEW and EMUL=LMUL but have a destination group with EEW=2*SEW and
+EMUL=2*LMUL. Narrowing instructions have a source operand that has
+EEW=2*SEW and EMUL=2*LMUL but with a destination where EEW=SEW and EMUL=LMUL.
+
+Vector operands or results may occupy one or more vector registers
+depending on EMUL, but are always specified using the lowest-numbered
+vector register in the group. Using other than the lowest-numbered
+vector register to specify a vector register group is a reserved
+encoding.
+
+A vector register cannot be used to provide source operands with more
+than one EEW for a single instruction. A mask register source is
+considered to have EEW=1 for this constraint. An encoding that would
+result in the same vector register being read with two or more
+different EEWs, including when the vector register appears at
+different positions within two or more vector register groups, is
+reserved.
+
+NOTE: In practice, there is no software benefit to reading the same
+register with different EEW in the same instruction, and this
+constraint reduces complexity for implementations that internally
+rearrange data dependent on EEW.
+
+A destination vector register group can overlap a source vector register
+group only if one of the following holds:
+
+- The destination EEW equals the source EEW.
+- The destination EEW is smaller than the source EEW, and the lowest-numbered
+ register in the destination vector register group is the same as the the
+ lowest-numbered register in the source vector register group.
+ (For example, when LMUL=1,
+ `vnsrl.wi v0, v0, 3` is legal, but a destination of `v1` is not).
+- The destination EEW is greater than the source EEW, the source EMUL is
+ at least 1, and the highest-numbered register in the destination
+ vector register group is the same as the highest-numbered register in
+ the source vector register group.
+ (For example, when LMUL=8, `vzext.vf4 v0, v6` is legal,
+ but a source of `v0`, `v2`, or `v4` is not).
+
+For the purpose of determining register group overlap constraints,
+mask elements have EEW=1.
+
+NOTE: The overlap constraints are designed to support resumable
+exceptions in machines without register renaming.
+
+Any instruction encoding that violates the overlap constraints is reserved.
+
+When source and destination registers overlap and have different EEW, the
+instruction is mask- and tail-agnostic, regardless of the setting of the
+`vta` and `vma` bits in `vtype`.
+
+The largest vector register group used by an instruction can not be
+greater than 8 vector registers (i.e., EMUL{le}8), and if a vector
+instruction would require greater than 8 vector registers in a group,
+the instruction encoding is reserved. For example, a widening
+operation that produces a widened vector register group result when
+LMUL=8 is reserved as this would imply a result EMUL=16.
+
+Widened scalar values, e.g., input and output to a widening reduction
+operation, are held in the first element of a vector register and
+have EMUL=1.
+
+==== Vector Masking
+
+Masking is supported on many vector instructions. Element operations
+that are masked off (inactive) never generate exceptions. The
+destination vector register elements corresponding to masked-off
+elements are handled with either a mask-undisturbed or mask-agnostic
+policy depending on the setting of the `vma` bit in `vtype`
+(<<sec-agnostic>>).
+
+The mask value used to control execution of a masked vector
+instruction is always supplied by vector register `v0`.
+
+NOTE: Masks are held in vector registers, rather than in a separate mask
+register file, to reduce total architectural state and to simplify the ISA.
+
+NOTE: Future vector extensions may provide longer instruction
+encodings with space for a full mask register specifier.
+
+The destination vector register group for a masked vector instruction
+cannot overlap the source mask register (`v0`), unless the destination
+vector register is being written with a mask value (e.g., compares)
+or the scalar result of a reduction. These instruction encodings are
+reserved.
+
+NOTE: This constraint supports restart with a non-zero `vstart` value.
+
+Other vector registers can be used to hold working mask values, and
+mask vector logical operations are provided to perform predicate
+calculations. [[sec-mask-vector-logical]]
+
+As specified in <<sec-agnostic>>, mask destination tail elements are
+always treated as tail-agnostic, regardless of the setting of `vta`.
+
+[[sec-vector-mask-encoding]]
+===== Mask Encoding
+
+Where available, masking is encoded in a single-bit `vm` field in the
+ instruction (`inst[25]`).
+
+[cols="1,15"]
+|===
+| vm | Description
+
+| 0 | vector result, only where v0.mask[i] = 1
+| 1 | unmasked
+|===
+
+Vector masking is represented in assembler code as another vector
+operand, with `.t` indicating that the operation occurs when
+`v0.mask[i]` is `1` (`t` for "true"). If no masking operand is
+specified, unmasked vector execution (`vm=1`) is assumed.
+
+----
+ vop.v* v1, v2, v3, v0.t # enabled where v0.mask[i]=1, vm=0
+ vop.v* v1, v2, v3 # unmasked vector operation, vm=1
+----
+
+NOTE: Even though the current vector extensions only support one vector
+mask register `v0` and only the true form of predication, the assembly
+syntax writes it out in full to be compatible with future extensions
+that might add a mask register specifier and support both true and
+complement mask values. The `.t` suffix on the masking operand also helps
+to visually encode the use of a mask.
+
+NOTE: The `.mask` suffix is not part of the assembly syntax.
+We only append it in contexts where a mask vector is subscripted,
+e.g., `v0.mask[i]`.
+
+[[sec-inactive-defs]]
+==== Prestart, Active, Inactive, Body, and Tail Element Definitions
+
+The destination element indices operated on during a vector
+instruction's execution can be divided into three disjoint subsets.
+
+* The _prestart_ elements are those whose element index is less than the
+initial value in the `vstart` register. The prestart elements do not
+raise exceptions and do not update the destination vector register.
+
+* The _body_ elements are those whose element index is greater than or equal
+to the initial value in the `vstart` register, and less than the current
+vector length setting in `vl`. The body can be split into two disjoint subsets:
+
+** The _active_ elements during a vector instruction's execution are the
+elements within the body and where the current mask is enabled at that element
+position. The active elements can raise exceptions and update the destination
+vector register group.
+
+** The _inactive_ elements are the elements within the body
+but where the current mask is disabled at that element
+position. The inactive elements do not raise exceptions and do not
+update any destination vector register group unless masked agnostic is
+specified (`vtype.vma`=1), in which case inactive elements may be
+overwritten with 1s.
+
+* The _tail_ elements during a vector instruction's execution are the
+elements past the current vector length setting specified in `vl`.
+The tail elements do not raise exceptions, and do not update any
+destination vector register group unless tail agnostic is specified
+(`vtype.vta`=1), in which case tail elements may be overwritten with
+1s, or with the result of the instruction in the case of
+mask-producing instructions except for mask loads. When LMUL < 1, the
+tail includes the elements past VLMAX that are held in the same vector
+register.
+
+----
+ for element index x
+ prestart(x) = (0 <= x < vstart)
+ body(x) = (vstart <= x < vl)
+ tail(x) = (vl <= x < max(VLMAX,VLEN/SEW))
+ mask(x) = unmasked || v0.mask[x] == 1
+ active(x) = body(x) && mask(x)
+ inactive(x) = body(x) && !mask(x)
+----
+
+When `vstart` {ge} `vl`, there are no body elements, and no elements
+are updated in any destination vector register group, including that
+no tail elements are updated with agnostic values.
+
+NOTE: As a consequence, when `vl`=0, no elements, including agnostic
+elements, are updated in the destination vector register group
+regardless of `vstart`.
+
+Instructions that write an `x` register or `f` register
+do so even when `vstart` {ge} `vl`, including when `vl`=0.
+
+NOTE: Some instructions such as `vslidedown` and `vrgather` may read
+indices past `vl` or even VLMAX in source vector register groups. The
+general policy is to return the value 0 when the index is greater than
+VLMAX in the source vector register group.
+
+[[sec-vector-config]]
+=== Configuration-Setting Instructions (`vsetvli`/`vsetivli`/`vsetvl`)
+
+One of the common approaches to handling a large number of elements is
+"strip mining" where each iteration of a loop handles some number of elements,
+and the iterations continue until all elements have been processed. The RISC-V
+vector specification provides direct, portable support for this approach.
+The application specifies the total number of elements to be processed (the application vector length or AVL) as a
+candidate value for `vl`, and the hardware responds via a general-purpose
+register with the (frequently smaller) number of elements that the hardware
+will handle per iteration (stored in `vl`), based on the microarchitectural
+implementation and the `vtype` setting. A straightforward loop structure,
+shown in <<example-stripmine-sew>>, depicts the ease with which the code keeps
+track of the remaining number of elements and the amount per iteration handled
+by hardware.
+
+A set of instructions is provided to allow rapid configuration of the
+values in `vl` and `vtype` to match application needs. The
+`vset{i}vl{i}` instructions set the `vtype` and `vl` CSRs based on
+their arguments, and write the new value of `vl` into `rd`.
+
+----
+ vsetvli rd, rs1, vtypei # rd = new vl, rs1 = AVL, vtypei = new vtype setting
+ vsetivli rd, uimm, vtypei # rd = new vl, uimm = AVL, vtypei = new vtype setting
+ vsetvl rd, rs1, rs2 # rd = new vl, rs1 = AVL, rs2 = new vtype value
+----
+
+include::images/wavedrom/vcfg-format.edn[]
+
+==== `vtype` encoding
+
+include::images/wavedrom/vtype-format.edn[]
+
+The new `vtype` value is encoded in the immediate fields of `vsetvli`
+and `vsetivli`, and in the `rs2` register for `vsetvl`.
+
+----
+ Suggested assembler names used for vset{i}vli vtypei immediate
+
+ e8 # SEW=8b
+ e16 # SEW=16b
+ e32 # SEW=32b
+ e64 # SEW=64b
+
+ mf8 # LMUL=1/8
+ mf4 # LMUL=1/4
+ mf2 # LMUL=1/2
+ m1 # LMUL=1
+ m2 # LMUL=2
+ m4 # LMUL=4
+ m8 # LMUL=8
+
+Examples:
+ vsetvli t0, a0, e8, m1, ta, ma # SEW= 8, LMUL=1
+ vsetvli t0, a0, e8, m2, ta, ma # SEW= 8, LMUL=2
+ vsetvli t0, a0, e32, mf2, ta, ma # SEW=32, LMUL=1/2
+----
+
+The `vsetvl` variant operates similarly to `vsetvli` except that it
+takes a `vtype` value from `rs2` and can be used for context restore.
+
+===== Unsupported `vtype` Values
+
+If the `vtype` value is not supported by the implementation, then
+the `vill` bit is set in `vtype`, the remaining bits in `vtype` are
+set to zero, and the `vl` register is also set to zero.
+
+NOTE: Earlier drafts required a trap when setting `vtype` to an
+illegal value. However, this would have added the first
+data-dependent trap on a CSR write to the ISA. Implementations could
+choose to trap when illegal values are written to `vtype` instead of
+setting `vill`, to allow emulation to support new configurations for
+forward-compatibility. The current scheme supports light-weight
+runtime interrogation of the supported vector unit configurations by
+checking if `vill` is clear for a given setting.
+
+A `vtype` value with `vill` set is treated as an unsupported
+configuration.
+
+Implementations must consider all bits of the `vtype` value to
+determine if the configuration is supported. An unsupported value in
+any location within the `vtype` value must result in `vill` being set.
+
+NOTE: In particular, all XLEN bits of the register `vtype` argument to
+the `vsetvl` instruction must be checked. Implementations cannot
+ignore fields they do not implement. All bits must be checked to
+ensure that new code assuming unsupported vector features in `vtype`
+traps instead of executing incorrectly on an older implementation.
+
+==== AVL encoding
+
+The new vector
+length setting is based on AVL, which for `vsetvli` and `vsetvl` is encoded in the `rs1` and `rd`
+fields as follows:
+
+.AVL used in `vsetvli` and `vsetvl` instructions
+[cols="2,2,10,10"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+| `rd` | `rs1` | AVL value | Effect on `vl`
+| - | !x0 | Value in `x[rs1]` | Normal strip mining
+| !x0 | x0 | ~0 | Set `vl` to VLMAX
+| x0 | x0 | Value in `vl` register | Keep existing `vl` (of course, `vtype` may change)
+|===
+
+When _rs1_ is not `x0`, the AVL is an unsigned integer held in the `x`
+register specified by _rs1_, and the new `vl` value is also written to
+the `x` register specified by _rd_.
+
+When _rs1_=`x0` but _rd_≠`x0`, the maximum unsigned integer value (`~0`)
+is used as the AVL, and the resulting VLMAX is written to `vl` and
+also to the `x` register specified by `rd`.
+
+When _rs1_=`x0` and _rd_=`x0`, the instructions operate as if the current
+vector length in `vl` is used as the AVL, and the resulting value is
+written to `vl`, but not to a destination register. This form can
+only be used when VLMAX and hence `vl` is not actually changed by the
+new SEW/LMUL ratio. Use of the instructions with a new SEW/LMUL ratio
+that would result in a change of VLMAX is reserved.
+Use of the instructions is also reserved if `vill` was 1 beforehand.
+Implementations may set `vill` in either case.
+
+NOTE: This last form of the instructions allows the `vtype` register to
+be changed while maintaining the current `vl`, provided VLMAX is not
+reduced. This design was chosen to ensure `vl` would always hold a
+legal value for current `vtype` setting. The current `vl` value can
+be read from the `vl` CSR. The `vl` value could be reduced by these
+instructions if the new SEW/LMUL ratio causes VLMAX to shrink, and so
+this case has been reserved as it is not clear this is a generally
+useful operation, and implementations can otherwise assume `vl` is not
+changed by these instructions to optimize their microarchitecture.
+
+For the `vsetivli` instruction, the AVL is encoded as a 5-bit
+zero-extended immediate (0--31) in the `rs1` field.
+
+NOTE: The encoding of AVL for `vsetivli` is the same as for regular
+CSR immediate values.
+
+NOTE: The `vsetivli` instruction provides more compact code when the
+dimensions of vectors are small and known to fit inside the vector
+registers, in which case there is no strip-mining overhead.
+
+[[constraints-on-setting-vl]]
+==== Constraints on Setting `vl`
+
+The `vset{i}vl{i}` instructions first set VLMAX according to their `vtype`
+argument, then set `vl` obeying the following constraints:
+
+. `vl = AVL` if `AVL {le} VLMAX`
+. `ceil(AVL / 2) {le} vl {le} VLMAX` if `AVL < (2 * VLMAX)`
+. `vl = VLMAX` if `AVL {ge} (2 * VLMAX)`
+. Deterministic on any given implementation for same input AVL and VLMAX values
+. These specific properties follow from the prior rules:
+.. `vl = 0` if `AVL = 0`
+.. `vl > 0` if `AVL > 0`
+.. `vl {le} VLMAX`
+.. `vl {le} AVL`
+.. a value read from `vl` when used as the AVL argument to `vset{i}vl{i}` results in the same
+value in `vl`, provided the resultant VLMAX equals the value of VLMAX at the time that `vl` was read
+
+[NOTE]
+--
+The `vl` setting rules are designed to be sufficiently strict to
+preserve `vl` behavior across register spills and context swaps for
+`AVL {le} VLMAX`, yet flexible enough to enable implementations to improve
+vector lane utilization for `AVL > VLMAX`.
+
+For example, this permits an implementation to set `vl = ceil(AVL / 2)`
+for `VLMAX < AVL < 2*VLMAX` in order to evenly distribute work over the
+last two iterations of a strip-mine loop.
+Requirement 2 ensures that the first strip-mine iteration of reduction
+loops uses the largest vector length of all iterations, even in the case
+of `AVL < 2*VLMAX`.
+This allows software to avoid needing to explicitly calculate a running
+maximum of vector lengths observed during a strip-mined loop.
+Requirement 2 also allows an implementation to set vl to VLMAX for `VLMAX < AVL < 2*VLMAX`
+--
+
+[[example-stripmine-sew]]
+==== Example of strip mining and changes to SEW
+
+The SEW and LMUL settings can be changed dynamically to provide high
+throughput on mixed-width operations in a single loop.
+----
+# Example: Load 16-bit values, widen multiply to 32b, shift 32b result
+# right by 3, store 32b values.
+# On entry:
+# a0 holds the total number of elements to process
+# a1 holds the address of the source array
+# a2 holds the address of the destination array
+
+loop:
+ vsetvli a3, a0, e16, m4, ta, ma # vtype = 16-bit integer vectors;
+ # also update a3 with vl (# of elements this iteration)
+ vle16.v v4, (a1) # Get 16b vector
+ slli t1, a3, 1 # Multiply # elements this iteration by 2 bytes/source element
+ add a1, a1, t1 # Bump pointer
+ vwmul.vx v8, v4, x10 # Widening multiply into 32b in <v8--v15>
+
+ vsetvli x0, x0, e32, m8, ta, ma # Operate on 32b values
+ vsrl.vi v8, v8, 3
+ vse32.v v8, (a2) # Store vector of 32b elements
+ slli t1, a3, 2 # Multiply # elements this iteration by 4 bytes/destination element
+ add a2, a2, t1 # Bump pointer
+ sub a0, a0, a3 # Decrement count by vl
+ bnez a0, loop # Any more?
+----
+
+[[sec-vector-memory]]
+=== Vector Loads and Stores
+
+Vector loads and stores move values between vector registers and
+memory.
+Vector loads and stores can be masked, and they only access memory or raise
+exceptions for active elements.
+Masked vector loads do not update inactive elements in the destination vector
+register group, unless masked agnostic is specified (`vtype.vma`=1).
+All vector loads and stores may
+generate and accept a non-zero `vstart` value.
+
+==== Vector Load/Store Instruction Encoding
+
+Vector loads and stores are encoded within the scalar floating-point
+load and store major opcodes (LOAD-FP/STORE-FP). The vector load and
+store encodings repurpose a portion of the standard scalar
+floating-point load/store 12-bit immediate field to provide further
+vector instruction encoding, with bit 25 holding the standard vector
+mask bit (see <<sec-vector-mask-encoding>>).
+
+include::images/wavedrom/vmem-format.edn[]
+
+[cols="4,12"]
+|===
+| Field | Description
+
+| rs1[4:0] | specifies x register holding base address
+| rs2[4:0] | specifies x register holding stride
+| vs2[4:0] | specifies v register holding address offsets
+| vs3[4:0] | specifies v register holding store data
+| vd[4:0] | specifies v register destination of load
+| vm | specifies whether vector masking is enabled (0 = mask enabled, 1 = mask disabled)
+| width[2:0] | specifies size of memory elements, and distinguishes from FP scalar
+| mew | extended memory element width. See <<sec-vector-loadstore-width-encoding>>
+| mop[1:0] | specifies memory addressing mode
+| nf[2:0] | specifies the number of fields in each segment, for segment load/stores
+| lumop[4:0]/sumop[4:0] | are additional fields encoding variants of unit-stride instructions
+|===
+
+Vector memory unit-stride and constant-stride operations directly
+encode EEW of the data to be transferred statically in the instruction
+to reduce the number of `vtype` changes when accessing memory in a
+mixed-width routine. Indexed operations use the explicit EEW encoding
+in the instruction to set the size of the indices used, and use
+SEW/LMUL to specify the data width.
+
+==== Vector Load/Store Addressing Modes
+
+The vector extension supports unit-stride, constant-stride, and
+indexed (scatter/gather) addressing modes. Vector load/store base
+registers and strides are taken from the GPR `x` registers.
+
+The base effective address for all vector accesses is given by the
+contents of the `x` register named in `rs1`.
+
+Vector unit-stride operations access elements stored contiguously in
+memory starting from the base effective address.
+
+Vector constant-stride operations access the first memory element at the base
+effective address, and then access subsequent elements at address
+increments given by the byte offset contained in the `x` register
+specified by `rs2`.
+
+Vector indexed operations add the contents of each element of the
+vector offset operand specified by `vs2` to the base effective address
+to give the effective address of each element. The data vector
+register group has EEW=SEW, EMUL=LMUL, while the offset vector
+register group has EEW encoded in the instruction and
+EMUL=(EEW/SEW)*LMUL.
+
+The vector offset operand is treated as a vector of byte-address
+offsets.
+
+NOTE: The indexed operations can also be used to access fields within
+a vector of objects, where the `vs2` vector holds pointers to the base
+of the objects and the scalar `x` register holds the offset of the
+member field in each object. Supporting this case is why the indexed
+operations were not defined to scale the element indices by the data
+EEW.
+
+If the vector offset elements are narrower than XLEN, they are
+zero-extended to XLEN before adding to the base effective address. If
+the vector offset elements are wider than XLEN, the least-significant
+XLEN bits are used in the address calculation.
+If the implementation does not support the EEW of the offset elements,
+the instruction is reserved.
+
+NOTE: A profile may place an upper limit on the maximum supported index
+EEW (e.g., only up to XLEN) smaller than ELEN.
+
+The vector addressing modes are encoded using the 2-bit `mop[1:0]`
+field.
+
+.encoding for loads
+[cols="1,1,7,6"]
+|===
+2+| mop [1:0] | Description | Opcodes
+
+| 0 | 0 | unit-stride | VLE<EEW>
+| 0 | 1 | indexed-unordered | VLUXEI<EEW>
+| 1 | 0 | constant-stride | VLSE<EEW>
+| 1 | 1 | indexed-ordered | VLOXEI<EEW>
+|===
+
+.encoding for stores
+[cols="1,1,7,6"]
+|===
+2+| mop [1:0] | Description | Opcodes
+
+| 0 | 0 | unit-stride | VSE<EEW>
+| 0 | 1 | indexed-unordered | VSUXEI<EEW>
+| 1 | 0 | constant-stride | VSSE<EEW>
+| 1 | 1 | indexed-ordered | VSOXEI<EEW>
+|===
+
+Vector unit-stride and constant-stride memory accesses do not
+guarantee ordering between individual element accesses. The vector
+indexed load and store memory operations have two forms, ordered and
+unordered. The indexed-ordered variants preserve element ordering on
+memory accesses.
+
+For unordered instructions (`mop[1:0]`!=11) there is no guarantee on
+element access order. If the accesses are to a strongly ordered IO
+region, the element accesses can be initiated in any order.
+
+NOTE: To provide ordered vector accesses to a strongly ordered IO
+region, the ordered indexed instructions should be used.
+
+For implementations with precise vector traps, exceptions on
+indexed-unordered stores must also be precise.
+
+Additional unit-stride vector addressing modes are encoded using the
+5-bit `lumop` and `sumop` fields in the unit-stride load and store
+instruction encodings respectively.
+
+.lumop
+[cols="1,1,1,1,1,11"]
+|===
+5+| lumop[4:0] | Description
+
+| 0 | 0 | 0 | 0 | 0 | unit-stride load
+| 0 | 1 | 0 | 0 | 0 | unit-stride, whole register load
+| 0 | 1 | 0 | 1 | 1 | unit-stride, mask load, EEW=8
+| 1 | 0 | 0 | 0 | 0 | unit-stride fault-only-first
+| x | x | x | x | x | other encodings reserved
+|===
+
+.sumop
+[cols="1,1,1,1,1,11"]
+|===
+5+| sumop[4:0] | Description
+
+| 0 | 0 | 0 | 0 | 0 | unit-stride store
+| 0 | 1 | 0 | 0 | 0 | unit-stride, whole register store
+| 0 | 1 | 0 | 1 | 1 | unit-stride, mask store, EEW=8
+| x | x | x | x | x | other encodings reserved
+|===
+
+The `nf[2:0]` field encodes the number of fields in each segment. For
+regular vector loads and stores, `nf`=0, indicating that a single
+value is moved between a vector register group and memory at each
+element position. Larger values in the `nf` field are used to access
+multiple contiguous fields within a segment as described below in
+<<sec-aos>>.
+
+The `nf[2:0]` field also encodes the number of whole vector registers
+to transfer for the whole vector register load/store instructions.
+
+[[sec-vector-loadstore-width-encoding]]
+==== Vector Load/Store Width Encoding
+
+Vector loads and stores have an EEW encoded directly in the
+instruction. The corresponding EMUL is calculated as EMUL =
+(EEW/SEW)*LMUL. If the EMUL would be out of range (EMUL>8 or
+EMUL<1/8), the instruction encoding is reserved. The vector register
+groups must have legal register specifiers for the selected EMUL,
+otherwise the instruction encoding is reserved.
+
+Vector unit-stride and constant-stride use the EEW/EMUL encoded in the
+instruction for the data values, while vector indexed loads and stores
+use the EEW/EMUL encoded in the instruction for the index values and
+the SEW/LMUL encoded in `vtype` for the data values.
+
+Vector loads and stores are encoded using width values that are not
+claimed by the standard scalar floating-point loads and stores.
+
+Implementations must provide vector loads and stores with EEWs
+corresponding to all supported SEW settings. Vector load/store
+encodings for unsupported EEW widths are reserved.
+
+.Width encoding for vector loads and stores.
+[cols="5,1,1,1,1,>3,>3,>3,3"]
+|===
+| | mew 3+| width [2:0] | Mem bits | Data Reg bits | Index bits | Opcodes
+
+| Standard scalar FP | x | 0 | 0 | 1 | 16| FLEN | - | FLH/FSH
+| Standard scalar FP | x | 0 | 1 | 0 | 32| FLEN | - | FLW/FSW
+| Standard scalar FP | x | 0 | 1 | 1 | 64| FLEN | - | FLD/FSD
+| Standard scalar FP | x | 1 | 0 | 0 | 128| FLEN | - | FLQ/FSQ
+| Vector 8b element | 0 | 0 | 0 | 0 | 8| 8 | - | VLxE8/VSxE8
+| Vector 16b element | 0 | 1 | 0 | 1 | 16| 16 | - | VLxE16/VSxE16
+| Vector 32b element | 0 | 1 | 1 | 0 | 32| 32 | - | VLxE32/VSxE32
+| Vector 64b element | 0 | 1 | 1 | 1 | 64| 64 | - | VLxE64/VSxE64
+| Vector 8b index | 0 | 0 | 0 | 0 | SEW | SEW | 8 | VLxEI8/VSxEI8
+| Vector 16b index | 0 | 1 | 0 | 1 | SEW | SEW | 16 | VLxEI16/VSxEI16
+| Vector 32b index | 0 | 1 | 1 | 0 | SEW | SEW | 32 | VLxEI32/VSxEI32
+| Vector 64b index | 0 | 1 | 1 | 1 | SEW | SEW | 64 | VLxEI64/VSxEI64
+| Reserved | 1 | X | X | X | - | - | - |
+|===
+
+Mem bits is the size of each element accessed in memory.
+
+Data reg bits is the size of each data element accessed in register.
+
+Index bits is the size of each index accessed in register.
+
+The `mew` bit (`inst[28]`) when set is expected to be used to encode
+expanded memory sizes of 128 bits and above, but these encodings are
+currently reserved.
+
+==== Vector Unit-Stride Instructions
+
+----
+# Vector unit-stride loads and stores
+
+# vd destination, rs1 base address, vm is mask encoding (v0.t or <missing>)
+vle8.v vd, (rs1), vm # 8-bit unit-stride load
+vle16.v vd, (rs1), vm # 16-bit unit-stride load
+vle32.v vd, (rs1), vm # 32-bit unit-stride load
+vle64.v vd, (rs1), vm # 64-bit unit-stride load
+
+# vs3 store data, rs1 base address, vm is mask encoding (v0.t or <missing>)
+vse8.v vs3, (rs1), vm # 8-bit unit-stride store
+vse16.v vs3, (rs1), vm # 16-bit unit-stride store
+vse32.v vs3, (rs1), vm # 32-bit unit-stride store
+vse64.v vs3, (rs1), vm # 64-bit unit-stride store
+----
+
+Additional unit-stride mask load and store instructions are
+provided to transfer mask values to/from memory. These
+operate similarly to unmasked byte loads or stores (EEW=8), except that
+the effective vector length is ``evl``=ceil(``vl``/8) (i.e. EMUL=1),
+and the destination register is always written with a tail-agnostic
+policy.
+
+----
+# Vector unit-stride mask load
+vlm.v vd, (rs1) # Load byte vector of length ceil(vl/8)
+
+# Vector unit-stride mask store
+vsm.v vs3, (rs1) # Store byte vector of length ceil(vl/8)
+----
+
+`vlm.v` and `vsm.v` are encoded with the same `width[2:0]`=0 encoding as
+`vle8.v` and `vse8.v`, but are distinguished by different
+`lumop` and `sumop` encodings. Since `vlm.v` and `vsm.v` operate as byte loads and stores,
+`vstart` is in units of bytes for these instructions.
+
+NOTE: `vlm.v` and `vsm.v` respect the `vill` field in `vtype`, as
+they depend on `vtype` indirectly through its constraints on `vl`.
+
+NOTE: The previous assembler mnemonics `vle1.v` and `vse1.v` were
+confusing as length was handled differently for these instructions
+versus other element load/store instructions. To avoid software
+churn, these older assembly mnemonics are being retained as aliases.
+
+NOTE: The primary motivation to provide mask load and store is to
+support machines that internally rearrange data to reduce
+cross-datapath wiring. However, these instructions also provide a convenient
+mechanism to use packed bit vectors in memory as mask values,
+and also reduce the cost of mask spill/fill by reducing need to change
+`vl`.
+
+==== Vector Constant-Stride Instructions
+
+----
+# Vector constant-stride loads and stores
+
+# vd destination, rs1 base address, rs2 byte constant-stride
+vlse8.v vd, (rs1), rs2, vm # 8-bit constant-stride load
+vlse16.v vd, (rs1), rs2, vm # 16-bit constant-stride load
+vlse32.v vd, (rs1), rs2, vm # 32-bit constant-stride load
+vlse64.v vd, (rs1), rs2, vm # 64-bit constant-stride load
+
+# vs3 store data, rs1 base address, rs2 byte constant-stride
+vsse8.v vs3, (rs1), rs2, vm # 8-bit constant-stride store
+vsse16.v vs3, (rs1), rs2, vm # 16-bit constant-stride store
+vsse32.v vs3, (rs1), rs2, vm # 32-bit constant-stride store
+vsse64.v vs3, (rs1), rs2, vm # 64-bit constant-stride store
+----
+
+Negative and zero strides are supported.
+
+Element accesses within a constant-stride instruction are unordered with
+respect to each other.
+
+When `rs2`=`x0`, then an implementation is allowed, but not required,
+to perform fewer memory operations than the number of active elements,
+and may perform different numbers of memory operations across
+different dynamic executions of the same static instruction.
+
+NOTE: Compilers must be aware to not use the `x0` form for rs2 when
+the immediate stride is `0` if the intent is to require all memory
+accesses are performed.
+
+When `rs2!=x0` and the value of `x[rs2]=0`, the implementation must
+perform one memory access for each active element (but these accesses
+will not be ordered).
+
+NOTE: As with other architectural mandates, implementations must
+_appear_ to perform each memory access. Microarchitectures are
+free to optimize away accesses that would not be observed by another
+agent, for example, in idempotent memory regions obeying RVWMO. For
+non-idempotent memory regions, where by definition each access can be
+observed by a device, the optimization would not be possible.
+
+NOTE: When repeating ordered vector accesses to the same memory
+address are required, then an ordered indexed operation can be used.
+
+==== Vector Indexed Instructions
+
+----
+# Vector indexed loads and stores
+
+# Vector indexed-unordered load instructions
+# vd destination, rs1 base address, vs2 byte offsets
+vluxei8.v vd, (rs1), vs2, vm # unordered 8-bit indexed load of SEW data
+vluxei16.v vd, (rs1), vs2, vm # unordered 16-bit indexed load of SEW data
+vluxei32.v vd, (rs1), vs2, vm # unordered 32-bit indexed load of SEW data
+vluxei64.v vd, (rs1), vs2, vm # unordered 64-bit indexed load of SEW data
+
+# Vector indexed-ordered load instructions
+# vd destination, rs1 base address, vs2 byte offsets
+vloxei8.v vd, (rs1), vs2, vm # ordered 8-bit indexed load of SEW data
+vloxei16.v vd, (rs1), vs2, vm # ordered 16-bit indexed load of SEW data
+vloxei32.v vd, (rs1), vs2, vm # ordered 32-bit indexed load of SEW data
+vloxei64.v vd, (rs1), vs2, vm # ordered 64-bit indexed load of SEW data
+
+# Vector indexed-unordered store instructions
+# vs3 store data, rs1 base address, vs2 byte offsets
+vsuxei8.v vs3, (rs1), vs2, vm # unordered 8-bit indexed store of SEW data
+vsuxei16.v vs3, (rs1), vs2, vm # unordered 16-bit indexed store of SEW data
+vsuxei32.v vs3, (rs1), vs2, vm # unordered 32-bit indexed store of SEW data
+vsuxei64.v vs3, (rs1), vs2, vm # unordered 64-bit indexed store of SEW data
+
+# Vector indexed-ordered store instructions
+# vs3 store data, rs1 base address, vs2 byte offsets
+vsoxei8.v vs3, (rs1), vs2, vm # ordered 8-bit indexed store of SEW data
+vsoxei16.v vs3, (rs1), vs2, vm # ordered 16-bit indexed store of SEW data
+vsoxei32.v vs3, (rs1), vs2, vm # ordered 32-bit indexed store of SEW data
+vsoxei64.v vs3, (rs1), vs2, vm # ordered 64-bit indexed store of SEW data
+----
+
+NOTE: The assembler syntax for indexed loads and stores uses
+``ei``__x__ instead of ``e``__x__ to indicate the statically encoded EEW
+is of the index not the data.
+
+NOTE: The indexed operations mnemonics have a "U" or "O" to
+distinguish between unordered and ordered, while the other vector
+addressing modes have no character. While this is perhaps a little
+less consistent, this approach minimizes disruption to existing
+software, as VSXEI previously meant "ordered" - and the opcode can be
+retained as an alias during transition to help reduce software churn.
+
+==== Unit-stride Fault-Only-First Loads
+
+The unit-stride fault-only-first load instructions are used to
+vectorize loops with data-dependent exit conditions ("while" loops).
+These instructions execute as a regular load except that they will
+only take a trap caused by a synchronous exception on element 0. If
+element 0 raises an exception, `vl` is not modified, and the trap is
+taken. If an element > 0 raises an exception, the corresponding trap
+is not taken, and the vector length `vl` is reduced to the index of
+the element that would have raised an exception.
+
+Load instructions may overwrite active destination vector register
+group elements past the element index at which the trap is reported.
+Similarly, fault-only-first load instructions may update active destination
+elements past the element that causes trimming of the vector length
+(but not past the original vector length). The values of these
+spurious updates do not have to correspond to the values in memory at
+the addressed memory locations. Non-idempotent memory locations can
+only be accessed when it is known the corresponding element load
+operation will not be restarted due to a trap or vector-length
+trimming.
+
+----
+# Vector unit-stride fault-only-first loads
+
+# vd destination, rs1 base address, vm is mask encoding (v0.t or <missing>)
+vle8ff.v vd, (rs1), vm # 8-bit unit-stride fault-only-first load
+vle16ff.v vd, (rs1), vm # 16-bit unit-stride fault-only-first load
+vle32ff.v vd, (rs1), vm # 32-bit unit-stride fault-only-first load
+vle64ff.v vd, (rs1), vm # 64-bit unit-stride fault-only-first load
+----
+
+----
+strlen example using unit-stride fault-only-first instruction
+
+include::example/strlen.s[lines=4..-1]
+----
+
+NOTE: There is a security concern with fault-on-first loads, as they
+can be used to probe for valid effective addresses. The unit-stride
+versions only allow probing a region immediately contiguous to a known
+region, and so reduce the security impact when used in unprivileged
+code. However, code running in S-mode can establish arbitrary page
+translations that allow probing of random guest physical addresses
+provided by a hypervisor. Constant-stride and scatter/gather fault-only-first
+instructions are not provided due to lack of encoding space, but they
+can also represent a larger security hole, allowing even unprivileged
+software to easily check multiple random pages for accessibility
+without experiencing a trap. This standard does not address possible
+security mitigations for fault-only-first instructions.
+
+Even when an exception is not raised, implementations are permitted to process
+fewer than `vl` elements and reduce `vl` accordingly, but if `vstart`=0 and
+`vl`>0, then at least one element must be processed.
+
+When the fault-only-first instruction takes a trap due to an
+interrupt, implementations should not reduce `vl` and should instead
+set a `vstart` value.
+
+NOTE: When the fault-only-first instruction would trigger a debug
+data-watchpoint trap on an element after the first, implementations
+should not reduce `vl` but instead should trigger the debug trap as
+otherwise the event might be lost.
+
+[[sec-aos]]
+==== Vector Load/Store Segment Instructions
+
+The vector load/store segment instructions move multiple contiguous
+fields in memory to and from consecutively numbered vector registers.
+
+NOTE: The name "segment" reflects that the items moved are subarrays
+with homogeneous elements. These operations can be used to transpose
+arrays between memory and registers, and can support operations on
+"array-of-structures" datatypes by unpacking each field in a structure
+into a separate vector register.
+
+The three-bit `nf` field in the vector instruction encoding is an
+unsigned integer that contains one less than the number of fields per
+segment, _NFIELDS_.
+
+[[fig-nf]]
+.NFIELDS Encoding
+[cols="1,1,1,13"]
+|===
+3+| nf[2:0] | NFIELDS
+
+| 0 | 0 | 0 | 1
+| 0 | 0 | 1 | 2
+| 0 | 1 | 0 | 3
+| 0 | 1 | 1 | 4
+| 1 | 0 | 0 | 5
+| 1 | 0 | 1 | 6
+| 1 | 1 | 0 | 7
+| 1 | 1 | 1 | 8
+|===
+
+The EMUL setting must be such that EMUL * NFIELDS {le} 8, otherwise
+the instruction encoding is reserved.
+
+NOTE: The product ceil(EMUL) * NFIELDS represents the number of underlying
+vector registers that will be touched by a segmented load or store
+instruction. This constraint makes this total no larger than 1/4 of
+the architectural register file, and the same as for regular
+operations with EMUL=8.
+
+Each field will be held in successively numbered vector register
+groups. When EMUL>1, each field will occupy a vector register group
+held in multiple successively numbered vector registers, and the
+vector register group for each field must follow the usual vector
+register alignment constraints (e.g., when EMUL=2 and NFIELDS=4, each
+field's vector register group must start at an even vector register,
+but does not have to start at a multiple of 8 vector register number).
+
+If the vector register numbers accessed by the segment load or store
+would increment past 31, then the instruction encoding is reserved.
+
+NOTE: This constraint is to help allow for forward-compatibility with
+a possible future longer instruction encoding that has more
+addressable vector registers.
+
+The `vl` register gives the number of segments to move, which is
+equal to the number of elements transferred to each vector register
+group. Masking is also applied at the level of whole segments.
+
+For segment loads and stores, the individual memory accesses used to
+access fields within each segment are unordered with respect to each
+other even for ordered indexed segment loads and stores.
+
+The `vstart` value is in units of whole segments. If a trap occurs during
+access to a segment, it is implementation-defined whether a subset
+of the faulting segment's accesses are performed before the trap is taken.
+
+===== Vector Unit-Stride Segment Loads and Stores
+
+The vector unit-stride load and store segment instructions move packed
+contiguous segments into multiple destination vector register groups.
+
+NOTE: Where the segments hold structures with heterogeneous-sized
+fields, software can later unpack individual structure fields using
+additional instructions after the segment load brings data into the
+vector registers.
+
+The assembler prefixes `vlseg`/`vsseg` are used for unit-stride
+segment loads and stores respectively.
+
+----
+# Format
+# In this syntax, <nf> equals NFIELDS and is an integer in the range [2, 8].
+vlseg<nf>e<eew>.v vd, (rs1), vm # Unit-stride segment load template
+vsseg<nf>e<eew>.v vs3, (rs1), vm # Unit-stride segment store template
+
+# Examples
+vlseg8e8.v vd, (rs1), vm # Load eight vector registers with eight byte fields.
+
+vsseg3e32.v vs3, (rs1), vm # Store packed vector of 3*4-byte segments from vs3,vs3+1,vs3+2 to memory
+----
+
+For loads, the `vd` register will hold the first field loaded from the
+segment. For stores, the `vs3` register is read to provide the first
+field to be stored to each segment.
+
+----
+# Example 1
+# Memory structure holds packed RGB pixels (24-bit data structure, 8bpp)
+vsetvli a1, t0, e8, m1, ta, ma
+vlseg3e8.v v8, (a0), vm
+# v8 holds the red pixels
+# v9 holds the green pixels
+# v10 holds the blue pixels
+
+# Example 2
+# Memory structure holds complex values, 32b for real and 32b for imaginary
+vsetvli a1, t0, e32, m1, ta, ma
+vlseg2e32.v v8, (a0), vm
+# v8 holds real
+# v9 holds imaginary
+----
+
+There are also fault-only-first versions of the unit-stride instructions.
+
+----
+# Template for vector fault-only-first unit-stride segment loads.
+vlseg<nf>e<eew>ff.v vd, (rs1), vm # Unit-stride fault-only-first segment loads
+----
+
+For fault-only-first segment loads, if an exception is detected partway
+through accessing the zeroth segment, the trap is taken.
+If an exception is detected partway through accessing a subsequent segment,
+`vl` is reduced to the index of that segment.
+In both cases, it is implementation-defined whether a subset of the segment is
+loaded.
+
+These instructions may overwrite destination vector register group
+elements past the point at which a trap is reported or past the point
+at which vector length is trimmed.
+
+===== Vector Constant-Stride Segment Loads and Stores
+
+Vector constant-stride segment loads and stores move contiguous segments where
+each segment is separated by the byte-stride offset given in the `rs2`
+GPR argument.
+
+NOTE: Negative and zero strides are supported.
+
+----
+# Format
+vlsseg<nf>e<eew>.v vd, (rs1), rs2, vm # Constant-stride segment loads
+vssseg<nf>e<eew>.v vs3, (rs1), rs2, vm # Constant-stride segment stores
+
+# Examples
+vsetvli a1, t0, e8, m1, ta, ma
+vlsseg3e8.v v4, (x5), x6 # Load bytes at addresses x5+i*x6 into v4[i],
+ # and bytes at addresses x5+i*x6+1 into v5[i],
+ # and bytes at addresses x5+i*x6+2 into v6[i].
+
+# Examples
+vsetvli a1, t0, e32, m1, ta, ma
+vssseg2e32.v v2, (x5), x6 # Store words from v2[i] to address x5+i*x6
+ # and words from v3[i] to address x5+i*x6+4
+----
+
+Accesses to the fields within each segment can occur in any order,
+including the case where the byte stride is such that segments overlap
+in memory.
+
+===== Vector Indexed Segment Loads and Stores
+
+Vector indexed segment loads and stores move contiguous segments where
+each segment is located at an address given by adding the scalar base
+address in the `rs1` field to byte offsets in vector register `vs2`.
+Both ordered and unordered forms are provided, where the ordered forms
+access segments in element order. However, even for the ordered form,
+accesses to the fields within an individual segment are not ordered
+with respect to each other.
+
+The data vector register group has EEW=SEW, EMUL=LMUL, while the index
+vector register group has EEW encoded in the instruction with
+EMUL=(EEW/SEW)*LMUL.
+The EMUL * NFIELDS {le} 8 constraint applies to the data vector register group.
+
+----
+# Format
+vluxseg<nf>ei<eew>.v vd, (rs1), vs2, vm # Indexed-unordered segment loads
+vloxseg<nf>ei<eew>.v vd, (rs1), vs2, vm # Indexed-ordered segment loads
+vsuxseg<nf>ei<eew>.v vs3, (rs1), vs2, vm # Indexed-unordered segment stores
+vsoxseg<nf>ei<eew>.v vs3, (rs1), vs2, vm # Indexed-ordered segment stores
+
+# Examples
+vsetvli a1, t0, e8, m1, ta, ma
+vluxseg3ei8.v v4, (x5), v3 # Load bytes at addresses x5+v3[i] into v4[i],
+ # and bytes at addresses x5+v3[i]+1 into v5[i],
+ # and bytes at addresses x5+v3[i]+2 into v6[i].
+
+# Examples
+vsetvli a1, t0, e32, m1, ta, ma
+vsuxseg2ei32.v v2, (x5), v5 # Store words from v2[i] to address x5+v5[i]
+ # and words from v3[i] to address x5+v5[i]+4
+----
+
+For vector indexed segment loads, the destination vector register
+groups cannot overlap the source vector register group (specified by
+`vs2`), else the instruction encoding is reserved.
+
+NOTE: This constraint supports restart of indexed segment loads
+that raise exceptions partway through loading a structure.
+
+==== Vector Load/Store Whole Register Instructions
+
+Format for Vector Load Whole Register Instructions under LOAD-FP major opcode
+
+////
+31 29 28 27 26 25 24 20 19 15 14 12 11 7 6 0
+ nf | mew| 00 | 1| 01000 | rs1 | width | vd |0000111| VL<nf>R
+////
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x07, attr: 'VL*R*'},
+ {bits: 5, name: 'vd', attr: 'destination of load', type: 2},
+ {bits: 3, name: 'width'},
+ {bits: 5, name: 'rs1', attr: 'base address', type: 4},
+ {bits: 5, name: 8, attr: 'lumop'},
+ {bits: 1, name: 1, attr: 'vm'},
+ {bits: 2, name: 0x10000, attr: 'mop'},
+ {bits: 1, name: 'mew'},
+ {bits: 3, name: 'nf'},
+]}
+....
+
+Format for Vector Store Whole Register Instructions under STORE-FP major opcode
+
+////
+31 29 28 27 26 25 24 20 19 15 14 12 11 7 6 0
+ nf | 0 | 00 | 1| 01000 | rs1 | 000 | vs3 |0100111| VS<nf>R
+////
+
+[wavedrom,,svg]
+....
+{reg: [
+ {bits: 7, name: 0x27, attr: 'VS*R*'},
+ {bits: 5, name: 'vs3', attr: 'store data', type: 2},
+ {bits: 3, name: 0x1000},
+ {bits: 5, name: 'rs1', attr: 'base address', type: 4},
+ {bits: 5, name: 8, attr: 'sumop'},
+ {bits: 1, name: 1, attr: 'vm'},
+ {bits: 2, name: 0x100, attr: 'mop'},
+ {bits: 1, name: 0x100, attr: 'mew'},
+ {bits: 3, name: 'nf'},
+]}
+....
+
+These instructions load and store whole vector register groups.
+
+NOTE: These instructions are intended to be used to save and restore
+vector registers when the type or length of the current contents of
+the vector register is not known, or where modifying `vl` and `vtype`
+would be costly. Examples include compiler register spills, vector
+function calls where values are passed in vector registers, interrupt
+handlers, and OS context switches. Software can determine the number
+of bytes transferred by reading the `vlenb` register.
+
+The load instructions have an EEW encoded in the `mew` and `width`
+fields following the pattern of regular unit-stride loads.
+
+NOTE: Because in-register byte layouts are identical to in-memory byte
+layouts, the same data is written to the destination register group
+regardless of EEW.
+Hence, it would have sufficed to provide only EEW=8 variants.
+The full set of EEW variants is provided so that the encoded EEW can be used
+as a hint to indicate the destination register group will next be accessed
+with this EEW, which aids implementations that rearrange data internally.
+
+The vector whole register store instructions are encoded similar to
+unmasked unit-stride store of elements with EEW=8.
+
+The `nf` field encodes how many vector registers to load and store using the NFIELDS encoding (Figure <<fig-nf>>).
+The encoded number of registers must be a power of 2 and the vector
+register numbers must be aligned as with a vector register group,
+otherwise the instruction encoding is reserved. NFIELDS
+indicates the number of vector registers to transfer, numbered
+successively after the base. Only NFIELDS values of 1, 2, 4, 8 are
+supported, with other values reserved. When multiple registers are
+transferred, the lowest-numbered vector register is held in the
+lowest-numbered memory addresses and successive vector register
+numbers are placed contiguously in memory.
+
+The instructions operate with an effective vector length,
+`evl`=NFIELDS*VLEN/EEW, regardless of current settings in `vtype` and
+`vl`. The usual property that no elements are written if `vstart`
+{ge} `vl` does not apply to these instructions. Instead, no elements
+are written if `vstart` {ge} `evl`.
+
+The instructions operate similarly to unmasked unit-stride load and
+store instructions, with the base address passed in the scalar `x`
+register specified by `rs1`.
+
+Implementations are allowed to raise a misaligned address exception on
+whole register loads and stores if the base address is not naturally
+aligned to the larger of the size of the encoded EEW in bytes (EEW/8)
+or the implementation's smallest supported SEW size in bytes
+(SEW~MIN~/8).
+
+NOTE: Allowing misaligned exceptions to be raised based on
+non-alignment to the encoded EEW simplifies the implementation of these
+instructions. Some subset implementations might not support smaller
+SEW widths, so are allowed to report misaligned exceptions for the
+smallest supported SEW even if larger than encoded EEW. An extreme
+non-standard implementation might have SEW~MIN~>XLEN for example. Software
+environments can mandate the minimum alignment requirements to support
+an ABI.
+
+----
+# Format of whole register load and store instructions.
+vl1r.v v3, (a0) # Pseudoinstruction equal to vl1re8.v
+
+vl1re8.v v3, (a0) # Load v3 with VLEN/8 bytes held at address in a0
+vl1re16.v v3, (a0) # Load v3 with VLEN/16 halfwords held at address in a0
+vl1re32.v v3, (a0) # Load v3 with VLEN/32 words held at address in a0
+vl1re64.v v3, (a0) # Load v3 with VLEN/64 doublewords held at address in a0
+
+vl2r.v v2, (a0) # Pseudoinstruction equal to vl2re8.v
+
+vl2re8.v v2, (a0) # Load v2-v3 with 2*VLEN/8 bytes from address in a0
+vl2re16.v v2, (a0) # Load v2-v3 with 2*VLEN/16 halfwords held at address in a0
+vl2re32.v v2, (a0) # Load v2-v3 with 2*VLEN/32 words held at address in a0
+vl2re64.v v2, (a0) # Load v2-v3 with 2*VLEN/64 doublewords held at address in a0
+
+vl4r.v v4, (a0) # Pseudoinstruction equal to vl4re8.v
+
+vl4re8.v v4, (a0) # Load v4-v7 with 4*VLEN/8 bytes from address in a0
+vl4re16.v v4, (a0)
+vl4re32.v v4, (a0)
+vl4re64.v v4, (a0)
+
+vl8r.v v8, (a0) # Pseudoinstruction equal to vl8re8.v
+
+vl8re8.v v8, (a0) # Load v8-v15 with 8*VLEN/8 bytes from address in a0
+vl8re16.v v8, (a0)
+vl8re32.v v8, (a0)
+vl8re64.v v8, (a0)
+
+vs1r.v v3, (a1) # Store v3 to address in a1
+vs2r.v v2, (a1) # Store v2-v3 to address in a1
+vs4r.v v4, (a1) # Store v4-v7 to address in a1
+vs8r.v v8, (a1) # Store v8-v15 to address in a1
+----
+
+NOTE: We have considered adding a whole register mask load instruction
+(`vl1rm.v`) but have decided to omit from initial extension. The
+primary purpose would be to inform the microarchitecture that the data
+will be used as a mask. The same effect can be achieved with the
+following code sequence, whose cost is at most four instructions. Of
+these, the first could likely be removed as `vl` is often already
+in a scalar register, and the last might already be present if the
+following vector instruction needs a new SEW/LMUL. So, in best case
+only two instructions (of which only one performs vector operations) are needed to synthesize the effect of the
+dedicated instruction:
+----
+csrr t0, vl # Save current vl (potentially not needed)
+vsetvli t1, x0, e8, m8, ta, ma # Maximum VLMAX
+vlm.v v0, (a0) # Load mask register
+vsetvli x0, t0, <new type> # Restore vl (potentially already present)
+----
+
+=== Vector Memory Alignment Constraints
+
+If an element accessed by a vector memory instruction is not naturally
+aligned to the size of the element, either the element is transferred
+successfully or an address-misaligned exception is raised on that
+element.
+
+Support for misaligned vector memory accesses is independent of an
+implementation's support for misaligned scalar memory accesses.
+
+NOTE: An implementation may have neither, one, or both scalar and
+vector memory accesses support some or all misaligned accesses in
+hardware. A separate PMA should be defined to determine if vector
+misaligned accesses are supported in the associated address range.
+
+Vector misaligned memory accesses follow the same rules for atomicity
+as scalar misaligned memory accesses.
+
+=== Vector Memory Consistency Model
+
+Vector memory instructions appear to execute in program order on the
+local hart.
+
+Vector memory instructions follow RVWMO at the instruction level.
+If the Ztso extension is implemented, vector memory instructions additionally
+follow RVTSO at the instruction level.
+
+Except for vector indexed-ordered loads and stores, element operations
+are unordered within the instruction.
+
+Vector indexed-ordered loads and stores read and write elements
+from/to memory in element order respectively,
+obeying RVWMO at the element level.
+
+NOTE: Ztso only imposes RVTSO at the instruction level; intra-instruction
+ordering follows RVWMO regardless of whether Ztso is implemented.
+
+NOTE: More formal definitions required.
+
+Instructions affected by the vector length register `vl` have a control
+dependency on `vl`, rather than a data dependency.
+Similarly, masked vector instructions have a control dependency on the source
+mask register, rather than a data dependency.
+
+NOTE: Treating the vector length and mask as control rather than data
+typically matches the semantics of the corresponding scalar code, where branch
+instructions ordinarily would have been used.
+Treating the mask as control allows masked vector load instructions to access
+memory before the mask value is known, without the need for
+a misspeculation-recovery mechanism.
+
+=== Vector Arithmetic Instruction Formats
+
+The vector arithmetic instructions use a new major opcode (OP-V =
+1010111~2~) which neighbors OP-FP. The three-bit `funct3` field is
+used to define sub-categories of vector instructions.
+
+include::images/wavedrom/valu-format.edn[]
+
+[[sec-arithmetic-encoding]]
+==== Vector Arithmetic Instruction encoding
+
+The `funct3` field encodes the operand type and source locations.
+
+.funct3
+[cols="1,1,1,3,5,5"]
+|===
+3+| funct3[2:0] | Category | Operands | Type of scalar operand
+
+| 0 | 0 | 0 | OPIVV | vector-vector | N/A
+| 0 | 0 | 1 | OPFVV | vector-vector | N/A
+| 0 | 1 | 0 | OPMVV | vector-vector | N/A
+| 0 | 1 | 1 | OPIVI | vector-immediate | `imm[4:0]`
+| 1 | 0 | 0 | OPIVX | vector-scalar | GPR `x` register `rs1`
+| 1 | 0 | 1 | OPFVF | vector-scalar | FP `f` register `rs1`
+| 1 | 1 | 0 | OPMVX | vector-scalar | GPR `x` register `rs1`
+| 1 | 1 | 1 | OPCFG | scalars-imms | GPR `x` register `rs1` & `rs2`/`imm`
+|===
+
+Integer operations are performed using unsigned or two's-complement
+signed integer arithmetic depending on the opcode.
+
+NOTE: In this discussion, fixed-point operations are
+considered to be integer operations.
+
+All standard vector floating-point arithmetic operations follow the
+IEEE-754/2008 standard. All vector floating-point operations use the
+dynamic rounding mode in the `frm` register. Use of the `frm` field
+when it contains an invalid rounding mode by any vector floating-point
+instruction--even those that do not depend on the rounding mode, or
+when `vl`=0, or when `vstart` {ge} `vl`--is reserved.
+
+NOTE: All vector floating-point code will rely on a valid value in
+`frm`. Implementations can make all vector FP instructions report
+exceptions when the rounding mode is invalid to simplify control
+logic.
+
+Vector-vector operations take two vectors of operands from vector
+register groups specified by `vs2` and `vs1` respectively.
+
+Vector-scalar operations can have three possible forms. In all three forms,
+the vector register group operand is specified by `vs2`. The second
+scalar source operand comes from one of three alternative sources:
+
+. For integer operations, the scalar can be a 5-bit immediate, `imm[4:0]`, encoded
+in the `rs1` field. The value is sign-extended to SEW bits, unless
+otherwise specified.
+
+. For integer operations, the scalar can be taken from the scalar `x`
+register specified by `rs1`. If XLEN>SEW, the least-significant SEW
+bits of the `x` register are used, unless otherwise specified. If
+XLEN<SEW, the value from the `x` register is sign-extended to SEW
+bits.
+
+. For floating-point operations, the scalar can be taken from a scalar
+`f` register. If FLEN > SEW, the value in the `f` registers is
+checked for a valid NaN-boxed value, in which case the
+least-significant SEW bits of the `f` register are used, else the
+canonical NaN value is used. Vector instructions where any
+floating-point vector operand's EEW is not a supported floating-point
+type width (which includes when FLEN < SEW) are reserved.
+
+NOTE: Some instructions _zero_-extend the 5-bit immediate, and denote this
+by naming the immediate `uimm` in the assembly syntax.
+
+NOTE: When adding a vector extension to the Zfinx/Zdinx/Zhinx
+extensions, floating-point scalar arguments are taken from the `x`
+registers.
+NaN-boxing is not supported in these extensions, and so operands narrower
+than XLEN bits are not checked for a NaN box; bits XLEN-1:EEW are ignored.
+For RV32_Zdinx, EEW=64 scalar arguments are supplied by an `x`-register pair.
+
+Vector arithmetic instructions are masked under control of the `vm`
+field.
+
+----
+# Assembly syntax pattern for vector binary arithmetic instructions
+
+# Operations returning vector results, masked by vm (v0.t, <nothing>)
+vop.vv vd, vs2, vs1, vm # integer vector-vector vd[i] = vs2[i] op vs1[i]
+vop.vx vd, vs2, rs1, vm # integer vector-scalar vd[i] = vs2[i] op x[rs1]
+vop.vi vd, vs2, imm, vm # integer vector-immediate vd[i] = vs2[i] op imm
+
+vfop.vv vd, vs2, vs1, vm # FP vector-vector operation vd[i] = vs2[i] fop vs1[i]
+vfop.vf vd, vs2, rs1, vm # FP vector-scalar operation vd[i] = vs2[i] fop f[rs1]
+----
+
+NOTE: In the encoding, `vs2` is the first operand, while `rs1/imm`
+is the second operand. This is the opposite to the standard scalar
+ordering. This arrangement retains the existing encoding conventions
+that instructions that read only one scalar register, read it from
+`rs1`, and that 5-bit immediates are sourced from the `rs1` field.
+
+----
+# Assembly syntax pattern for vector ternary arithmetic instructions (multiply-add)
+
+# Integer operations overwriting sum input
+vop.vv vd, vs1, vs2, vm # vd[i] = vs1[i] * vs2[i] + vd[i]
+vop.vx vd, rs1, vs2, vm # vd[i] = x[rs1] * vs2[i] + vd[i]
+
+# Integer operations overwriting product input
+vop.vv vd, vs1, vs2, vm # vd[i] = vs1[i] * vd[i] + vs2[i]
+vop.vx vd, rs1, vs2, vm # vd[i] = x[rs1] * vd[i] + vs2[i]
+
+# Floating-point operations overwriting sum input
+vfop.vv vd, vs1, vs2, vm # vd[i] = vs1[i] * vs2[i] + vd[i]
+vfop.vf vd, rs1, vs2, vm # vd[i] = f[rs1] * vs2[i] + vd[i]
+
+# Floating-point operations overwriting product input
+vfop.vv vd, vs1, vs2, vm # vd[i] = vs1[i] * vd[i] + vs2[i]
+vfop.vf vd, rs1, vs2, vm # vd[i] = f[rs1] * vd[i] + vs2[i]
+----
+
+NOTE: For ternary multiply-add operations, the assembler syntax always
+places the destination vector register first, followed by either `rs1`
+or `vs1`, then `vs2`. This ordering provides a more natural reading
+of the assembler for these ternary operations, as the multiply
+operands are always next to each other.
+
+[[sec-widening]]
+==== Widening Vector Arithmetic Instructions
+
+A few vector arithmetic instructions are defined to be __widening__
+operations where the destination vector register group has EEW=2*SEW
+and EMUL=2*LMUL. These are generally given a `vw*` prefix on the
+opcode, or `vfw*` for vector floating-point instructions.
+
+The first vector register group operand can be either single or
+double-width.
+
+----
+# Assembly syntax pattern for vector widening arithmetic instructions
+
+# Double-width result, two single-width sources: 2*SEW = SEW op SEW
+vwop.vv vd, vs2, vs1, vm # integer vector-vector vd[i] = vs2[i] op vs1[i]
+vwop.vx vd, vs2, rs1, vm # integer vector-scalar vd[i] = vs2[i] op x[rs1]
+
+# Double-width result, first source double-width, second source single-width: 2*SEW = 2*SEW op SEW
+vwop.wv vd, vs2, vs1, vm # integer vector-vector vd[i] = vs2[i] op vs1[i]
+vwop.wx vd, vs2, rs1, vm # integer vector-scalar vd[i] = vs2[i] op x[rs1]
+----
+
+NOTE: Originally, a `w` suffix was used on opcode, but this could be
+confused with the use of a `w` suffix to mean word-sized operations in
+doubleword integers, so the `w` was moved to prefix.
+
+NOTE: The floating-point widening operations were changed to `vfw*`
+from `vwf*` to be more consistent with any scalar widening
+floating-point operations that will be written as `fw*`.
+
+Widening instruction encodings must follow the constraints in
+<<sec-vec-operands>>.
+
+[[sec-narrowing]]
+==== Narrowing Vector Arithmetic Instructions
+
+A few instructions are provided to convert double-width source vectors
+into single-width destination vectors. These instructions convert a
+vector register group specified by `vs2` with EEW/EMUL=2*SEW/2*LMUL to a vector register
+group with the current SEW/LMUL setting. Where there is a second
+source vector register group (specified by `vs1`), this has the same
+(narrower) width as the result (i.e., EEW=SEW).
+
+NOTE: An alternative design decision would have been to treat SEW/LMUL
+as defining the size of the source vector register group. The choice
+here is motivated by the belief the chosen approach will require fewer
+`vtype` changes.
+
+NOTE: Compare operations that set a mask register are also
+implicitly a narrowing operation.
+
+A `vn*` prefix on the opcode is used to distinguish these instructions
+in the assembler, or a `vfn*` prefix for narrowing floating-point
+opcodes. The double-width source vector register group is signified
+by a `w` in the source operand suffix (e.g., `vnsra.wv`)
+
+----
+Assembly syntax pattern for vector narrowing arithmetic instructions
+
+# Single-width result vd, double-width source vs2, single-width source vs1/rs1
+# SEW = 2*SEW op SEW
+vnop.wv vd, vs2, vs1, vm # integer vector-vector vd[i] = vs2[i] op vs1[i]
+vnop.wx vd, vs2, rs1, vm # integer vector-scalar vd[i] = vs2[i] op x[rs1]
+----
+
+Narrowing instruction encodings must follow the constraints in
+<<sec-vec-operands>>.
+
+[[sec-vector-integer]]
+=== Vector Integer Arithmetic Instructions
+
+A set of vector integer arithmetic instructions is provided. Unless
+otherwise stated, integer operations wrap around on overflow.
+
+==== Vector Single-Width Integer Add and Subtract
+
+Vector integer add and subtract are provided. Reverse-subtract
+instructions are also provided for the vector-scalar forms.
+
+----
+# Integer adds.
+vadd.vv vd, vs2, vs1, vm # Vector-vector
+vadd.vx vd, vs2, rs1, vm # vector-scalar
+vadd.vi vd, vs2, imm, vm # vector-immediate
+
+# Integer subtract
+vsub.vv vd, vs2, vs1, vm # Vector-vector
+vsub.vx vd, vs2, rs1, vm # vector-scalar
+
+# Integer reverse subtract
+vrsub.vx vd, vs2, rs1, vm # vd[i] = x[rs1] - vs2[i]
+vrsub.vi vd, vs2, imm, vm # vd[i] = imm - vs2[i]
+----
+
+NOTE: A vector of integer values can be negated using a
+reverse-subtract instruction with a scalar operand of `x0`. An
+assembly pseudoinstruction `vneg.v vd,vs` = `vrsub.vx vd,vs,x0` is provided.
+
+==== Vector Widening Integer Add/Subtract
+
+The widening add/subtract instructions are provided in both signed and
+unsigned variants, depending on whether the narrower source operands
+are first sign- or zero-extended before forming the double-width sum.
+
+----
+# Widening unsigned integer add/subtract, 2*SEW = SEW +/- SEW
+vwaddu.vv vd, vs2, vs1, vm # vector-vector
+vwaddu.vx vd, vs2, rs1, vm # vector-scalar
+vwsubu.vv vd, vs2, vs1, vm # vector-vector
+vwsubu.vx vd, vs2, rs1, vm # vector-scalar
+
+# Widening signed integer add/subtract, 2*SEW = SEW +/- SEW
+vwadd.vv vd, vs2, vs1, vm # vector-vector
+vwadd.vx vd, vs2, rs1, vm # vector-scalar
+vwsub.vv vd, vs2, vs1, vm # vector-vector
+vwsub.vx vd, vs2, rs1, vm # vector-scalar
+
+# Widening unsigned integer add/subtract, 2*SEW = 2*SEW +/- SEW
+vwaddu.wv vd, vs2, vs1, vm # vector-vector
+vwaddu.wx vd, vs2, rs1, vm # vector-scalar
+vwsubu.wv vd, vs2, vs1, vm # vector-vector
+vwsubu.wx vd, vs2, rs1, vm # vector-scalar
+
+# Widening signed integer add/subtract, 2*SEW = 2*SEW +/- SEW
+vwadd.wv vd, vs2, vs1, vm # vector-vector
+vwadd.wx vd, vs2, rs1, vm # vector-scalar
+vwsub.wv vd, vs2, vs1, vm # vector-vector
+vwsub.wx vd, vs2, rs1, vm # vector-scalar
+----
+
+NOTE: An integer value can be doubled in width using the widening add
+instructions with a scalar operand of `x0`. Assembly
+pseudoinstructions `vwcvt.x.x.v vd,vs,vm` = `vwadd.vx vd,vs,x0,vm` and
+`vwcvtu.x.x.v vd,vs,vm` = `vwaddu.vx vd,vs,x0,vm` are provided.
+
+==== Vector Integer Extension
+
+The vector integer extension instructions zero- or sign-extend a
+source vector integer operand with EEW less than SEW to fill SEW-sized
+elements in the destination. The EEW of the source is 1/2, 1/4, or
+1/8 of SEW, while EMUL of the source is (EEW/SEW)*LMUL. The
+destination has EEW equal to SEW and EMUL equal to LMUL.
+
+----
+vzext.vf2 vd, vs2, vm # Zero-extend SEW/2 source to SEW destination
+vsext.vf2 vd, vs2, vm # Sign-extend SEW/2 source to SEW destination
+vzext.vf4 vd, vs2, vm # Zero-extend SEW/4 source to SEW destination
+vsext.vf4 vd, vs2, vm # Sign-extend SEW/4 source to SEW destination
+vzext.vf8 vd, vs2, vm # Zero-extend SEW/8 source to SEW destination
+vsext.vf8 vd, vs2, vm # Sign-extend SEW/8 source to SEW destination
+----
+
+If the source EEW is not a supported width, or source EMUL would be
+below the minimum legal LMUL, the instruction encoding is reserved.
+
+NOTE: Standard vector load instructions access memory values that are
+the same size as the destination register elements. Some application
+code needs to operate on a range of operand widths in a wider element,
+for example, loading a byte from memory and adding to an eight-byte
+element. To avoid having to provide the cross-product of the number
+of vector load instructions by the number of data types (byte, word,
+halfword, and also signed/unsigned variants), we instead add explicit
+extension instructions that can be used if an appropriate widening
+arithmetic instruction is not available.
+
+==== Vector Integer Add-with-Carry / Subtract-with-Borrow Instructions
+
+To support multi-word integer arithmetic, instructions that operate on
+a carry bit are provided. For each operation (add or subtract), two
+instructions are provided: one to provide the result (SEW width), and
+the second to generate the carry output (single bit encoded as a mask
+boolean).
+
+The carry inputs and outputs are represented using the mask register
+layout as described in <<sec-mask-register-layout>>. Due to
+encoding constraints, the carry input must come from the implicit `v0`
+register, but carry outputs can be written to any vector register that
+respects the source/destination overlap restrictions.
+
+`vadc` and `vsbc` add or subtract the source operands and the carry-in or
+borrow-in, and write the result to vector register `vd`.
+These instructions are encoded as masked instructions (`vm=0`), but they operate
+on and write back all body elements.
+Encodings corresponding to the unmasked versions (`vm=1`) are reserved.
+
+`vmadc` and `vmsbc` add or subtract the source operands, optionally
+add the carry-in or subtract the borrow-in if masked (`vm=0`), and
+write the resulting carry-out or borrow-out back to mask register `vd`.
+If unmasked (`vm=1`), there is no carry-in or borrow-in. These instructions
+operate on and write back all body elements, even if masked. Because these
+instructions produce a mask value, they always operate with a
+tail-agnostic policy.
+
+----
+ # Produce sum with carry.
+
+ # vd[i] = vs2[i] + vs1[i] + v0.mask[i]
+ vadc.vvm vd, vs2, vs1, v0 # Vector-vector
+
+ # vd[i] = vs2[i] + x[rs1] + v0.mask[i]
+ vadc.vxm vd, vs2, rs1, v0 # Vector-scalar
+
+ # vd[i] = vs2[i] + imm + v0.mask[i]
+ vadc.vim vd, vs2, imm, v0 # Vector-immediate
+
+ # Produce carry out in mask register format
+
+ # vd.mask[i] = carry_out(vs2[i] + vs1[i] + v0.mask[i])
+ vmadc.vvm vd, vs2, vs1, v0 # Vector-vector
+
+ # vd.mask[i] = carry_out(vs2[i] + x[rs1] + v0.mask[i])
+ vmadc.vxm vd, vs2, rs1, v0 # Vector-scalar
+
+ # vd.mask[i] = carry_out(vs2[i] + imm + v0.mask[i])
+ vmadc.vim vd, vs2, imm, v0 # Vector-immediate
+
+ # vd.mask[i] = carry_out(vs2[i] + vs1[i])
+ vmadc.vv vd, vs2, vs1 # Vector-vector, no carry-in
+
+ # vd.mask[i] = carry_out(vs2[i] + x[rs1])
+ vmadc.vx vd, vs2, rs1 # Vector-scalar, no carry-in
+
+ # vd.mask[i] = carry_out(vs2[i] + imm)
+ vmadc.vi vd, vs2, imm # Vector-immediate, no carry-in
+----
+
+Because implementing a carry propagation requires executing two
+instructions with unchanged inputs, destructive accumulations will
+require an additional move to obtain correct results.
+
+----
+# Example multi-word arithmetic sequence, accumulating into v4
+vmadc.vvm v1, v4, v8, v0 # Get carry into temp register v1
+vadc.vvm v4, v4, v8, v0 # Calc new sum
+vmmv.m v0, v1 # Move temp carry into v0 for next word
+----
+
+The subtract with borrow instruction `vsbc` performs the equivalent
+function to support long word arithmetic for subtraction. There are
+no subtract with immediate instructions.
+
+----
+# Produce difference with borrow.
+
+# vd[i] = vs2[i] - vs1[i] - v0.mask[i]
+vsbc.vvm vd, vs2, vs1, v0 # Vector-vector
+
+# vd[i] = vs2[i] - x[rs1] - v0.mask[i]
+vsbc.vxm vd, vs2, rs1, v0 # Vector-scalar
+
+# Produce borrow out in mask register format
+
+# vd.mask[i] = borrow_out(vs2[i] - vs1[i] - v0.mask[i])
+vmsbc.vvm vd, vs2, vs1, v0 # Vector-vector
+
+# vd.mask[i] = borrow_out(vs2[i] - x[rs1] - v0.mask[i])
+vmsbc.vxm vd, vs2, rs1, v0 # Vector-scalar
+
+# vd.mask[i] = borrow_out(vs2[i] - vs1[i])
+vmsbc.vv vd, vs2, vs1 # Vector-vector, no borrow-in
+
+# vd.mask[i] = borrow_out(vs2[i] - x[rs1])
+vmsbc.vx vd, vs2, rs1 # Vector-scalar, no borrow-in
+----
+
+For `vmsbc`, the borrow is defined to be 1 iff the difference, prior to
+truncation, is negative.
+
+For `vadc` and `vsbc`, the instruction encoding is reserved if the
+destination vector register is `v0`.
+
+NOTE: This constraint corresponds to the constraint on masked vector
+operations that overwrite the mask register.
+
+==== Vector Bitwise Logical Instructions
+
+----
+# Bitwise logical operations.
+vand.vv vd, vs2, vs1, vm # Vector-vector
+vand.vx vd, vs2, rs1, vm # vector-scalar
+vand.vi vd, vs2, imm, vm # vector-immediate
+
+vor.vv vd, vs2, vs1, vm # Vector-vector
+vor.vx vd, vs2, rs1, vm # vector-scalar
+vor.vi vd, vs2, imm, vm # vector-immediate
+
+vxor.vv vd, vs2, vs1, vm # Vector-vector
+vxor.vx vd, vs2, rs1, vm # vector-scalar
+vxor.vi vd, vs2, imm, vm # vector-immediate
+----
+
+NOTE: With an immediate of -1, scalar-immediate forms of the `vxor`
+instruction provide a bitwise NOT operation. This is provided as
+an assembler pseudoinstruction `vnot.v vd,vs,vm` = `vxor.vi vd,vs,-1,vm`.
+
+==== Vector Single-Width Shift Instructions
+
+A full set of vector shift instructions are provided, including
+logical shift left (`sll`), and logical (zero-extending `srl`) and
+arithmetic (sign-extending `sra`) shift right. The data to be shifted
+is in the vector register group specified by `vs2` and the shift
+amount value can come from a vector register group `vs1`, a scalar
+integer register `rs1`, or a zero-extended 5-bit immediate. Only the low
+lg2(SEW) bits of the shift-amount value are used to control the shift
+amount.
+
+----
+# Bit shift operations
+vsll.vv vd, vs2, vs1, vm # Vector-vector
+vsll.vx vd, vs2, rs1, vm # vector-scalar
+vsll.vi vd, vs2, uimm, vm # vector-immediate
+
+vsrl.vv vd, vs2, vs1, vm # Vector-vector
+vsrl.vx vd, vs2, rs1, vm # vector-scalar
+vsrl.vi vd, vs2, uimm, vm # vector-immediate
+
+vsra.vv vd, vs2, vs1, vm # Vector-vector
+vsra.vx vd, vs2, rs1, vm # vector-scalar
+vsra.vi vd, vs2, uimm, vm # vector-immediate
+----
+
+==== Vector Narrowing Integer Right Shift Instructions
+
+The narrowing right shifts extract a smaller field from a wider
+operand and have both zero-extending (`srl`) and sign-extending
+(`sra`) forms. The shift amount can come from a vector register
+group, or a scalar `x` register, or a zero-extended 5-bit immediate.
+The low lg2(2*SEW) bits of the shift-amount value are
+used (e.g., the low 6 bits for a SEW=64-bit to SEW=32-bit narrowing
+operation).
+
+----
+ # Narrowing shift right logical, SEW = (2*SEW) >> SEW
+ vnsrl.wv vd, vs2, vs1, vm # vector-vector
+ vnsrl.wx vd, vs2, rs1, vm # vector-scalar
+ vnsrl.wi vd, vs2, uimm, vm # vector-immediate
+
+ # Narrowing shift right arithmetic, SEW = (2*SEW) >> SEW
+ vnsra.wv vd, vs2, vs1, vm # vector-vector
+ vnsra.wx vd, vs2, rs1, vm # vector-scalar
+ vnsra.wi vd, vs2, uimm, vm # vector-immediate
+----
+
+NOTE: Future extensions might add support for versions that narrow to
+a destination that is 1/4 the width of the source.
+
+NOTE: An integer value can be halved in width using the narrowing integer
+shift instructions with a scalar operand of `x0`. An assembly
+pseudoinstruction is provided `vncvt.x.x.w vd,vs,vm` = `vnsrl.wx vd,vs,x0,vm`.
+
+==== Vector Integer Compare Instructions
+
+The following integer compare instructions write 1 to the destination
+mask register element if the comparison evaluates to true, and 0
+otherwise. The destination mask vector is always held in a single
+vector register, with a layout of elements as described in
+<<sec-mask-register-layout>>. The destination mask vector register
+may be the same as the source vector mask register (`v0`).
+
+----
+# Set if equal
+vmseq.vv vd, vs2, vs1, vm # Vector-vector
+vmseq.vx vd, vs2, rs1, vm # vector-scalar
+vmseq.vi vd, vs2, imm, vm # vector-immediate
+
+# Set if not equal
+vmsne.vv vd, vs2, vs1, vm # Vector-vector
+vmsne.vx vd, vs2, rs1, vm # vector-scalar
+vmsne.vi vd, vs2, imm, vm # vector-immediate
+
+# Set if less than, unsigned
+vmsltu.vv vd, vs2, vs1, vm # Vector-vector
+vmsltu.vx vd, vs2, rs1, vm # Vector-scalar
+
+# Set if less than, signed
+vmslt.vv vd, vs2, vs1, vm # Vector-vector
+vmslt.vx vd, vs2, rs1, vm # vector-scalar
+
+# Set if less than or equal, unsigned
+vmsleu.vv vd, vs2, vs1, vm # Vector-vector
+vmsleu.vx vd, vs2, rs1, vm # vector-scalar
+vmsleu.vi vd, vs2, imm, vm # Vector-immediate
+
+# Set if less than or equal, signed
+vmsle.vv vd, vs2, vs1, vm # Vector-vector
+vmsle.vx vd, vs2, rs1, vm # vector-scalar
+vmsle.vi vd, vs2, imm, vm # vector-immediate
+
+# Set if greater than, unsigned
+vmsgtu.vx vd, vs2, rs1, vm # Vector-scalar
+vmsgtu.vi vd, vs2, imm, vm # Vector-immediate
+
+# Set if greater than, signed
+vmsgt.vx vd, vs2, rs1, vm # Vector-scalar
+vmsgt.vi vd, vs2, imm, vm # Vector-immediate
+
+# Following two instructions are not provided directly
+# Set if greater than or equal, unsigned
+# vmsgeu.vx vd, vs2, rs1, vm # Vector-scalar
+# Set if greater than or equal, signed
+# vmsge.vx vd, vs2, rs1, vm # Vector-scalar
+----
+
+The following table indicates how all comparisons are implemented in
+native machine code.
+
+----
+Comparison Assembler Mapping Assembler Pseudoinstruction
+
+va < vb vmslt{u}.vv vd, va, vb, vm
+va <= vb vmsle{u}.vv vd, va, vb, vm
+va > vb vmslt{u}.vv vd, vb, va, vm vmsgt{u}.vv vd, va, vb, vm
+va >= vb vmsle{u}.vv vd, vb, va, vm vmsge{u}.vv vd, va, vb, vm
+
+va < x vmslt{u}.vx vd, va, x, vm
+va <= x vmsle{u}.vx vd, va, x, vm
+va > x vmsgt{u}.vx vd, va, x, vm
+va >= x see below
+
+va < i vmsle{u}.vi vd, va, i-1, vm vmslt{u}.vi vd, va, i, vm
+va <= i vmsle{u}.vi vd, va, i, vm
+va > i vmsgt{u}.vi vd, va, i, vm
+va >= i vmsgt{u}.vi vd, va, i-1, vm vmsge{u}.vi vd, va, i, vm
+
+va, vb vector register groups
+x scalar integer register
+i immediate
+----
+
+NOTE: The immediate forms of `vmslt{u}.vi` are not provided as the
+immediate value can be decreased by 1 and the `vmsle{u}.vi` variants
+used instead. The `vmsle.vi` range is -16 to 15, resulting in an
+effective `vmslt.vi` range of -15 to 16. The `vmsleu.vi` range is 0
+to 15 giving an effective `vmsltu.vi` range of 1 to 16 (Note,
+`vmsltu.vi` with immediate 0 is not useful as it is always
+false).
+
+NOTE: Because the 5-bit vector immediates are always sign-extended,
+when the high bit of the `simm5` immediate is set, `vmsleu.vi` also
+supports unsigned immediate values in the range `2^SEW^-16` to
+`2^SEW^-1`, allowing corresponding `vmsltu.vi` compares against
+unsigned immediates in the range `2^SEW^-15` to `2^SEW^`. Note that
+`vmsltu.vi` with immediate `2^SEW^` is not useful as it is always
+true.
+
+Similarly, `vmsge{u}.vi` is not provided and the compare is
+implemented using `vmsgt{u}.vi` with the immediate decremented by one.
+The resulting effective `vmsge.vi` range is -15 to 16, and the
+resulting effective `vmsgeu.vi` range is 1 to 16 (Note, `vmsgeu.vi` with
+immediate 0 is not useful as it is always true).
+
+NOTE: The `vmsgt` forms for register scalar and immediates are provided
+to allow a single compare instruction to provide the correct
+polarity of mask value without using additional mask logical
+instructions.
+
+To reduce encoding space, the `vmsge{u}.vx` form is not directly
+provided, and so the `va {ge} x` case requires special treatment.
+
+NOTE: The `vmsge{u}.vx` could potentially be encoded in a
+non-orthogonal way under the unused OPIVI variant of `vmslt{u}`. These
+would be the only instructions in OPIVI that use a scalar `x`register
+however. Alternatively, a further two funct6 encodings could be used,
+but these would have a different operand format (writes to mask
+register) than others in the same group of 8 funct6 encodings. The
+current PoR is to omit these instructions and to synthesize where
+needed as described below.
+
+The `vmsge{u}.vx` operation can be synthesized by reducing the
+value of `x` by 1 and using the `vmsgt{u}.vx` instruction, when it is
+known that this will not underflow the representation in `x`.
+
+----
+Sequences to synthesize `vmsge{u}.vx` instruction
+
+va >= x, x > minimum
+
+ addi t0, x, -1; vmsgt{u}.vx vd, va, t0, vm
+----
+
+The above sequence will usually be the most efficient implementation,
+but assembler pseudoinstructions can be provided for cases where the
+range of `x` is unknown.
+
+----
+unmasked va >= x
+
+ pseudoinstruction: vmsge{u}.vx vd, va, x
+ expansion: vmslt{u}.vx vd, va, x; vmnand.mm vd, vd, vd
+
+masked va >= x, vd != v0
+
+ pseudoinstruction: vmsge{u}.vx vd, va, x, v0.t
+ expansion: vmslt{u}.vx vd, va, x, v0.t; vmxor.mm vd, vd, v0
+
+masked va >= x, vd == v0
+
+ pseudoinstruction: vmsge{u}.vx vd, va, x, v0.t, vt
+ expansion: vmslt{u}.vx vt, va, x; vmandn.mm vd, vd, vt
+
+masked va >= x, any vd
+
+ pseudoinstruction: vmsge{u}.vx vd, va, x, v0.t, vt
+ expansion: vmslt{u}.vx vt, va, x; vmandn.mm vt, v0, vt; vmandn.mm vd, vd, v0; vmor.mm vd, vt, vd
+
+ The vt argument to the pseudoinstruction must name a temporary vector register that is
+ not same as vd and which will be clobbered by the pseudoinstruction
+----
+
+Compares effectively AND in the mask under a mask-undisturbed policy if the destination register is `v0`, e.g.,
+
+----
+# (a < b) && (b < c) in two instructions when mask-undisturbed
+vmslt.vv v0, va, vb # All body elements written
+vmslt.vv v0, vb, vc, v0.t # Only update at set mask
+----
+
+Compares write mask registers, and so always operate under a
+tail-agnostic policy.
+
+==== Vector Integer Min/Max Instructions
+
+Signed and unsigned integer minimum and maximum instructions are
+supported.
+
+----
+# Unsigned minimum
+vminu.vv vd, vs2, vs1, vm # Vector-vector
+vminu.vx vd, vs2, rs1, vm # vector-scalar
+
+# Signed minimum
+vmin.vv vd, vs2, vs1, vm # Vector-vector
+vmin.vx vd, vs2, rs1, vm # vector-scalar
+
+# Unsigned maximum
+vmaxu.vv vd, vs2, vs1, vm # Vector-vector
+vmaxu.vx vd, vs2, rs1, vm # vector-scalar
+
+# Signed maximum
+vmax.vv vd, vs2, vs1, vm # Vector-vector
+vmax.vx vd, vs2, rs1, vm # vector-scalar
+----
+
+==== Vector Single-Width Integer Multiply Instructions
+
+The single-width multiply instructions perform a SEW-bit*SEW-bit
+multiply to generate a 2*SEW-bit product, then return one half of the
+product in the SEW-bit-wide destination. The `*mul*` versions write
+the low word of the product to the destination register, while the
+`*mulh*` versions write the high word of the product to the
+destination register.
+
+----
+# Signed multiply, returning low bits of product
+vmul.vv vd, vs2, vs1, vm # Vector-vector
+vmul.vx vd, vs2, rs1, vm # vector-scalar
+
+# Signed multiply, returning high bits of product
+vmulh.vv vd, vs2, vs1, vm # Vector-vector
+vmulh.vx vd, vs2, rs1, vm # vector-scalar
+
+# Unsigned multiply, returning high bits of product
+vmulhu.vv vd, vs2, vs1, vm # Vector-vector
+vmulhu.vx vd, vs2, rs1, vm # vector-scalar
+
+# Signed(vs2)-Unsigned multiply, returning high bits of product
+vmulhsu.vv vd, vs2, vs1, vm # Vector-vector
+vmulhsu.vx vd, vs2, rs1, vm # vector-scalar
+----
+
+NOTE: There is no `vmulhus.vx` opcode to return high half of
+unsigned-vector * signed-scalar product. The scalar can be splatted
+to a vector, then a `vmulhsu.vv` used.
+
+NOTE: The current `vmulh*` opcodes perform simple fractional
+multiplies, but with no option to scale, round, and/or saturate the
+result. A possible future extension can consider variants of `vmulh`,
+`vmulhu`, `vmulhsu` that use the `vxrm` rounding mode when discarding
+low half of product. There is no possibility of overflow in these
+cases.
+
+==== Vector Integer Divide Instructions
+
+The divide and remainder instructions are equivalent to the RISC-V
+standard scalar integer multiply/divides, with the same results for
+extreme inputs.
+
+----
+# Unsigned divide.
+vdivu.vv vd, vs2, vs1, vm # Vector-vector
+vdivu.vx vd, vs2, rs1, vm # vector-scalar
+
+# Signed divide
+vdiv.vv vd, vs2, vs1, vm # Vector-vector
+vdiv.vx vd, vs2, rs1, vm # vector-scalar
+
+# Unsigned remainder
+vremu.vv vd, vs2, vs1, vm # Vector-vector
+vremu.vx vd, vs2, rs1, vm # vector-scalar
+
+# Signed remainder
+vrem.vv vd, vs2, vs1, vm # Vector-vector
+vrem.vx vd, vs2, rs1, vm # vector-scalar
+----
+
+NOTE: The decision to include integer divide and remainder was
+contentious. The argument in favor is that without a standard
+instruction, software would have to pick some algorithm to perform the
+operation, which would likely perform poorly on some
+microarchitectures versus others.
+
+NOTE: There is no instruction to perform a "scalar divide by vector"
+operation.
+
+==== Vector Widening Integer Multiply Instructions
+
+The widening integer multiply instructions return the full 2*SEW-bit
+product from an SEW-bit*SEW-bit multiply.
+
+----
+# Widening signed-integer multiply
+vwmul.vv vd, vs2, vs1, vm # vector-vector
+vwmul.vx vd, vs2, rs1, vm # vector-scalar
+
+# Widening unsigned-integer multiply
+vwmulu.vv vd, vs2, vs1, vm # vector-vector
+vwmulu.vx vd, vs2, rs1, vm # vector-scalar
+
+# Widening signed(vs2)-unsigned integer multiply
+vwmulsu.vv vd, vs2, vs1, vm # vector-vector
+vwmulsu.vx vd, vs2, rs1, vm # vector-scalar
+----
+
+==== Vector Single-Width Integer Multiply-Add Instructions
+
+The integer multiply-add instructions are destructive and are provided
+in two forms, one that overwrites the addend or minuend
+(`vmacc`, `vnmsac`) and one that overwrites the first multiplicand
+(`vmadd`, `vnmsub`).
+
+The low half of the product is added or subtracted from the third operand.
+
+NOTE: `sac` is intended to be read as "subtract from accumulator". The
+opcode is `vnmsac` to match the (unfortunately counterintuitive)
+floating-point `fnmsub` instruction definition. Similarly for the
+`vnmsub` opcode.
+
+----
+# Integer multiply-add, overwrite addend
+vmacc.vv vd, vs1, vs2, vm # vd[i] = (vs1[i] * vs2[i]) + vd[i]
+vmacc.vx vd, rs1, vs2, vm # vd[i] = (x[rs1] * vs2[i]) + vd[i]
+
+# Integer multiply-sub, overwrite minuend
+vnmsac.vv vd, vs1, vs2, vm # vd[i] = -(vs1[i] * vs2[i]) + vd[i]
+vnmsac.vx vd, rs1, vs2, vm # vd[i] = -(x[rs1] * vs2[i]) + vd[i]
+
+# Integer multiply-add, overwrite multiplicand
+vmadd.vv vd, vs1, vs2, vm # vd[i] = (vs1[i] * vd[i]) + vs2[i]
+vmadd.vx vd, rs1, vs2, vm # vd[i] = (x[rs1] * vd[i]) + vs2[i]
+
+# Integer multiply-sub, overwrite multiplicand
+vnmsub.vv vd, vs1, vs2, vm # vd[i] = -(vs1[i] * vd[i]) + vs2[i]
+vnmsub.vx vd, rs1, vs2, vm # vd[i] = -(x[rs1] * vd[i]) + vs2[i]
+----
+
+==== Vector Widening Integer Multiply-Add Instructions
+
+The widening integer multiply-add instructions add the full 2*SEW-bit
+product from a SEW-bit*SEW-bit multiply to a 2*SEW-bit value and
+produce a 2*SEW-bit result. All combinations of signed and unsigned
+multiply operands are supported.
+
+----
+# Widening unsigned-integer multiply-add, overwrite addend
+vwmaccu.vv vd, vs1, vs2, vm # vd[i] = (vs1[i] * vs2[i]) + vd[i]
+vwmaccu.vx vd, rs1, vs2, vm # vd[i] = (x[rs1] * vs2[i]) + vd[i]
+
+# Widening signed-integer multiply-add, overwrite addend
+vwmacc.vv vd, vs1, vs2, vm # vd[i] = (vs1[i] * vs2[i]) + vd[i]
+vwmacc.vx vd, rs1, vs2, vm # vd[i] = (x[rs1] * vs2[i]) + vd[i]
+
+# Widening signed-unsigned-integer multiply-add, overwrite addend
+vwmaccsu.vv vd, vs1, vs2, vm # vd[i] = (signed(vs1[i]) * unsigned(vs2[i])) + vd[i]
+vwmaccsu.vx vd, rs1, vs2, vm # vd[i] = (signed(x[rs1]) * unsigned(vs2[i])) + vd[i]
+
+# Widening unsigned-signed-integer multiply-add, overwrite addend
+vwmaccus.vx vd, rs1, vs2, vm # vd[i] = (unsigned(x[rs1]) * signed(vs2[i])) + vd[i]
+----
+
+==== Vector Integer Merge Instructions
+
+The vector integer merge instructions combine two source operands
+based on a mask. Unlike regular arithmetic instructions, the
+merge operates on all body elements (i.e., the set of elements from
+`vstart` up to the current vector length in `vl`).
+
+The `vmerge` instructions are encoded as masked instructions (`vm=0`).
+The instructions combine two
+sources as follows. At elements where the mask value is zero, the
+first operand is copied to the destination element, otherwise the
+second operand is copied to the destination element. The first
+operand is always a vector register group specified by `vs2`. The
+second operand is a vector register group specified by `vs1` or a
+scalar `x` register specified by `rs1` or a 5-bit sign-extended
+immediate.
+
+----
+vmerge.vvm vd, vs2, vs1, v0 # vd[i] = v0.mask[i] ? vs1[i] : vs2[i]
+vmerge.vxm vd, vs2, rs1, v0 # vd[i] = v0.mask[i] ? x[rs1] : vs2[i]
+vmerge.vim vd, vs2, imm, v0 # vd[i] = v0.mask[i] ? imm : vs2[i]
+----
+
+==== Vector Integer Move Instructions
+
+The vector integer move instructions copy a source operand to a vector
+register group.
+The `vmv.v.v` variant copies a vector register group, whereas the `vmv.v.x`
+and `vmv.v.i` variants __splat__ a scalar register or immediate to all active
+elements of the destination vector register group.
+These instructions are encoded as unmasked instructions (`vm=1`).
+The first operand specifier (`vs2`) must contain `v0`, and any other vector
+register number in `vs2` is _reserved_.
+
+----
+vmv.v.v vd, vs1 # vd[i] = vs1[i]
+vmv.v.x vd, rs1 # vd[i] = x[rs1]
+vmv.v.i vd, imm # vd[i] = imm
+----
+
+NOTE: Mask values can be widened into SEW-width elements using a
+sequence `vmv.v.i vd, 0; vmerge.vim vd, vd, 1, v0`.
+
+NOTE: The vector integer move instructions share the encoding with the vector
+merge instructions, but with `vm=1` and `vs2=v0`.
+
+The form `vmv.v.v vd, vd`, which leaves body elements unchanged,
+can be used to indicate that the register will next be used
+with an EEW equal to SEW.
+
+NOTE: Implementations that internally reorganize data according to EEW
+can shuffle the internal representation according to SEW.
+Implementations that do not internally reorganize data can dynamically
+elide this instruction (aside from resetting `vstart` to 0).
+
+NOTE: The `vmv.v.v vd, vd` instruction is not a RISC-V HINT as a
+tail-agnostic setting may cause an architectural state change on some
+implementations.
+
+[[sec-vector-fixed-point]]
+=== Vector Fixed-Point Arithmetic Instructions
+
+The preceding set of integer arithmetic instructions is extended to support
+fixed-point arithmetic.
+
+A fixed-point number is a two's-complement signed or unsigned integer
+interpreted as the numerator in a fraction with an implicit denominator.
+The fixed-point instructions are intended to be applied to the numerators;
+it is the responsibility of software to manage the denominators.
+An N-bit element can hold two's-complement signed integers in the
+range -2^N-1^...+2^N-1^-1, and unsigned integers in the range 0
+... +2^N^-1. The fixed-point instructions help preserve precision in
+narrow operands by supporting scaling and rounding, and can handle
+overflow by saturating results into the destination format range.
+
+NOTE: The widening integer operations described above can also be used
+to avoid overflow.
+
+==== Vector Single-Width Saturating Add and Subtract
+
+Saturating forms of integer add and subtract are provided, for both
+signed and unsigned integers. If the result would overflow the
+destination, the result is replaced with the closest representable
+value, and the `vxsat` bit is set.
+
+----
+# Saturating adds of unsigned integers.
+vsaddu.vv vd, vs2, vs1, vm # Vector-vector
+vsaddu.vx vd, vs2, rs1, vm # vector-scalar
+vsaddu.vi vd, vs2, imm, vm # vector-immediate
+
+# Saturating adds of signed integers.
+vsadd.vv vd, vs2, vs1, vm # Vector-vector
+vsadd.vx vd, vs2, rs1, vm # vector-scalar
+vsadd.vi vd, vs2, imm, vm # vector-immediate
+
+# Saturating subtract of unsigned integers.
+vssubu.vv vd, vs2, vs1, vm # Vector-vector
+vssubu.vx vd, vs2, rs1, vm # vector-scalar
+
+# Saturating subtract of signed integers.
+vssub.vv vd, vs2, vs1, vm # Vector-vector
+vssub.vx vd, vs2, rs1, vm # vector-scalar
+----
+
+==== Vector Single-Width Averaging Add and Subtract
+
+The averaging add and subtract instructions right shift the result by
+one bit and round off the result according to the setting in `vxrm`.
+Computation is performed in infinite precision before rounding and truncating.
+Both unsigned and signed versions are provided.
+For `vaaddu` and `vaadd` there can be no overflow in the result.
+For `vasub` and `vasubu`, overflow is ignored and the result wraps around.
+
+NOTE: For `vasub`, overflow occurs only when subtracting the smallest number
+from the largest number under `rnu` or `rne` rounding.
+
+----
+# Averaging add
+
+# Averaging adds of unsigned integers.
+vaaddu.vv vd, vs2, vs1, vm # roundoff_unsigned(vs2[i] + vs1[i], 1)
+vaaddu.vx vd, vs2, rs1, vm # roundoff_unsigned(vs2[i] + x[rs1], 1)
+
+# Averaging adds of signed integers.
+vaadd.vv vd, vs2, vs1, vm # roundoff_signed(vs2[i] + vs1[i], 1)
+vaadd.vx vd, vs2, rs1, vm # roundoff_signed(vs2[i] + x[rs1], 1)
+
+# Averaging subtract
+
+# Averaging subtract of unsigned integers.
+vasubu.vv vd, vs2, vs1, vm # roundoff_unsigned(vs2[i] - vs1[i], 1)
+vasubu.vx vd, vs2, rs1, vm # roundoff_unsigned(vs2[i] - x[rs1], 1)
+
+# Averaging subtract of signed integers.
+vasub.vv vd, vs2, vs1, vm # roundoff_signed(vs2[i] - vs1[i], 1)
+vasub.vx vd, vs2, rs1, vm # roundoff_signed(vs2[i] - x[rs1], 1)
+----
+
+==== Vector Single-Width Fractional Multiply with Rounding and Saturation
+
+The signed fractional multiply instruction produces a 2*SEW product of
+the two SEW inputs, then shifts the result right by SEW-1 bits,
+rounding these bits according to `vxrm`, then saturates the result to
+fit into SEW bits. If the result causes saturation, the `vxsat` bit
+is set.
+
+----
+# Signed saturating and rounding fractional multiply
+# See vxrm description for rounding calculation
+vsmul.vv vd, vs2, vs1, vm # vd[i] = clip(roundoff_signed(vs2[i]*vs1[i], SEW-1))
+vsmul.vx vd, vs2, rs1, vm # vd[i] = clip(roundoff_signed(vs2[i]*x[rs1], SEW-1))
+----
+
+NOTE: When multiplying two N-bit signed numbers, the largest magnitude
+is obtained for -2^N-1^ * -2^N-1^ producing a result +2^2N-2^, which
+has a single (zero) sign bit when held in 2N bits. All other products
+have two sign bits in 2N bits. To retain greater precision in N
+result bits, the product is shifted right by one bit less than N,
+saturating the largest magnitude result but increasing result
+precision by one bit for all other products.
+
+NOTE: We do not provide an equivalent fractional multiply where one
+input is unsigned, as these would retain all upper SEW bits and would
+not need to saturate. This operation is partly covered by the
+`vmulhu` and `vmulhsu` instructions, for the case where rounding is
+simply truncation (`rdn`).
+
+==== Vector Single-Width Scaling Shift Instructions
+
+These instructions shift the input value right, and round off the
+shifted out bits according to `vxrm`. The scaling right shifts have
+both zero-extending (`vssrl`) and sign-extending (`vssra`) forms. The
+data to be shifted is in the vector register group specified by `vs2`
+and the shift amount value can come from a vector register group
+`vs1`, a scalar integer register `rs1`, or a zero-extended 5-bit
+immediate. Only the low lg2(SEW) bits of the shift-amount value are
+used to control the shift amount.
+
+----
+ # Scaling shift right logical
+ vssrl.vv vd, vs2, vs1, vm # vd[i] = roundoff_unsigned(vs2[i], vs1[i])
+ vssrl.vx vd, vs2, rs1, vm # vd[i] = roundoff_unsigned(vs2[i], x[rs1])
+ vssrl.vi vd, vs2, uimm, vm # vd[i] = roundoff_unsigned(vs2[i], uimm)
+
+ # Scaling shift right arithmetic
+ vssra.vv vd, vs2, vs1, vm # vd[i] = roundoff_signed(vs2[i],vs1[i])
+ vssra.vx vd, vs2, rs1, vm # vd[i] = roundoff_signed(vs2[i], x[rs1])
+ vssra.vi vd, vs2, uimm, vm # vd[i] = roundoff_signed(vs2[i], uimm)
+----
+
+==== Vector Narrowing Fixed-Point Clip Instructions
+
+The `vnclip` instructions are used to pack a fixed-point value into a
+narrower destination. The instructions support rounding, scaling, and
+saturation into the final destination format. The source data is in
+the vector register group specified by `vs2`. The scaling shift amount
+value can come from a vector register group `vs1`, a scalar integer
+register `rs1`, or a zero-extended 5-bit immediate. The low
+lg2(2*SEW) bits of the vector or scalar shift-amount value (e.g., the
+low 6 bits for a SEW=64-bit to SEW=32-bit narrowing operation) are
+used to control the right shift amount, which provides the scaling.
+----
+# Narrowing unsigned clip
+# SEW 2*SEW SEW
+vnclipu.wv vd, vs2, vs1, vm # vd[i] = clip(roundoff_unsigned(vs2[i], vs1[i]))
+vnclipu.wx vd, vs2, rs1, vm # vd[i] = clip(roundoff_unsigned(vs2[i], x[rs1]))
+vnclipu.wi vd, vs2, uimm, vm # vd[i] = clip(roundoff_unsigned(vs2[i], uimm))
+
+# Narrowing signed clip
+vnclip.wv vd, vs2, vs1, vm # vd[i] = clip(roundoff_signed(vs2[i], vs1[i]))
+vnclip.wx vd, vs2, rs1, vm # vd[i] = clip(roundoff_signed(vs2[i], x[rs1]))
+vnclip.wi vd, vs2, uimm, vm # vd[i] = clip(roundoff_signed(vs2[i], uimm))
+----
+
+For `vnclipu`/`vnclip`, the rounding mode is specified in the `vxrm`
+CSR. Rounding occurs around the least-significant bit of the
+destination and before saturation.
+
+For `vnclipu`, the shifted rounded source value is treated as an
+unsigned integer and saturates if the result would overflow the
+destination viewed as an unsigned integer.
+
+NOTE: There is no single instruction that can saturate a signed value
+into an unsigned destination. A sequence of two vector instructions
+that first removes negative numbers by performing a max against 0
+using `vmax` then clips the resulting unsigned value into the
+destination using `vnclipu` can be used if setting `vxsat` value for
+negative numbers is not required. A `vsetvli` is required between
+these two instructions to change SEW.
+
+For `vnclip`, the shifted rounded source value is treated as a signed
+integer and saturates if the result would overflow the destination viewed
+as a signed integer.
+
+If any destination element is saturated, the `vxsat` bit is set in the
+`vxsat` register.
+
+[[sec-vector-float]]
+=== Vector Floating-Point Instructions
+
+The standard vector floating-point instructions treat elements as
+IEEE-754/2008-compatible values. If the EEW of a vector
+floating-point operand does not correspond to a supported IEEE
+floating-point type, the instruction encoding is reserved.
+
+NOTE: Whether floating-point is supported, and for which element
+widths, is determined by the specific vector extension. The current
+set of extensions include support for 32-bit and 64-bit floating-point
+values. When 16-bit and 128-bit element widths are added, they will be
+also be treated as IEEE-754/2008-compatible values. Other
+floating-point formats may be supported in future extensions.
+
+Vector floating-point instructions require the presence of base scalar
+floating-point extensions corresponding to the supported vector
+floating-point element widths.
+
+NOTE: In particular, future vector extensions supporting 16-bit
+half-precision floating-point values will also require some scalar
+half-precision floating-point support.
+
+If the floating-point unit status field `mstatus.FS` is `Off` then any
+attempt to execute a vector floating-point instruction will raise an
+illegal-instruction exception. Any vector floating-point instruction
+that modifies any floating-point extension state (i.e., floating-point
+CSRs or `f` registers) must set `mstatus.FS` to `Dirty`.
+
+If the hypervisor extension is implemented and V=1, the `vsstatus.FS` field is
+additionally in effect for vector floating-point instructions. If
+`vsstatus.FS` or `mstatus.FS` is `Off` then any
+attempt to execute a vector floating-point instruction will raise an
+illegal-instruction exception. Any vector floating-point instruction
+that modifies any floating-point extension state (i.e., floating-point
+CSRs or `f` registers) must set both `mstatus.FS` and `vsstatus.FS` to `Dirty`.
+
+The vector floating-point instructions have the same behavior as the
+scalar floating-point instructions with regard to NaNs.
+
+Scalar values for floating-point vector-scalar operations are sourced
+as described in <<sec-arithmetic-encoding>>.
+
+==== Vector Floating-Point Exception Flags
+
+A vector floating-point exception at any active floating-point element
+sets the standard FP exception flags in the `fflags` register. Inactive
+elements do not set FP exception flags.
+
+==== Vector Single-Width Floating-Point Add/Subtract Instructions
+
+----
+# Floating-point add
+vfadd.vv vd, vs2, vs1, vm # Vector-vector
+vfadd.vf vd, vs2, rs1, vm # vector-scalar
+
+# Floating-point subtract
+vfsub.vv vd, vs2, vs1, vm # Vector-vector
+vfsub.vf vd, vs2, rs1, vm # Vector-scalar vd[i] = vs2[i] - f[rs1]
+vfrsub.vf vd, vs2, rs1, vm # Scalar-vector vd[i] = f[rs1] - vs2[i]
+----
+
+==== Vector Widening Floating-Point Add/Subtract Instructions
+
+----
+# Widening FP add/subtract, 2*SEW = SEW +/- SEW
+vfwadd.vv vd, vs2, vs1, vm # vector-vector
+vfwadd.vf vd, vs2, rs1, vm # vector-scalar
+vfwsub.vv vd, vs2, vs1, vm # vector-vector
+vfwsub.vf vd, vs2, rs1, vm # vector-scalar
+
+# Widening FP add/subtract, 2*SEW = 2*SEW +/- SEW
+vfwadd.wv vd, vs2, vs1, vm # vector-vector
+vfwadd.wf vd, vs2, rs1, vm # vector-scalar
+vfwsub.wv vd, vs2, vs1, vm # vector-vector
+vfwsub.wf vd, vs2, rs1, vm # vector-scalar
+----
+
+==== Vector Single-Width Floating-Point Multiply/Divide Instructions
+
+----
+# Floating-point multiply
+vfmul.vv vd, vs2, vs1, vm # Vector-vector
+vfmul.vf vd, vs2, rs1, vm # vector-scalar
+
+# Floating-point divide
+vfdiv.vv vd, vs2, vs1, vm # Vector-vector
+vfdiv.vf vd, vs2, rs1, vm # vector-scalar
+
+# Reverse floating-point divide vector = scalar / vector
+vfrdiv.vf vd, vs2, rs1, vm # scalar-vector, vd[i] = f[rs1]/vs2[i]
+----
+
+==== Vector Widening Floating-Point Multiply
+
+----
+# Widening floating-point multiply
+vfwmul.vv vd, vs2, vs1, vm # vector-vector
+vfwmul.vf vd, vs2, rs1, vm # vector-scalar
+----
+
+==== Vector Single-Width Floating-Point Fused Multiply-Add Instructions
+
+All four varieties of fused multiply-add are provided, and in two
+destructive forms that overwrite one of the operands, either the
+addend or the first multiplicand.
+
+----
+# FP multiply-accumulate, overwrites addend
+vfmacc.vv vd, vs1, vs2, vm # vd[i] = (vs1[i] * vs2[i]) + vd[i]
+vfmacc.vf vd, rs1, vs2, vm # vd[i] = (f[rs1] * vs2[i]) + vd[i]
+
+# FP negate-(multiply-accumulate), overwrites subtrahend
+vfnmacc.vv vd, vs1, vs2, vm # vd[i] = -(vs1[i] * vs2[i]) - vd[i]
+vfnmacc.vf vd, rs1, vs2, vm # vd[i] = -(f[rs1] * vs2[i]) - vd[i]
+
+# FP multiply-subtract-accumulator, overwrites subtrahend
+vfmsac.vv vd, vs1, vs2, vm # vd[i] = (vs1[i] * vs2[i]) - vd[i]
+vfmsac.vf vd, rs1, vs2, vm # vd[i] = (f[rs1] * vs2[i]) - vd[i]
+
+# FP negate-(multiply-subtract-accumulator), overwrites minuend
+vfnmsac.vv vd, vs1, vs2, vm # vd[i] = -(vs1[i] * vs2[i]) + vd[i]
+vfnmsac.vf vd, rs1, vs2, vm # vd[i] = -(f[rs1] * vs2[i]) + vd[i]
+
+# FP multiply-add, overwrites multiplicand
+vfmadd.vv vd, vs1, vs2, vm # vd[i] = (vs1[i] * vd[i]) + vs2[i]
+vfmadd.vf vd, rs1, vs2, vm # vd[i] = (f[rs1] * vd[i]) + vs2[i]
+
+# FP negate-(multiply-add), overwrites multiplicand
+vfnmadd.vv vd, vs1, vs2, vm # vd[i] = -(vs1[i] * vd[i]) - vs2[i]
+vfnmadd.vf vd, rs1, vs2, vm # vd[i] = -(f[rs1] * vd[i]) - vs2[i]
+
+# FP multiply-sub, overwrites multiplicand
+vfmsub.vv vd, vs1, vs2, vm # vd[i] = (vs1[i] * vd[i]) - vs2[i]
+vfmsub.vf vd, rs1, vs2, vm # vd[i] = (f[rs1] * vd[i]) - vs2[i]
+
+# FP negate-(multiply-sub), overwrites multiplicand
+vfnmsub.vv vd, vs1, vs2, vm # vd[i] = -(vs1[i] * vd[i]) + vs2[i]
+vfnmsub.vf vd, rs1, vs2, vm # vd[i] = -(f[rs1] * vd[i]) + vs2[i]
+----
+
+NOTE: While we considered using the two unused rounding modes
+in the scalar FP FMA encoding to provide a few non-destructive FMAs,
+these would complicate microarchitectures by being the only maskable
+operation with three inputs and separate output.
+
+==== Vector Widening Floating-Point Fused Multiply-Add Instructions
+
+The widening floating-point fused multiply-add instructions all
+overwrite the wide addend with the result. The multiplier inputs are
+all SEW wide, while the addend and destination is 2*SEW bits wide.
+
+----
+# FP widening multiply-accumulate, overwrites addend
+vfwmacc.vv vd, vs1, vs2, vm # vd[i] = (vs1[i] * vs2[i]) + vd[i]
+vfwmacc.vf vd, rs1, vs2, vm # vd[i] = (f[rs1] * vs2[i]) + vd[i]
+
+# FP widening negate-(multiply-accumulate), overwrites addend
+vfwnmacc.vv vd, vs1, vs2, vm # vd[i] = -(vs1[i] * vs2[i]) - vd[i]
+vfwnmacc.vf vd, rs1, vs2, vm # vd[i] = -(f[rs1] * vs2[i]) - vd[i]
+
+# FP widening multiply-subtract-accumulator, overwrites addend
+vfwmsac.vv vd, vs1, vs2, vm # vd[i] = (vs1[i] * vs2[i]) - vd[i]
+vfwmsac.vf vd, rs1, vs2, vm # vd[i] = (f[rs1] * vs2[i]) - vd[i]
+
+# FP widening negate-(multiply-subtract-accumulator), overwrites addend
+vfwnmsac.vv vd, vs1, vs2, vm # vd[i] = -(vs1[i] * vs2[i]) + vd[i]
+vfwnmsac.vf vd, rs1, vs2, vm # vd[i] = -(f[rs1] * vs2[i]) + vd[i]
+----
+
+==== Vector Floating-Point Square-Root Instruction
+
+This is a unary vector-vector instruction.
+
+----
+# Floating-point square root
+vfsqrt.v vd, vs2, vm # Vector-vector square root
+----
+
+==== Vector Floating-Point Reciprocal Square-Root Estimate Instruction
+
+----
+# Floating-point reciprocal square-root estimate to 7 bits.
+vfrsqrt7.v vd, vs2, vm
+----
+
+This is a unary vector-vector instruction that returns an estimate of
+1/sqrt(x) accurate to 7 bits.
+
+NOTE: An earlier draft version had used the assembler name `vfrsqrte7`
+but this was deemed to cause confusion with the ``e``__x__ notation for element
+width. The earlier name can be retained as alias in tool chains for
+backward compatibility.
+
+The following table describes the instruction's behavior for all
+classes of floating-point inputs:
+
+[cols="1,1,1"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+| Input | Output | Exceptions raised
+
+| -{inf} {le} _x_ < -0.0 | canonical NaN | NV
+| -0.0 | -{inf} | DZ
+| +0.0 | +{inf} | DZ
+| +0.0 < _x_ < +{inf} | _estimate of 1/sqrt(x)_ |
+| +{inf} | +0.0 |
+| qNaN | canonical NaN |
+| sNaN | canonical NaN | NV
+|===
+
+NOTE: All positive normal and subnormal inputs produce normal outputs.
+
+NOTE: The output value is independent of the dynamic rounding mode.
+
+For the non-exceptional cases, the low bit of the exponent and the six high
+bits of significand (after the leading one) are concatenated and used to
+address the following table.
+The output of the table becomes the seven high bits of the result significand
+(after the leading one); the remainder of the result significand is zero.
+Subnormal inputs are normalized and the exponent adjusted appropriately before
+the lookup.
+The output exponent is chosen to make the result approximate the reciprocal of
+the square root of the argument.
+
+More precisely, the result is computed as follows.
+Let the normalized input exponent be equal to the input exponent if the input
+is normal, or 0 minus the number of leading zeros in the significand
+otherwise.
+If the input is subnormal, the normalized input significand is given by
+shifting the input significand left by 1 minus the normalized input exponent,
+discarding the leading 1 bit.
+The output exponent equals floor((3*B - 1 - the normalized input exponent) / 2),
+where B is the exponent bias. The output sign equals the input sign.
+
+The following table gives the seven MSBs of the output significand as a
+function of the LSB of the normalized input exponent and the six MSBs of the
+normalized input significand; the other bits of the output significand are zero.
+
+include::images/wavedrom/vfrsqrt7.edn[]
+
+NOTE: For example, when SEW=32, vfrsqrt7(0x00718abc ({approx} 1.043e-38)) = 0x5f080000 ({approx} 9.800e18), and vfrsqrt7(0x7f765432 ({approx} 3.274e38)) = 0x1f820000 ({approx} 5.506e-20).
+
+NOTE: The 7 bit accuracy was chosen as it requires 0,1,2,3
+Newton-Raphson iterations to converge to close to bfloat16, FP16,
+FP32, FP64 accuracy respectively. Future instructions can be defined
+with greater estimate accuracy.
+
+==== Vector Floating-Point Reciprocal Estimate Instruction
+
+----
+# Floating-point reciprocal estimate to 7 bits.
+vfrec7.v vd, vs2, vm
+----
+
+NOTE: An earlier draft version had used the assembler name `vfrece7`
+but this was deemed to cause confusion with ``e``__x__ notation for element
+width. The earlier name can be retained as alias in tool chains for
+backward compatibility.
+
+This is a unary vector-vector instruction that returns an estimate of
+1/x accurate to 7 bits.
+
+The following table describes the instruction's behavior for all
+classes of floating-point inputs, where _B_ is the exponent bias:
+
+[cols="1,1,1,1"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+| Input (_x_) | Rounding Mode | Output (_y_ {approx} _1/x_) | Exceptions raised
+
+| -{inf} | _any_ | -0.0 |
+| -2^B+1^ < _x_ {le} -2^B^ (normal) | _any_ | -2^-(B+1)^ {ge} _y_ > -2^-B^ (subnormal, sig=01...) |
+| -2^B^ < _x_ {le} -2^B-1^ (normal) | _any_ | -2^-B^ {ge} _y_ > -2^-B+1^ (subnormal, sig=1...) |
+| -2^B-1^ < _x_ {le} -2^-B+1^ (normal) | _any_ | -2^-B+1^ {ge} _y_ > -2^B-1^ (normal) |
+| -2^-B+1^ < _x_ {le} -2^-B^ (subnormal, sig=1...) | _any_ | -2^B-1^ {ge} _y_ > -2^B^ (normal) |
+| -2^-B^ < _x_ {le} -2^-(B+1)^ (subnormal, sig=01...) | _any_ | -2^B^ {ge} _y_ > -2^B+1^ (normal) |
+| -2^-(B+1)^ < _x_ < -0.0 (subnormal, sig=00...) | RUP, RTZ | greatest-mag. negative finite value | NX, OF
+| -2^-(B+1)^ < _x_ < -0.0 (subnormal, sig=00...) | RDN, RNE, RMM | -{inf} | NX, OF
+| -0.0 | _any_ | -{inf} | DZ
+| +0.0 | _any_ | +{inf} | DZ
+| +0.0 < _x_ < 2^-(B+1)^ (subnormal, sig=00...) | RUP, RNE, RMM | +{inf} | NX, OF
+| +0.0 < _x_ < 2^-(B+1)^ (subnormal, sig=00...) | RDN, RTZ | greatest finite value | NX, OF
+| 2^-(B+1)^ {le} _x_ < 2^-B^ (subnormal, sig=01...) | _any_ | 2^B+1^ > _y_ {ge} 2^B^ (normal) |
+| 2^-B^ {le} _x_ < 2^-B+1^ (subnormal, sig=1...) | _any_ | 2^B^ > _y_ {ge} 2^B-1^ (normal) |
+| 2^-B+1^ {le} _x_ < 2^B-1^ (normal) | _any_ | 2^B-1^ > _y_ {ge} 2^-B+1^ (normal) |
+| 2^B-1^ {le} _x_ < 2^B^ (normal) | _any_ | 2^-B+1^ > _y_ {ge} 2^-B^ (subnormal, sig=1...) |
+| 2^B^ {le} _x_ < 2^B+1^ (normal) | _any_ | 2^-B^ > _y_ {ge} 2^-(B+1)^ (subnormal, sig=01...) |
+| +{inf} | _any_ | +0.0 |
+| qNaN | _any_ | canonical NaN |
+| sNaN | _any_ | canonical NaN | NV
+|===
+
+NOTE: Subnormal inputs with magnitude at least 2^-(B+1)^ produce normal outputs;
+other subnormal inputs produce infinite outputs.
+Normal inputs with magnitude at least 2^B-1^ produce subnormal outputs;
+other normal inputs produce normal outputs.
+
+NOTE: The output value depends on the dynamic rounding mode when
+the overflow exception is raised.
+
+For the non-exceptional cases, the seven high bits of significand (after the
+leading one) are used to address the following table.
+The output of the table becomes the seven high bits of the result significand
+(after the leading one); the remainder of the result significand is zero.
+Subnormal inputs are normalized and the exponent adjusted appropriately before
+the lookup.
+The output exponent is chosen to make the result approximate the reciprocal of
+the argument, and subnormal outputs are denormalized accordingly.
+
+More precisely, the result is computed as follows.
+Let the normalized input exponent be equal to the input exponent if the input
+is normal, or 0 minus the number of leading zeros in the significand
+otherwise.
+The normalized output exponent equals (2*B - 1 - the normalized input exponent).
+If the normalized output exponent is outside the range [-1, 2*B], the result
+corresponds to one of the exceptional cases in the table above.
+
+If the input is subnormal, the normalized input significand is given by
+shifting the input significand left by 1 minus the normalized input exponent,
+discarding the leading 1 bit.
+Otherwise, the normalized input significand equals the input significand.
+The following table gives the seven MSBs of the normalized output significand
+as a function of the seven MSBs of the normalized input significand; the other
+bits of the normalized output significand are zero.
+
+include::images/wavedrom/vfrec7.edn[]
+
+If the normalized output exponent is 0 or -1, the result is subnormal: the
+output exponent is 0, and the output significand is given by concatenating
+a 1 bit to the left of the normalized output significand, then shifting that
+quantity right by 1 minus the normalized output exponent.
+Otherwise, the output exponent equals the normalized output exponent, and the
+output significand equals the normalized output significand.
+The output sign equals the input sign.
+
+NOTE: For example, when SEW=32, vfrec7(0x00718abc ({approx} 1.043e-38)) = 0x7e900000 ({approx} 9.570e37), and vfrec7(0x7f765432 ({approx} 3.274e38)) = 0x00214000 ({approx} 3.053e-39).
+
+NOTE: The 7 bit accuracy was chosen as it requires 0,1,2,3
+Newton-Raphson iterations to converge to close to bfloat16, FP16,
+FP32, FP64 accuracy respectively. Future instructions can be defined
+with greater estimate accuracy.
+
+==== Vector Floating-Point MIN/MAX Instructions
+
+The vector floating-point `vfmin` and `vfmax` instructions have the
+same behavior as the corresponding scalar floating-point instructions
+in version 2.2 of the RISC-V F/D/Q extension: they perform the `minimumNumber`
+or `maximumNumber` operation on active elements.
+
+----
+# Floating-point minimum
+vfmin.vv vd, vs2, vs1, vm # Vector-vector
+vfmin.vf vd, vs2, rs1, vm # vector-scalar
+
+# Floating-point maximum
+vfmax.vv vd, vs2, vs1, vm # Vector-vector
+vfmax.vf vd, vs2, rs1, vm # vector-scalar
+----
+
+==== Vector Floating-Point Sign-Injection Instructions
+
+Vector versions of the scalar sign-injection instructions. The result
+takes all bits except the sign bit from the vector `vs2` operands.
+
+----
+vfsgnj.vv vd, vs2, vs1, vm # Vector-vector
+vfsgnj.vf vd, vs2, rs1, vm # vector-scalar
+
+vfsgnjn.vv vd, vs2, vs1, vm # Vector-vector
+vfsgnjn.vf vd, vs2, rs1, vm # vector-scalar
+
+vfsgnjx.vv vd, vs2, vs1, vm # Vector-vector
+vfsgnjx.vf vd, vs2, rs1, vm # vector-scalar
+----
+
+NOTE: A vector of floating-point values can be negated using a
+sign-injection instruction with both source operands set to the same
+vector operand. An assembly pseudoinstruction is provided: `vfneg.v vd,vs` = `vfsgnjn.vv vd,vs,vs`.
+
+NOTE: The absolute value of a vector of floating-point elements can be
+calculated using a sign-injection instruction with both source
+operands set to the same vector operand. An assembly
+pseudoinstruction is provided: `vfabs.v vd,vs` = `vfsgnjx.vv vd,vs,vs`.
+
+==== Vector Floating-Point Compare Instructions
+
+These vector FP compare instructions compare two source operands and
+write the comparison result to a mask register. The destination mask
+vector is always held in a single vector register, with a layout of
+elements as described in <<sec-mask-register-layout>>. The
+destination mask vector register may be the same as the source vector
+mask register (`v0`). Compares write mask registers, and so always
+operate under a tail-agnostic policy.
+
+The compare instructions follow the semantics of the scalar
+floating-point compare instructions. `vmfeq` and `vmfne` raise the invalid
+operation exception only on signaling NaN inputs. `vmflt`, `vmfle`, `vmfgt`,
+and `vmfge` raise the invalid operation exception on both signaling and
+quiet NaN inputs.
+`vmfne` writes 1 to the destination element when either
+operand is NaN, whereas the other compares write 0 when either operand
+is NaN.
+
+----
+# Compare equal
+vmfeq.vv vd, vs2, vs1, vm # Vector-vector
+vmfeq.vf vd, vs2, rs1, vm # vector-scalar
+
+# Compare not equal
+vmfne.vv vd, vs2, vs1, vm # Vector-vector
+vmfne.vf vd, vs2, rs1, vm # vector-scalar
+
+# Compare less than
+vmflt.vv vd, vs2, vs1, vm # Vector-vector
+vmflt.vf vd, vs2, rs1, vm # vector-scalar
+
+# Compare less than or equal
+vmfle.vv vd, vs2, vs1, vm # Vector-vector
+vmfle.vf vd, vs2, rs1, vm # vector-scalar
+
+# Compare greater than
+vmfgt.vf vd, vs2, rs1, vm # vector-scalar
+
+# Compare greater than or equal
+vmfge.vf vd, vs2, rs1, vm # vector-scalar
+----
+
+----
+Comparison Assembler Mapping Assembler pseudoinstruction
+
+va < vb vmflt.vv vd, va, vb, vm
+va <= vb vmfle.vv vd, va, vb, vm
+va > vb vmflt.vv vd, vb, va, vm vmfgt.vv vd, va, vb, vm
+va >= vb vmfle.vv vd, vb, va, vm vmfge.vv vd, va, vb, vm
+
+va < f vmflt.vf vd, va, f, vm
+va <= f vmfle.vf vd, va, f, vm
+va > f vmfgt.vf vd, va, f, vm
+va >= f vmfge.vf vd, va, f, vm
+
+va, vb vector register groups
+f scalar floating-point register
+----
+
+NOTE: Providing all forms is necessary to correctly handle unordered
+compares for NaNs.
+
+NOTE: C99 floating-point quiet compares can be implemented by masking
+the signaling compares when either input is NaN, as follows. When
+the comparand is a non-NaN constant, the middle two instructions can be
+omitted.
+
+----
+# Example of implementing isgreater()
+vmfeq.vv v0, va, va # Only set where A is not NaN.
+vmfeq.vv v1, vb, vb # Only set where B is not NaN.
+vmand.mm v0, v0, v1 # Only set where A and B are ordered,
+vmfgt.vv v0, va, vb, v0.t # so only set flags on ordered values.
+----
+
+NOTE: In the above sequence, it is tempting to mask the second `vmfeq`
+instruction and remove the `vmand` instruction, but this more efficient
+sequence incorrectly fails to raise the invalid exception when an
+element of `va` contains a quiet NaN and the corresponding element in
+`vb` contains a signaling NaN.
+
+==== Vector Floating-Point Classify Instruction
+
+This is a unary vector-vector instruction that operates in the same
+way as the scalar classify instruction.
+
+----
+vfclass.v vd, vs2, vm # Vector-vector
+----
+
+The 10-bit mask produced by this instruction is placed in the
+least-significant bits of the result elements. The upper (SEW-10)
+bits of the result are filled with zeros. The instruction is only
+defined for SEW=16b and above, so the result will always fit in the
+destination elements.
+
+==== Vector Floating-Point Merge Instruction
+
+A vector-scalar floating-point merge instruction is provided, which
+operates on all body elements from `vstart` up to the current vector
+length in `vl` regardless of mask value.
+
+The `vfmerge.vfm` instruction is encoded as a masked instruction (`vm=0`).
+At elements where the mask value is zero, the first vector operand is
+copied to the destination element, otherwise a scalar floating-point
+register value is copied to the destination element.
+
+----
+vfmerge.vfm vd, vs2, rs1, v0 # vd[i] = v0.mask[i] ? f[rs1] : vs2[i]
+----
+
+==== Vector Floating-Point Move Instruction
+
+The vector floating-point move instruction __splats__ a floating-point
+scalar operand to a vector register group. The instruction copies a
+scalar `f` register value to all active elements of a vector register
+group. This instruction is encoded as an unmasked instruction (`vm=1`).
+The instruction must have the `vs2` field set to `v0`, with all other
+values for `vs2` reserved.
+
+----
+vfmv.v.f vd, rs1 # vd[i] = f[rs1]
+----
+
+NOTE: The `vfmv.v.f` instruction shares the encoding with the `vfmerge.vfm`
+instruction, but with `vm=1` and `vs2=v0`.
+
+==== Single-Width Floating-Point/Integer Type-Convert Instructions
+
+Conversion operations are provided to convert to and from
+floating-point values and unsigned and signed integers, where both
+source and destination are SEW wide.
+
+----
+vfcvt.xu.f.v vd, vs2, vm # Convert float to unsigned integer.
+vfcvt.x.f.v vd, vs2, vm # Convert float to signed integer.
+
+vfcvt.rtz.xu.f.v vd, vs2, vm # Convert float to unsigned integer, truncating.
+vfcvt.rtz.x.f.v vd, vs2, vm # Convert float to signed integer, truncating.
+
+vfcvt.f.xu.v vd, vs2, vm # Convert unsigned integer to float.
+vfcvt.f.x.v vd, vs2, vm # Convert signed integer to float.
+----
+
+The conversions follow the same rules on exceptional conditions as the
+scalar conversion instructions.
+The conversions use the dynamic rounding mode in `frm`, except for the `rtz`
+variants, which round towards zero.
+
+NOTE: The `rtz` variants are provided to accelerate truncating conversions
+from floating-point to integer, as is common in languages like C and Java.
+
+==== Widening Floating-Point/Integer Type-Convert Instructions
+
+A set of conversion instructions is provided to convert between
+narrower integer and floating-point datatypes to a type of twice the
+width.
+
+----
+vfwcvt.xu.f.v vd, vs2, vm # Convert float to double-width unsigned integer.
+vfwcvt.x.f.v vd, vs2, vm # Convert float to double-width signed integer.
+
+vfwcvt.rtz.xu.f.v vd, vs2, vm # Convert float to double-width unsigned integer, truncating.
+vfwcvt.rtz.x.f.v vd, vs2, vm # Convert float to double-width signed integer, truncating.
+
+vfwcvt.f.xu.v vd, vs2, vm # Convert unsigned integer to double-width float.
+vfwcvt.f.x.v vd, vs2, vm # Convert signed integer to double-width float.
+
+vfwcvt.f.f.v vd, vs2, vm # Convert single-width float to double-width float.
+----
+
+These instructions have the same constraints on vector register overlap
+as other widening instructions (see <<sec-widening>>).
+
+NOTE: A double-width IEEE floating-point value can always represent a
+single-width integer exactly.
+
+NOTE: A double-width IEEE floating-point value can always represent a
+single-width IEEE floating-point value exactly.
+
+NOTE: A full set of floating-point widening conversions is not
+supported as single instructions, but any widening conversion can be
+implemented as several doubling steps with equivalent results and no
+additional exception flags raised.
+
+==== Narrowing Floating-Point/Integer Type-Convert Instructions
+
+A set of conversion instructions is provided to convert wider integer
+and floating-point datatypes to a type of half the width.
+
+----
+vfncvt.xu.f.w vd, vs2, vm # Convert double-width float to unsigned integer.
+vfncvt.x.f.w vd, vs2, vm # Convert double-width float to signed integer.
+
+vfncvt.rtz.xu.f.w vd, vs2, vm # Convert double-width float to unsigned integer, truncating.
+vfncvt.rtz.x.f.w vd, vs2, vm # Convert double-width float to signed integer, truncating.
+
+vfncvt.f.xu.w vd, vs2, vm # Convert double-width unsigned integer to float.
+vfncvt.f.x.w vd, vs2, vm # Convert double-width signed integer to float.
+
+vfncvt.f.f.w vd, vs2, vm # Convert double-width float to single-width float.
+vfncvt.rod.f.f.w vd, vs2, vm # Convert double-width float to single-width float,
+ # rounding towards odd.
+----
+
+These instructions have the same constraints on vector register overlap
+as other narrowing instructions (see <<sec-narrowing>>).
+
+NOTE: A full set of floating-point narrowing conversions is not
+supported as single instructions. Conversions can be implemented in
+a sequence of halving steps. Results are equivalently rounded and
+the same exception flags are raised if all but the last halving step
+use round-towards-odd (`vfncvt.rod.f.f.w`). Only the final step
+should use the desired rounding mode.
+
+NOTE: For `vfncvt.rod.f.f.w`, a finite value that exceeds the range of the
+destination format is converted to the destination format's largest finite value with the same sign.
+
+=== Vector Reduction Operations
+
+Vector reduction operations take a vector register group of elements
+and a scalar held in element 0 of a vector register, and perform a
+reduction using some binary operator, to produce a scalar result in
+element 0 of a vector register. The scalar input and output operands
+are held in element 0 of a single vector register, not a vector
+register group, so any vector register can be the scalar source or
+destination of a vector reduction regardless of LMUL setting.
+
+The destination vector register can overlap the source operands,
+including the mask register.
+
+NOTE: Vector reductions read and write the scalar operand and result
+into element 0 of a vector register instead of a scalar register to
+avoid a loss of decoupling with the scalar processor, and to support
+future polymorphic use with future types not supported in the scalar
+unit.
+
+Inactive elements from the source vector register group are excluded
+from the reduction, but the scalar operand is always included
+regardless of the mask values.
+
+The other elements in the destination vector register ( 0 < index <
+VLEN/SEW) are considered the tail and are managed with the current
+tail agnostic/undisturbed policy.
+
+If `vl`=0, no operation is performed and the destination register is
+not updated.
+
+NOTE: This choice of behavior for `vl`=0 reduces implementation
+complexity as it is consistent with other operations on vector
+register state. For the common case that the source and destination
+scalar operand are the same vector register, this behavior also
+produces the expected result. For the uncommon case that the source
+and destination scalar operand are in different vector registers, this
+instruction will not copy the source into the destination when `vl`=0.
+However, it is expected that in most of these cases it will be
+statically known that `vl` is not zero. In other cases, a check for
+`vl`=0 will have to be added to ensure that the source scalar is
+copied to the destination (e.g., by explicitly setting `vl`=1 and
+performing a register-register copy).
+
+Traps on vector reduction instructions are always reported with a
+`vstart` of 0. Vector reduction operations raise an
+illegal-instruction exception if `vstart` is non-zero.
+
+The assembler syntax for a reduction operation is `vredop.vs`, where
+the `.vs` suffix denotes the first operand is a vector register group
+and the second operand is a scalar stored in element 0 of a vector
+register.
+
+[[sec-vector-integer-reduce]]
+==== Vector Single-Width Integer Reduction Instructions
+
+All operands and results of single-width reduction instructions have
+the same SEW width. Overflows wrap around on arithmetic sums.
+
+----
+# Simple reductions, where [*] denotes all active elements:
+vredsum.vs vd, vs2, vs1, vm # vd[0] = sum( vs1[0] , vs2[*] )
+vredmaxu.vs vd, vs2, vs1, vm # vd[0] = maxu( vs1[0] , vs2[*] )
+vredmax.vs vd, vs2, vs1, vm # vd[0] = max( vs1[0] , vs2[*] )
+vredminu.vs vd, vs2, vs1, vm # vd[0] = minu( vs1[0] , vs2[*] )
+vredmin.vs vd, vs2, vs1, vm # vd[0] = min( vs1[0] , vs2[*] )
+vredand.vs vd, vs2, vs1, vm # vd[0] = and( vs1[0] , vs2[*] )
+vredor.vs vd, vs2, vs1, vm # vd[0] = or( vs1[0] , vs2[*] )
+vredxor.vs vd, vs2, vs1, vm # vd[0] = xor( vs1[0] , vs2[*] )
+----
+
+[[sec-vector-integer-reduce-widen]]
+==== Vector Widening Integer Reduction Instructions
+
+The unsigned `vwredsumu.vs` instruction zero-extends the SEW-wide
+vector elements before summing them, then adds the 2*SEW-width scalar
+element, and stores the result in a 2*SEW-width scalar element.
+
+The `vwredsum.vs` instruction sign-extends the SEW-wide vector
+elements before summing them.
+
+For both `vwredsumu.vs` and `vwredsum.vs`, overflows wrap around.
+
+----
+# Unsigned sum reduction into double-width accumulator
+vwredsumu.vs vd, vs2, vs1, vm # 2*SEW = 2*SEW + sum(zero-extend(SEW))
+
+# Signed sum reduction into double-width accumulator
+vwredsum.vs vd, vs2, vs1, vm # 2*SEW = 2*SEW + sum(sign-extend(SEW))
+----
+
+[[sec-vector-float-reduce]]
+==== Vector Single-Width Floating-Point Reduction Instructions
+
+----
+# Simple reductions.
+vfredosum.vs vd, vs2, vs1, vm # Ordered sum
+vfredusum.vs vd, vs2, vs1, vm # Unordered sum
+vfredmax.vs vd, vs2, vs1, vm # Maximum value
+vfredmin.vs vd, vs2, vs1, vm # Minimum value
+----
+
+NOTE: Older assembler mnemonic `vfredsum` is retained as alias for `vfredusum`.
+
+===== Vector Ordered Single-Width Floating-Point Sum Reduction
+
+The `vfredosum` instruction must sum the floating-point values in
+element order, starting with the scalar in `vs1[0]`--that is, it
+performs the computation:
+
+----
+ vd[0] = `(((vs1[0] + vs2[0]) + vs2[1]) + ...) + vs2[vl-1]`
+----
+where each addition operates identically to the scalar floating-point
+instructions in terms of raising exception flags and generating or
+propagating special values.
+
+NOTE: The ordered reduction supports compiler auto-vectorization, while
+the unordered FP sum allows for faster implementations.
+
+When the operation is masked (`vm=0`), the masked-off elements do not
+affect the result or the exception flags.
+
+NOTE: If no elements are active, no additions are performed, so the scalar in
+`vs1[0]` is simply copied to the destination register, without canonicalizing
+NaN values and without setting any exception flags. This behavior preserves
+the handling of NaNs, exceptions, and rounding when auto-vectorizing a scalar
+summation loop.
+
+===== Vector Unordered Single-Width Floating-Point Sum Reduction
+
+The unordered sum reduction instruction, `vfredusum`, provides an
+implementation more freedom in performing the reduction.
+
+The implementation must produce a result equivalent to a reduction tree
+composed of binary operator nodes, with the inputs being elements from
+the source vector register group (`vs2`) and the source scalar value
+(`vs1[0]`). Each operator in the tree accepts two inputs and produces
+one result.
+Each operator first computes an exact sum as a RISC-V scalar floating-point
+addition with infinite exponent range and precision, then converts this exact
+sum to a floating-point format with range and precision each at least as great
+as the element floating-point format indicated by SEW, rounding using the
+currently active floating-point dynamic rounding mode and raising exception
+flags as necessary.
+A different floating-point range and precision may be chosen for the result of
+each operator.
+A node where one input is derived only from elements masked-off or beyond the
+active vector length may either treat that input as the additive identity of the
+appropriate EEW or simply copy the other input to its output.
+The rounded result from the root node in the tree is converted (rounded again,
+using the dynamic rounding mode) to the standard floating-point format
+indicated by SEW.
+An implementation
+is allowed to add an additional additive identity to the final result.
+
+The additive identity is +0.0 when rounding down (towards -{inf}) or
+-0.0 for all other rounding modes.
+
+The reduction tree structure must be deterministic for a given value
+in `vtype` and `vl`.
+
+NOTE: As a consequence of this definition, implementations need not propagate
+NaN payloads through the reduction tree when no elements are active. In
+particular, if no elements are active and the scalar input is NaN,
+implementations are permitted to canonicalize the NaN and, if the NaN is
+signaling, set the invalid exception flag. Implementations are alternatively
+permitted to pass through the original NaN and set no exception flags, as with
+`vfredosum`.
+
+NOTE: The `vfredosum` instruction is a valid implementation of the
+`vfredusum` instruction.
+
+===== Vector Single-Width Floating-Point Max and Min Reductions
+
+The `vfredmin` and `vfredmax` instructions reduce the scalar argument in
+`vs1[0]` and active elements in `vs2` using the `minimumNumber` and
+`maximumNumber` operations, respectively.
+
+NOTE: Floating-point max and min reductions should return the same
+final value and raise the same exception flags regardless of operation
+order.
+
+NOTE: If no elements are active, the scalar in `vs1[0]` is simply copied to
+the destination register, without canonicalizing NaN values and without
+setting any exception flags.
+
+[[sec-vector-float-reduce-widen]]
+==== Vector Widening Floating-Point Reduction Instructions
+
+Widening forms of the sum reductions are provided that
+read and write a double-width reduction result.
+
+----
+ # Simple reductions.
+ vfwredosum.vs vd, vs2, vs1, vm # Ordered sum
+ vfwredusum.vs vd, vs2, vs1, vm # Unordered sum
+----
+
+NOTE: Older assembler mnemonic `vfwredsum` is retained as alias for `vfwredusum`.
+
+The reduction of the SEW-width elements is performed as in the
+single-width reduction case, with the elements in `vs2` promoted
+to 2*SEW bits before adding to the 2*SEW-bit accumulator.
+
+NOTE: `vfwredosum.vs` handles inactive elements and NaN payloads analogously
+to `vfredosum.vs`; `vfwredusum.vs` does so analogously to `vfredusum.vs`.
+
+[[sec-vector-mask]]
+=== Vector Mask Instructions
+
+Several instructions are provided to help operate on mask values held in
+a vector register.
+
+[[sec-mask-register-logical]]
+==== Vector Mask-Register Logical Instructions
+
+Vector mask-register logical operations operate on mask registers.
+Each element in a mask register is a single bit, so these instructions
+all operate on single vector registers regardless of the setting of
+the `vlmul` field in `vtype`. They do not change the value of
+`vlmul`. The destination vector register may be the same as either
+source vector register.
+
+As with other vector instructions, the elements with indices less than
+`vstart` are unchanged, and `vstart` is reset to zero after execution.
+Vector mask logical instructions are always unmasked, so there are no
+inactive elements, and the encodings with `vm=0` are reserved.
+Mask elements past `vl`, the tail elements, are
+always updated with a tail-agnostic policy.
+
+----
+vmand.mm vd, vs2, vs1 # vd.mask[i] = vs2.mask[i] && vs1.mask[i]
+vmnand.mm vd, vs2, vs1 # vd.mask[i] = !(vs2.mask[i] && vs1.mask[i])
+vmandn.mm vd, vs2, vs1 # vd.mask[i] = vs2.mask[i] && !vs1.mask[i]
+vmxor.mm vd, vs2, vs1 # vd.mask[i] = vs2.mask[i] ^^ vs1.mask[i]
+vmor.mm vd, vs2, vs1 # vd.mask[i] = vs2.mask[i] || vs1.mask[i]
+vmnor.mm vd, vs2, vs1 # vd.mask[i] = !(vs2.mask[i] || vs1.mask[i])
+vmorn.mm vd, vs2, vs1 # vd.mask[i] = vs2.mask[i] || !vs1.mask[i]
+vmxnor.mm vd, vs2, vs1 # vd.mask[i] = !(vs2.mask[i] ^^ vs1.mask[i])
+----
+
+NOTE: The previous assembler mnemonics `vmandnot` and `vmornot` have
+been changed to `vmandn` and `vmorn` to be consistent with the
+equivalent scalar instructions. The old `vmandnot` and `vmornot`
+mnemonics can be retained as assembler aliases for compatibility.
+
+Several assembler pseudoinstructions are defined as shorthand for
+common uses of mask logical operations:
+----
+vmmv.m vd, vs => vmand.mm vd, vs, vs # Copy mask register
+vmclr.m vd => vmxor.mm vd, vd, vd # Clear mask register
+vmset.m vd => vmxnor.mm vd, vd, vd # Set mask register
+vmnot.m vd, vs => vmnand.mm vd, vs, vs # Invert bits
+----
+
+NOTE: The `vmmv.m` instruction was previously called `vmcpy.m`, but
+with new layout it is more consistent to name as a "mv" because bits
+are copied without interpretation. The `vmcpy.m` assembler
+pseudoinstruction can be retained for compatibility. For
+implementations that internally rearrange bits according to EEW, a
+`vmmv.m` instruction with same source and destination can be used as
+idiom to force an internal reformat into a mask vector.
+
+The set of eight mask logical instructions can generate any of the 16
+possibly binary logical functions of the two input masks:
+
+[cols="1,1,1,1,12"]
+|===
+4+| inputs |
+
+| 0 | 0 | 1 | 1 | src1
+| 0 | 1 | 0 | 1 | src2
+|===
+
+[cols="1,1,1,1,6,6"]
+|===
+4+| output | instruction | pseudoinstruction
+
+| 0 | 0 | 0 | 0 | vmxor.mm vd, vd, vd | vmclr.m vd
+| 1 | 0 | 0 | 0 | vmnor.mm vd, src1, src2 |
+| 0 | 1 | 0 | 0 | vmandn.mm vd, src2, src1 |
+| 1 | 1 | 0 | 0 | vmnand.mm vd, src1, src1 | vmnot.m vd, src1
+| 0 | 0 | 1 | 0 | vmandn.mm vd, src1, src2 |
+| 1 | 0 | 1 | 0 | vmnand.mm vd, src2, src2 | vmnot.m vd, src2
+| 0 | 1 | 1 | 0 | vmxor.mm vd, src1, src2 |
+| 1 | 1 | 1 | 0 | vmnand.mm vd, src1, src2 |
+| 0 | 0 | 0 | 1 | vmand.mm vd, src1, src2 |
+| 1 | 0 | 0 | 1 | vmxnor.mm vd, src1, src2 |
+| 0 | 1 | 0 | 1 | vmand.mm vd, src2, src2 | vmmv.m vd, src2
+| 1 | 1 | 0 | 1 | vmorn.mm vd, src2, src1 |
+| 0 | 0 | 1 | 1 | vmand.mm vd, src1, src1 | vmmv.m vd, src1
+| 1 | 0 | 1 | 1 | vmorn.mm vd, src1, src2 |
+| 0 | 1 | 1 | 1 | vmor.mm vd, src1, src2 |
+| 1 | 1 | 1 | 1 | vmxnor.mm vd, vd, vd | vmset.m vd
+|===
+
+NOTE: The vector mask logical instructions are designed to be easily
+fused with a following masked vector operation to effectively expand
+the number of predicate registers by moving values into `v0` before
+use.
+
+
+==== Vector count population in mask `vcpop.m`
+
+----
+vcpop.m rd, vs2, vm
+----
+
+NOTE: This instruction previously had the assembler mnemonic `vpopc.m`
+but was renamed to be consistent with the scalar instruction. The
+assembler instruction alias `vpopc.m` is being retained for software
+compatibility.
+
+The source operand is a single vector register holding mask register
+values as described in <<sec-mask-register-layout>>.
+
+The `vcpop.m` instruction counts the number of mask elements of the
+active elements of the vector source mask register that have the value
+1 and writes the result to a scalar `x` register.
+
+The operation can be performed under a mask, in which case only the
+masked elements are counted.
+
+----
+vcpop.m rd, vs2, v0.t # x[rd] = sum_i ( vs2.mask[i] && v0.mask[i] )
+----
+
+The `vcpop.m` instruction writes `x[rd]` even if `vl`=0 (with the
+value 0, since no mask elements are active).
+
+Traps on `vcpop.m` are always reported with a `vstart` of 0. The
+`vcpop.m` instruction will raise an illegal-instruction exception if
+`vstart` is non-zero.
+
+==== `vfirst` find-first-set mask bit
+
+----
+vfirst.m rd, vs2, vm
+----
+
+The `vfirst` instruction finds the lowest-numbered active element of
+the source mask vector that has the value 1 and writes that element's
+index to a GPR. If no active element has the value 1, -1 is written
+to the GPR.
+
+NOTE: Software can assume that any negative value (highest bit set)
+corresponds to no element found, as vector lengths will never reach
+2^(XLEN-1)^ on any implementation.
+
+The `vfirst.m` instruction writes `x[rd]` even if `vl`=0 (with the
+value -1, since no mask elements are active).
+
+Traps on `vfirst` are always reported with a `vstart` of 0. The
+`vfirst` instruction will raise an illegal-instruction exception if
+`vstart` is non-zero.
+
+==== `vmsbf.m` set-before-first mask bit
+
+----
+ vmsbf.m vd, vs2, vm
+
+ # Example
+
+ 7 6 5 4 3 2 1 0 Element number
+
+ 1 0 0 1 0 1 0 0 v3 contents
+ vmsbf.m v2, v3
+ 0 0 0 0 0 0 1 1 v2 contents
+
+ 1 0 0 1 0 1 0 1 v3 contents
+ vmsbf.m v2, v3
+ 0 0 0 0 0 0 0 0 v2
+
+ 0 0 0 0 0 0 0 0 v3 contents
+ vmsbf.m v2, v3
+ 1 1 1 1 1 1 1 1 v2
+
+ 1 1 0 0 0 0 1 1 v0 vcontents
+ 1 0 0 1 0 1 0 0 v3 contents
+ vmsbf.m v2, v3, v0.t
+ 0 1 x x x x 1 1 v2 contents
+----
+
+The `vmsbf.m` instruction takes a mask register as input and writes
+results to a mask register. The instruction writes a 1 to all active
+mask elements before the first active source element that is a 1, then
+writes a 0 to that element and all following active elements. If
+there is no set bit in the active elements of the source vector, then
+all active elements in the destination are written with a 1.
+
+The tail elements in the destination mask register are updated under a
+tail-agnostic policy.
+
+Traps on `vmsbf.m` are always reported with a `vstart` of 0. The
+`vmsbf` instruction will raise an illegal-instruction exception if
+`vstart` is non-zero.
+
+The destination register cannot overlap the source register
+and, if masked, cannot overlap the mask register ('v0').
+
+==== `vmsif.m` set-including-first mask bit
+
+The vector mask set-including-first instruction is similar to
+set-before-first, except it also includes the element with a set bit.
+
+----
+ vmsif.m vd, vs2, vm
+
+ # Example
+
+ 7 6 5 4 3 2 1 0 Element number
+
+ 1 0 0 1 0 1 0 0 v3 contents
+ vmsif.m v2, v3
+ 0 0 0 0 0 1 1 1 v2 contents
+
+ 1 0 0 1 0 1 0 1 v3 contents
+ vmsif.m v2, v3
+ 0 0 0 0 0 0 0 1 v2
+
+ 1 1 0 0 0 0 1 1 v0 vcontents
+ 1 0 0 1 0 1 0 0 v3 contents
+ vmsif.m v2, v3, v0.t
+ 1 1 x x x x 1 1 v2 contents
+----
+
+The tail elements in the destination mask register are updated under a
+tail-agnostic policy.
+
+Traps on `vmsif.m` are always reported with a `vstart` of 0. The
+`vmsif` instruction will raise an illegal-instruction exception if
+`vstart` is non-zero.
+
+The destination register cannot overlap the source register
+and, if masked, cannot overlap the mask register ('v0').
+
+==== `vmsof.m` set-only-first mask bit
+
+The vector mask set-only-first instruction is similar to
+set-before-first, except it only sets the first element with a bit
+set, if any.
+
+----
+ vmsof.m vd, vs2, vm
+
+ # Example
+
+ 7 6 5 4 3 2 1 0 Element number
+
+ 1 0 0 1 0 1 0 0 v3 contents
+ vmsof.m v2, v3
+ 0 0 0 0 0 1 0 0 v2 contents
+
+ 1 0 0 1 0 1 0 1 v3 contents
+ vmsof.m v2, v3
+ 0 0 0 0 0 0 0 1 v2
+
+ 1 1 0 0 0 0 1 1 v0 vcontents
+ 1 1 0 1 0 1 0 0 v3 contents
+ vmsof.m v2, v3, v0.t
+ 0 1 x x x x 0 0 v2 contents
+----
+
+The tail elements in the destination mask register are updated under a
+tail-agnostic policy.
+
+Traps on `vmsof.m` are always reported with a `vstart` of 0. The
+`vmsof` instruction will raise an illegal-instruction exception if
+`vstart` is non-zero.
+
+The destination register cannot overlap the source register
+and, if masked, cannot overlap the mask register ('v0').
+
+==== Example using vector mask instructions
+
+The following is an example of vectorizing a data-dependent exit loop.
+
+----
+include::example/strcpy.s[lines=4..-1]
+----
+----
+include::example/strncpy.s[lines=4..-1]
+----
+
+==== Vector Iota Instruction
+
+The `viota.m` instruction reads a source vector mask register and
+writes to each element of the destination vector register group the
+sum of all the bits of elements in the mask register
+whose index is less than the element, e.g., a parallel prefix sum of
+the mask values.
+
+This instruction can be masked, in which case only the enabled
+elements contribute to the sum.
+
+----
+ viota.m vd, vs2, vm
+
+ # Example
+
+ 7 6 5 4 3 2 1 0 Element number
+
+ 1 0 0 1 0 0 0 1 v2 contents
+ viota.m v4, v2 # Unmasked
+ 2 2 2 1 1 1 1 0 v4 result
+
+ 1 1 1 0 1 0 1 1 v0 contents
+ 1 0 0 1 0 0 0 1 v2 contents
+ 2 3 4 5 6 7 8 9 v4 contents
+ viota.m v4, v2, v0.t # Masked, vtype.vma=0
+ 1 1 1 5 1 7 1 0 v4 results
+----
+
+The result value is zero-extended to fill the destination element if
+SEW is wider than the result. If the result value would overflow the
+destination SEW, the least-significant SEW bits are retained.
+
+Traps on `viota.m` are always reported with a `vstart` of 0, and
+execution is always restarted from the beginning when resuming after a
+trap handler. An illegal-instruction exception is raised if `vstart`
+is non-zero.
+
+The destination register group cannot overlap the source register
+and, if masked, cannot overlap the mask register (`v0`).
+
+The `viota.m` instruction can be combined with memory scatter
+instructions (indexed stores) to perform vector compress functions.
+
+----
+# Compact non-zero elements from input memory array to output memory array
+#
+# size_t compact_non_zero(size_t n, const int* in, int* out)
+# {
+# size_t i;
+# int *p = out;
+#
+# for (i=0; i<n; i++)
+# {
+# const int v = *in++;
+# if (v != 0)
+# *p++ = v;
+# }
+#
+# return (size_t) (p - out);
+# }
+#
+# a0 = n
+# a1 = &in
+# a2 = &out
+
+compact_non_zero:
+ li a6, 0 # Clear count of non-zero elements
+loop:
+ vsetvli a5, a0, e32, m8, ta, ma # 32-bit integers
+ vle32.v v8, (a1) # Load input vector
+ sub a0, a0, a5 # Decrement number done
+ slli a5, a5, 2 # Multiply by four bytes
+ vmsne.vi v0, v8, 0 # Locate non-zero values
+ add a1, a1, a5 # Bump input pointer
+ vcpop.m a5, v0 # Count number of elements set in v0
+ viota.m v16, v0 # Get destination offsets of active elements
+ add a6, a6, a5 # Accumulate number of elements
+ vsll.vi v16, v16, 2, v0.t # Multiply offsets by four bytes
+ slli a5, a5, 2 # Multiply number of non-zero elements by four bytes
+ vsuxei32.v v8, (a2), v16, v0.t # Scatter using scaled viota results under mask
+ add a2, a2, a5 # Bump output pointer
+ bnez a0, loop # Any more?
+
+ mv a0, a6 # Return count
+ ret
+----
+
+==== Vector Element Index Instruction
+
+The `vid.v` instruction writes each element's index to the
+destination vector register group, from 0 to `vl`-1.
+
+----
+vid.v vd, vm # Write element ID to destination.
+----
+
+The instruction can be masked. Masking does not change the
+index value written to active elements.
+
+The `vs2` field of the instruction must be set to `v0`, otherwise the
+encoding is _reserved_.
+
+The result value is zero-extended to fill the destination element if
+SEW is wider than the result. If the result value would overflow the
+destination SEW, the least-significant SEW bits are retained.
+
+NOTE: Microarchitectures can implement `vid.v` instruction using the
+same datapath as `viota.m` but with an implicit set mask source.
+
+[[sec-vector-permute]]
+=== Vector Permutation Instructions
+
+A range of permutation instructions are provided to move elements
+around within the vector registers.
+
+==== Integer Scalar Move Instructions
+
+The integer scalar read/write instructions transfer a single
+value between a scalar `x` register and element 0 of a vector
+register. The instructions ignore LMUL and vector register groups.
+
+----
+vmv.x.s rd, vs2 # x[rd] = vs2[0] (vs1=0)
+vmv.s.x vd, rs1 # vd[0] = x[rs1] (vs2=0)
+----
+
+The `vmv.x.s` instruction copies a single SEW-wide element from index 0 of the
+source vector register to a destination integer register. If SEW > XLEN, the
+least-significant XLEN bits are transferred and the upper SEW-XLEN bits are
+ignored. If SEW < XLEN, the value is sign-extended to XLEN bits.
+
+NOTE: `vmv.x.s` performs its operation even if `vstart` {ge} `vl` or `vl`=0.
+
+The `vmv.s.x` instruction copies the scalar integer register to element 0 of
+the destination vector register. If SEW < XLEN, the least-significant bits
+are copied and the upper XLEN-SEW bits are ignored. If SEW > XLEN, the value
+is sign-extended to SEW bits. The other elements in the destination vector
+register ( 0 < index < VLEN/SEW) are treated as tail elements using the current tail agnostic/undisturbed policy. If `vstart` {ge} `vl`, no
+operation is performed and the destination register is not updated.
+
+NOTE: As a consequence, when `vl`=0, no elements are updated in the
+destination vector register group, regardless of `vstart`.
+
+The encodings corresponding to the masked versions (`vm=0`) of `vmv.x.s`
+and `vmv.s.x` are reserved.
+
+[[sec-vector-float-move]]
+==== Floating-Point Scalar Move Instructions
+
+The floating-point scalar read/write instructions transfer a single
+value between a scalar `f` register and element 0 of a vector
+register. The instructions ignore LMUL and vector register groups.
+
+----
+vfmv.f.s rd, vs2 # f[rd] = vs2[0] (rs1=0)
+vfmv.s.f vd, rs1 # vd[0] = f[rs1] (vs2=0)
+----
+
+The `vfmv.f.s` instruction copies a single SEW-wide element from index
+0 of the source vector register to a destination scalar floating-point
+register.
+
+NOTE: `vfmv.f.s` performs its operation even if `vstart` {ge} `vl` or `vl`=0.
+
+The `vfmv.s.f` instruction copies the scalar floating-point register
+to element 0 of the destination vector register. The other elements
+in the destination vector register ( 0 < index < VLEN/SEW) are treated
+as tail elements using the current tail agnostic/undisturbed policy.
+If `vstart` {ge} `vl`, no operation is performed and the destination
+register is not updated.
+
+NOTE: As a consequence, when `vl`=0, no elements are updated in the
+destination vector register group, regardless of `vstart`.
+
+The encodings corresponding to the masked versions (`vm=0`) of `vfmv.f.s`
+and `vfmv.s.f` are reserved.
+
+==== Vector Slide Instructions
+
+The slide instructions move elements up and down a vector register
+group.
+
+NOTE: The slide operations can be implemented much more efficiently
+than using the arbitrary register gather instruction. Implementations
+may optimize certain OFFSET values for `vslideup` and `vslidedown`.
+In particular, power-of-2 offsets may operate substantially faster
+than other offsets.
+
+For all of the `vslideup`, `vslidedown`, `v[f]slide1up`, and
+`v[f]slide1down` instructions, if `vstart` {ge} `vl`, the instruction performs no
+operation and leaves the destination vector register unchanged.
+
+NOTE: As a consequence, when `vl`=0, no elements are updated in the
+destination vector register group, regardless of `vstart`.
+
+The tail agnostic/undisturbed policy is followed for tail elements.
+
+The slide instructions may be masked, with mask element _i_
+controlling whether _destination_ element _i_ is written. The mask
+undisturbed/agnostic policy is followed for inactive elements.
+
+===== Vector Slide-up Instructions
+
+----
+vslideup.vx vd, vs2, rs1, vm # vd[i+x[rs1]] = vs2[i]
+vslideup.vi vd, vs2, uimm, vm # vd[i+uimm] = vs2[i]
+----
+
+For `vslideup`, the value in `vl` specifies the maximum number of destination
+elements that are written. The start index (_OFFSET_) for the
+destination can be either specified using an unsigned integer in the
+`x` register specified by `rs1`, or a 5-bit immediate, zero-extended to XLEN bits.
+If XLEN > SEW, _OFFSET_ is _not_ truncated to SEW bits.
+Destination elements _OFFSET_ through `vl`-1 are written if unmasked and
+if _OFFSET_ < `vl`.
+
+----
+vslideup behavior for destination elements (`vstart` < `vl`)
+
+OFFSET is amount to slideup, either from x register or a 5-bit immediate
+
+ 0 <= i < min(vl, max(vstart, OFFSET)) Unchanged
+max(vstart, OFFSET) <= i < vl vd[i] = vs2[i-OFFSET] if v0.mask[i] enabled
+ vl <= i < VLMAX Follow tail policy
+----
+
+The destination vector register group for `vslideup` cannot overlap
+the source vector register group, otherwise the instruction encoding
+is reserved.
+
+NOTE: The non-overlap constraint avoids WAR hazards on the
+input vectors during execution, and enables restart with non-zero
+`vstart`.
+
+===== Vector Slide-down Instructions
+
+----
+vslidedown.vx vd, vs2, rs1, vm # vd[i] = vs2[i+x[rs1]]
+vslidedown.vi vd, vs2, uimm, vm # vd[i] = vs2[i+uimm]
+----
+
+For `vslidedown`, the value in `vl` specifies the maximum number of
+destination elements that are written. The remaining elements past
+`vl` are handled according to the current tail policy
+(<<sec-agnostic>>).
+
+The start index (_OFFSET_) for the source can be either specified
+using an unsigned integer in the `x` register specified by `rs1`, or a
+5-bit immediate, zero-extended to XLEN bits.
+If XLEN > SEW, _OFFSET_ is _not_ truncated to SEW bits.
+
+----
+vslidedown behavior for source elements for element i in slide (`vstart` < `vl`)
+ 0 <= i+OFFSET < VLMAX src[i] = vs2[i+OFFSET]
+ VLMAX <= i+OFFSET src[i] = 0
+
+vslidedown behavior for destination element i in slide (`vstart` < `vl`)
+ 0 <= i < vstart Unchanged
+ vstart <= i < vl vd[i] = src[i] if v0.mask[i] enabled
+ vl <= i < VLMAX Follow tail policy
+----
+
+===== Vector Slide-1-up
+
+Variants of slide are provided that only move by one element but which
+also allow a scalar integer value to be inserted at the vacated
+element position.
+
+----
+vslide1up.vx vd, vs2, rs1, vm # vd[0]=x[rs1], vd[i+1] = vs2[i]
+----
+
+The `vslide1up` instruction places the `x` register argument at
+location 0 of the destination vector register group, provided that
+element 0 is active, otherwise the destination element update follows the
+current mask agnostic/undisturbed policy. If XLEN < SEW, the value is
+sign-extended to SEW bits. If XLEN > SEW, the least-significant bits
+are copied over and the high XLEN-SEW bits are ignored.
+
+The remaining active `vl`-1 elements are copied over from index _i_ in
+the source vector register group to index _i_+1 in the destination
+vector register group.
+
+The `vl` register specifies the maximum number of destination vector
+register elements updated with source values, and remaining elements
+past `vl` are handled according to the current tail policy
+(<<sec-agnostic>>).
+
+
+----
+vslide1up behavior when vl > 0
+
+ i < vstart unchanged
+ 0 = i = vstart vd[i] = x[rs1] if v0.mask[i] enabled
+max(vstart, 1) <= i < vl vd[i] = vs2[i-1] if v0.mask[i] enabled
+ vl <= i < VLMAX Follow tail policy
+----
+
+The `vslide1up` instruction requires that the destination vector
+register group does not overlap the source vector register group.
+Otherwise, the instruction encoding is reserved.
+
+[[sec-vfslide1up]]
+===== Vector Floating-Point Slide-1-up Instruction
+
+----
+vfslide1up.vf vd, vs2, rs1, vm # vd[0]=f[rs1], vd[i+1] = vs2[i]
+----
+
+The `vfslide1up` instruction is defined analogously to `vslide1up`,
+but sources its scalar argument from an `f` register.
+
+===== Vector Slide-1-down Instruction
+
+The `vslide1down` instruction copies the first `vl`-1 active elements
+values from index _i_+1 in the source vector register group to index
+_i_ in the destination vector register group.
+
+The `vl` register specifies the maximum number of destination vector
+register elements written with source values, and remaining elements
+past `vl` are handled according to the current tail policy
+(<<sec-agnostic>>).
+
+----
+vslide1down.vx vd, vs2, rs1, vm # vd[i] = vs2[i+1], vd[vl-1]=x[rs1]
+----
+
+The `vslide1down` instruction places the `x` register argument at
+location `vl`-1 in the destination vector register, provided that
+element `vl-1` is active, otherwise the destination element update
+follows the current mask agnostic/undisturbed policy.
+If XLEN < SEW, the value is sign-extended to SEW bits. If
+XLEN > SEW, the least-significant bits are copied over and the high
+SEW-XLEN bits are ignored.
+
+----
+vslide1down behavior
+
+ i < vstart unchanged
+vstart <= i < vl-1 vd[i] = vs2[i+1] if v0.mask[i] enabled
+vstart <= i = vl-1 vd[vl-1] = x[rs1] if v0.mask[i] enabled
+ vl <= i < VLMAX Follow tail policy
+----
+
+NOTE: The `vslide1down` instruction can be used to load values into a
+vector register without using memory and without disturbing other
+vector registers. This provides a path for debuggers to modify the
+contents of a vector register, albeit slowly, with multiple repeated
+`vslide1down` invocations.
+
+[[sec-vfslide1down]]
+===== Vector Floating-Point Slide-1-down Instruction
+
+----
+vfslide1down.vf vd, vs2, rs1, vm # vd[i] = vs2[i+1], vd[vl-1]=f[rs1]
+----
+
+The `vfslide1down` instruction is defined analogously to `vslide1down`,
+but sources its scalar argument from an `f` register.
+
+==== Vector Register Gather Instructions
+
+The vector register gather instructions read elements from a first
+source vector register group at locations given by a second source
+vector register group. The index values in the second vector are
+treated as unsigned integers. The source vector can be read at any
+index < VLMAX regardless of `vl`. The maximum number of elements to write to
+the destination register is given by `vl`, and the remaining elements
+past `vl` are handled according to the current tail policy
+(<<sec-agnostic>>). The operation can be masked, and the mask
+undisturbed/agnostic policy is followed for inactive elements.
+
+----
+vrgather.vv vd, vs2, vs1, vm # vd[i] = (vs1[i] >= VLMAX) ? 0 : vs2[vs1[i]];
+vrgatherei16.vv vd, vs2, vs1, vm # vd[i] = (vs1[i] >= VLMAX) ? 0 : vs2[vs1[i]];
+----
+
+The `vrgather.vv` form uses SEW/LMUL for both the data and
+indices. The `vrgatherei16.vv` form uses SEW/LMUL for the data in
+`vs2` but EEW=16 and EMUL = (16/SEW)*LMUL for the indices in `vs1`.
+
+NOTE: When SEW=8, `vrgather.vv` can only reference vector elements
+0-255. The `vrgatherei16` form can index 64K elements, and can also
+be used to reduce the register capacity needed to hold indices when
+SEW > 16.
+
+If an element index is out of range ( `vs1[i]` {ge} VLMAX )
+then zero is returned for the element value.
+
+Vector-scalar and vector-immediate forms of the register gather are
+also provided. These read one element from the source vector at the
+given index, and write this value to the active elements
+of the destination vector register. The index value in the scalar
+register and the immediate, zero-extended to XLEN bits, are treated as
+unsigned integers. If XLEN > SEW, the index value is _not_ truncated
+to SEW bits.
+
+NOTE: These forms allow any vector element to be "splatted" to an entire vector.
+
+----
+vrgather.vx vd, vs2, rs1, vm # vd[i] = (x[rs1] >= VLMAX) ? 0 : vs2[x[rs1]]
+vrgather.vi vd, vs2, uimm, vm # vd[i] = (uimm >= VLMAX) ? 0 : vs2[uimm]
+----
+
+For any `vrgather` instruction, the destination vector register group
+cannot overlap with the source vector register groups, otherwise the
+instruction encoding is reserved.
+
+==== Vector Compress Instruction
+
+The vector compress instruction allows elements selected by a vector
+mask register from a source vector register group to be packed into
+contiguous elements at the start of the destination vector register
+group.
+
+----
+vcompress.vm vd, vs2, vs1 # Compress into vd elements of vs2 where vs1 is enabled
+----
+
+The vector mask register specified by `vs1` indicates which of the
+first `vl` elements of vector register group `vs2` should be extracted
+and packed into contiguous elements at the beginning of vector
+register `vd`. The remaining elements of `vd` are treated as tail
+elements according to the current tail policy
+(<<sec-agnostic>>).
+
+----
+Example use of vcompress instruction
+
+8 7 6 5 4 3 2 1 0 Element number
+
+1 1 0 1 0 0 1 0 1 v0
+8 7 6 5 4 3 2 1 0 v1
+1 2 3 4 5 6 7 8 9 v2
+ vsetivli t0, 9, e8, m1, tu, ma
+ vcompress.vm v2, v1, v0
+1 2 3 4 8 7 5 2 0 v2
+----
+
+`vcompress` is encoded as an unmasked instruction (`vm=1`). The equivalent
+masked instruction (`vm=0`) is reserved.
+
+The destination vector register group cannot overlap the source vector
+register group or the source mask register, otherwise the instruction
+encoding is reserved.
+
+A trap on a `vcompress` instruction is always reported with a
+`vstart` of 0. Executing a `vcompress` instruction with a non-zero
+`vstart` raises an illegal-instruction exception.
+
+NOTE: Although possible, `vcompress` is one of the more difficult
+instructions to restart with a non-zero `vstart`, so assumption is
+implementations will choose not do that but will instead restart from
+element 0. This does mean elements in destination register after
+`vstart` will already have been updated.
+
+===== Synthesizing `vdecompress`
+
+There is no inverse `vdecompress` provided, as this operation can be
+readily synthesized using iota and a masked vrgather:
+
+----
+Desired functionality of 'vdecompress'
+7 6 5 4 3 2 1 0 # vid
+
+ e d c b a # packed vector of 5 elements
+1 0 0 1 1 1 0 1 # mask vector of 8 elements
+p q r s t u v w # destination register before vdecompress
+
+e q r d c b v a # result of vdecompress
+----
+
+----
+# v0 holds mask
+# v1 holds packed data
+# v11 holds input expanded vector and result
+viota.m v10, v0 # Calc iota from mask in v0
+vrgather.vv v11, v1, v10, v0.t # Expand into destination
+----
+----
+p q r s t u v w # v11 destination register
+ e d c b a # v1 source vector
+1 0 0 1 1 1 0 1 # v0 mask vector
+
+4 4 4 3 2 1 1 0 # v10 result of viota.m
+e q r d c b v a # v11 destination after vrgather using viota.m under mask
+----
+
+==== Whole Vector Register Move
+
+The `vmv<nr>r.v` instructions copy whole vector registers (i.e., all
+VLEN bits) and can copy whole vector register groups. The `nr` value
+in the opcode is the number of individual vector registers, NREG, to
+copy. The instructions operate as if EEW=SEW, EMUL = NREG, effective
+length `evl`= EMUL * VLEN/SEW.
+
+NOTE: These instructions are intended to aid compilers to shuffle
+vector registers without needing to know or change `vl`.
+
+NOTE: The usual property that no elements are written if `vstart` {ge} `vl`
+does not apply to these instructions.
+Instead, no elements are written if `vstart` {ge} `evl`.
+
+NOTE: If `vd` is equal to `vs2`, the instruction does not change any
+vector register state.
+Implementations that rearrange data internally can treat this instruction
+as a hint that the register group will next be accessed with an EEW
+equal to SEW.
+
+The instruction is encoded as an OPIVI instruction. The number of
+vector registers to copy is encoded in the low three bits of the
+`simm` field (`simm[2:0]`) using the same encoding as the `nf[2:0]` field for memory
+instructions (Figure <<fig-nf>>), i.e., `simm[2:0]` = NREG-1.
+
+The value of NREG must be 1, 2, 4, or 8, and values of `simm[4:0]`
+other than 0, 1, 3, and 7 are reserved.
+
+NOTE: A future extension may support other numbers of registers to be moved.
+
+NOTE: The instruction uses the same funct6 encoding as the `vsmul`
+instruction but with an immediate operand, and only the unmasked
+version (`vm=1`). This encoding is chosen as it is close to the
+related `vmerge` encoding, and it is unlikely the `vsmul` instruction
+would benefit from an immediate form.
+
+----
+vmv<nr>r.v vd, vs2 # General form
+
+vmv1r.v v1, v2 # Copy v1=v2
+vmv2r.v v10, v12 # Copy v10=v12; v11=v13
+vmv4r.v v4, v8 # Copy v4=v8; v5=v9; v6=v10; v7=v11
+vmv8r.v v0, v8 # Copy v0=v8; v1=v9; ...; v7=v15
+----
+
+The source and destination vector register numbers must be aligned
+appropriately for the vector register group size, and encodings with
+other vector register numbers are reserved.
+
+NOTE: A future extension may relax the vector register alignment
+restrictions.
+
+=== Exception Handling
+
+On a trap during a vector instruction (caused by either a synchronous
+exception or an asynchronous interrupt), the existing `*epc` CSR is
+written with a pointer to the trapping vector instruction, while the
+`vstart` CSR contains the element index on which the trap was
+taken.
+
+NOTE: We chose to add a `vstart` CSR to allow resumption of a
+partially executed vector instruction to reduce interrupt latencies
+and to simplify forward-progress guarantees. This is similar to the
+scheme in the IBM 3090 vector facility. To ensure forward progress
+without the `vstart` CSR, implementations would have to guarantee an
+entire vector instruction can always complete atomically without
+generating a trap. This is particularly difficult to ensure in the
+presence of constant-stride or scatter/gather operations and demand-paged
+virtual memory.
+
+==== Precise vector traps
+
+NOTE: We assume most supervisor-mode environments with demand-paging
+will require precise vector traps.
+
+Precise vector traps require that:
+
+. all instructions older than the trapping vector instruction have committed their results
+. no instructions newer than the trapping vector instruction have altered architectural state
+. any operations within the trapping vector instruction affecting result elements preceding the index in the `vstart` CSR have committed their results
+. no operations within the trapping vector instruction affecting elements at or following the `vstart` CSR have altered architectural state except if restarting and completing the affected vector instruction will nevertheless produce the correct final state.
+
+We relax the last requirement to allow elements following `vstart` to
+have been updated at the time the trap is reported, provided that
+re-executing the instruction from the given `vstart` will correctly
+overwrite those elements.
+
+In idempotent memory regions, vector store instructions may have
+updated elements in memory past the element causing a synchronous
+trap. Non-idempotent memory regions must not have been updated for
+indices equal to or greater than the element that caused a synchronous
+trap during a vector store instruction.
+
+Except where noted above, vector instructions are allowed to overwrite
+their inputs, and so in most cases, the vector instruction restart
+must be from the `vstart` element index. However, there are a number of
+cases where this overwrite is prohibited to enable execution of the
+vector instructions to be idempotent and hence restartable from an
+earlier index location.
+
+Implementations must ensure forward progress can be eventually
+guaranteed for the element or segment reported by `vstart`.
+
+==== Imprecise vector traps
+
+Imprecise vector traps are traps that are not precise. In particular,
+instructions newer than `*epc` may have committed results, and
+instructions older than `*epc` may have not completed execution.
+Imprecise traps are primarily intended to be used in situations where
+reporting an error and terminating execution is the appropriate
+response.
+
+NOTE: A profile might specify that interrupts are precise while other
+traps are imprecise. We assume many embedded implementations will
+generate only imprecise traps for vector instructions on fatal errors,
+as they will not require resumable traps.
+
+Imprecise traps shall report the faulting element in `vstart` for
+traps caused by synchronous vector exceptions.
+
+There is no support for imprecise traps in the current standard extensions.
+
+==== Selectable precise/imprecise traps
+
+Some profiles may choose to provide a privileged mode bit to select
+between precise and imprecise vector traps. Imprecise mode would run
+at high-performance but possibly make it difficult to discern error
+causes, while precise mode would run more slowly, but support
+debugging of errors albeit with a possibility of not experiencing the
+same errors as in imprecise mode.
+
+This mechanism is not defined in the current standard extensions.
+
+==== Swappable traps
+
+Another trap mode can support swappable state in the vector unit,
+where on a trap, special instructions can save and restore the vector
+unit microarchitectural state, to allow execution to continue
+correctly around imprecise traps.
+
+This mechanism is not defined in the current standard extensions.
+
+NOTE: A future extension might define a standard way of saving and
+restoring opaque microarchitectural state from a vector unit
+implementation to support context switching with imprecise traps.
+
+[[sec-vector-extensions]]
+=== Standard Vector Extensions
+
+This section describes the standard vector extensions.
+A set of smaller extensions intended for embedded
+use are named with a "Zve" prefix, while a larger vector extension
+designed for application processors is named as a single-letter V
+extension. A set of vector length extension names with prefix "Zvl"
+are also provided.
+
+The initial vector extensions are designed to act as a base for
+additional vector extensions in various domains, including
+cryptography and machine learning.
+
+==== Zvl*: Minimum Vector Length Standard Extensions
+
+All standard vector extensions have a minimum required VLEN as
+described below. A set of vector length extensions are provided to
+increase the minimum vector length of a vector extension.
+
+NOTE: The vector length extensions can be used to either specify
+additional software or architecture profile requirements, or to
+advertise hardware capabilities.
+
+.Vector length extensions
+[cols="1,1"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+| Extension | Minimum VLEN
+
+| Zvl32b | 32
+| Zvl64b | 64
+| Zvl128b | 128
+| Zvl256b | 256
+| Zvl512b | 512
+| Zvl1024b | 1024
+|===
+
+NOTE: Longer vector length extensions should follow the same pattern.
+
+NOTE: Every vector length extension effectively includes all shorter
+vector length extensions.
+
+NOTE: Explicit use of the Zvl32b extension string is not required for
+any standard vector extension as they all effectively mandate at least
+this minimum, but the string can be useful when stating hardware
+capabilities.
+
+==== Zve*: Vector Extensions for Embedded Processors
+
+The following five standard extensions are defined to provide varying
+degrees of vector support and are intended for use with embedded
+processors. Any of these extensions can be added to base ISAs with
+XLEN=32 or XLEN=64. The table lists the minimum VLEN and supported
+EEWs for each extension as well as what floating-point types are
+supported.
+
+.Embedded vector extensions
+[cols="1,1,2,1,1"]
+[%autowidth,float="center",align="center",options="header"]
+|===
+| Extension | Minimum VLEN | Supported EEW | FP32 | FP64
+
+| Zve32x | 32 | 8, 16, 32 | N | N
+| Zve32f | 32 | 8, 16, 32 | Y | N
+| Zve64x | 64 | 8, 16, 32, 64 | N | N
+| Zve64f | 64 | 8, 16, 32, 64 | Y | N
+| Zve64d | 64 | 8, 16, 32, 64 | Y | Y
+|===
+
+The Zve32f and Zve64x extensions depend on the Zve32x extension.
+The Zve64f extension depends on the Zve32f and Zve64x extensions.
+The Zve64d extension depends on the Zve64f extension.
+
+All Zve* extensions have precise traps.
+
+NOTE: There is currently no standard support for handling imprecise
+traps, so standard extensions have to provide precise traps.
+
+All Zve* extensions provide support for EEW of 8, 16, and 32, and
+Zve64* extensions also support EEW of 64.
+
+All Zve* extensions support the vector configuration instructions
+(<<sec-vector-config>>).
+
+All Zve* extensions support all vector load and store instructions
+(<<sec-vector-memory>>), except Zve64* extensions do not
+support EEW=64 for index values when XLEN=32.
+
+All Zve* extensions support all vector integer instructions
+(<<sec-vector-integer>>), except that the `vmulh` integer multiply
+variants that return the high word of the product (`vmulh.vv`,
+`vmulh.vx`, `vmulhu.vv`, `vmulhu.vx`, `vmulhsu.vv`, `vmulhsu.vx`) are
+not included for EEW=64 in Zve64*.
+
+NOTE: Producing the high-word of a product can take substantial
+additional gates for large EEW.
+
+All Zve* extensions support all vector fixed-point arithmetic
+instructions (<<sec-vector-fixed-point>>), except that `vsmul.vv` and
+`vsmul.vx` are not included in EEW=64 in Zve64*.
+
+NOTE: As with `vmulh`, `vsmul` requires a large amount of additional
+logic, and 64-bit fixed-point multiplies are relatively rare.
+
+All Zve* extensions support all vector integer single-width and
+widening reduction operations (<<sec-vector-integer-reduce>>,
+<<sec-vector-integer-reduce-widen>>).
+
+All Zve* extensions support all vector mask instructions
+(<<sec-vector-mask>>).
+
+All Zve* extensions support all vector permutation instructions
+(<<sec-vector-permute>>), except that Zve32x and Zve64x
+do not include those with floating-point operands, and Zve64f does not include those
+with EEW=64 floating-point operands.
+
+The Zve32x extension depends on the Zicsr extension.
+The Zve32f and Zve64f extensions depend upon the F extension,
+and implement all
+vector floating-point instructions (<<sec-vector-float>>) for
+floating-point operands with EEW=32. Vector single-width floating-point reduction
+operations (<<sec-vector-float-reduce>>) for EEW=32 are supported.
+
+The Zve64d extension depends upon the D extension,
+and implements all vector
+floating-point instructions (<<sec-vector-float>>) for
+floating-point operands with EEW=32 or EEW=64 (including widening
+instructions and conversions between FP32 and FP64). Vector
+single-width floating-point reductions (<<sec-vector-float-reduce>>)
+for EEW=32 and EEW=64 are supported as well as widening reductions
+from FP32 to FP64.
+
+==== V: Vector Extension for Application Processors
+
+The single-letter V extension is intended for use in application
+processor profiles.
+
+The `misa.v` bit is set for implementations providing `misa` and
+supporting V.
+
+The V vector extension has precise traps.
+
+The V vector extension depends upon the Zvl128b and Zve64d extensions.
+
+NOTE: The value of 128 was chosen as a compromise for application
+processors. Providing a larger VLEN allows strip-mining code to be
+elided in some cases for short vectors, but also increases the size of
+the minimum implementation. Note that larger LMUL can be used to
+avoid strip mining for longer known-size application vectors at the
+cost of having fewer available vector register groups. For example, an
+LMUL of 8 allows vectors of up to sixteen 64-bit elements to be
+processed without strip mining using four vector register groups.
+
+The V extension supports EEW of 8, 16, and 32, and 64.
+
+The V extension supports the vector configuration instructions
+(<<sec-vector-config>>).
+
+The V extension supports all vector load and store instructions
+(<<sec-vector-memory>>), except the V extension does not
+support EEW=64 for index values when XLEN=32.
+
+The V extension supports all vector integer instructions
+(<<sec-vector-integer>>).
+
+The V extension supports all vector fixed-point arithmetic
+instructions (<<sec-vector-fixed-point>>).
+
+The V extension supports all vector integer single-width and
+widening reduction operations (<<sec-vector-integer-reduce>>,
+<<sec-vector-integer-reduce-widen>>).
+
+The V extension supports all vector mask instructions
+(<<sec-vector-mask>>).
+
+The V extension supports all vector permutation instructions
+(<<sec-vector-permute>>).
+
+The V extension depends upon the F and D
+extensions, and implements all vector floating-point instructions
+(<<sec-vector-float>>) for floating-point operands with EEW=32
+or EEW=64 (including widening instructions and conversions between
+FP32 and FP64). Vector single-width floating-point reductions
+(<<sec-vector-float-reduce>>) for EEW=32 and EEW=64 are supported as
+well as widening reductions from FP32 to FP64.
+
+[NOTE]
+====
+As is the case with other RISC-V extensions, it is valid to
+include overlapping extensions in the same ISA string. For example,
+RV64GCV and RV64GCV_Zve64f are both valid and equivalent ISA strings,
+as is RV64GCV_Zve64f_Zve32x_Zvl128b.
+====
+
+==== Zvfhmin: Vector Extension for Minimal Half-Precision Floating-Point
+
+The Zvfhmin extension provides minimal support for vectors of IEEE 754-2008
+binary16 values, adding conversions to and from binary32.
+When the Zvfhmin extension is implemented, the `vfwcvt.f.f.v` and
+`vfncvt.f.f.w` instructions become defined when SEW=16.
+The EEW=16 floating-point operands of these instructions use the binary16
+format.
+
+The Zvfhmin extension depends on the Zve32f extension.
+
+==== Zvfh: Vector Extension for Half-Precision Floating-Point
+
+The Zvfh extension provides support for vectors of IEEE 754-2008
+binary16 values.
+When the Zvfh extension is implemented, all instructions in
+<<sec-vector-float>>, <<sec-vector-float-reduce>>,
+<<sec-vector-float-reduce-widen>>, <<sec-vector-float-move>>,
+<<sec-vfslide1up>>, and <<sec-vfslide1down>>
+become defined when SEW=16.
+The EEW=16 floating-point operands of these instructions use the binary16
+format.
+
+Additionally, conversions between 8-bit integers and binary16 values are
+provided. The floating-point-to-integer narrowing conversions
+(`vfncvt[.rtz].x[u].f.w`) and integer-to-floating-point
+widening conversions (`vfwcvt.f.x[u].v`) become defined when SEW=8.
+
+The Zvfh extension depends on the Zve32f and Zfhmin extensions.
+
+NOTE: Requiring basic scalar half-precision support makes Zvfh's
+vector-scalar instructions substantially more useful.
+We considered requiring more complete scalar half-precision support, but we
+reasoned that, for many half-precision vector workloads, performing the scalar
+computation in single-precision will suffice.
+
+[[vector-element-groups]]
+=== Vector Element Groups
+
+Some vector instructions treat operands as a vector of one or more
+_element_ _groups_, where each element group is a fixed number of
+elements. For example, complex numbers can be viewed as a two-element
+group (one real element and one imaginary element).
+As another example, the SHA-256 cryptographic instructions in the Zvknha
+extension operate on 128-bit values represented as a 4-element group of 32-bit
+elements.
+
+This section describes recommendations and terminology for generic
+instruction set design for vector instructions that operate on element
+groups.
+
+==== Element Group Size
+
+The _element_ _group_ _size_ (EGS) is the number of elements in one
+group, and must be a power-of-two (POT).
+
+NOTE: Support for non-POT EGS was considered but causes many practical
+complications and so has been dropped. Error checking for `vl` is a
+little more difficult. For LMUL>1, non-POT EGSs will result in groups
+straddling the individual vector registers in a vector register
+group. Non-POT EGS can also cause large increases in the
+lowest-common-multiple of element group sizes, which adds constraints
+to `vl` setting in order to avoid splitting an element group across
+strip-mine iterations in vector-length-agnostic code.
+
+The element group size is statically encoded in the instruction, often
+implicitly as part of the opcode.
+
+Vector instructions with EGS > VLMAX are reserved.
+
+NOTE: The vector instructions in the base V vector ISA can be viewed
+as all having an element group size of 1 for all operands statically
+encoded in the instruction.
+
+NOTE: Many operations only make sense with a certain number of
+elements per group (e.g., complex operations require a element group
+size of 2 and SHA-256 requires an element group size of 4).
+
+==== Setting `vl`
+
+Each source and destination operand to a vector instruction might be
+defined as either a single element group or a vector of element
+groups. When an operand is a vector of element groups, the `vl`
+setting must correspond to an integer multiple of the element group
+size, with other values of `vl` reserved.
+
+NOTE: For example, a SHA-256 instruction would require that `vl` is a
+multiple of 4.
+
+When element group instructions are present, an additional constraint
+is placed on the setting of `vl` based on an AVL value
+(augmenting <<constraints-on-setting-vl>>).
+EGSMAX is the largest EGS supported by the
+implementation. When AVL > VLMAX, the value of `vl` must be set to
+either VLMAX or a positive integer multiple of EGSMAX.
+
+NOTE: As the base vector extension only has element group size of 1,
+this constraint is backwards-compatible.
+
+NOTE: This constraint prevents element groups being broken across
+strip-mining iterations in vector-length-agnostic code when a
+VLMAX-size vector would otherwise be able to accommodate a whole number
+of element groups.
+
+NOTE: If EEW is encoded statically in the instruction, or if an
+instruction has multiple operands containing vectors of element groups
+with different EEW, an appropriate SEW must be chosen for `vsetvl`
+instructions.
+
+NOTE: Additional constraints may be required for some element group
+instructions to ensure legal length values for all operands.
+
+==== Determining EEW
+
+The `vtype` SEW can be used to indicate or calculate the effective
+element size (EEW) of one or more operands of an element group
+instruction. Where the operand is an element group, SEW and EEW refer
+to the number of bits in each individual element within a group not
+the number of bits in the group as a whole.
+
+Alternatively, the opcode might encode EEW of all operands statically
+and ignore the value of SEW when the operation only makes sense for a
+single size on each operand.
+
+NOTE: Many operations are only defined for one EEW, e.g., SHA-256
+requires EEW=32. Encoding EEWs statically in the instruction removes
+a dynamic dependency on the SEW value and the need to check for errors
+in SEW values. However, ignoring SEW also prevents reuse of the
+static opcode with a different dynamic SEW, and in many cases, the SEW
+setting will be needed for regular vector instructions used to process
+the individual elements in the vector.
+
+==== Determining EMUL
+
+The `vtype` LMUL setting can be used to indicate or calculate the
+effective length multiplier (EMUL) for one or more operands. Element
+group instructions tend to exhibit a much wider range of relationships
+between various operand EEW/EMUL values. For example, an instruction
+might take a vector of length N of 4-element groups with EEW=8b and
+reduce each group to produce a vector length N of 1-element groups
+with EEW=32b. In this case, the input and output EMUL values are equal
+even though the EEW settings differ by a factor of 4.
+
+Each source and destination operand to a vector instruction may have a
+different element group size, different EMUL, and/or different EEW.
+
+==== Element Group Width
+
+The _element_ _group_ _width_ (EGW) is the number of bits in the
+element group as a whole.
+For example, the SHA-256 instructions in the Zvknha extension operate on an
+EGW of 128, with EGS=4 and EEW=32.
+It is possible to use LMUL to concatenate multiple vector registers together
+to support larger EGW>VLEN.
+
+NOTE: If software using large-EGW instructions need be portable
+across a range of implementations, some of which may have VLEN<EGW and
+hence require LMUL>1, then software can only use a subset of the
+architectural registers. Profiles can set minimum VLEN requirements
+to inform authors of such software.
+
+NOTE: Element group operations by their nature will gather data from
+across a wider portion of a vector datapath than regular vector
+instructions. Some element group instructions might allow temporal
+execution of individual element operations in a larger group, while
+others will require all EGW bits of a group to be presented to a
+functional unit at the same time.
+
+==== Masking
+
+No ratified extensions include masked element-group instructions.
+Future extensions might extend the element-group scheme to support
+element-level masking, or might define the concept of a _mask element group_
+(which might, e.g., update the destination element group if any mask bit in
+the mask element group is set).
+
+=== Vector Instruction Listing
+
+include::images/wavedrom/v-inst-table.edn[]
diff --git a/src/v.tex b/src/v.tex
deleted file mode 100644
index c5c277d..0000000
--- a/src/v.tex
+++ /dev/null
@@ -1,1402 +0,0 @@
-\chapter{``V'' Standard Extension for Vector Operations, Version 0.4-DRAFT}
-\label{sec:vector}
-
-{\bf This version is out-of-date with respect to the current working
- group draft, which is now hosted on {\tt https://github.com/riscv/riscv-v-spec}.}
-
-This chapter presents a proposal for the RISC-V base vector
-instruction-set extension. The base vector extension is intended to
-provide general support for data-parallel execution within the 32-bit
-instruction encoding space, with later vector extensions supporting
-richer functionality for certain domains.
-
-\begin{commentary}
-The vector extension is based on the style of vector register
-architecture introduced by Seymour Cray in the 1970s, as opposed to
-the earlier packed SIMD approach, introduced with the Lincoln Labs
-TX-2 in 1957 and now adopted by most other commercial instruction
-sets.
-\end{commentary}
-
-The base vector extension defines the components that must be included
-when the ``V'' bit is set in the {\tt misa} register, and consequently
-those that will be assumed to exist by software written for an ABI
-specifying V.
-
-\begin{commentary}
- This draft version of the chapter includes additional specifications
- of proposed extensions to the base vector extension to explain some
- of the encoding choices made for the base.
-\end{commentary}
-
-The vector extension supports a configurable vector unit, to enable
-implementations to tradeoff the number of active architectural vector
-registers and supported element widths against available maximum
-vector length. The vector extension is designed to allow the same
-binary code to work efficiently across a variety of hardware
-implementations varying in physical vector storage capacity and
-datapath spatial and/or temporal parallelism.
-
-\begin{commentary}
-The vector instruction set contains many features developed in earlier
-research projects, including the Berkeley T0~\cite{} and VIRAM~\cite{VIRAM}
-vector microprocessors, the MIT Scale vector-thread processor~\cite{},
-and the Berkeley Maven~\cite{} and Hwacha~\cite{} projects.
-\end{commentary}
-
-\section{Vector Unit State}
-
-The additional vector unit architectural state includes 32 vector
-registers ({\tt v0}--{\tt v31}), and an XLEN-bit WARL vector length
-CSR, {\tt vl}. Each vector register {\tt v}$n$ has an associated
-16-bit configuration field {\tt vtype}$n$ described below. A 6-bit
-global maximum element width register {\tt vmaxew} defines the maximum
-number of bits of storage in every element of every active vector
-register.
-
-\begin{commentary}
- Future vector extensions using wider instruction encodings can
- support more architectural vector registers. For example, 256
- architectural vector registers in a 64-bit instruction encoding.
-\end{commentary}
-
-\begin{commentary}
- Future 2D shape extensions add two more vector length registers,
- {\tt vm} and {\tt vn}.
-\end{commentary}
-
-There is also a 3-bit fixed-point rounding mode CSR {\tt vxrm}, and a
-single-bit fixed-point saturation status CSR {\tt vxsat}. The {\tt
- vcs} CSR alias provides combined access to the {\tt vl}, {\tt vxrm},
-{\tt vxsat} fields to reduce context switch time. The {\tt vcs}
-register also includes a configuration mode field to support future
-extended configuration modes.
-
-\begin{discussion}
-The components of vcs might not need separate CSR addresses,
-depending on how they're accessed via other non-CSR instructions.
-\end{discussion}
-
-\section{Vector Unit Type Configuration Register ({\tt vtype}$n$)}
-
-The vector unit must be configured before use. Each architectural
-vector register, {\tt v}$n$, is configured via 16 bits of vector type
-configuration state {\tt vtype}$n$, which can be accessed via vector
-configuration ({\tt vcfg}) CSRs and other rapid vector configuration
-instructions as described below. The vector register type
-configuration encodes the overall organization, or {\em shape}, of the
-elements in each vector register (e.g., scalar versus 1-D vector), as
-well as the bitwidth and numeric representation of each element. As
-shown in Figure~\ref{fig:vtype}, the 16-bit {\tt vtype}$n$ encoding is
-divided into a 5-bit current shape field {\tt vshape}$n$, a 5-bit
-representation field {\tt verep}$n$, and a 6-bit element bit-width
-field {\tt vew}$n$\, held in the {\tt vcfg}$x$ CSRs. The combination
-of an element numeric representation and an element bitwidth is called
-an element {\em format}. Each vector register can also be disabled to
-free physical vector storage for other architectural vector registers.
-
-\begin{figure}[htb]
-\begin{center}
-\begin{tabular}{O@{}O@{}O}
-\\
-\instbitrange{15}{11} &
-\instbitrange{10}{6} &
-\instbitrange{5}{0} \\
-\hline
-\multicolumn{1}{|c|}{{\tt vshape}$n$} &
-\multicolumn{1}{c|}{{\tt verep}$n$} &
-\multicolumn{1}{c|}{{\tt vew}$n$} \\
-\hline
-5 & 5 & 6 \\
-\end{tabular}
-\end{center}
-\caption{Location of subfields within a single {\tt vtype}$n$ field.}
-\label{fig:vtype}
-\end{figure}
-
-\begin{commentary}
- It was also common in earlier vector machines to support multiple
- precisions within the vector datapath. In particular, the CDC
- STAR-100~\cite{cdcstar100} supported single-precision and
- double-precision floating-point operations and also bit, byte, and
- nibble operations in the vector unit; TI ASC~\cite{tiasc} designs
- supported dividing 64-bit vector lanes into two 32-bit lanes for
- double throughput.
-\end{commentary}
-
-\clearpage
-
-\section{Shape Encoding}
-
-The 5-bit shape field describes the structure of the elements within
-the vector register. In the base vector extension, the shape can be
-set to either scalar or vector.
-
-\begin{table}[hbt]
- \centering
- \begin{tabular}{|c|l|}
- \hline
- {\tt vshape} & Shape \\
- \hline
- 00000 & scalar \\
- 00100 & 1-D vector, length controlled by {\tt vl} \\
- \hline
- \multicolumn{2}{|c|}{All other encodings reserved}\\
- \hline
- \end{tabular}
- \caption{Base vector encoding of {\tt vshape}$n$ field.}
- \label{tab:vshape}
-\end{table}
-
-\begin{commentary}
- For the base vector ISA, only a single bit is required in each {\tt
- vshape} field to select between scalar and 1-D vector elements
- with the other bits hardwired to zero.
-\end{commentary}
-
-\begin{table}[hbt]
- \centering
- \begin{tabular}{|c|l|}
- \hline
- {\tt vshape} & Shape \\
- \hline
- 00000 & scalar \\
- 00001 & {\em Reserved} \\
- 0001x & {\em Reserved} \\
- \hline
- 00100 & 1-D vector {\tt vl} \\
- 01000 & 1-D vector {\tt vm} \\
- 01100 & 1-D vector {\tt vn} \\
- \hline
- 00101 & 2-D matrix {\tt vl} x {\tt vl} \\
- 00110 & 2-D matrix {\tt vl} x {\tt vm} \\
- 00111 & 2-D matrix {\tt vl} x {\tt vn} \\
- \hline
- 01001 & 2-D matrix {\tt vm} x {\tt vl} \\
- 01010 & 2-D matrix {\tt vm} x {\tt vm} \\
- 01011 & 2-D matrix {\tt vm} x {\tt vn} \\
- \hline
- 01101 & 2-D matrix {\tt vn} x {\tt vl} \\
- 01110 & 2-D matrix {\tt vn} x {\tt vm} \\
- 01111 & 2-D matrix {\tt vn} x {\tt vn} \\
- \hline
- 1xxxx & {\em Reserved}/{\em Custom} \\
- \hline
- \end{tabular}
- \caption{Extended encoding of per-vector-register {\tt vshape} field.}
- \label{tab:extvshape}
-\end{table}
-
-\begin{commentary}
- A sketch of the proposed encodings for the 2D shape extension is
- shown in the Table.
-\end{commentary}
-
-\clearpage
-
-\section{Representation Encoding}
-
-The 5-bit {\tt verep}$n$ register sets the numeric representation of
-each element of the vector register. In the base vector
-extension, the representation can be set to unsigned integer,
-two's-complement signed integer, or floating-point. The
-floating-point representations follow the IEEE 754 standards.
-
-\begin{table}[hbtp]
- \centering
- \begin{tabular}{|c|l|}
- \hline
- {\tt verep} & Representation \\
- \hline
- 00000 & Unsigned integer \\
- 00001 & Two's-complement signed integer \\
- 00010 & {\em Reserved (unsigned floating-point?)}\\
- 00011 & IEEE-754 floating-point \\
- \hline
- \multicolumn{2}{|c|}{All other encodings reserved}\\
- \hline
- \end{tabular}
- \caption{Base vector representation encoding.}
- \label{tab:verep}
-\end{table}
-
-\begin{table}[hbtp]
- \centering
- \begin{tabular}{|c|l|}
- \hline
- {\tt verep} & Representation \\
- \hline
- 00000 & Unsigned integer \\
- 00001 & Two's-complement signed integer \\
- 00010 & {\em Reserved (unsigned floating-point)}\\
- 00011 & IEEE-754 floating-point \\
- \hline
- 001x0 & {\em Reserved} \\
- 00101 & Complex signed integer \\
- 00111 & Complex floating-point \\
- \hline
- 01000 & Prime Galois field - integer representation \\
- 01001 & Prime Galois field - Montgomery representation \\
- 01100 & Binary extension Galois field - polynomial basis \\
- 01101 & Binary extension Galois field - normal basis \\
- \hline
- 01010 & UNORM \\
- 01011 & SNORM \\
- 01110 & {\em Reserved} \\
- 01111 & {\em Reserved (complex SNORM?)} \\
- \hline
- 10xxx & Custom representations \\
- \hline
- 11xxx & {\em Reserved} \\
- \hline
- \end{tabular}
- \caption{Extended vector representation encoding.}
- \label{tab:extverep}
-\end{table}
-
-\begin{commentary}
- The complex representations split the element width given in {\tt
- vew}$n$ into two equal-sized real and imaginary fields, so an
- element width of 64 bits can hold a single complex value with a
- 32-bit real and a 32-bit imaginary component.
-\end{commentary}
-
-\clearpage
-
-\section{Element Bitwidth}
-
-Each vector register, {\tt v}$n$, has a 6-bit element width
-register, {\tt vew}$n$, to specify the number of bits for each element
-of the current type in the vector register.
-
-The largest element width supported is
-termed ELEN, and is defined to be the larger of the supported integer
-and floating-point type widths:
-\[ \mbox{\em ELEN} = max(\mbox{\em XLEN}, \mbox{\em FLEN}) \]
-For the base vector ISA, the bit width can be set at any power of two
-between 8 and ELEN.
-
-\begin{table}[hbt]
- \centering
- \begin{tabular}{|c|r|l|}
- \hline
- {\tt vew} & Width & Required in Base \\
- \hline
- 000 000 & disabled & All \\
- 001 000 & 8 & All \\
- 010 000 & 16 & All \\
- 011 000 & 32 & All \\
- 100 000 & 64 & RV32D, RV64, RV128\\
- 101 000 & 128 & RV64Q, RV128\\
- \hline
- \multicolumn{3}{|c|}{All other encodings reserved.}\\
- \hline
- \end{tabular}
- \caption{Base vector ISA encoding of vector element width ({\tt
- vew}$n$) register fields.}
- \label{tab:basevew}
-\end{table}
-
-\begin{table}[hbtp]
- \centering
- \begin{tabular}{|c|r|}
- \hline
- {\tt vew} & Width \\
- \hline
- 000 000 & disabled \\
- 000 001 & 1 \\
- 000 xxx & \multicolumn{1}{r|}{steps of 1}\\
- 000 111 & 7 \\
- \hline
- 001 000 & 8 \\
- 001 xxx & \multicolumn{1}{r|}{steps of 1}\\
- 001 111 & 15 \\
- \hline
- 010 000 & 16 \\
- 010 xxx & \multicolumn{1}{r|}{steps of 2}\\
- 010 111 & 30 \\
- \hline
- 011 000 & 32 \\
- 011 xxx & \multicolumn{1}{r|}{steps of 4}\\
- 011 111 & 60 \\
- \hline
- 100 000 & 64 \\
- 100 xxx & \multicolumn{1}{r|}{steps of 8}\\
- 100 111 & 120 \\
- \hline
- 101 xxx & reserved \\
- \hline
- 110 000 & 128 \\
- 110 001 & 192 \\
- 110 010 & 2048 \\
- 110 011 & 3072 \\
- 110 100 & 512 \\
- 110 101 & 768 \\
- 110 110 & 8192 \\
- 110 111 & 12288 \\
- \hline
- 111 000 & 256 \\
- 111 001 & 384 \\
- 111 010 & 4096 \\
- 111 011 & 6144 \\
- 111 100 & 1024 \\
- 111 101 & 1536 \\
- 111 110 & 16384 \\
- 111 111 & 24576 \\
- \hline
- \end{tabular}
-
- \caption{Proposed extended encoding of vector element width ({\tt
- vew}$n$) register fields. Every bit width between 1 and 16 can
- be supported. Bit widths in steps of 2 between 16 to 32 (i.e.,
- 16, 18, 20, ...). Bit widths in steps of 4 between 32 to 64
- (i.e., 32, 36, 40, ...). Bit widths in steps of 8 between 64 and
- 128 (i.e., 64, 72, 80,...). For bit widths greater than 128, all
- powers-of-two up to 16384 and all widths 1.5$\times$ greater are
- supported (128, 384, 512, 768,...). }
- \label{tab:extvew}
-\end{table}
-
-\begin{commentary}
- The extended bit-width encoding is designed to minimize the number
- of state bits required to support useful subsets of widths. For
- example, an RV32 system only needs two bits of state per {\tt
- vew}$n$ field to represent {\em disabled}, 8, 16, and 32. An
- RV32 system with 3 bits of state can represent {\em disabled}, 4,
- 8, 12, 16, 24, 32, and 48. An RV64 system with 4 bits of state
- can represent {\em disabled}, 4, 8, 12, 16, 24, 32, 48, 64, 96,
- 128, 256, 512, 1024.
-\end{commentary}
-
-\clearpage
-
-\section{Base Vector Extension Supported Types}
-
-The types supported by the base V extension depend upon the base
-scalar ISA and supported extensions. When the base V extension is
-added to a base scalar ISA, it must support the vector data element
-types implied by the supported scalar types as defined by
-Table~\ref{tab:velemtypes}.
-
-\begin{table}[hbt]
- \centering
-\begin{tabular}{|l|l|}
- \hline
- \multicolumn{2}{|c|}{Supported Fixed-Point Formats} \\
- \hline
- RV32I & I8, U8, I16, U16, I32, U32 \\
- RV64I & I8, U8, I16, U16, I32, U32, I64, U64 \\
- RV128I & I8, U8, I16, U16, I32, U32, I64, U64, I128, U128 \\
- \hline
- \hline
- \multicolumn{2}{|c|}{Supported Floating-Point Formats} \\
- \hline
- F & F16, F32 \\
- FD & F16, F32, F64 \\
- FDQ & F16, F32, F64, F128 \\
- \hline
-\end{tabular}
-\caption{Supported data element formats depending on base integer ISA
- and supported floating-point extensions. I$x$ indicates a signed
- integer of $x$ bits, U$x$ indicates an unsigned integer of $x$ bits,
- and F$x$ indicates an IEEE floating-point number of $x$ bits.}
-\label{tab:velemtypes}
-\end{table}
-
-\begin{commentary}
- Future vector extensions might expand the set of supported
- datatypes, including custom application-specific datatypes.
-\end{commentary}
-
-\clearpage
-
-\section{Maximum Vector Element Width ({\tt vmaxew})}
-
-The global {\tt vmaxew} field is used to support more complex vector
-runtime environments where the types to be held in each register of a
-single configuration may vary dynamically, and may not even be known
-at compile time due to separate compilation.
-
-The global maximum element width register {\tt vmaxew} defines the
-maximum number of bits of storage in every element of every active
-architectural register, or if zero, defers to the per-vector-register
-width field.
-
-\begin{commentary}
- The VIRAM processor had a virtual processor width
- register similar to {\tt vmaxew}~\cite{VIRAM}.
-\end{commentary}
-
-If {\tt vmaxew} is zero, then the per-element vector element widths
-{\tt vew}$n$ determine the minimum storage required for each element
-of the associated vector register {\tt v}$n$.
-
-If {\tt vmaxew} is non-zero, it sets the largest element width that
-can be supported in any vector register element in the current
-configuration.
-
-\clearpage
-
-\section{Vector Configuration Registers ({\tt vcfg0}--{\tt vcfg15})}
-
-The vector type configuration requires 512 bits of state (32 vector
-registers each with 16-bit {\tt vtype}$n$ field) that can be accessed
-via the {\tt vcfg CSRs}.
-
-RV128 uses four vector configuration CSRs: {\tt vcfg0} holds
-configuration data for {\tt v0}--{\tt v7} with bits $16n$ to $16n+15$
-holding {\tt vtype}$n$, while {\tt vcfg4}, {\tt vcfg8} and {\tt
- vcfg12} similarly holds configuration data for {\tt v8}--{\tt v15},
- {\tt v16}--{\tt v23}, and {\tt v24}--{\tt v31} respectively.
-
-In RV64, the {\tt vcfg2} CSR provides access to the upper 64 bits of {\tt
- vcfg0} and {\tt vcfg6} provides access to the upper 64 bits of
-{\tt vcfg4}. In RV32, the {\tt vcfg1}, {\tt vcfg3}, {\tt vcfg5}
-and {\tt vcfg7} CSRs provides access to the upper bits of {\tt
- vcfg0}, {\tt vcfg2}, {\tt vcfg4} and {\tt vcfg6} respectively.
-
-Any CSR write to a {\tt vcfg}$x$ register zeros all {\tt vcfg}$y$
-registers, for $y>x$. As a result configuration data should be
-written from the {\tt vcfg0} CSR upwards.
-
-\begin{commentary}
- Zeroing higher-numbered {\tt vcfg}$y$ registers allows more rapid
- reconfiguration of the vector register file via CSR writes, and
- provides backward-compatibility for extensions that increase the
- number of possible architectural vector registers. This choice does
- prevent the use of CSRRW instructions to swap the configuration
- context; an entire old configuration must be read out before a new
- configuration is written in.
-\end{commentary}
-
-Additional instructions are provided to support more rapid changes to
-the vector unit configuration as described below.
-
-\section{Legal Vector Unit Configurations}
-
-To simplify hardware configuration calculations and to reduce software
-context-switch complexity, vector unit configurations are constrained
-to have non-disabled architectural vector registers numbered
-contiguously starting at {\tt v0}. An exception will be raised if an
-instruction tries to change {\tt vtype}$n$ in a way that violates this
-constraint.
-
-\begin{commentary}
- During a software vector-context save, the software handler can stop
- searching for active architectural registers after encountering the
- first disabled vector register. Hardware to calculate physical
- register allocation is also simplified with this constraint.
-\end{commentary}
-
-\clearpage
-
-\section{Vector Unit CSRs}
-
-\begin{table}[hbt]
- \centering
- \begin{tabular}{|l|c|l|l|}
- \hline
- CSR name & Number & Base ISA & Description\\
- \hline
- {\tt vcs} & TBD & RV32, RV64, RV128 & Vector control-status register\\
- {\tt vl} & TBD & RV32, RV64, RV128 & Active vector length\\
- {\tt vxrm} & TBD & RV32, RV64, RV128 & Vector fixed-point rounding mode\\
- {\tt vxsat} & TBD & RV32, RV64, RV128 & Vector fixed-point
- saturation flag \\
- {\tt vmaxew} & TBD & RV32, RV64, RV128 & Global maximum vector element width \\
- \hline
- {\tt vcfg0} & TBD & RV32, RV64, RV128 & \multirow{16}{*}{Vector
- register configuration}\\
- {\tt vcfg1} & TBD & RV32 &\\
- {\tt vcfg2} & TBD & RV32, RV64 &\\
- {\tt vcfg3} & TBD & RV32 &\\
- {\tt vcfg4} & TBD & RV32, RV64, RV128 &\\
- {\tt vcfg5} & TBD & RV32 &\\
- {\tt vcfg6} & TBD & RV32, RV64 &\\
- {\tt vcfg7} & TBD & RV32 &\\
- {\tt vcfg8} & TBD & RV32, RV64, RV128 & \\
- {\tt vcfg9} & TBD & RV32 &\\
- {\tt vcfg10} & TBD & RV32, RV64 &\\
- {\tt vcfg11} & TBD & RV32 &\\
- {\tt vcfg12} & TBD & RV32, RV64, RV128 &\\
- {\tt vcfg13} & TBD & RV32 &\\
- {\tt vcfg14} & TBD & RV32, RV64 &\\
- {\tt vcfg15} & TBD & RV32 &\\
- \hline
- \end{tabular}
- \caption{Vector extension CSRs.}
- \label{tab:vcsrs}
-\end{table}
-
-\clearpage
-
-\section{Maximum Vector Length (MVL)}
-
-The implementation determines an available {\em maximum vector length}
-(MVL) dependent on the current vector type configuration held in {\tt
- vcfg}$x$ and {\tt vmaxew}. The available MVL depends on the
-configuration setting and on the implementation's microarchitecture,
-but MVL must always have the same value for the same configuration
-parameters on a given hart.
-
-\begin{commentary}
- Several earlier vector machines had the ability to configure
- physical vector register storage into a larger number of short
- vectors or a shorter number of long vectors. In particular the
- Fujitsu VP series~\cite{vp200} supported combining power-of-2 base
- vector registers into longer vector registers.
-
- The Scale~\cite{}, Maven~\cite{}, and Hwacha~\cite{} processors also
- support configuration-dependent MVL.
-\end{commentary}
-
-\begin{commentary}
- Previously, the specification imposed a minimum vector length (4) on
- all configurations to allow stripmining code to be removed for short
- vector lengths. With the expanded scope of the vector unit types,
- this would be too onerous to support, and so the requirement is removed.
-\end{commentary}
-
-\begin{discussion}
- A separate mechanism for supporting fixed vector lengths should be
- designed, possibly as part of an optional extension.
-\end{discussion}
-
-Any change to the vector configuration that might change MVL cause the
-entire vector unit state to be zeroed. Any write to the global {\tt
- vmaxew} causes the entire vector unit state to be zeroed, even if
-the value in {\tt vmaxew} is unchanged.
-
-If {\tt vmaxew} is non-zero, any write to an individual {\tt vew}$n$
-register that would set the width greater than {\tt vmaxew} raises an
-illegal instruction exception and leaves the vector unit state
-unchanged.
-
-If {\tt vmaxew} is non-zero, any write to an individual {\tt vew}$n$
-field with a value less than or equal to the value in {\tt vmaxew}
-only zeros the associated vector register {\tt v}$n$ and leaves other
-vector unit state unchanged. The vector register data is zeroed even
-if {\tt vew}$n$ would be unchanged by the write.
-
-If {\tt vmaxew} is zero, then any write to an individual {\tt vew}$n$
-register zeros the associated {\tt v}$n$ vector register. In addition,
-any write that changes the value in {\tt vew}$n$, zeros the entire vector
-unit state.
-
-\begin{commentary}
- The state is zeroed to hide implementation-dependent bit mappings
- and to provide additional security when context swapping. Zero is
- also a convenient initial value for some loops.
-
- In-order implementations will probably use a flag bit per register to
- mux in 0 instead of garbage values on each source until it is
- overwritten. For in-order machines, vector lengths less than MVL
- complicate this zeroing, but these cases can be handled by adding a
- zero bit per element or element group. Machines with vector
- register renaming can just initialize the rename table to point
- entries at a physical zero register.
-\end{commentary}
-
-Each vector register can be reconfigured dynamically to hold different
-formats without zeroing the entire vector unit state provided that: if
-{\tt vmaxew} is zero, the bit-width of the new format is the same as
-the current {\tt vew}; or if {\tt vmaxew} is non-zero, the format does
-not require more than {\tt vmaxew} bits. Any change to a vector
-register's format zeros the affected vector register.
-
-If a vector register is disabled, then any vector instruction
-that attempts to access that vector register will raise an
-illegal instruction exception. Attempting to write any {\tt
- vmaxew}$n$ with an unsupported value will raise an illegal
-instruction exception.
-
-\begin{commentary}
- Vector registers have both a maximum element width and a
- current element data type to allow the same vector register to
- be changed to different types during execution provided the
- maximum width is not exceeded. This reduces register pressure and
- helps support vector function calls, where the caller does not know
- the types needed by the callee, as described below.
-\end{commentary}
-
-\begin{commentary}
- The set of supported types might be greatly increased with future
- extensions. For example (and not limited to), new scalar types in
- new number systems, a complex type with real and imaginary
- components, a key-value type, or an application-specific structure
- type with multiple constituent fields. Auxiliary type
- configuration state might be required in these cases.
-\end{commentary}
-
-Attempting to write an unsupported type or a type that requires more
-than the current {\tt vmaxew} width to a {\tt vetype} field will raise
-an illegal instruction exception.
-
-\begin{commentary}
-Implementations must still raise an exception for a {\tt vetype}$n$
-setting that is greater than the architectural {\tt vmaxew}$n$ width,
-even if they internally implement a larger physical {\tt vmaxew}$n$
-that could accommodate the {\tt vetype}$n$ request.
-\end{commentary}
-
-\begin{discussion}
-We can either have 1) implementations raise exceptions whenever
-illegal values are written to {\tt vmaxew} and {\tt vetype} fields
-(current design), 2) raise exceptions at use if config holds illegal
-values, 3) make the fields WARL so silently reduce to supported types
-with no exceptions. Option 2 could complicate vector unit context
-switch code by having more cases to check, while Option 3 could make
-debugging more difficult by allowing code to run with reduced
-precision or incorrect types.
-\end{discussion}
-
-\begin{commentary}
-Three broad classes of implementation can be distinguished by how they
-handle {\tt vmaxew} settings.
-
-The simplest is {\em max-width-per-implementation} (MWPI), where the
-vector unit is organized in fixed ELEN-width physical lanes, and
-changes to {\tt vmaxew} settings simply cause portions of the
-physical registers and datapath to be disabled for operations narrower
-than ELEN bits.
-
-The next most complex implementation, {\em
- max-width-per-configuration} (MWPC), uses the maximum width across
-all {\tt vmaxew} settings in a dynamic configuration to divide the
-physical register storage and datapaths. For example, a MWPC machine
-with ELEN=64 might subdivide physical lanes into 32-bit datapaths if
-no {\tt vmaxew} setting is greater than 32. Operations on
-sub-32-bit quantities would disable appropriate portions of the
-physical registers and functional units in each 32-bit lane. Several
-early vector supercomputers, including the CDC
-Star-100~\cite{cdcstart100}, provided a similar facility to divide
-64-bit physical vector lanes into narrower 32-bit lanes.
-
-The most complex implementations are {\em max-width-per-register}
-(MWPR), which reduce wasted space in the physical register files by
-packing elements in each vector register according to the individual
-{\tt vmaxew} settings and which within one configuration can
-execute instructions with narrower datatypes at higher rates than for
-wider datatypes. The Berkeley Hwacha vector
-engine~\cite{hwachatr,mixedprecision} is an example microarchitecture
-with this property.
-\end{commentary}
-
-\clearpage
-
-{\bf Following Sections are out-of-date.}
-
-\section{Vector Instruction Formats}
-
-\begin{commentary}
- The instruction encoding is a work in progress.
-
- An important design goal was that the base vector extension fit
- within a few major opcodes of the 32-bit encoding. It is envisioned
- that future vector extensions will use 48-bit or 64-bit encodings to
- increase both the opcode space and the set of architectural
- registers. The 64-bit vector encoding would support 256
- architectural vector registers and orthogonal specification of a
- predicate register in each instruction.
-\end{commentary}
-
-Vector arithmetic and vector memory instructions are encoded in new
-variants of the R-format, shown in Figure~\ref{fig:vinstformats}.
-Both new formats use one bit to hold a {\em vp} field, which usually
-controls the predicate register in use, either {\tt vp0} or {\tt vp1}.
-The VR4 form is used for fused multiply-add instructions. The
-existing RISC-V instruction formats are used for other vector-related
-instructions, such as the vector configuration instructions.
-
-\vspace{-0.2in}
-\begin{figure}[h]
-\begin{center}
-\setlength{\tabcolsep}{4pt}
-\begin{tabular}{p{0.7in}@{}p{0.4in}@{}p{0.7in}@{}p{0.7in}@{}p{0.5in}@{}p{0.4in}@{}p{0.7in}@{}p{1in}l}
-\\
-\instbitrange{31}{27} &
-\instbitrange{26}{25} &
-\instbitrange{24}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{13} &
-\instbit{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\cline{1-8}
-\multicolumn{2}{|c|}{funct7} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct2} &
-\multicolumn{1}{c|}{vp} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} &
-VR-type \\
-\cline{1-8}
-\\
-\cline{1-8}
-\multicolumn{1}{|c|}{rs3} &
-\multicolumn{1}{c|}{fmt} &
-\multicolumn{1}{c|}{rs2} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct2} &
-\multicolumn{1}{c|}{vp} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} &
-VR4-type \\
-\cline{1-8}
-\end{tabular}
-\end{center}
-\caption{New V extension instruction formats. }
-\label{fig:vinstformats}
-\end{figure}
-
-Most vector instructions are available in both vector-vector and
-vector-scalar variants. Vector-vector instructions take the first
-operand from the vector register specified by {\em rs1} and the second
-operand from the vector register specified by {\em rs2}.
-
-For vector-scalar operations, the {\em rs1} field specifies the scalar
-register to be accessed. For most vector-scalar instructions, the
-type of the vector operand specified by {\em rs2} indicates whether
-the integer or floating-point scalar register file is accessed using
-the {\em rs1} register specifier.
-
-Some non-commutative vector-scalar instructions (such as sub) are
-provided in two forms, with the scalar value used as the second
-operand.
-
-\begin{commentary}
- The {\em rs1} field is used to provide the scalar operand because in
- the base encoding, whenever an instruction has a single scalar
- source operand, it is encoded in the {\tt rs1} field.
-\end{commentary}
-
-\section{Polymorphic Vector Instructions}
-
-The vector extension uses a polymorphic instruction encoding where the
-opcode is combined with the types of the source and destination
-registers to determine the operation to be performed. For example, an
-ADD opcode will perform a 32-bit integer vector-vector add if both
-vector source operands and the vector destination register are 32-bit
-integers, but will perform a 16-bit floating-point vector-vector
-operation if both vector source operands and the vector destination
-are 16-bit floats.
-
-The polymorphic encoding also naturally supports operations with mixed
-precisions on the input and output, and also supports extending the
-instruction set with new types without necessarily increasing the
-opcode space.
-
-Not all combinations of source and destination argument types need be
-supported. The base vector extension mandates only that
-implementations provide a subset of combinations of types on inputs
-and outputs. Table~\ref{tab:vtypemix} shows the general rules for
-integer and floating-point instructions, but the detailed instruction
-listing should be consulted for accurate information.
-
-\begin{table}
- \centering
- \begin{tabular}{|r|r|r|r|r|}
- \hline
- \multicolumn{1}{|c|}{Src1} &
- \multicolumn{1}{c|}{Src2} &
- \multicolumn{1}{c|}{Src3} &
- \multicolumn{1}{c|}{Dest} &
- \multicolumn{1}{c|}{Example} \\
- \hline
- \hline
- \multicolumn{5}{|c|}{Integer vector-scalar}\\
- \hline
- XLEN & X & - & X & 64b + 32b $\rightarrow$ 32b \\
- XLEN & X & - & 2X & 64b + 8b $\rightarrow$ 16b \\
- \hline
- \hline
- \multicolumn{5}{|c|}{Integer vector-vector}\\
- \hline
- X & X & - & X & 32b + 32b $\rightarrow$ 32b \\
- X & X & - & 2X & 16b + 16b $\rightarrow$ 32b \\
- 2X & X & - & 2X & 64b + 32b $\rightarrow$ 64b \\
- \hline
- \hline
- \multicolumn{5}{|c|}{Floating-point vector-scalar}\\
- \hline
- F & F & - & F & 64b + 64b $\rightarrow$ 64b \\
- F & F & F & F & 32b $\times$ 32b + 32b $\rightarrow$ 32b \\
- F & F & - & 2F & 32b + 32b $\rightarrow$ 64b \\
- F & F & 2F & 2F & 32b $\times$ 32b + 64b $\rightarrow$ 64b \\
- \hline
- \hline
- \multicolumn{5}{|c|}{Floating-point vector-vector}\\
- \hline
- F & F & - & F & 32b + 32b $\rightarrow$ 32b \\
- F & F & - & 2F & 16b + 16b $\rightarrow$ 32b \\
- 2F & F & - & 2F & 64b + 32b $\rightarrow$ 64b \\
- F & F & F & F & 64b $\times$ 64b + 64b $\rightarrow$ 64b \\
- F & F & 2F & 2F & 16b $\times$ 16b + 32b $\rightarrow$ 32b \\
- \hline
- \end{tabular}
- \caption{General rules for supported types per instruction in base
- vector extension. X represents the number of bits in an integer
- type and F represents the number of bits in a floating-point type.
- Individual instruction types will provide more detailed listings.
- Note that the type of a scalar floating-point operand can never be
- different from that of the vector in Src2, hence the Src1=2F case
- is missing from vector-scalar operations.}
- \label{tab:vtypemix}
-\end{table}
-
-A general rule in the base vector instruction set is that the
-destination precision is never less than any source operand, except
-for explicit type-conversion instructions. Another general rule is
-that the input operands can only be the same width or half the width
-of the destination operand except for the scalar operand in integer
-vector-scalar instructions, which is always XLEN wide. Also, src2 is
-never larger than src1 or src3.
-
-Integer computations of mixed-precision values always aligns values by
-their LSB, and sign or zero-extends any smaller value according to its
-type. The result is truncated to fit in the destination type. Note a
-scalar integer value is already XLEN bits wide, and as wide as any
-possible integer vector value.
-
-Floating-point computations on mixed-precision values acts as if the
-calculations are performed exactly then rounded once to the
-destination format.
-
-\section{Rapid Configuration Instructions}
-
-It can take several CSR instructions to set up the {\tt vcfg} and
-{\tt vnp} CSRs for a given configuration. Specialized configuration
-instructions are provided to quickly set up common configurations in
-the {\tt vcfg} and {\tt vnp} CSRs.
-
-The {\tt vsetdcfg} instruction takes a scalar register value encoded as
-shown in Figure~\ref{fig:vcfg}, and returns the corresponding MVL in
-the destination register. The {\tt vsetdcfg} and {\tt vsetdcfgi}
-instructions also clear the {\tt vnp} register, so no predicate
-registers are allocated.
-
-\begin{discussion}
- For now, only a 32-bit value supporting up to three different vector
- data types is supported by the {\tt vsetdcfg} instruction. RV64 and
- RV128 could support larger number of types, though it's not clear if
- the hardware cost (area, latency) to support a larger number of
- different types is justified.
-\end{discussion}
-
-\begin{figure}[b]
- \centering
- \begin{tabular}{p{1cm}p{1cm}ccc|c|c|c|c|c|c|c|l}
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{mode} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} & \\
- \cline{6-12}
- & & & & &
- \tt type2 & \tt ntype2 &
- \tt type1 & \tt ntype1 &
- 0 &
- \tt type0 & \tt ntype0 & \\
- \cline{6-12}
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{} &
- \multicolumn{1}{c}{5} &
- \multicolumn{1}{c}{5} &
- \multicolumn{1}{c}{5} &
- \multicolumn{1}{c}{5} &
- \multicolumn{1}{c}{2} &
- \multicolumn{1}{c}{5} &
- \multicolumn{1}{c}{5} & \\
- %% \cline{2-12}
- %% & \multicolumn{1}{|c|}{0} & F128 &
- %% \multicolumn{1}{c|}{type3} & \multicolumn{1}{c|}{\#type3} &
- %% type2 & \#type2 & type1 & \#type1 & 0 & type0 & \#type0 & RV64 \\
- %% \cline{2-12}
- %% & & &
- %% \multicolumn{1}{c}{} &
- %% \multicolumn{1}{c}{24} &
- %% \multicolumn{1}{c}{5} &
- %% \multicolumn{1}{c}{5} &
- %% \multicolumn{1}{c}{5} &
- %% \multicolumn{1}{c}{5} &
- %% \multicolumn{1}{c}{2} &
- %% \multicolumn{1}{c}{5} &
- %% \multicolumn{1}{c}{5} & \\
- %% \cline{1-12}
- %% \multicolumn{1}{|c|}{0} & \multicolumn{1}{c|}{X128} &
- %% \multicolumn{1}{c|}{F128} & I64 & F64 & F32 & F16 & I32 & I16 & I8 & RV128 \\
- %% \cline{1-12}
- %% \multicolumn{1}{c}{83} &
- %% \multicolumn{1}{c}{5} &
- %% \multicolumn{1}{c}{5} &
- %% \multicolumn{1}{c}{5} &
- %% \multicolumn{1}{c}{5} &
- %% \multicolumn{1}{c}{2} &
- %% \multicolumn{1}{c}{5} &
- %% \multicolumn{1}{c}{5} & \\
- \end{tabular}
- \caption{Format of the {\tt vsetdcfg} value. The value contains
- three pairs of a 5-bit type and a 5-bit number of registers
- to create of that type. A value of 0 for the number of a type
- indicates that 32 registers should be allocated. A value of 0 for
- the type indicates this pair should be skipped. The types must be
- of monotonically increasing size from type0 to type2. }
- \label{fig:vcfg}
-\end{figure}
-
-The {\tt vsetdcfg} value specifies how many vector registers of each
-datatype are allocated, and is divided into a 2-bit mode field and
-pairs of 5-bit fields for each data type in the configuration.
-
-The 2-bit mode field indicates the configuration mode of the vector
-unit and is zero for the base vector extension.
-
-\begin{commentary}
- The standard vector extension operating mode configures the vector
- unit into some number of vector registers, each with some number of
- elements of types supported by the scalar unit.
-
- At least one alternative mode is planned, where the vector unit is
- configured as some number of registers each holding a single large
- element, e.g., 256 bits. This would be the base for cryptographic
- operations, or other coprocessors that operated on large structures.
-
- Other modes can be used to reconfigure the vector unit register file
- and functional units for other domain-specific purposes.
-\end{commentary}
-
-Each datatype pair contains a 5-bit {\tt type}$x$ value encoded as a
-{\tt vetype}$n$ value, and a 5-bit {\tt ntype}$x$ for the number of
-registers to allocate for that type. If the {\tt type0} field is
-non-zero, the {\tt vsetdcfg} instruction will configure the first {\tt
- ntype0} vector data registers to have {\tt vetype}$n$ values of {\tt
- type0} with {\tt vmaxew}$n$ values set accordingly as shown in
-Table~\ref{tab:vetype}. If the {\tt type0} value is 0, the datatype
-pair is skipped. If the {\tt type1} field is non-zero, then the next
-{\tt ntype1} vector registers are configured to be of the type given
-in {\tt type1}. Similarly for the {\tt type2} pair.
-
-A value of zero in a {\tt type}$x$ field indicates this datatype pair
-should be ignored. A value of zero in a {\tt ntype}$x$ field
-indicates 32 registers should be allocated for the corresponding type.
-
-\begin{commentary}
-Zero values are skipped to simplify setting a configuration with two
-different data types, where a single LUI instruction can set the upper
-20 bits leaving the low bits zero.
-
-A single 12-bit immediate value is sufficient to create a
-configuration with some number of vector registers with a single given
-datatype.
-
-A compressed C.LI with a zero-extended 5-bit immediate can create a
-configuration with 32 vector registers of a given datatype.
-\end{commentary}
-
-A corresponding {\tt vsetdcfgi} instruction takes a 12-bit immediate
-value to set the configuration instead of a scalar value, but
-otherwise is identical to the {\tt vsetcfgd} instruction.
-
-\begin{discussion}
-It is not clear how many immediate bits will be made available for the
-{\tt vsetdcfgi} instruction. If encoding space is available for both
-12 immediate bits and a source register specifier, then {\tt
- vsetdcgfi} can be defined to read the source register, OR in the
-bits in the immediate, then create a configuration. In this case,
-there is no need for a separate {\tt vsetdcfg} instruction.
-\end{discussion}
-
-The configuration value given must result in a legal configuration or
-else an illegal instruction exception will be raised.
-
-If a zero argument is given to {\tt vsetdcfg} the vector unit will be
-disabled and the value 0 will be returned for MVL. This instruction
-({\tt vsetdcfg x0, x0}) is given the assembly pseudo-code {\tt
- vdisable}.
-
-Separate {\tt vsetpcfg} and {\tt vsetpcfgi} instructions are provided
-that write the source value to the {\tt vnp} register and return the
-new MVL. These writes also clear the vector data registers, set all
-bits in the allocated predicate registers, and set {\tt vl}=MVL. A
-{\tt vsetpcfg} or {\tt vsetpcfgi} instruction can be used after a {\tt
- vsetdcfg} to complete a reconfiguration of the vector unit.
-
-\begin{discussion}
- If {\tt vnp} is made accessible as a separate CSR, the {\tt setpcfg}
- and {\tt setpcfgi} instructions are less useful. The only advantage
- over a CSR instruction is that they return MVL, which is rarely
- needed, and which can be obtained via that {\tt setvl} instruction.
-\end{discussion}
-
-\section{Vector-Type-Change Instructions}
-
-To quickly change the individual types of a vector register, {\tt
- vetyperw} and {\tt vetyperwi} instructions are provided to change
-the type of the specified vector data register to the given scalar
-register value or 5-bit immediate value respectively, while returning
-the previous type in the destination scalar register.
-
-A vector convert instruction, described below, can simultaneously
-convert a source vector register into a new type, and set that type in
-the destination vector register.
-
-\section{Vector Length}
-
-The active vector length is held in the XLEN-bit WARL vector length
-CSR {\tt vl}, which can only hold values between 0 and MVL inclusive.
-Any writes to the configuration registers ({\tt vcfg}$x$ or {\tt
- vnp}) cause {\tt vl} to be initialized with MVL. Changes to {\tt
- vetype}$n$ via vector-type-change instructions do not affect {\tt
- vl}.
-
-The active vector length is usually set via the {\tt setvl}
-instruction. The source argument to the {\tt setvl} is the requested
-application vector length (AVL) as an unsigned XLEN-bit integer. The
-{\tt setvl} instruction calculates the value to assign to {\tt vl}
-according to Table~\ref{tab:vlcalc}. The result of this calculation
-is also returned as the result of the {\tt setvl} instruction.
-
-\begin{commentary}
-Earlier drafts encoded {\tt setvl} using a modified CSRRW instruction
-whereas it is now encoded as a separate new instruction.
-\end{commentary}
-
-\begin{table}
- \centering
- \begin{tabular}{|c|c|}
- \hline
- AVL Value & {\tt vl} setting \\
- \hline
- AVL $\geq$ 2\,MVL & MVL \\
- 2\,MVL $>$ AVL $>$ MVL & $\lceil$AVL$/2\rceil$ \\
- MVL $\geq$ AVL & AVL \\
- \hline
- \end{tabular}
- \caption{Operation of {\tt setvl} instruction to set vector
- length register {\tt vl} based on requested application vector
- length (AVL) and current maximum vector length (MVL).}
- \label{tab:vlcalc}
-\end{table}
-
-\begin{commentary}
- The rules for setting the {\tt vl} register help keep vector
- pipelines full over the last two iterations of a stripmined loop.
- This version of the rules guarantees monotonically decreasing vector
- lengths.
- Similar rules were previously used in Cray-designed machines~\cite{crayx1asm}.
-\end{commentary}
-
-\begin{discussion}
- There are multiple possible rules for setting VL, and we could give
- implementations freedom to use different VL setting rules.
-\end{discussion}
-
-\begin{commentary}
- The idea of having implementation-defined vector length dates back
- to at least the IBM 3090 Vector Facility~\cite{ibm370varch}, which
- used a special ``Load Vector Count and Update'' (VLVCU) instruction
- to control stripmine loops. The {\tt setvl} instruction included
- here is based on the simpler {\tt setvlr} instruction introduced by
- Asanovi\'{c}~\cite{krstephd}.
-\end{commentary}
-
-The {\tt setvl} instruction is typically used at the start of every
-iteration of a stripmined loop to set the number of vector elements to
-operate on in the following loop iteration. The current MVL can be
-obtained from a vector configuration instruction, or by performing a
-{\tt setvl} with a source argument that has all bits set (largest
-unsigned integer).
-
-When {\tt vl} is less than MVL, vector instructions will set all
-elements in the range [{\tt vl}:MAXVL-1] in the destination vector
-data register or destination vector predicate register to zero.
-
-\begin{commentary}
- Requiring zeroing of elements past the current active vector length
- simplifies the design of units with renamed vector data registers.
- If the specification left destination elements unchanged, renaming
- implementations would have to copy the tail of the old destination
- register to the newly allocated destination register.
- Alternatively, specifying the tail to be undefined will expose
- implementation differences and possibly cause a security hole.
-
- Implementations that do not support renaming, will have to zero the
- tail of a vector, but this can reuse the mechanism that is already
- required to initialize all vector data registers to zero on
- reconfiguration, for example, by having a zero bit on each element
- or element group.
-\end{commentary}
-
-No element operations are performed for any vector instruction when
-{\tt vl}=0.
-
-\begin{commentary}
- Two possible choices are to 1) require destination registers to be
- completely zeroed when {\tt vl}=0, or 2) no changes to the
- destination registers. Option 2 is currently chosen as this will
- prevents unnecessary work in some implementations, and option 1 does
- not provide a clear advantage beyond seeming more consistent with
- {\tt vl}>0 case.
-\end{commentary}
-
-\begin{figure}[bt]
- \centering
-\begin{verbatim}
- # Vector-vector 32-bit add loop.
- # a0 holds N
- # a1 holds pointer to result vector
- # a2 holds pointer to first source vector
- # a3 holds pointer to second source vector
- li t0, (2<<VNTYPE0|VREGF32)
- vsetdcfg t0 # Configure with two 32-bit float vectors
-
- loop: setvl t0, a0 # Set length, get how many elements in strip
- vld v0, a2 # Load first vector
- sll t1, t0, 2 # Multiply length by 4 to get bytes
- add a2, t1 # Bump pointer
- vld v1, a3 # Load second vector
- add a3, t1 # Bump pointer
- vadd v0, v1 # Add elements
- sub a0, t0 # Decrement elements completed
- vst v0, a1 # Store result vector
- add a1, t1 # Bump pointer
- bnez a0, loop # Any more?
-
- vdisable # Turn off vector unit
-\end{verbatim}
-\caption{Example vector-vector add loop.}
-\label{fig:vvadd}
-\end{figure}
-
-\section{Predicated Execution}
-
-
-\begin{commentary}
- The 32-bit base encoding does not leave room for a fully orthogonal
- predicate register specifier. A single bit is dedicated to the
- predicate register specification, and is used to select between two
- active predicate registers, {\tt vp0} or {\tt vp1}. An alternative
- scheme would have used the bit to select between {\tt vp0} and
- unpredicated (all elements active). However, given the ease of
- setting all predicate bits in a vector predicate register with a
- single predicate instruction, the current scheme provides more
- flexibility.
-
- When there are no vector predicate registers enabled, {\tt vp0}
- returns all set bits when read. So, the assembler convention is to
- assume {\tt vp0} as the predicate register when no predicate
- register is explicitly given. The assembler can support a strict
- operands option to require the vector predicate register is
- explicitly specified.
-\end{commentary}
-
-At element positions where the selected predicate register bit is
-zero, the corresponding vector element operation has no effect (does
-not change architectural state or generate exceptions), except to
-write a zero to the element position in the destination vector
-register.
-
-\begin{discussion}
- The previous proposal (undisturb) left the destination vector
- unchanged at element positions where the predicate bit is false,
- whereas the current plan-of-record (zero) writes zero to the
- destination where the predicate bit is false.
-
- The advantage of the undisturb option is that it can require fewer
- instructions and fewer architectural registers for many common code
- sequences. For in-order machines without register renaming, the
- undisturb operation simply disables writes to the destination
- elements, except for vector registers that have not been written
- since configuration time. Typically an extra zero bit per vector
- register or element group will be added to represent a zeroed
- register instead of actually zeroing state at configuration time.
- For predicated undisturb writes to these uninitialized registers,
- the predicated false elements must be explicitly written with zeros
- on each element group and the zero bit is then cleared down.
- However, in a machine with vector register renaming, undisturb does
- imply an additional read of the original destination register to
- write the value into the new physical destination register when the
- predicate is false. This additional read port will often be cheaper
- than in a scalar machine as vector machines often time-multiplex
- read ports, and the additional read can be skipped when the
- predicate registers are disabled ({\tt vnp}=0) or when the source is
- known to be zero after configuration, but still adds complexity to a
- design.
-
- The advantage of the zero option is that a machine with vector
- register renaming does not need to read the original destination
- vector register and so a read port is saved. The disadvantage of
- the zero option is that more instructions and architectural
- registers are required for common code sequences, and simpler
- microarchitectures without register renaming are penalized by
- requiring longer code sequences and greater register pressure. In
- particular, vector merge instructions are required to collect
- results from two divergent control paths, and each vector merge has
- to read two vector values and write a vector result. Whether the
- zero option saves total register file traffic in an register-renamed
- microarchitecture depends on the ratio of a) internal temporary
- writes, to b) writes creating values that are live out of each basic
- block, and also to the frequency of control flow merges.
-
- Overall, the zero option removes significant complexity from the
- renamed machines while reducing efficiency somewhat for the
- non-renamed machines, and is the current plan-of-record.
-\end{discussion}
-
-\section{Vector Load/Store Instructions}
-
-Three vector load/store addressing modes are supported, unit-stride,
-constant stride, and indexed (scatter/gather). Each addressing mode
-has a 7-bit unsigned immediate offset that is scaled by the element
-type.
-
-The unit-stride address mode takes a scalar base byte address, adds
-the scaled immediate, then generates a contiguous set of element
-addresses for loads or stores.
-
-\begin{commentary}
- The primary use of immediates in unit-stride loads is to generate
- overlapping unit-stride loads for convolution operations.
-\end{commentary}
-
-The constant-stride address mode takes a scalar base byte address, a
-stride value encoded in bytes, and adds a scaled immediate value.
-
-\begin{commentary}
- The stride value is in bytes to allow a single stride register to be
- used to support operations on arrays-of-structures, where not all
- elements in each structure have the same size. The immediate value
- is still scaled by element size to increase reach, given that
- element types will be naturally aligned.
-\end{commentary}
-
-The indexed address mode takes a scalar base byte address and a vector
-of byte offsets. The scalar base address and the immediate value are
-added to element of the offset vector to give a vector of addresses
-used in a scatter/gather.
-
-Indexed stores are provided in three types. Unordered, ordered, and
-reverse-ordered. The unordered indexed stores might update the same
-memory location from two different elements in an unspecified order.
-The ordered stores always update memory locations in increasing vector
-element order. The reverse-ordered stores always update memory
-locations in decreasing memory order.
-
-\begin{commentary}
- The reverse-ordered stores support vectorization of software memory
- disambiguation techniques. A reverse-ordered store of element id
- into a hash table indexed by a hash on a store access address,
- followed by a read of the hash table using a load access address and
- a comparison against the original element id, will indicate if
- there's a potential RAW hazard with an earlier loop iteration.
-\end{commentary}
-
-\begin{discussion}
- Not clear if there is sufficient realizable improvement for
- supporting unordered stores over ordered stores.
-\end{discussion}
-
-Vector loads/stores have a simple memory model, where each vector
-load/store is observed to complete sequentially in program order only
-the local hart, i.e., a vector load on a hart will observe all earlier
-vector stores on the same hart, and no later vector stores.
-
-Vector loads are available in a length-speculative form that writes
-predicate register {\tt vp1} in addition to the destination vector
-data register. These instructions raise an illegal instruction
-exception if {\tt vp1} is not configured. For elements that do not
-generate a permissions fault, the length-speculative vector loads
-operate as normally except to also clear the bit in {\tt vp1}. If an
-element encounters a permission fault, a zero is written to the
-destination vector register element and the {\tt vp1} bit is set to a
-1. Implementations may treat elements past the first faulting element
-as also causing a fault even if they might not cause a permissions
-fault when accessed alone.
-
-Once software determines the active vector length, it should check if
-any loads within the active vector length caused a fault, and in this
-case, generate a non-length-speculative load to trigger reporting of
-the error.
-
-\begin{commentary}
- Length-speculative vector loads are required to vectorize while
- loops, with data-dependent exits (e.g. strlen).
-
- The only faults ignored by the length-speculative vector loads are
- ones that would have resulted in a permissions violation. Page
- faults and other virtualization-related faults should be handled
- invisibly to the user thread by the execution environment.
-
- A malicious program can use length-speculative vector loads to probe
- accessible address space without fear of a fatal fault.
-\end{commentary}
-
-\section{Vector Register Gather}
-
-A vector register gather produces a new result data vector by gathering
-elements from one source data vector at the element locations
-specified by a second source index vector. Data source and
-destination vector types must agree. The index vector can have any
-integer type. Legal element indices can range from 0 to current
-MAXVL. Indices out of this range raise an illegal instruction
-exception.
-
-\begin{verbatim}
- # vindices holds values from 0..MAXVL
- vrgather vdest, vsrc, vindices
-\end{verbatim}
-
-\section{Vector Slide}
-
-Reductions (and convolutions) are supported via a vector slide
-instruction that takes elements starting from the middle of one vector
-and places these at the beginning of a second vector register. This
-supports a recursive-halving reduction approach for any binary
-associative operator.
-
-\begin{commentary}
- A similar vector register extract instruction was added to the Cray
- C90 after memory latency grew too large for the memory-memory
- reductions used in earlier Crays.
-
- The vector unit microarchitecture can be optimized for the
- power-of-2 sized element offsets used for reductions.
-\end{commentary}
-
-
-\section{Fixed-Point Support}
-
-Clip instruction supports scaling, rounding, and clipping to
-destination type. Rounding set by CSR fixed-point rounding mode
-(truncate, jam, round-up, round-nearest-even). Clipping set by CSR
-clip mode (wrap, saturate).
-
-Add with average, rounding set by rounding mode.
-
-Multiply with same size source and destination types, with some result
-scaling values (+1, 0, -1, -8?) and rounding and clipping according to
-CSR mode.
-
-Accumulate with carry into predicate register to support larger
-precise dot-products.
-
-\section{Optional Transcendental Support}
-
-\section{Instruction-Set Encoding}
-
-\note{This section is out of date.}
-
-On the next two pages is a proposed instruction-set encoding.
-
-\input{v-instr-table}
diff --git a/src/vector-crypto.adoc b/src/vector-crypto.adoc
new file mode 100644
index 0000000..a5c66c4
--- /dev/null
+++ b/src/vector-crypto.adoc
@@ -0,0 +1,4965 @@
+== Cryptography Extensions: Vector Instructions, Version 1.0
+
+This document describes the Vector Cryptography extensions to the
+RISC-V Instruction Set Architecture.
+
+[[crypto_vector_introduction]]
+=== Introduction
+
+This document describes the RISC-V _vector_ cryptography extensions.
+All instructions described here are based on the Vector registers.
+The instructions are designed to be highly performant, with large
+application and server-class cores being the main target.
+A companion chapter _Volume I: Scalar & Entropy Source Instructions_,
+describes
+cryptographic instructions for smaller cores which do not
+implement the vector extension.
+
+[[crypto_vector_audience]]
+==== Intended Audience
+
+Cryptography is a specialized subject, requiring people with many different
+backgrounds to cooperate in its secure and efficient implementation.
+Where possible, we have written this specification to be understandable by
+all, though we recognize that the motivations and references to
+algorithms or other specifications and standards may be unfamiliar to those
+who are not domain experts.
+
+This specification anticipates being read and acted on by various people
+with different backgrounds.
+We have tried to capture these backgrounds
+here, with a brief explanation of what we expect them to know, and how
+it relates to the specification.
+We hope this aids people's understanding of which aspects of the specification
+are particularly relevant to them, and which they may (safely!) ignore or
+pass to a colleague.
+
+Cryptographers and cryptographic software developers::
+These are the people we expect to write code using the instructions
+in this specification.
+They should understand the motivations for the
+instructions we include, and be familiar with most of the algorithms
+and outside standards to which we refer.
+
+Computer architects::
+We do not expect architects to have a cryptography background.
+We nonetheless expect architects to be able to examine our instructions
+for implementation issues, understand how the instructions will be used
+in context, and advise on how best to fit the functionality the
+cryptographers want.
+
+Digital design engineers & micro-architects::
+These are the people who will implement the specification inside a
+core. Again, no cryptography expertise is assumed, but we expect them to
+interpret the specification and anticipate any hardware implementation
+issues, e.g., where high-frequency design considerations apply, or where
+latency/area tradeoffs exist etc.
+In particular, they should be aware of the literature around efficiently
+implementing AES and SM4 SBoxes in hardware.
+
+Verification engineers::
+These people are responsible for ensuring the correct implementation of the
+extensions in hardware.
+No cryptography background is assumed.
+We expect them to identify interesting test cases from the
+specification. An understanding of their real-world usage will help with this.
+
+These are by no means the only people concerned with the specification,
+but they are the ones we considered most while writing it.
+
+[[crypto_vector_sail_specifications]]
+==== Sail Specifications
+
+RISC-V maintains a
+link:https://github.com/riscv/sail-riscv[formal model]
+of the ISA specification,
+implemented in the Sail ISA specification language
+cite:[sail].
+Note that _Sail_ refers to the specification language itself,
+and that there is a _model of RISC-V_, written using Sail.
+
+It was our intention to include actual Sail code in this specification.
+However, the Vector Crypto Sail model needs the Vector Sail model as a
+basis on which to build. This Vector Cryptography extensions specification
+was completed before there was an approved RISC-V Vector Sail Model.
+Therefore, we don't have any Sail code to include in the instruction
+descriptions. Instead we have included Sail-like pseudocode. While we have
+endeavored to adhere to Sail syntax, we have taken some liberties for the
+sake of simplicity where we believe that that our intent is clear to the
+reader.
+
+[NOTE]
+====
+Where variables are concatenated, the order shown is how they would appear
+in a vector register from left to right.
+For example, an element group specified as `{a, b, e, f}` would appear in a vector
+register with `a` having the highest element index of the group and `f` having the
+lowest index of the group.
+====
+
+For the sake of brevity, our pseudocode does not include the handling of
+masks or tail elements. We follow the _undisturbed_ and _agnostic_ policies
+for masks and tails as described in the *RISC-V "V" Vector Extension*
+specification. Furthermore, the code does not explicitly handle overlap and SEW
+constraints; these are, however, explicitly stated in the text.
+
+In many cases the pseudocode includes
+calls to supporting functions which are too verbose to include directly
+in the specification.
+This supporting code is listed in
+<<crypto_vector_appx_sail>>.
+
+
+The
+link:https://alasdair.github.io/manual.html[Sail Manual]
+is recommended reading in order to best understand the code snippets.
+Also, the
+link:https://github.com/billmcspadden-riscv/sail/blob/cookbook_br/cookbook/doc/TheSailCookbook_Complete.pdf[The Sail Programming Language: A Sail Cookbook]
+is a good reference.
+
+For the latest RISC-V Sail model, refer to
+the formal model GitHub
+link:https://github.com/riscv/sail-riscv[repository].
+
+[[crypto_vector_policies]]
+==== Policies
+
+In creating this extension, we tried to adhere to the following
+policies:
+
+* Where there is a choice between:
+ 1) supporting diverse implementation strategies for an algorithm
+ or
+ 2) supporting a single implementation style which is more performant /
+ less expensive;
+ the vector crypto extensions will pick the more constrained but performant
+ option.
+ This fits a common pattern in other parts of the RISC-V specifications,
+ where recommended (but not required) instruction sequences for performing
+ particular tasks are given as an example, such that both hardware and
+ software implementers can optimize for only a single use-case.
+
+* The extensions will be designed to support _existing_ standardized
+ cryptographic constructs well.
+ It will not try to support proposed standards, or cryptographic
+ constructs which exist only in academia.
+ Cryptographic standards which are settled upon concurrently with or after
+ the RISC-V vector cryptographic extensions standardization will be dealt with
+ by future RISC-V vector cryptographic
+ standard extensions.
+
+* Historically, there has been some discussion
+ cite:[LSYRR:04]
+ on how newly supported operations in general-purpose computing might
+ enable new bases for cryptographic algorithms.
+ The standard will not try to anticipate new useful low-level
+ operations which _may_ be useful as building blocks for
+ future cryptographic constructs.
+
+* Regarding side-channel countermeasures:
+ Where relevant, proposed instructions must aim to remove the
+ possibility of any timing side-channels. All instructions
+ shall be implemented with data-independent timing. That is, the latency of
+ the execution of these instructions shall not vary with different input values.
+
+[[crypto-vector-element-groups]]
+==== Element Groups
+
+Many vector crypto instructions operate on operands that are wider than elements (which are currently limited
+to 64 bits wide).
+Typically, these operands are 128- and 256-bits wide. In many cases, these operands are comprised of smaller
+operands that are combined (for example, each SHA-2 operand is comprised of 4 words). However, in other cases
+these operands are a single value (for example, in the AES round instructions, each operand is 128-bit block
+or round key).
+
+We treat these operands as a vector of one or more _element groups_ as defined in <<vector-element-groups>>.
+
+Each vector crypto instruction that operates on element groups explicitly specifies their three defining
+parameters: EGW, EGS, and EEW.
+
+[%autowidth]
+[%header,cols="4,4,4,4,4"]
+|===
+| Instruction Group
+| Extension
+| EGW
+| EEW
+| EGS
+
+| AES | <<zvkned>> | 128 | 32 | 4
+| SHA256 | <<zvknh,zvknh[ab]>> | 128 | 32 | 4
+| SHA512 | <<zvknh,zvknhb>> | 256 | 64 | 4
+| GCM | <<zvkg>> | 128 | 32 | 4
+| SM4 | <<zvksed>> | 128 | 32 | 4
+| SM3 | <<Zvksh>> | 256 | 32 | 8
+|===
+
+[NOTE]
+====
+- Element Group Width (`EGW`) - total number of bits in an element group
+- Effective Element Width (`EEW`) - number of bits in each element
+- Element Group Size (`EGS`) - number of elements in an element group
+====
+
+For all of the vector crypto instructions in this specification, `EEW`=`SEW`.
+
+[NOTE]
+====
+The required `SEW` for each cryptographic instruction was chosen to match what is
+typically needed for other instructions when implementing the targeted algorithm.
+====
+
+- A *Vector Element Group* is a vector of one or more element groups.
+- A *Scalar Element Group* is a single element group.
+
+Element groups can be formed across registers in implementations where
+`VLEN`< `EGW` by using an `LMUL`>1.
+
+[NOTE]
+====
+Since the *vector extension for application processors* requires a minimum of VLEN of 128,
+at most such implementations would require LMUL=2 to form the largest element groups in this specification.
+
+However, implementations with a smaller VLEN, such as embedded designs, will requires a larger `LMUL`
+to form the necessary element groups.
+It is important to keep in mind that this reduces the number of register groups available such
+that it may be difficult or impossible to write efficient code for the intended cryptographic algorithms.
+
+For example, an implementation with `VLEN`=32 would need to set `LMUL`=8 to create a
+256-bit element group for `SM3`. This would mean that there would only be 4 register groups,
+3 of which would be consumed by a single `SM3` message-expansion instruction.
+====
+
+As with all vector instructions, the number of elements processed is specified by the
+vector length `vl`. The number of element groups operated upon is then `vl`/`EGS`.
+Likewise the starting element group is `vstart`/`EGS`.
+See <<crypto-vector-instruction-constraints>> for limitations on `vl` and `vstart`
+for vector crypto instructions.
+
+// If this ratio is not an integer for a vector crypto instruction, an illegal-instruction exception is raised.
+
+// Since `vstart` is expressed in elements, the starting element group is `vstart`/`EGS`.
+// If this ratio is not an integer for a vector crypto instruction, an illegal-instruction exception is raised.
+
+[[crypto-vector-instruction-constraints]]
+==== Instruction Constraints
+
+All standard vector instruction constraints specified by RVV 1.0 apply to Vector Crypto instructions.
+In addition to those constraints a few additional specific constraints are introduced.
+
+The following is a quick reference for the various constraints of specific Vector Crypto instructions.
+
+
+vl and vstart constraints::
+Since `vl` and `vstart` refer to elements, Vector Crypto instructions that use elements groups
+(See <<crypto-vector-element-groups>>) require that these values are an integer multiple of the
+Element Group Size (`EGS`).
+
+- Instructions that violate the `vl` or `vstart` requirements are _reserved_.
+
+[%autowidth]
+[%header,cols="4,4"]
+|===
+| Instructions
+| EGS
+
+| vaes* | 4
+| vsha2* | 4
+| vg* | 4
+| vsm3* | 8
+| vsm4* | 4
+
+|===
+
+LMUL constraints::
+For element-group instructions, `LMUL`*`VLEN` must always be at least as large as `EGW`, otherwise an
+_illegal-instruction exception_ is raised, even if `vl`=0.
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+| Instructions
+| SEW
+| EGW
+
+| vaes* | 32 | 128
+| vsha2* | 32 | 128
+| vsha2* | 64 | 256
+| vg* | 32 | 128
+| vsm3* | 32 | 256
+| vsm4* | 32 | 128
+
+|===
+
+
+SEW constraints::
+Some Vector Crypto instructions are only defined for a specific `SEW`. In such a case
+all other `SEW` values are _reserved_.
+
+[%autowidth]
+[%header,cols="4,4"]
+|===
+| Instructions
+| Required SEW
+
+| vaes* | 32
+| Zvknha: vsha2* | 32
+| Zvknhb: vsha2* | 32 or 64
+| vclmul[h] | 64
+| vg* | 32
+| vsm3* | 32
+| vsm4* | 32
+
+
+|===
+
+Vector/Scalar constraints::
+This specification defines new vector/scalar (.vs) instructions that uses *Scalar Element Groups*. The *Scalar Element Group* operand has `EMUL = ceil(EGW / VLEN)`.
+
+[NOTE]
+====
+Scalar element group operands do not need to be aligned to LMUL for any implementation with VLEN >= EGW.
+====
+
+In the case of the `.vs` instructions defined in this specification, `vs2` holds a 128-bit scalar element group.
+For implementations with `VLEN` {ge} 128, `vs2` refers to a single register. Thus, the `vd` register group must not
+overlap the `vs2` register.
+However, in implementations where `VLEN` < 128, `vs2` refers to a register group comprised of the number
+of registers needed to hold the 128-bit scalar element group. In this case, the `vd` register group must not
+overlap this `vs2` register group.
+
+[%autowidth]
+[%header,cols="4,4,4"]
+|===
+| Instruction
+| Register
+| Cannot Overlap
+
+| vaes*.vs | vs2 | vd
+| vsm4r.vs | vs2 | vd
+| vsha2c[hl] | vs1, vs2 | vd
+| vsha2ms | vs1, vs2 | vd
+| vsm3me | vs2 | vd
+| vsm3c | vs2 | vd
+
+
+|===
+
+[[crypto-vector-scalar-instructions]]
+==== Vector-Scalar Instructions
+
+The RISC-V Vector Extension defines three encodings for Vector-Scalar operations which get their scalar operand from a GPR or FP register:
+
+- OPIVX: Scalar GPR _x_ register
+- OPFVF: Scalar FP _f_ register
+- OPMVX: Scalar GPR _x_ register
+
+However, the Vector Extensions include Vector Reduction Operations which can also be considered
+Vector-Scalar operations because a scalar operand is provided from element 0 of
+vector register `vs1`. The vector operand is provided in vector register group `vs2`.
+These reduction operations all use the `.vs` suffix in their mnemonics. Additionally, the reduction operations all produce a scalar result in element 0 of the destination register, `vd`.
+
+The Vector Crypto Extensions define Vector-Scalar instructions that are similar to these
+Vector Reduction Operations in that they get a scalar operand from a vector register. However, they differ
+in that they get a scalar element group
+(see <<crypto-vector-element-groups>>)
+from `vs2` and they return _vector_ results to `vd`, which is also a source vector operand.
+These Vector-Scalar crypto instructions also use the `.vs` suffix in their mnemonics.
+
+[NOTE]
+====
+We chose to use `vs2` as the scalar operand, and `vd` as the vector operand, so that we could use the `vs1`
+specifier as additional encoding bits for these instructions. This allows these instructions to have a
+much smaller encoding footprint, leaving more rooms for other instructions in the future.
+====
+
+These instructions enable a single key, specified as a scalar element group in `vs2`, to be
+applied to each element group of register group `vd`.
+
+[NOTE]
+====
+Scalar element groups will occupy at most a single register in application processors. However, in implementations where
+VLEN<128, they will occupy 2 (VLEN=64) or 4 (VLEN=32) registers.
+====
+
+
+[NOTE]
+====
+It is common for multiple AES encryption rounds (for example) to be performed in parallel with the same
+round key (e.g. in counter modes).
+Rather than having to first splat the common key across the whole vector group, these vector-scalar
+crypto instructions allow the round key to be specified as a scalar element group.
+====
+
+// In the case of AES256 all-rounds instructions we need to provide two 128-bit keys; one is held in `vs1` and
+// the other is held in `vs2`. The 128-bit data to be processed is held in `vd`.
+// A vector-scalar form of this instruction looks different from the existing vector-scalar instructions in that
+// both `vs1` and `vs2` are treated as scalar operands that apply to the vector operands of `vd`.
+
+// [NOTE]
+// ====
+// Previously, the AES and SM4 instructions that performed rounds operations (including AES all-rounds instructions)
+// were defined to be destructive operations where the data source was provided in `vd` and the key was provided in
+// `vs2`. With the advent of the new crypto vector-scalar instructions, we are changing these instructions
+// to use `vs1` for the key and `vs2` for the data.
+// In the case of vector-scalar instructions, the scalar key will be held in
+// element group 0 of `vs1` . This is done to remain consistent with the use of `vs1` for the scalar element in
+// all of the existing vector-scalar operations as well as the vector reduction operations.
+// ====
+
+[[crypto-vector-software-portability]]
+==== Software Portability
+The following contains some guidelines that enable the portability of vector-crypto-based code
+to implementations with different values for `VLEN`
+
+Application Processors::
+Application processors are expected to follow the V-extension and will therefore have `VLEN` {ge} 128.
+
+
+
+// [NOTE]
+// ====
+Since most of the _cryptography-specific_ instructions have an `EGW`=128, nothing special needs to be done
+for these instructions to support implementations with `VLEN`=128.
+
+However, the SHA-512 and SM3 instructions have an `EGW`=256. Implementations with `VLEN` = 128, require that
+`LMUL` is doubled for these instructions in order to create 256-bit elements across a pair of registers.
+Code written with this doubling of `LMUL` will not affect the results returned by implementations with `VLEN` {ge} 256
+because `vl` controls how many element groups are processed. Therefore, we recommend that libraries that implement
+SHA-512 and SM3 employ this doubling of `LMUL` to ensure that the software can run on all implementation
+with `VLEN` {ge} 128.
+
+While the doubling of `LMUL` for these instructions is _safe_ for implementations with `VLEN` {ge} 256, it may be less
+optimal as it will result in unnecessary register pressure and might exact a performance penalty in
+some microarchitectures. Therefore, we suggest that in addition to providing portable code for SHA-512 and SM3,
+libraries should also include more optimal code for these instructions when `VLEN` {ge} 256.
+// ====
+
+[%autowidth]
+[%header,cols="4,4,4,4"]
+|===
+| Algorithm
+| Instructions
+| VLEN
+| LMUL
+
+| SHA-512 | vsha2* | 64 | vl/2
+| SM3 | vsm3* | 32 | vl/4
+|===
+
+// [NOTE]
+// ====
+// We recommend that all library code for application processors be written so that it can be run on any
+// implementation with `VLEN` {ge} 128. Such libraries are also encouraged to have versions of code for
+// SHA-512 and SM3 optimized for implementations with `VLEN` {ge} 256.
+// ====
+
+Embedded Processors::
+
+Embedded processors will typically have implementations with `VLEN` < 128. This will require code to be written with
+larger `LMUL` values to enable the element groups to be formed.
+
+The `.vs` instructions require scalar element groups of `EGW`=128. On implementations with `VLEN` < 128, these scalar
+element groups will necessarily be formed across registers. This is different from most scalars in vector instructions
+that typically consume part of a single register.
+
+
+// [NOTE]
+// ====
+We recommend that different code be available for `VLEN`=32 and `VLEN`=64, as code written for `VLEN`=32 will
+likely be too burdensome for `VLEN`=64 implementations.
+// ====
+
+[[crypto_vector_extensions]]
+=== Extensions Overview
+
+The section introduces all of the extensions in the Vector Cryptography
+Instruction Set Extension Specification.
+
+The <<zvknh,Zvknhb>> and <<zvbc>> Vector Crypto Extensions
+--and accordingly the composite extensions <<Zvkn>>, <<Zvknc>>, <<Zvkng>>, and <<Zvksc>>--
+depend on Zve64x.
+
+All of the other Vector Crypto Extensions depend on `Zve32x`.
+
+Note: If `Zve32x` is supported then `Zvkb` or `Zvbb` provide support for EEW of 8, 16, and 32. If `Zve64x` is supported then `Zvkb` or `Zvbb` also add support for EEW 64.
+
+
+// See <<crypto-vector-element-groups>> for more details on vector element groups and the drawbacks of
+// small `VLEN` values.
+
+
+All _cryptography-specific_ instructions defined in this Vector Crypto specification (i.e., those
+in <<zvkned>>, <<zvknh,Zvknh[ab]>>, <<Zvkg>>, <<Zvksed>> and <<zvksh>> but _not_ <<zvbb>>,<<zvkb>>, or <<zvbc>>) shall
+be executed with data-independent execution latency as defined in the
+<<#crypto_scalar_instructions,RISC-V Scalar Cryptography Extensions specification>>.
+It is important to note that the Vector Crypto instructions are independent of the
+implementation of the `Zkt` extension and do not require that `Zkt` is implemented.
+
+This specification includes a <<Zvkt>> extension that, when implemented, requires certain vector instructions
+(including <<zvbb>>, <<zvkb>>, and <<zvbc>>) to be executed with data-independent execution latency.
+
+Detection of individual cryptography extensions uses the
+unified software-based RISC-V discovery method.
+
+[NOTE]
+====
+At the time of writing, these discovery mechanisms are still a work in
+progress.
+====
+
+[[zvbb,Zvbb]]
+==== `Zvbb` - Vector Basic Bit-manipulation
+
+Vector basic bit-manipulation instructions.
+
+[NOTE]
+====
+This extension is a superset of the <<Zvkb>> extension.
+====
+
+[%autowidth]
+[%header,cols="2,4"]
+|===
+|Mnemonic
+|Instruction
+
+| vandn.[vv,vx] | <<insns-vandn>>
+| vbrev.v | <<insns-vbrev>>
+| vbrev8.v | <<insns-vbrev8>>
+| vrev8.v | <<insns-vrev8>>
+| vclz.v | <<insns-vclz>>
+| vctz.v | <<insns-vctz>>
+| vcpop.v | <<insns-vcpop>>
+| vrol.[vv,vx] | <<insns-vrol>>
+| vror.[vv,vx,vi] | <<insns-vror>>
+| vwsll.[vv,vx,vi] | <<insns-vwsll>>
+
+|===
+
+<<<
+
+[[zvbc,Zvbc]]
+==== `Zvbc` - Vector Carryless Multiplication
+
+General purpose carryless multiplication instructions which are commonly used in cryptography
+and hashing (e.g., Elliptic curve cryptography, GHASH, CRC).
+
+These instructions are only defined for `SEW`=64.
+
+[%autowidth]
+[%header,cols="^2,4"]
+|===
+|Mnemonic
+|Instruction
+| vclmul.[vv,vx] | <<insns-vclmul>>
+| vclmulh.[vv,vx] | <<insns-vclmulh>>
+
+|===
+
+<<<
+
+[[zvkb,Zvkb]]
+==== `Zvkb` - Vector Cryptography Bit-manipulation
+
+Vector bit-manipulation instructions that are essential
+for implementing common cryptographic workloads securely &
+efficiently.
+
+[NOTE]
+====
+This Zvkb extension is a proper subset of the Zvbb extension.
+Zvkb allows for vector crypto implementations without incurring
+the cost of implementing the additional bitmanip instructions
+in the Zvbb extension: vbrev.v, vclz.v, vctz.v, vcpop.v, and vwsll.[vv,vx,vi].
+====
+
+[%autowidth]
+[%header,cols="2,4"]
+|===
+|Mnemonic
+|Instruction
+
+| vandn.[vv,vx] | <<insns-vandn>>
+// | vbrev.v | <<insns-vbrev>>
+| vbrev8.v | <<insns-vbrev8>>
+| vrev8.v | <<insns-vrev8>>
+// | vclz.v | <<insns-vclz>>
+// | vctz.v | <<insns-vctz>>
+// | vcpop.v | <<insns-vcpop>>
+| vrol.[vv,vx] | <<insns-vrol>>
+| vror.[vv,vx,vi] | <<insns-vror>>
+// | vwsll.[vv,vx,vi] | <<insns-vwsll>>
+|===
+
+<<<
+
+[[zvkg,Zvkg]]
+==== `Zvkg` - Vector GCM/GMAC
+
+Instructions to enable the efficient implementation of GHASH~H~ which is used in Galois/Counter Mode (GCM) and
+Galois Message Authentication Code (GMAC).
+
+All of these instructions work on 128-bit element groups comprised of four 32-bit elements.
+
+GHASH~H~ is defined in the
+// link:https://csrc.nist.gov/publications/detail/sp/800-38d/final[NIST Special Publication 800-38D]
+ "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC"
+ cite:[nist:gcm]
+(NIST Specification).
+
+[NOTE]
+====
+GCM is used in conjunction with block ciphers (e.g., AES and SM4) to encrypt a message and
+provide authentication.
+GMAC is used to provide authentication of a message without encryption.
+====
+
+To help avoid side-channel timing attacks, these instructions shall be implemented with data-independent timing.
+
+The number of element groups to be processed is `vl`/`EGS`.
+`vl` must be set to the number of `SEW=32` elements to be processed and
+therefore must be a multiple of `EGS=4`. +
+Likewise, `vstart` must be a multiple of `EGS=4`.
+
+[%autowidth]
+[%header,cols="^2,4,4,4"]
+|===
+
+|SEW
+|EGW
+|Mnemonic
+|Instruction
+| 32 | 128 | vghsh.vv | <<insns-vghsh>>
+| 32 | 128 | vgmul.vv | <<insns-vgmul>>
+
+|===
+
+<<<
+
+[[zvkned,Zvkned]]
+==== `Zvkned` - NIST Suite: Vector AES Block Cipher
+
+Instructions for accelerating
+encryption, decryption and key-schedule
+functions of the AES block cipher as defined in
+Federal Information Processing Standards Publication 197
+cite:[nist:fips:197]
+
+All of these instructions work on 128-bit element groups comprised of four
+32-bit elements.
+
+For the best performance, it is suggested that these instruction be implemented on systems with `VLEN`>=128.
+On systems with `VLEN`<128, element groups may be formed by concatenating 32-bit elements
+from two or four registers by using an LMUL =2 and LMUL=4 respectively.
+
+// Implementations with `VLEN<128` should consider the existing
+// Scalar Cryptography Extensions, specifically <<Zkne,Zkne>> and <<Zknd,Zknd>>
+// for accelerated cryptographic operations.
+
+To help avoid side-channel timing attacks, these instructions shall be implemented with data-independent timing.
+
+The number of element groups to be processed is `vl`/`EGS`.
+`vl` must be set to the number of `SEW=32` elements to be processed and
+therefore must be a multiple of `EGS=4`. +
+Likewise, `vstart` must be a multiple of `EGS=4`.
+
+[%autowidth]
+[%header,cols="^2,4,4,4"]
+|===
+|SEW
+|EGW
+|Mnemonic
+|Instruction
+
+| 32| 128 | vaesef.[vv,vs] | <<insns-vaesef>>
+| 32| 128 | vaesem.[vv,vs] | <<insns-vaesem>>
+| 32| 128 | vaesdf.[vv,vs] | <<insns-vaesdf>>
+| 32| 128 | vaesdm.[vv,vs] | <<insns-vaesdm>>
+| 32| 128 | vaeskf1.vi | <<insns-vaeskf1>>
+| 32| 128 | vaeskf2.vi | <<insns-vaeskf2>>
+| 32| 128 | vaesz.vs | <<insns-vaesz>>
+|===
+
+<<<
+
+[[zvknh, zvknh[ab]]]
+==== `Zvknh[ab]` - NIST Suite: Vector SHA-2 Secure Hash
+
+Instructions for accelerating SHA-2 as defined in FIPS PUB 180-4 Secure Hash Standard (SHS)
+cite:[nist:fips:180:4]
+
+`SEW` differentiates between SHA-256 (`SEW`=32) and SHA-512 (`SEW`=64).
+
+- SHA-256: these instructions work on 128-bit element groups comprised of four 32-bit elements.
+- SHA-512: these instructions work on 256-bit element groups comprised of four 64-bit elements.
+
+[%autowidth]
+[%header,cols="^2,^2,^2,2"]
+|===
+|SEW
+|EGW
+|SHA-2
+|Extension
+
+|32 | 128 | SHA-256 | Zvknha, Zvknhb
+|64 | 256 | SHA-512 | Zvknhb
+|===
+
+// link:https://doi.org/10.6028/NIST.FIPS.180-4[FIPS PUB 180-4 Secure Hash Standard (SHS)])
+
+- Zvknhb supports SHA-256 and SHA-512.
+- Zvknha supports only SHA-256.
+
+// [NOTE]
+// ====
+// Zvknhb is implemented, `SEW` is used to differentiate between SHA-256 (SEW=32) and SHA-512 (SEW=64).
+// If Zvknha is implemented, only SHA-256 is supported, and SEW must be 32.
+// ====
+
+SHA-256 implementations with VLEN < 128 require LMUL>1 to combine
+32-bit elements from register groups to provide all four elements of the element group.
+
+SHA-512 implementations with VLEN < 256 require LMUL>1 to combine
+64-bit elements from register groups to provide all four elements of the element group.
+
+// SHA-2 is defined in
+// link:https://doi.org/10.6028/NIST.FIPS.180-4[FIPS PUB 180-4 Secure Hash Standard (SHS)].
+
+To help avoid side-channel timing attacks, these instructions shall be implemented with data-independent timing.
+
+// [NOTE]
+// ====
+// It is recommended that implementations have VLEN{ge}128 for these instructions.
+// // Furthermore, for the best performance in SHA512, it is recommended that implementations have VLEN{ge}256.
+// When VLEN<EGW, an appropriate LMUL needs to be used by software so that elements from the
+// specified register groups can be combined to form the full element group.
+// ====
+
+The number of element groups to be processed is `vl`/`EGS`.
+`vl` must be set to the number of `SEW` elements to be processed and
+therefore must be a multiple of `EGS=4`. +
+Likewise, `vstart` must be a multiple of `EGS=4`.
+
+[%autowidth]
+[%header,cols="2,4"]
+|===
+// |`VLENmin`
+|Mnemonic
+|Instruction
+
+// | 128
+| vsha2ms.vv | <<insns-vsha2ms>>
+// | 128
+| vsha2c[hl].vv | <<insns-vsha2c>>
+|===
+
+<<<
+
+[[zvksed,Zvksed]]
+==== `Zvksed` - ShangMi Suite: SM4 Block Cipher
+
+Instructions for accelerating
+encryption, decryption, and key-schedule
+functions of the SM4 block cipher.
+
+The SM4 block cipher is specified in _32907-2016: {SM4} Block Cipher Algorithm_
+cite:[gbt:sm4]
+
+There are other various sources available that describe the SM4 block cipher.
+While not the final version of the standard,
+link:https://www.rfc-editor.org/rfc/rfc8998.html[RFC 8998 ShangMi (SM) Cipher Suites for TLS 1.3]
+is useful and easy to access.
+
+// https://datatracker.ietf.org/doc/id/draft-crypto-sm4-00
+
+All of these instructions work on 128-bit element groups comprised of four
+32-bit elements.
+
+// Systems which implement `VLEN<128` should consider the existing
+// Scalar Cryptography Extensions, specifically <<Zkne,Zkne>> and <<Zknd,Zknd>>
+// for accelerated cryptographic operations.
+
+To help avoid side-channel timing attacks, these instructions shall be implemented with data-independent timing.
+
+The number of element groups to be processed is `vl`/`EGS`.
+`vl` must be set to the number of `SEW=32` elements to be processed and
+therefore must be a multiple of `EGS=4`. +
+Likewise, `vstart` must be a multiple of `EGS=4`.
+
+[%autowidth]
+[%header,cols="^2,4,4,4"]
+|===
+|SEW
+|EGW
+|Mnemonic
+|Instruction
+
+| 32 | 128 | vsm4k.vi | <<insns-vsm4k>>
+| 32 | 128 | vsm4r.[vv,vs] | <<insns-vsm4r>>
+|===
+
+<<<
+
+[[zvksh,Zvksh]]
+==== `Zvksh` - ShangMi Suite: SM3 Secure Hash
+
+Instructions for accelerating
+functions of the SM3 Hash Function.
+
+The SM3 secure hash algorithm is specified in _32905-2016: SM3 Cryptographic Hash Algorithm_
+cite:[gbt:sm4]
+
+There are other various sources available that describe the SM3 secure hash.
+While not the final version of the standard,
+link:https://www.rfc-editor.org/rfc/rfc8998.html[RFC 8998 ShangMi (SM) Cipher Suites for TLS 1.3]
+is useful and easy to access.
+
+// https://datatracker.ietf.org/doc/id/draft-crypto-sm4-00
+
+All of these instructions work on 256-bit element groups comprised of
+eight 32-bit elements.
+
+Implementations with VLEN < 256 require LMUL>1 to combine 32-bit elements from register groups
+to provide all eight elements of the element group.
+
+// The instructions will be most efficient on implementations where `VLEN`{ge}256.
+// They will also provide substantial benefit on implementations where
+// `VLEN`=128, but will require an `LMUL`>1 in order to combine elements
+// within a register group to form the full element group.
+// Implementations with `VLEN`<128 might not be as efficient and should
+// consider the existing
+// Scalar Cryptography Extensions, specifically `Zkne` and `Zknd`,
+// for accelerated cryptographic operations.
+
+To help avoid side-channel timing attacks, these instructions shall be implemented with data-independent timing.
+
+The number of element groups to be processed is `vl`/`EGS`.
+`vl` must be set to the number of `SEW=32` elements to be processed and
+therefore must be a multiple of `EGS=8`. +
+Likewise, `vstart` must be a multiple of `EGS=8`.
+
+[%autowidth]
+[%header,cols="2,4,4,4"]
+|===
+| SEW
+| EGW
+| Mnemonic
+| Instruction
+
+| 32 | 256 | vsm3me.vv | <<insns-vsm3me>>
+| 32 | 256 | vsm3c.vi | <<insns-vsm3c>>
+|===
+
+<<<
+
+[[zvkn,Zvkn]]
+==== `Zvkn` - NIST Algorithm Suite
+
+This extension is shorthand for the following set of other extensions:
+
+[%autowidth]
+[%header,cols="^2,4"]
+|===
+|Included Extension
+|Description
+
+
+| Zvkned | <<Zvkned>>
+| Zvknhb | <<zvknh,Zvknhb>>
+// | Zvbb | <<Zvbb>>
+| Zvkb | <<Zvkb>>
+// | Zvbc | <<Zvbc>>
+| Zvkt | <<Zvkt>>
+|===
+
+[NOTE]
+====
+While Zvkg and Zvbc are not part of this extension, it is recommended that at least one of them is implemented with this extension to enable efficient AES-GCM.
+====
+
+<<<
+
+[[zvknc,Zvknc]]
+==== `Zvknc` - NIST Algorithm Suite with carryless multiply
+
+This extension is shorthand for the following set of other extensions:
+
+[%autowidth]
+[%header,cols="^2,4"]
+|===
+|Included Extension
+|Description
+
+
+| Zvkn | <<Zvkn>>
+| Zvbc | <<Zvbc>>
+|===
+
+[NOTE]
+====
+This extension combines the NIST Algorithm Suite with the
+vector carryless multiply extension to enable AES-GCM.
+====
+
+<<<
+
+[[zvkng,Zvkng]]
+==== `Zvkng` - NIST Algorithm Suite with GCM
+
+This extension is shorthand for the following set of other extensions:
+
+[%autowidth]
+[%header,cols="^2,4"]
+|===
+|Included Extension
+|Description
+
+
+| Zvkn | <<Zvkn>>
+| Zvkg | <<Zvkg>>
+|===
+
+[NOTE]
+====
+This extension combines the NIST Algorithm Suite with the
+GCM/GMAC extension to enable high-performance AES-GCM.
+====
+
+<<<
+
+[[zvks,Zvks]]
+==== `Zvks` - ShangMi Algorithm Suite
+
+This extension is shorthand for the following set of other extensions:
+
+[%autowidth]
+[%header,cols="^2,4"]
+|===
+|Included Extension
+|Description
+
+
+| Zvksed | <<Zvksed>>
+| Zvksh | <<Zvksh>>
+// | Zvbb | <<Zvbb>>
+| Zvkb | <<Zvkb>>
+// | Zvbc | <<Zvbc>>
+| Zvkt | <<Zvkt>>
+|===
+
+[NOTE]
+====
+While Zvkg and Zvbc are not part of this extension, it is recommended that at least one of them is implemented with this extension to enable efficient SM4-GCM.
+====
+
+<<<
+
+[[zvksc,Zvksc]]
+==== `Zvksc` - ShangMi Algorithm Suite with carryless multiplication
+
+This extension is shorthand for the following set of other extensions:
+
+[%autowidth]
+[%header,cols="^2,4"]
+|===
+|Included Extension
+|Description
+
+
+| Zvks | <<Zvks>>
+| Zvbc | <<Zvbc>>
+|===
+
+[NOTE]
+====
+This extension combines the ShangMi Algorithm Suite with the
+vector carryless multiply extension to enable SM4-GCM.
+====
+
+<<<
+
+[[zvksg,Zvksg]]
+==== `Zvksg` - ShangMi Algorithm Suite with GCM
+
+This extension is shorthand for the following set of other extensions:
+
+[%autowidth]
+[%header,cols="^2,4"]
+|===
+|Included Extension
+|Description
+
+
+| Zvks | <<Zvks>>
+| Zvkg | <<Zvkg>>
+|===
+
+[NOTE]
+====
+This extension combines the ShangMi Algorithm Suite with the
+GCM/GMAC extension to enable high-performance SM4-GCM.
+====
+
+<<<
+
+[[zvkt,Zvkt]]
+==== `Zvkt` - Vector Data-Independent Execution Latency
+
+The Zvkt extension requires all implemented instructions from the following list to be
+executed with data-independent execution latency as defined in the
+<<#crypto_scalar_instructions,RISC-V Scalar Cryptography Extensions specification>>.
+
+Data-independent execution latency (DIEL) applies to all _data operands_ of an instruction, even those that are not a
+part of the body or that are inactive. However, DIEL does not apply
+to other values such as vl, vtype, and the mask (when used to control
+execution of a masked vector instruction).
+Also, DIEL does not apply to constant values specified in the
+instruction encoding such as the use of the zero register (`x0`), and, in the
+case of immediate forms of an instruction, the values in the immediate
+fields (i.e., imm, and uimm).
+
+In some cases --- which are explicitly specified in the lists below
+--- operands that are used as control rather than data
+are exempt from DIEL.
+
+[NOTE]
+====
+DIEL helps protect against side-channel timing attacks that are used
+to determine data values that are intended to be kept secret. Such
+values include cryptographic keys, plain text, and partially encrypted
+text. DIEL is not intended to keep software (and cryptographic
+algorithms contained therein) secret as it is assumed that an adversary
+would already know these. This is why DIEL doesn't apply to constants
+embedded in instruction encodings.
+
+It is important that the _values_ of elements that are not in the body or that are masked off do not affect the execution
+latency of the instruction. Sometimes such elements contain data that
+also needs to be kept secret.
+====
+
+===== All <<Zvbb>> instructions
+- vandn.v[vx]
+- vclz.v
+- vcpop.v
+- vctz.v
+- vbrev.v
+- vbrev8.v
+- vrev8.v
+- vrol.v[vx]
+- vror.v[vxi]
+- vwsll.[vv,vx,vi]
+
+[NOTE]
+====
+All <<Zvkb>> instructions are also covered by DIEL as they are a
+proper subset of <<Zvbb>>
+====
+
+===== All <<Zvbc>> instructions
+- vclmul[h].v[vx]
+
+===== add/sub
+- v[r]sub.v[vx]
+- vadd.v[ivx]
+- vsub.v[vx]
+- vwadd[u].[vw][vx]
+- vwsub[u].[vw][vx]
+
+===== add/sub with carry
+- vadc.v[ivx]m
+- vmadc.v[ivx][m]
+- vmsbc.v[vx]m
+- vsbc.v[vx]m
+
+===== compare and set
+- vmseq.v[vxi]
+- vmsgt[u].v[xi]
+- vmsle[u].v[xi]
+- vmslt[u].v[xi]
+- vmsne.v[ivx]
+
+===== copy
+- vmv.s.x
+- vmv.v.[ivxs]
+- vmv[1248]r.v
+
+===== extend
+- vsext.vf[248]
+- vzext.vf[248]
+
+===== logical
+- vand.v[ivx]
+- vm[n]or.mm
+- vmand[n].mm
+- vmnand.mm
+- vmorn.mm
+- vmx[n]or.mm
+- vor.v[ivx]
+- vxor.v[ivx]
+
+===== multiply
+- vmul[h].v[vx]
+- vmulh[s]u.v[vx]
+- vwmul.v[vx]
+- vwmul[s]u.v[vx]
+
+===== multiply-add
+- vmacc.v[vx]
+- vmadd.v[vx]
+- vnmsac.v[vx]
+- vnmsub.v[vx]
+- vwmacc.v[vx]
+- vwmacc[s]u.v[vx]
+- vwmaccus.vx
+
+===== Integer Merge
+- vmerge.v[ivx]m
+
+===== permute
+In the `.vv` and `.xv` forms of the `vrgather[ei16]` instructions,
+the values in `vs1` and `rs1` are used for control and therefore are exempt from DIEL.
+
+- vrgather.v[ivx]
+- vrgatherei16.vv
+
+===== shift
+// The values in `vs1`, `rs1`, `imm` are used for control (i.e., shift amount) and are exempt from DIEL.
+
+- vnsr[al].w[ivx]
+- vsll.v[ivx]
+- vsr[al].v[ivx]
+
+===== slide
+- vslide1[up|down].vx
+- vfslide1[up|down].vf
+
+In the vslide[up|down].vx instructions, the value in `rs1`
+is used for control (i.e., slide amount) and therefore is exempt
+from DIEL.
+
+- vslide[up|down].v[ix]
+
+[NOTE]
+====
+The following instructions are not affected by Zvkt:
+
+- *All storage operations*
+- *All floating-point operations*
+- add/sub saturate
+* vsadd[u].v[ivx]
+* vssub[u].v[vx]
+- clip
+* vnclip[u].w[ivx]
+- compress
+* vcompress.vm
+- divide
+* vdiv[u].v[vx]
+* vrem[u].v[vx]
+- average
+* vaadd[u].v[vx]
+* vasub[u].v[vx]
+- mask Op
+* vcpop.m
+* vfirst.m
+* vid.v
+* viota.m
+* vms[bio]f.m
+- min/max
+* vmax[u].v[vx]
+* vmin[u].v[vx]
+- Multiply-saturate
+* vsmul.v[vx]
+- reduce
+* vredsum.vs
+* vwredsum[u].vs
+* vred[and|or|xor].vs
+* vred[min|max][u].vs
+- shift round
+* vssra.v[ivx]
+* vssrl.v[ivx]
+- vset
+* vsetivli
+* vsetvl[i]
+====
+
+[[crypto_vector_insns, reftext="Vector Cryptography Instructions"]]
+=== Instructions
+
+[[insns-vaesdf, Vector AES decrypt final round]]
+==== vaesdf.[vv,vs]
+
+Synopsis::
+Vector AES final-round decryption
+
+Mnemonic::
+vaesdf.vv vd, vs2 +
+vaesdf.vs vd, vs2
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '00001'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101000'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '00001'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101001`'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+* Only for the `.vs` form: the `vd` register group overlaps the `vs2` scalar element group
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| Vd | input | 128 | 4 | 32 | round state
+| Vs2 | input | 128 | 4 | 32 | round key
+| Vd | output | 128 | 4 | 32 | new round state
+|===
+
+Description::
+A final-round AES block cipher decryption is performed.
+
+The InvShiftRows and InvSubBytes steps are applied to each round state element group from `vd`.
+This is then XORed with the round key in either the corresponding element group in `vs2` (vector-vector
+form) or scalar element group in `vs2` (vector-scalar form).
+
+This instruction must always be implemented such that its execution latency does not depend
+on the data being operated upon.
+
+// if( ((vl%EGS)<>0) | ((vstart%EGS)<>0) | (LMUL*VLEN < EGW)) then {
+
+Operation::
+[source,sail]
+--
+function clause execute (VAESDF(vs2, vd, suffix)) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ let keyelem = if suffix == "vv" then i else 0;
+ let state : bits(128) = get_velem(vd, EGW=128, i);
+ let rkey : bits(128) = get_velem(vs2, EGW=128, keyelem);
+ let sr : bits(128) = aes_shift_rows_inv(state);
+ let sb : bits(128) = aes_subbytes_inv(sr);
+ let ark : bits(128) = sb ^ rkey;
+ set_velem(vd, EGW=128, i, ark);
+ }
+ RETIRE_SUCCESS
+ }
+}
+--
+
+Included in::
+<<zvkn>>, <<zvknc>>, <<zvkned>>, <<zvkng>>
+
+<<<
+
+[[insns-vaesdm, Vector AES decrypt middle round]]
+==== vaesdm.[vv,vs]
+
+Synopsis::
+Vector AES middle-round decryption
+
+Mnemonic::
+vaesdm.vv vd, vs2 +
+vaesdm.vs vd, vs2
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '00000'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101000'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '00000'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101001'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+* Only for the `.vs` form: the `vd` register group overlaps the `vs2` scalar element group
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| Vd | input | 128 | 4 | 32 | round state
+| Vs2 | input | 128 | 4 | 32 | round key
+| Vd | output | 128 | 4 | 32 | new round state
+|===
+
+Description::
+A middle-round AES block cipher decryption is performed.
+
+The InvShiftRows and InvSubBytes steps are applied to each round state element group from `vd`.
+This is then XORed with the round key in either the corresponding element group in `vs2` (vector-vector
+form) or the scalar element group in `vs2` (vector-scalar form). The result is then applied to the
+InvMixColumns step.
+
+This instruction must always be implemented such that its execution latency does not depend
+on the data being operated upon.
+//
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`.
+
+Operation::
+[source,sail]
+--
+function clause execute (VAESDM(vs2, vd, suffix)) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ let keyelem = if suffix == "vv" then i else 0;
+ let state : bits(128) = get_velem(vd, EGW=128, i);
+ let rkey : bits(128) = get_velem(vs2, EGW=128, keyelem);
+ let sr : bits(128) = aes_shift_rows_inv(state);
+ let sb : bits(128) = aes_subbytes_inv(sr);
+ let ark : bits(128) = sb ^ rkey;
+ let mix : bits(128) = aes_mixcolumns_inv(ark);
+ set_velem(vd, EGW=128, i, mix);
+ }
+ RETIRE_SUCCESS
+ }
+}
+--
+
+Included in::
+<<zvkn>>, <<zvknc>>, <<zvkned>>, <<zvkng>>
+
+<<<
+
+[[insns-vaesef, Vector AES encrypt final round]]
+==== vaesef.[vv,vs]
+
+Synopsis::
+Vector AES final-round encryption
+
+Mnemonic::
+vaesef.vv vd, vs2 +
+vaesef.vs vd, vs2
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '00011'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101000'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '00011'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101001'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+* Only for the `.vs` form: the `vd` register group overlaps the `vs2` scalar element group
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| vd | input | 128 | 4 | 32 | round state
+| vs2 | input | 128 | 4 | 32 | round key
+| vd | output | 128 | 4 | 32 | new round state
+|===
+
+Description::
+A final-round encryption function of the AES block cipher is performed.
+
+The SubBytes and ShiftRows steps are applied to each round state element group from `vd`.
+This is then XORed with the round key in either the corresponding element group in `vs2` (vector-vector
+form) or the scalar element group in `vs2` (vector-scalar form).
+
+This instruction must always be implemented such that its execution latency does not depend
+on the data being operated upon.
+//
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`.
+
+
+Operation::
+[source,sail]
+--
+function clause execute (VAESEF(vs2, vd, suffix) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ let keyelem = if suffix == "vv" then i else 0;
+ let state : bits(128) = get_velem(vd, EGW=128, i);
+ let rkey : bits(128) = get_velem(vs2, EGW=128, keyelem);
+ let sb : bits(128) = aes_subbytes_fwd(state);
+ let sr : bits(128) = aes_shift_rows_fwd(sb);
+ let ark : bits(128) = sr ^ rkey;
+ set_velem(vd, EGW=128, i, ark);
+ }
+ RETIRE_SUCCESS
+ }
+}
+--
+
+Included in::
+<<zvkn>>, <<zvknc>>, <<zvkned>>, <<zvkng>>
+
+<<<
+
+[[insns-vaesem, Vector AES encrypt middle round]]
+==== vaesem.[vv,vs]
+
+Synopsis::
+Vector AES middle-round encryption
+
+Mnemonic::
+vaesem.vv vd, vs2 +
+vaesem.vs vd, vs2
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '00010'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101000'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '00010'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101001'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+* Only for the `.vs` form: the `vd` register group overlaps the `vs2` scalar element group
+
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| Vd | input | 128 | 4 | 32 | round state
+| Vs2 | input | 128 | 4 | 32 | Round key
+| Vd | output | 128 | 4 | 32 | new round state
+|===
+
+Description::
+A middle-round encryption function of the AES block cipher is performed.
+
+The SubBytes, ShiftRows, and MixColumns steps are applied to each round state element group from `vd`.
+This is then XORed with the round key in either the corresponding element group in `vs2` (vector-vector
+form) or the scalar element group in `vs2` (vector-scalar form).
+
+This instruction must always be implemented such that its execution latency does not depend
+on the data being operated upon.
+//
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`.
+
+Operation::
+[source,sail]
+--
+function clause execute (VAESEM(vs2, vd, suffix)) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ let keyelem = if suffix == "vv" then i else 0;
+ let state : bits(128) = get_velem(vd, EGW=128, i);
+ let rkey : bits(128) = get_velem(vs2, EGW=128, keyelem);
+ let sb : bits(128) = aes_subbytes_fwd(state);
+ let sr : bits(128) = aes_shift_rows_fwd(sb);
+ let mix : bits(128) = aes_mixcolumns_fwd(sr);
+ let ark : bits(128) = mix ^ rkey;
+ set_velem(vd, EGW=128, i, ark);
+ }
+ RETIRE_SUCCESS
+ }
+}
+--
+
+Included in::
+<<zvkn>>, <<zvknc>>, <<zvkned>>, <<zvkng>>
+
+<<<
+
+[[insns-vaeskf1, Vector AES-128 Forward KeySchedule]]
+==== vaeskf1.vi
+
+Synopsis::
+Vector AES-128 Forward KeySchedule generation
+
+Mnemonic::
+vaeskf1.vi vd, vs2, uimm
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'uimm'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '100010'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| uimm | input | - | - | - | Round Number (rnd)
+| Vs2 | input | 128 | 4 | 32 | Current round key
+| Vd | output | 128 | 4 | 32 | Next round key
+|===
+
+Description::
+A single round of the forward AES-128 KeySchedule is performed.
+
+// Within each element group,
+The next round key is generated word by word from the
+current round key element group in `vs2` and the immediately previous word of the
+round key. The least significant word is generated using the most significant
+word of the current round key as well as a round constant which is selected by
+the round number.
+
+The round number, which ranges from 1 to 10, comes from `uimm[3:0]`;
+`uimm[4]` is ignored.
+The out-of-range `uimm[3:0]` values of 0 and 11-15 are mapped to in-range
+values by inverting `uimm[3]`. Thus, 0 maps to 8, and 11-15 maps to 3-7.
+The round number is used to specify a round constant which is used in generating
+the first round key word.
+
+This instruction must always be implemented such that its execution latency does not depend
+on the data being operated upon.
+
+[NOTE]
+====
+We chose to map out-of-range round numbers to in-range values as this allows the instruction's
+behavior to be fully defined for all values of `uimm[4:0]` with minimal extra logic.
+====
+
+// Each `EGW=128` element group next-round-key output is produced and is written to each `EGW=128`
+// element group of `vd`.
+
+
+//
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`.
+
+
+Operation::
+[source,Sail]
+--
+function clause execute (VAESKF1(rnd, vd, vs2)) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ // project out-of-range immediates onto in-range values
+ if( (unsigned(rnd[3:0]) > 10) | (rnd[3:0] = 0)) then rnd[3] = ~rnd[3]
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ let r : bits(4) = rnd-1;
+
+ foreach (i from eg_start to eg_len-1) {
+ let CurrentRoundKey[3:0] : bits(128) = get_velem(vs2, EGW=128, i);
+ let w[0] : bits(32) = aes_subword_fwd(aes_rotword(CurrentRoundKey[3])) XOR
+ aes_decode_rcon(r) XOR CurrentRoundKey[0]
+ let w[1] : bits(32) = w[0] XOR CurrentRoundKey[1]
+ let w[2] : bits(32) = w[1] XOR CurrentRoundKey[2]
+ let w[3] : bits(32) = w[2] XOR CurrentRoundKey[3]
+ set_velem(vd, EGW=128, i, w[3:0]);
+ }
+ RETIRE_SUCCESS
+ }
+}
+
+--
+
+Included in::
+<<zvkn>>, <<zvknc>>, <<zvkned>>, <<zvkng>>
+
+<<<
+
+[[insns-vaeskf2, Vector AES-256 Forward KeySchedule]]
+==== vaeskf2.vi
+
+Synopsis::
+Vector AES-256 Forward KeySchedule generation
+
+Mnemonic::
+vaeskf2.vi vd, vs2, uimm
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'uimm'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101010'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| Vd | input | 128 | 4 | 32 | Previous Round key
+| uimm | input | - | - | - | Round Number (rnd)
+| Vs2 | input | 128 | 4 | 32 | Current Round key
+| Vd | output | 128 | 4 | 32 | Next round key
+|===
+
+Description::
+A single round of the forward AES-256 KeySchedule is performed.
+
+// Within each element group,
+The next round key is generated word by word from the
+previous round key element group in `vd` and the immediately previous word of the
+round key. The least significant word of the next round key is generated by
+applying a function to the most significant word of the current round key and
+then XORing the result with the round constant.
+The round number is used to select the round constant as well as the function.
+
+The round number, which ranges from 2 to 14, comes from `uimm[3:0]`;
+`uimm[4]` is ignored.
+The out-of-range `uimm[3:0]` values of 0-1 and 15 are mapped to in-range
+values by inverting `uimm[3]`. Thus, 0-1 maps to 8-9, and 15 maps to 7.
+
+This instruction must always be implemented such that its execution latency does not depend
+on the data being operated upon.
+
+[NOTE]
+====
+We chose to map out-of-range round numbers to in-range values as this allows the instruction's
+behavior to be fully defined for all values of `uimm[4:0]` with minimal extra logic.
+====
+
+//
+
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`.
+
+Operation::
+[source,Sail]
+--
+function clause execute (VAESKF2(rnd, vd, vs2)) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ // project out-of-range immediates into in-range values
+ if((unsigned(rnd[3:0]) < 2) | (unsigned(rnd[3:0]) > 14)) then rnd[3] = ~rnd[3]
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ let CurrentRoundKey[3:0] : bits(128) = get_velem(vs2, EGW=128, i);
+ let RoundKeyB[3:0] : bits(32) = get_velem(vd, EGW=128, i); // Previous round key
+
+ let w[0] : bits(32) = if (rnd[0]==1) then
+ aes_subword_fwd(CurrentRoundKey[3]) XOR RoundKeyB[0];
+ else
+ aes_subword_fwd(aes_rotword(CurrentRoundKey[3])) XOR aes_decode_rcon((rnd>>1) - 1) XOR RoundKeyB[0];
+ w[1] : bits(32) = w[0] XOR RoundKeyB[1]
+ w[2] : bits(32) = w[1] XOR RoundKeyB[2]
+ w[3] : bits(32) = w[2] XOR RoundKeyB[3]
+ set_velem(vd, EGW=128, i, w[3:0]);
+ }
+ RETIRE_SUCCESS
+ }
+}
+--
+
+Included in::
+<<zvkn>>, <<zvknc>>, <<zvkned>>, <<zvkng>>
+
+<<<
+
+[[insns-vaesz, Vector AES round zero]]
+==== vaesz.vs
+
+Synopsis::
+Vector AES round zero encryption/decryption
+
+Mnemonic::
+vaesz.vs vd, vs2
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '00111'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101001'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+* The `vd` register group overlaps the `vs2` register
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| vd | input | 128 | 4 | 32 | round state
+| vs2 | input | 128 | 4 | 32 | round key
+| vd | output | 128 | 4 | 32 | new round state
+|===
+
+Description::
+A round-0 AES block cipher operation is performed. This operation is used for both encryption and decryption.
+
+There is only a `.vs` form of the instruction.
+`Vs2` holds a
+scalar element group that is used
+as the round key for all of the round state element groups.
+The new round state output of each element group is produced by XORing
+the round key with each element group of `vd`.
+
+This instruction must always be implemented such that its execution latency does not depend
+on the data being operated upon.
+
+[NOTE]
+====
+This instruction is needed to avoid the need to "splat" a 128-bit vector register group when the round key is the same for
+all 128-bit "lanes". Such a splat would typically be implemented with a `vrgather` instruction which would hurt performance
+in many implementations.
+This instruction only exists in the `.vs` form because the `.vv` form would be identical to the `vxor.vv vd, vs2, vd` instruction.
+====
+
+//
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`.
+
+Operation::
+[source,sail]
+--
+function clause execute (VAESZ(vs2, vd) = {
+ if(((vstart%EGS)<>0) | (LMUL*VLEN < EGW)) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ let state : bits(128) = get_velem(vd, EGW=128, i);
+ let rkey : bits(128) = get_velem(vs2, EGW=128, 0);
+ let ark : bits(128) = state ^ rkey;
+ set_velem(vd, EGW=128, i, ark);
+ }
+ RETIRE_SUCCESS
+ }
+}
+--
+
+Included in::
+<<zvkn>>, <<zvknc>>, <<zvkned>>, <<zvkng>>
+
+<<<
+
+[[insns-vandn, Vector And-Not]]
+==== vandn.[vv,vx]
+
+Synopsis::
+Bitwise And-Not
+
+Mnemonic::
+vandn.vv vd, vs2, vs1, vm +
+vandn.vx vd, vs2, rs1, vm
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPIVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '000001'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPIVX'},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '000001'},
+]}
+....
+
+Vector-Vector Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs1 | input | Op1 (to be inverted)
+| Vs2 | input | Op2
+| Vd | output | Result
+|===
+
+Vector-Scalar Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Rs1 | input | Op1 (to be inverted)
+| Vs2 | input | Op2
+| Vd | output | Result
+|===
+
+Description::
+A bitwise _and-not_ operation is performed.
+
+Each bit of `Op1` is inverted and logically ANDed with the corresponding bits in `vs2`.
+In the vector-scalar version, `Op1` is the sign-extended or truncated value in scalar
+register `rs1`.
+In the vector-vector version, `Op1` is `vs1`.
+
+// This instruction must always be implemented such that its execution latency does not depend
+// on the data being operated upon.
+
+[NOTE]
+.Note on necessity of instruction
+====
+This instruction is performance-critical to SHA3. Specifically, the Chi step of the FIPS 202 Keccak Permutation.
+Emulating it via 2 instructions is expected to have significant performance impact.
+The `.vv` form of the instruction is what is needed for SHA3; the `.vx` form was added for completeness.
+====
+
+[NOTE]
+====
+There is no .vi version of this instruction because the same functionality can be achieved by using an inversion
+of the immediate value with the `vand.vi` instruction.
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (VANDN(vs2, vs1, vd, suffix)) = {
+ foreach (i from vstart to vl-1) {
+ let op1 = match suffix {
+ "vv" => get_velem(vs1, SEW, i),
+ "vx" => sext_or_truncate_to_sew(X(vs1))
+ };
+ let op2 = get_velem(vs2, SEW, i);
+ set_velem(vd, EEW=SEW, i, ~op1 & op2);
+ }
+ RETIRE_SUCCESS
+}
+
+--
+
+Included in::
+<<zvbb>>, <<zvkb>>, <<zvkn>>, <<zvknc>>, <<Zvkng>>, <<zvks>>
+<<Zvksc>>, <<Zvksg>>
+
+<<<
+
+[[insns-vbrev, Vector Reverse Bits in Elements]]
+==== vbrev.v
+
+Synopsis::
+Vector Reverse Bits in Elements
+
+Mnemonic::
+vbrev.v vd, vs2, vm
+
+Encoding (Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '01010'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010010'},
+]}
+....
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs2 | input | Input elements
+| Vd | output | Elements with bits reversed
+|===
+
+Description::
+A bit reversal is performed on the bits of each element.
+
+Operation::
+[source,sail]
+--
+function clause execute (VBREV(vs2)) = {
+
+ foreach (i from vstart to vl-1) {
+ let input = get_velem(vs2, SEW, i);
+ let output : bits(SEW) = 0;
+ foreach (i from 0 to SEW-1)
+ let output[SEW-1-i] = input[i];
+ set_velem(vd, SEW, i, output)
+ }
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+<<zvbb>>
+
+<<<
+
+[[insns-vbrev8, Vector Reverse Bits in Bytes]]
+==== vbrev8.v
+
+Synopsis::
+Vector Reverse Bits in Bytes
+
+Mnemonic::
+vbrev8.v vd, vs2, vm
+
+Encoding (Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '01000'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010010'},
+]}
+....
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs2 | input | Input elements
+| Vd | output | Elements with bit-reversed bytes
+|===
+
+Description::
+A bit reversal is performed on the bits of each byte.
+
+// This instruction must always be implemented such that its execution latency does not depend
+// on the data being operated upon.
+
+[NOTE]
+====
+This instruction is commonly used for GCM when the zvkg extension is not implemented.
+This byte-wise instruction is defined for all SEWs to eliminate the need to change SEW when operating on wider elements.
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (VBREV8(vs2)) = {
+
+ foreach (i from vstart to vl-1) {
+ let input = get_velem(vs2, SEW, i);
+ let output : bits(SEW) = 0;
+ foreach (i from 0 to SEW-8 by 8)
+ let output[i+7..i] = reverse_bits_in_byte(input[i+7..i]);
+ set_velem(vd, SEW, i, output)
+ }
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+<<zvbb>>, <<zvkb>>, <<zvkn>>, <<zvknc>>, <<Zvkng>>, <<zvks>>
+<<Zvksc>>, <<Zvksg>>
+
+<<<
+
+[[insns-vclmul, Vector Carry-less Multiply]]
+==== vclmul.[vv,vx]
+
+Synopsis::
+Vector Carry-less Multiply by vector or scalar - returning low half of product.
+
+Mnemonic::
+vclmul.vv vd, vs2, vs1, vm +
+vclmul.vx vd, vs2, rs1, vm
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '001100'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVX'},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '001100'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 64
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs1/Rs1 | input | multiplier
+| Vs2 | input | multiplicand
+| Vd | output | carry-less product low
+|===
+
+Description::
+Produces the low half of 128-bit carry-less product.
+
+Each 64-bit element in the `vs2` vector register is carry-less multiplied by
+either each 64-bit element in `vs1` (vector-vector), or the 64-bit value
+from integer register `rs1` (vector-scalar). The result is the least
+significant 64 bits of the carry-less product.
+
+[NOTE]
+====
+The 64-bit carryless multiply instructions can be used for implementing GCM in the absence of the `zvkg` extension.
+We do not make these instructions exclusive as the 64-bit carryless multiply is readily derived from the
+instructions in the `zvkg` extension and can have utility in other areas.
+Likewise, we treat other SEW values as reserved so as not to preclude
+future extensions from using this opcode with different element widths.
+For example, a future extension might define an `SEW`=32 version of this instruction to enable `Zve32*` implementations to have
+vector carryless multiplication instructions.
+====
+
+Operation::
+[source,sail]
+--
+
+
+function clause execute (VCLMUL(vs2, vs1, vd, suffix)) = {
+
+ foreach (i from vstart to vl-1) {
+ let op1 : bits (64) = if suffix =="vv" then get_velem(vs1,i)
+ else zext_or_truncate_to_sew(X(vs1));
+ let op2 : bits (64) = get_velem(vs2,i);
+ let product : bits (64) = clmul(op1,op2,SEW);
+ set_velem(vd, i, product);
+ }
+ RETIRE_SUCCESS
+}
+
+function clmul(x, y, width) = {
+ let result : bits(width) = zeros();
+ foreach (i from 0 to (width - 1)) {
+ if y[i] == 1 then result = result ^ (x << i);
+ }
+ result
+}
+--
+
+Included in::
+<<zvbc>>, <<zvknc>>, <<zvksc>>
+
+<<<
+
+[[insns-vclmulh, Vector Carry-less Multiply Return High Half]]
+==== vclmulh.[vv,vx]
+
+Synopsis::
+Vector Carry-less Multiply by vector or scalar - returning high half of product.
+
+Mnemonic::
+vclmulh.vv vd, vs2, vs1, vm +
+vclmulh.vx vd, vs2, rs1, vm
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '001101'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVX'},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '001101'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 64
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs1 | input | multiplier
+| Vs2 | input | multiplicand
+| Vd | output | carry-less product high
+|===
+
+Description::
+Produces the high half of 128-bit carry-less product.
+
+Each 64-bit element in the `vs2` vector register is carry-less multiplied by
+either each 64-bit element in `vs1` (vector-vector), or the 64-bit value
+from integer register `rs1` (vector-scalar). The result is the most
+significant 64 bits of the carry-less product.
+
+// This instruction must always be implemented such that its execution latency does not depend
+// on the data being operated upon.
+
+Operation::
+[source,sail]
+--
+function clause execute (VCLMULH(vs2, vs1, vd, suffix)) = {
+
+ foreach (i from vstart to vl-1) {
+ let op1 : bits (64) = if suffix =="vv" then get_velem(vs1,i)
+ else zext_or_truncate_to_sew(X(vs1));
+ let op2 : bits (64) = get_velem(vs2, i);
+ let product : bits (64) = clmulh(op1, op2, SEW);
+ set_velem(vd, i, product);
+ }
+ RETIRE_SUCCESS
+}
+
+function clmulh(x, y, width) = {
+ let result : bits(width) = 0;
+ foreach (i from 1 to (width - 1)) {
+ if y[i] == 1 then result = result ^ (x >> (width - i));
+ }
+ result
+}
+
+--
+
+Included in::
+<<zvbc>>, <<zvknc>>, <<zvksc>>
+
+<<<
+
+[[insns-vclz, Vector Count Leading Zeros]]
+==== vclz.v
+
+Synopsis::
+Vector Count Leading Zeros
+
+Mnemonic::
+vclz.v vd, vs2, vm
+
+Encoding (Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '01100'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010010'},
+]}
+....
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs2 | input | Input elements
+| Vd | output | Count of leading zero bits
+|===
+
+Description::
+A leading zero count is performed on each element.
+
+The result for zero-valued inputs is the value SEW.
+
+Operation::
+[source,sail]
+--
+function clause execute (VCLZ(vs2)) = {
+
+ foreach (i from vstart to vl-1) {
+ let input = get_velem(vs2, SEW, i);
+ for (j = (SEW - 1); j >= 0; j--)
+ if [input[j]] == 0b1 then break;
+ set_velem(vd, SEW, i, SEW - 1 - j)
+ }
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+<<zvbb>>
+
+[[insns-vcpop, Vector Population Count]]
+==== vcpop.v
+
+Synopsis::
+Count the number of bits set in each element
+
+Mnemonic::
+vcpop.v vd, vs2, vm
+
+Encoding (Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '01110'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010010'},
+]}
+....
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs2 | input | Input elements
+| Vd | output | Count of bits set
+|===
+
+Description::
+A population count is performed on each element.
+
+Operation::
+[source,sail]
+--
+function clause execute (VCPOP(vs2)) = {
+
+ foreach (i from vstart to vl-1) {
+ let input = get_velem(vs2, SEW, i);
+ let output : bits(SEW) = 0;
+ for (j = 0; j < SEW; j++)
+ output = output + input[j];
+ set_velem(vd, SEW, i, output)
+ }
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+<<zvbb>>
+
+[[insns-vctz, Vector Count Trailing Zeros]]
+==== vctz.v
+
+Synopsis::
+Vector Count Trailing Zeros
+
+Mnemonic::
+vctz.v vd, vs2, vm
+
+Encoding (Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '01101'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010010'},
+]}
+....
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs2 | input | Input elements
+| Vd | output | Count of trailing zero bits
+|===
+
+Description::
+A trailing zero count is performed on each element.
+
+// The result for zero-valued inputs is the value SEW.
+
+Operation::
+[source,sail]
+--
+function clause execute (VCTZ(vs2)) = {
+
+ foreach (i from vstart to vl-1) {
+ let input = get_velem(vs2, SEW, i);
+ for (j = 0; j < SEW; j++)
+ if [input[j]] == 0b1 then break;
+ set_velem(vd, SEW, i, j)
+ }
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+<<zvbb>>
+
+<<<
+
+[[insns-vghsh, Vector GHASH Add-Multiply]]
+==== vghsh.vv
+
+Synopsis::
+Vector Add-Multiply over GHASH Galois-Field
+
+Mnemonic::
+vghsh.vv vd, vs2, vs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101100'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|SEW
+|Definition
+
+| Vd | input | 128 | 4 | 32 | Partial hash (Y~i~)
+| Vs1 | input | 128 | 4 | 32 | Cipher text (X~i~)
+| Vs2 | input | 128 | 4 | 32 | Hash Subkey (H)
+| Vd | output | 128 | 4 | 32 | Partial-hash (Y~i+1~)
+|===
+
+Description::
+A single "iteration" of the GHASH~H~ algorithm is performed.
+
+This instruction treats all of the inputs and outputs as 128-bit polynomials and
+performs operations over GF[2].
+It produces the next partial hash (Y~i+1~) by adding the current partial
+hash (Y~i~) to the cipher text block (X~i~) and then multiplying (over GF(2^128^))
+this sum by the Hash Subkey (H).
+
+The multiplication over GF(2^128^) is a carryless multiply of two 128-bit polynomials
+modulo GHASH's irreducible polynomial (x^128^ + x^7^ + x^2^ + x + 1).
+
+The operation can be compactly defined as
+// Y~i+1~ = (Y~i~ &#183; H) ^ X~i~
+Y~i+1~ = ((Y~i~ ^ X~i~) &#183; H)
+
+The NIST specification (see <<zvkg>>) orders the coefficients from left to right x~0~x~1~x~2~...x~127~
+for a polynomial x~0~ + x~1~u +x~2~ u^2^ + ... + x~127~u^127^. This can be viewed as a collection of
+byte elements in memory with the byte containing the lowest coefficients (i.e., 0,1,2,3,4,5,6,7)
+residing at the lowest memory address. Since the bits in the bytes are reversed,
+this instruction internally performs bit swaps within bytes to put the bits in the standard ordering
+(e.g., 7,6,5,4,3,2,1,0).
+
+This instruction must always be implemented such that its execution latency does not depend
+on the data being operated upon.
+
+[NOTE]
+====
+We are bit-reversing the bytes of inputs and outputs so that the intermediate values are consistent
+with the NIST specification. These reversals are inexpensive to implement as they unconditionally
+swap bit positions and therefore do not require any logic.
+====
+
+[NOTE]
+====
+Since the same hash subkey `H` will typically be used repeatedly on a given message,
+a future extension might define a vector-scalar version of this instruction where
+`vs2` is the scalar element group. This would help reduce register pressure when `LMUL` > 1.
+====
+
+Operation::
+[source,pseudocode]
+--
+function clause execute (VGHSH(vs2, vs1, vd)) = {
+ // operands are input with bits reversed in each byte
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ let Y = (get_velem(vd,EGW=128,i)); // current partial-hash
+ let X = get_velem(vs1,EGW=128,i); // block cipher output
+ let H = brev8(get_velem(vs2,EGW=128,i)); // Hash subkey
+
+ let Z : bits(128) = 0;
+
+ let S = brev8(Y ^ X);
+
+ for (int bit = 0; bit < 128; bit++) {
+ if bit_to_bool(S[bit])
+ Z ^= H
+
+ bool reduce = bit_to_bool(H[127]);
+ H = H << 1; // left shift H by 1
+ if (reduce)
+ H ^= 0x87; // Reduce using x^7 + x^2 + x^1 + 1 polynomial
+ }
+
+ let result = brev8(Z); // bit reverse bytes to get back to GCM standard ordering
+ set_velem(vd, EGW=128, i, result);
+ }
+ RETIRE_SUCCESS
+ }
+}
+--
+
+Included in::
+<<zvkg>>, <<zvkng>>, <<zvksg>>
+
+<<<
+
+[[insns-vgmul, Vector GHASH Multiply]]
+==== vgmul.vv
+
+Synopsis::
+Vector Multiply over GHASH Galois-Field
+
+Mnemonic::
+vgmul.vv vd, vs2
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '10001'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101000'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|SEW
+|Definition
+
+| Vd | input | 128 | 4 | 32 | Multiplier
+| Vs2 | input | 128 | 4 | 32 | Multiplicand
+| Vd | output | 128 | 4 | 32 | Product
+|===
+
+Description::
+A GHASH~H~ multiply is performed.
+
+This instruction treats all of the inputs and outputs as 128-bit polynomials and
+performs operations over GF[2].
+It produces the product over GF(2^128^) of the two 128-bit inputs.
+
+The multiplication over GF(2^128^) is a carryless multiply of two 128-bit polynomials
+modulo GHASH's irreducible polynomial (x^128^ + x^7^ + x^2^ + x + 1).
+
+The NIST specification (see <<zvkg>>) orders the coefficients from left to right x~0~x~1~x~2~...x~127~
+for a polynomial x~0~ + x~1~u +x~2~ u^2^ + ... + x~127~u^127^. This can be viewed as a collection of
+byte elements in memory with the byte containing the lowest coefficients (i.e., 0,1,2,3,4,5,6,7)
+residing at the lowest memory address. Since the bits in the bytes are reversed,
+This instruction internally performs bit swaps within bytes to put the bits in the standard ordering
+(e.g., 7,6,5,4,3,2,1,0).
+
+This instruction must always be implemented such that its execution latency does not depend
+on the data being operated upon.
+
+[NOTE]
+====
+We are bit-reversing the bytes of inputs and outputs so that the intermediate values are consistent
+with the NIST specification. These reversals are inexpensive to implement as they unconditionally
+swap bit positions and therefore do not require any logic.
+====
+
+[NOTE]
+====
+Since the same multiplicand will typically be used repeatedly on a given message,
+a future extension might define a vector-scalar version of this instruction where
+`vs2` is the scalar element group. This would help reduce register pressure when `LMUL` > 1.
+====
+
+[NOTE]
+====
+This instruction is identical to `vghsh.vv` with vs1=0.
+This instruction is often used in GHASH code. In some cases it is followed
+by an XOR to perform a multiply-add. Implementations may choose to fuse these
+two instructions to improve performance on GHASH code that
+doesn't use the add-multiply form of the `vghsh.vv` instruction.
+====
+
+
+Operation::
+[source,pseudocode]
+--
+function clause execute (VGMUL(vs2, vs1, vd)) = {
+ // operands are input with bits reversed in each byte
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ let Y = brev8(get_velem(vd,EGW=128,i)); // Multiplier
+ let H = brev8(get_velem(vs2,EGW=128,i)); // Multiplicand
+ let Z : bits(128) = 0;
+
+ for (int bit = 0; bit < 128; bit++) {
+ if bit_to_bool(Y[bit])
+ Z ^= H
+
+ bool reduce = bit_to_bool(H[127]);
+ H = H << 1; // left shift H by 1
+ if (reduce)
+ H ^= 0x87; // Reduce using x^7 + x^2 + x^1 + 1 polynomial
+ }
+
+
+ let result = brev8(Z);
+ set_velem(vd, EGW=128, i, result);
+ }
+ RETIRE_SUCCESS
+ }
+}
+--
+
+Included in::
+<<zvkg>>, <<zvkng>>, <<zvksg>>
+
+<<<
+
+[[insns-vrev8, Vector Reverse Bytes]]
+==== vrev8.v
+
+Synopsis::
+Vector Reverse Bytes
+
+Mnemonic::
+vrev8.v vd, vs2, vm
+
+Encoding (Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '01001'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010010'},
+]}
+....
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs2 | input | Input elements
+| Vd | output | Byte-reversed elements
+|===
+
+Description::
+A byte reversal is performed on each element of `vs2`, effectively performing an endian swap.
+
+// This instruction must always be implemented such that its execution latency does not depend
+// on the data being operated upon.
+
+[NOTE]
+====
+This element-wise endian swapping is needed for several cryptographic algorithms including SHA2 and SM3.
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (VREV8(vs2)) = {
+ foreach (i from vstart to vl-1) {
+ input = get_velem(vs2, SEW, i);
+ let output : SEW = 0;
+ let j = SEW - 1;
+ foreach (k from 0 to (SEW - 8) by 8) {
+ output[k..(k + 7)] = input[(j - 7)..j];
+ j = j - 8;
+ set_velem(vd, SEW, i, output)
+ }
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+<<zvbb>>, <<zvkb>>, <<zvkn>>, <<zvknc>>, <<Zvkng>>, <<zvks>>
+<<Zvksc>>, <<Zvksg>>
+
+<<<
+
+[[insns-vrol, Vector Rotate Left]]
+==== vrol.[vv,vx]
+
+Synopsis::
+Vector rotate left by vector/scalar.
+
+Mnemonic::
+vrol.vv vd, vs2, vs1, vm +
+vrol.vx vd, vs2, rs1, vm +
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPIVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010101'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPIVX'},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010101'},
+]}
+....
+
+Vector-Vector Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs1 | input | Rotate amount
+| Vs2 | input | Data
+| Vd | output | Rotated data
+|===
+
+Vector-Scalar Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Rs1 | input | Rotate amount
+| Vs2 | input | Data
+| Vd | output | Rotated data
+|===
+
+Description::
+A bitwise left rotation is performed on each element of `vs2`
+
+The elements in `vs2` are rotated left by the rotate amount specified by either
+the corresponding elements of `vs1` (vector-vector), or integer register `rs1`
+(vector-scalar).
+Only the low log2(`SEW`) bits of the rotate-amount value are used, all other
+bits are ignored.
+
+// This instruction must always be implemented such that its execution latency does not depend
+// on the data being operated upon.
+
+[NOTE]
+====
+There is no immediate form of this instruction (i.e., `vrol.vi`) as the same result can be achieved by negating
+the rotate amount and using the immediate form of rotate right instruction (i.e., vror.vi).
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (VROL_VV(vs2, vs1, vd)) = {
+ foreach (i from vstart to vl - 1) {
+ set_velem(vd, EEW=SEW, i,
+ get_velem(vs2, i) <<< (get_velem(vs1, i) & (SEW-1))
+ )
+ }
+ RETIRE_SUCCESS
+}
+
+function clause execute (VROL_VX(vs2, rs1, vd)) = {
+ foreach (i from vstart to vl - 1) {
+ set_velem(vd, EEW=SEW, i,
+ get_velem(vs2, i) <<< (X(rs1) & (SEW-1))
+ )
+ }
+ RETIRE_SUCCESS
+}
+
+--
+
+Included in::
+<<zvbb>>, <<zvkb>>, <<zvkn>>, <<zvknc>>, <<Zvkng>>, <<zvks>>
+<<Zvksc>>, <<Zvksg>>
+
+<<<
+
+[[insns-vror, Vector Rotate Right]]
+==== vror.[vv,vx,vi]
+
+Synopsis::
+Vector rotate right by vector/scalar/immediate.
+
+Mnemonic::
+vror.vv vd, vs2, vs1, vm +
+vror.vx vd, vs2, rs1, vm +
+vror.vi vd, vs2, uimm, vm
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPIVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010100'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPIVX'},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '010100'},
+]}
+....
+
+Encoding (Vector-Immediate)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPIVI'},
+{bits: 5, name: 'uimm[4:0]'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 1, name: 'i5'},
+{bits: 5, name: '01010'},
+]}
+....
+
+Vector-Vector Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs1 | input | Rotate amount
+| Vs2 | input | Data
+| Vd | output | Rotated data
+|===
+
+Vector-Scalar/Immediate Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Rs1/imm | input | Rotate amount
+| Vs2 | input | Data
+| Vd | output | Rotated data
+|===
+
+
+Description::
+A bitwise right rotation is performed on each element of `vs2`.
+
+The elements in `vs2` are rotated right by the rotate amount specified by either
+the corresponding elements of `vs1` (vector-vector), integer register `rs1`
+(vector-scalar), or an immediate value (vector-immediate).
+Only the low log2(`SEW`) bits of the rotate-amount value are used, all other
+bits are ignored.
+
+// This instruction must always be implemented such that its execution latency does not depend
+// on the data being operated upon.
+
+Operation::
+[source,sail]
+--
+function clause execute (VROR_VV(vs2, vs1, vd)) = {
+ foreach (i from vstart to vl - 1) {
+ set_velem(vd, EEW=SEW, i,
+ get_velem(vs2, i) >>> (get_velem(vs1, i) & (SEW-1))
+ )
+ }
+ RETIRE_SUCCESS
+}
+
+function clause execute (VROR_VX(vs2, rs1, vd)) = {
+ foreach (i from vstart to vl - 1) {
+ set_velem(vd, EEW=SEW, i,
+ get_velem(vs2, i) >>> (X(rs1) & (SEW-1))
+ )
+ }
+ RETIRE_SUCCESS
+}
+
+function clause execute (VROR_VI(vs2, uimm[5:0], vd)) = {
+ foreach (i from vstart to vl - 1) {
+ set_velem(vd, EEW=SEW, i,
+ get_velem(vs2, i) >>> (uimm[5:0] & (SEW-1))
+ )
+ }
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+<<zvbb>>, <<zvkb>>, <<zvkn>>, <<zvknc>>, <<Zvkng>>, <<zvks>>
+<<Zvksc>>, <<Zvksg>>
+
+<<<
+
+[[insns-vsha2c, Vector SHA-2 Compression]]
+==== vsha2c[hl].vv
+
+Synopsis::
+Vector SHA-2 two rounds of compression.
+
+Mnemonic::
+vsha2ch.vv vd, vs2, vs1 +
+vsha2cl.vv vd, vs2, vs1
+
+Encoding (Vector-Vector) High part::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101110'},
+]}
+....
+
+Encoding (Vector-Vector) Low part::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101111'},
+]}
+....
+Reserved Encodings::
+* `zvknha`: `SEW` is any value other than 32
+* `zvknhb`: `SEW` is any value other than 32 or 64
+* The `vd` register group overlaps with either `vs1` or `vs2`
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| Vd | input | 4*SEW | 4 | SEW | current state {c, d, g, h}
+| Vs1 | input | 4*SEW | 4 | SEW | MessageSched plus constant[3:0]
+| Vs2 | input | 4*SEW | 4 | SEW | current state {a, b, e, f}
+| Vd | output | 4*SEW | 4 | SEW | next state {a, b, e, f}
+|===
+
+Description::
+- `SEW`=32: 2 rounds of SHA-256 compression are performed (`zvknha` and `zvknhb`)
+- `SEW`=64: 2 rounds of SHA-512 compression are performed (`zvkhnb`)
+
+Two words of `vs1` are processed with
+the 8 words of current state held in `vd` and `vs2` to perform two
+rounds of hash computation producing four words of the
+next state.
+
+
+// These instructions take in two SEW words _W1_ and _W0_ which are the next two words of the message
+// schedule incremented by the appropriate constant (see
+// link:https://doi.org/10.6028/NIST.FIPS.180-4[FIPS PUB 180-4 Secure Hash Standard (SHS)])
+// and eight SEW word variables: _a_, _b_, _c_, _d_, _e_, _f_, _g,_ and _h_. The
+// output is the new values of _a, b, e_ and _f_ after performing 2 rounds of the hash
+// computation. The new values, _c_, _d_, _g_, and _h_, are equal to the input values for _a_, _b_, // _e_, _f_ respectively.
+
+// [NOTE]
+// .Note to software developers
+// ====
+// The MessageSchedplus constant input to this instruction is generated by Software
+// increment each message schedule word by the corresponding
+// round constant as defined in the NIST specification (see <<zvknh>>).
+// ====
+
+[NOTE]
+.Note to software developers
+====
+The NIST standard (see <<zvknh>>) requires the final hash to be in big-endian byte ordering
+within SEW-sized words. Since this instruction treats all words as little-endian,
+software needs to perform an endian swap on the final output of this instruction
+after all of the message blocks have been processed.
+====
+
+[NOTE]
+====
+The `vsha2ch` version of this instruction uses the two most significant message schedule
+words from the element group in `vs1`
+while the `vsha2cl` version uses the two least significant message schedule words.
+Otherwise, these versions of the instruction are identical.
+Having a high and low version of this instruction typically improves performance when
+interleaving independent hashing operations (i.e., when hashing several files at once).
+====
+
+// [NOTE]
+// .Note to software developers
+// ====
+// These instructions take in two SEW words _W1_ and _W0_ which are the next two words of the message
+// schedule incremented by the appropriate constant,
+// and eight SEW word variables: _a_, _b_, _c_, _d_, _e_, _f_, _g,_ and _h_. The
+// output is the new values of _a, b, e_ and _f_ after performing 2 rounds of the hash
+// computation. The new values, _c_, _d_, _g_, and _h_, are equal to the input values for _a_, _b_, _e_, _f_ respectively.
+// ====
+
+// [NOTE]
+// ====
+// Between executions this instruction it is helpful to swap the register _specifiers_ for
+// `vd` and `vs2`. This is because the first instruction's `vd` next state output
+// (_a_, _b_, _e_, _f_)
+// becomes the second instruction's `vs2` current state input (_a_, _b_, _e_, _f_).
+// Likewise the first instruction's `vs2` input (_a_, _b_, _e_, _f_) "ages" to
+// becomes the second instruction's `vd` current state input of (_c_, _d_, _g_, _h_).
+// ====
+
+
+[NOTE]
+====
+Preventing overlap between `vd` and `vs1` or `vs2` simplifies implementation with `VLEN < EGW`.
+This restriction does not have any coding impact since proper implementation of the algorithm requires
+that `vd`, `vs1` and `vs2` each are different registers.
+====
+
+
+
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`.
+
+Operation::
+[source,sail]
+--
+function clause execute (VSHA2c(vs2, vs1, vd)) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ let {a @ b @ e @ f} : bits(4*SEW) = get_velem(vs2, 4*SEW, i);
+ let {c @ d @ g @ h} : bits(4*SEW) = get_velem(vd, 4*SEW, i);
+ let MessageShedPlusC[3:0] : bits(4*SEW) = get_velem(vs1, 4*SEW, i);
+ let {W1, W0} == VSHA2cl ? MessageSchedPlusC[1:0] : MessageSchedPlusC[3:2]; // l vs h difference is the words selected
+
+ let T1 : bits(SEW) = h + sum1(e) + ch(e,f,g) + W0;
+ let T2 : bits(SEW) = sum0(a) + maj(a,b,c);
+ h = g;
+ g = f;
+ f = e;
+ e = d + T1;
+ d = c;
+ c = b;
+ b = a;
+ a = T1 + T2;
+
+
+ T1 = h + sum1(e) + ch(e,f,g) + W1;
+ T2 = sum0(a) + maj(a,b,c);
+ h = g;
+ g = f;
+ f = e;
+ e = d + T1;
+ d = c;
+ c = b;
+ b = a;
+ a = T1 + T2;
+ set_velem(vd, 4*SEW, i, {a @ b @ e @ f});
+ }
+ RETIRE_SUCCESS
+ }
+}
+
+function sum0(x) = {
+ match SEW {
+ 32 => rotr(x,2) XOR rotr(x,13) XOR rotr(x,22),
+ 64 => rotr(x,28) XOR rotr(x,34) XOR rotr(x,39)
+ }
+}
+
+function sum1(x) = {
+ match SEW {
+ 32 => rotr(x,6) XOR rotr(x,11) XOR rotr(x,25),
+ 64 => rotr(x,14) XOR rotr(x,18) XOR rotr(x,41)
+ }
+}
+
+function ch(x, y, z) = ((x & y) ^ ((~x) & z))
+
+
+function maj(x, y, z) = ((x & y) ^ (x & z) ^ (y & z))
+
+function ROTR(x,n) = (x >> n) | (x << SEW - n)
+
+--
+
+Included in::
+<<zvkn>>, <<zvknc>>, <<zvkng>>, <<zvknh, zvknh[ab]>>
+
+<<<
+
+[[insns-vsha2ms, Vector SHA-2 Message Schedule]]
+==== vsha2ms.vv
+
+Synopsis::
+Vector SHA-2 message schedule.
+
+Mnemonic::
+vsha2ms.vv vd, vs2, vs1
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101101'},
+]}
+....
+Reserved Encodings::
+* `zvknha`: `SEW` is any value other than 32
+* `zvknhb`: `SEW` is any value other than 32 or 64
+* The `vd` register group overlaps with either `vs1` or `vs2`
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| Vd | input | 4*SEW | 4 | SEW | Message words {W[3], W[2], W[1], W[0]}
+| Vs2 | input | 4*SEW | 4 | SEW | Message words {W[11], W[10], W[9], W[4]}
+| Vs1 | input | 4*SEW | 4 | SEW | Message words {W[15], W[14], -, W[12]}
+| Vd | output | 4*SEW | 4 | SEW | Message words {W[19], W[18], W[17], W[16]}
+|===
+
+Description::
+- `SEW`=32: Four rounds of SHA-256 message schedule expansion are performed (`zvknha` and `zvknhb`)
+- `SEW`=64: Four rounds of SHA-512 message schedule expansion are performed (`zvkhnb`)
+
+Eleven of the last 16 `SEW`-sized message-schedule words from `vd` (oldest), `vs2`,
+and `vs1` (most recent) are processed to produce the
+next 4 message-schedule words.
+
+[NOTE]
+.Note to software developers
+====
+The first 16 SEW-sized words of the message schedule come from the _message block_
+in big-endian byte order. Since this instruction treats all words as little endian,
+software is required to endian swap these words.
+
+All of the subsequent message schedule words are produced by this instruction and
+therefore do not require an endian swap.
+====
+
+[NOTE]
+.Note to software developers
+====
+Software is required to pack the words into element groups
+as shown above in the arguments table. The indices indicate the relate age with
+lower indices indicating older words.
+====
+// [NOTE]
+// ====
+// W~13~ is not used by the instruction.
+// ====
+
+// Four `SEW` message schedule words are packed into each element group of the
+// source and destination registers. From a vector register point of view,
+// the message schedule words are packed into the
+// element groups from the left to the right with the most significant word on the left
+// and the least significant word on the right.
+
+// `{W~3~, W~2~, W~1~, W~0~} +
+// {W~7~, W~6~, W~5~, W~4~} +
+// {W~11~, W~10~, W~9~, W~8~} +
+// {W~15~, W~14~, W~13~, W~12~}`
+
+// Since W~5~ through W~8~ are not needed in these calculations, we are able to compact these into
+// three element groups
+//
+// `{W~3~, W~2~, W~1~, W~0~} +
+// {W~11~, W~10~, W~9~, W~4~} +
+// {W~15~, W~14~, W~13~, W~12~}`
+
+[NOTE]
+.Note to software developers
+====
+The {W~11~, W~10~, W~9~, W~4~} element group can easily be formed by using a vector
+vmerge instruction with the appropriate mask (for example with `vl=4` and `4b0001`
+as the 4 mask bits)
+
+`vmerge.vvm {W~11~, W~10~, W~9~, W~4~}, {W~11~, W~10~, W~9~, W~8~}, {W~7~, W~6~, W~5~, W~4~}, V0`
+====
+
+// The number of words to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`
+
+[NOTE]
+====
+Preventing overlap between `vd` and `vs1` or `vs2` simplifies implementation with `VLEN < EGW`.
+This restriction does not have any coding impact since proper implementation of the algorithm requires
+that `vd`, `vs1` and `vs2` each contain different portions of the message schedule.
+====
+
+// This instruction is not masked. If any element groups are not to be processed, the _vl_
+// must be set accordingly. It is not possible to skip an intermediary element group.
+// `VLMUL` must be at least 1. In typical usage it is expected to be 1.
+// There are three source operands: `vd`, `vs1` and `vs2`. The result
+// is written to `vd`.
+
+// NB:: for implementations with `VLEN < EGW`, the minimal `VLMUL` is `EGW / VLEN`.
+
+// In this code the input elements are numbered from 0 (16 words ago) to 15 (most recent message-schedule word).
+// The outputs are numbered from 16 to 19.
+
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`.
+
+Operation::
+[source,sail]
+--
+function clause execute (VSHA2ms(vs2, vs1, vd)) = {
+ // SEW32 = SHA-256
+ // SEW64 = SHA-512
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ {W[3] @ W[2] @ W[1] @ W[0]} : bits(EGW) = get_velem(vd, EGW, i);
+ {W[11] @ W[10] @ W[9] @ W[4]} : bits(EGW) = get_velem(vs2, EGW, i);
+ {W[15] @ W[14] @ W[13] @ W[12]} : bits(EGW) = get_velem(vs1, EGW, i);
+
+ W[16] = sig1(W[14]) + W[9] + sig0(W[1]) + W[0];
+ W[17] = sig1(W[15]) + W[10] + sig0(W[2]) + W[1];
+ W[18] = sig1(W[16]) + W[11] + sig0(W[3]) + W[2];
+ W[19] = sig1(W[17]) + W[12] + sig0(W[4]) + W[3];
+
+ set_velem(vd, EGW, i, {W[19] @ W[18] @ W[17] @ W[16]});
+ }
+ RETIRE_SUCCESS
+ }
+}
+
+function sig0(x) = {
+ match SEW {
+ 32 => (ROTR(x,7) XOR ROTR(x,18) XOR SHR(x,3)),
+ 64 => (ROTR(x,1) XOR ROTR(x,8) XOR SHR(x,7)));
+ }
+}
+
+function sig1(x) = {
+ match SEW {
+ 32 => (ROTR(x,17) XOR ROTR(x,19) XOR SHR(x,10),
+ 64 => ROTR(x,19) XOR ROTR(x,61) XOR SHR(x,6));
+ }
+}
+
+function ROTR(x,n) = (x >> n) | (x << SEW - n)
+function SHR (x,n) = x >> n
+
+--
+
+Included in::
+ <<zvkn>>, <<zvknc>>, <<zvkng>>, <<zvknh, zvknh[ab]>>
+
+<<<
+
+[[insns-vsm3c, SM3 Compression]]
+==== vsm3c.vi
+
+Synopsis::
+Vector SM3 Compression
+
+Mnemonic::
+vsm3c.vi vd, vs2, uimm
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'uimm'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101011'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+* The `vd` register group overlaps with the `vs2` register group
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| Vd | input | 256 | 8 | 32 | Current state {H,G.F,E,D,C,B,A}
+| uimm | input | - | - | - | round number (rnds)
+| Vs2 | input | 256 | 8 | 32 | Message words {-,-,w[5],w[4],-,-,w[1],w[0]}
+| Vd | output | 256 | 8 | 32 | Next state {H,G.F,E,D,C,B,A}
+|===
+
+Description::
+Two rounds of SM3 compression are performed.
+
+The current state of eight 32-bit words is read in as an element group from `vd`. Eight 32-bit
+message words are read in as an element group from `vs2`, although only four of them are used.
+All of the 32-bit input words are byte-swapped from big endian to little endian.
+These inputs are processed somewhat differently based on the round group (as specified in rnds),
+and the next state is generated as an element group of eight 32-bit words.
+The next state of eight 32-bit words are generated,
+swapped from little endian to big endian, and are returned in
+an eight-element group.
+
+The round number is provided by the 5-bit `rnds` unsigned immediate. Legal values are 0 - 31
+and indicate which group of two rounds are being performed. For example, if rnds=1,
+then rounds 2 and 3 are being performed.
+
+[NOTE]
+====
+The round number is used in the rotation of the constant as well to inform the
+behavior which differs between rounds 0-15 and rounds 16-63.
+====
+
+[NOTE]
+====
+The endian byte swapping of the input and output words enables us to align with the SM3
+specification without requiring that software perform these swaps.
+====
+
+[NOTE]
+====
+Preventing overlap between `vd` and `vs2` simplifies implementation with `VLEN < EGW`.
+This restriction does not have any coding impact since proper implementation of the algorithm requires
+that `vd` and `vs2` each are different registers.
+====
+
+// The elements are listed here in the order they appear in the register, with the most significant
+// element on the left, and the least significant on the right.
+
+// vs2 = {w[7], w[6], w[5], w[4], w[3], w[2], w[1], w[0]}
+
+// The values consumed by the instruction are
+
+// vs2 = {- , - , w[5], w[4], -, -, w[1], w[0]}
+
+// Where the "-" characters are not consumed and are therefore don't cares.
+
+// This instruction consumes the "W" message schedule inputs and internally generates the "W'" values as needed
+
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=8`. +
+// Likewise, `vstart` must be a multiple of `EGS=8`.
+
+Operation::
+[source,sail]
+--
+function clause execute (VSM3C(rnds, vs2, vd)) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+
+ // load state
+ let {Hi @ Gi @ Fi @ Ei @ Di @ Ci @ Bi @ Ai} : bits(256) : bits(256) = (get_velem(vd, 256, i));
+ //load message schedule
+ let {u_w7 @ u_w6 @ w5i @ w4i @ u_w3 @ u_w2 @ w1i @ w0i} : bits(256) = (get_velem(vs2, 256, i));
+ // u_w inputs are unused
+
+// perform endian swap
+let H : bits(32) = rev8(Hi);
+let G : bits(32) = rev8(Gi);
+let F : bits(32) = rev8(Fi);
+let E : bits(32) = rev8(Ei);
+let D : bits(32) = rev8(Di);
+let C : bits(32) = rev8(Ci);
+let B : bits(32) = rev8(Bi);
+let A : bits(32) = rev8(Ai);
+
+let w5 = : bits(32) rev8(w5i);
+let w4 = : bits(32) rev8(w4i);
+let w1 = : bits(32) rev8(w1i);
+let w0 = : bits(32) rev8(w0i);
+
+let x0 :bits(32) = w0 ^ w4; // W'[0]
+let x1 :bits(32) = w1 ^ w5; // W'[1]
+
+let j = 2 * rnds;
+let ss1 : bits(32) = ROL32(ROL32(A, 12) + E + ROL32(T_j(j), j % 32), 7);
+let ss2 : bits(32) = ss1 ^ ROL32(A, 12);
+let tt1 : bits(32) = FF_j(A, B, C, j) + D + ss2 + x0;
+let tt2 : bits(32) = GG_j(E, F, G, j) + H + ss1 + w0;
+D = C;
+let : bits(32) C1 = ROL32(B, 9);
+B = A;
+let A1 : bits(32) = tt1;
+H = G;
+let G1 : bits(32) = ROL32(F, 19);
+F = E;
+let E1 : bits(32) = P_0(tt2);
+
+j = 2 * rnds + 1;
+ss1 = ROL32(ROL32(A1, 12) + E1 + ROL32(T_j(j), j % 32), 7);
+ss2 = ss1 ^ ROL32(A1, 12);
+tt1 = FF_j(A1, B, C1, j) + D + ss2 + x1;
+tt2 = GG_j(E1, F, G1, j) + H + ss1 + w1;
+D = C1;
+let C2 : bits(32) = ROL32(B, 9);
+B = A1;
+let A2 : bits(32) = tt1;
+H = G1;
+let G2 = : bits(32) ROL32(F, 19);
+F = E1;
+let E2 = : bits(32) P_0(tt2);
+
+// Update the destination register - swap back to big endian
+let result : bits(256) = {rev8(G1) @ rev8(G2) @ rev8(E1) @ rev8(E2) @ rev8(C1) @ rev8(C2) @ rev8(A1) @ rev8(A2)};
+set_velem(vd, 256, i, result);
+ }
+
+RETIRE_SUCCESS
+ }
+}
+
+function FF1(X, Y, Z) = ((X) ^ (Y) ^ (Z))
+function FF2(X, Y, Z) = (((X) & (Y)) | ((X) & (Z)) | ((Y) & (Z)))
+
+function FF_j(X, Y, Z, J) = (((J) <= 15) ? FF1(X, Y, Z) : FF2(X, Y, Z))
+
+function GG1(X, Y, Z) = ((X) ^ (Y) ^ (Z))
+function GG2(X, Y, Z) = (((X) & (Y)) | ((~(X)) & (Z)))
+.
+function GG_j(X, Y, Z, J) = (((J) <= 15) ? GG1(X, Y, Z) : GG2(X, Y, Z))
+
+function T_j(J) = (((J) <= 15) ? (0x79CC4519) : (0x7A879D8A))
+
+function P_0(X) = ((X) ^ ROL32((X), 9) ^ ROL32((X), 17))
+
+--
+
+Included in::
+<<zvks>>, <<zvksc>>, <<zvksg>>, <<zvksh>>
+
+<<<
+
+[[insns-vsm3me, SM3 Message Expansion]]
+==== vsm3me.vv
+
+Synopsis::
+Vector SM3 Message Expansion
+
+Mnemonic::
+vsm3me.vv vd, vs2, vs1
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '100000'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+* The `vd` register group overlaps with the `vs2` register group.
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| Vs1 | input | 256 | 8 | 32 | Message words W[7:0]
+| Vs2 | input | 256 | 8 | 32 | Message words W[15:8]
+| Vd | output | 256 | 8 | 32 | Message words W[23:16]
+|===
+
+Description::
+Eight rounds of SM3 message expansion are performed.
+
+
+The sixteen most recent 32-bit message words are read in as two
+eight-element groups from `vs1` and `vs2`. Each of these words is
+swapped from big endian to little endian.
+The next eight 32-bit message words are generated,
+swapped from little endian to big endian, and are returned in
+an eight-element group.
+
+[NOTE]
+====
+The endian byte swapping of the input and output words enables us to align with the SM3
+specification without requiring that software perform these swaps.
+====
+
+// NOTE
+// ====
+// For the best performance, it is recommended that implementations have VLEN{ge}256.
+// When VLEN<EGW, an appropriate LMUL needs to be used by software so that elements from the
+// specified register groups can be combined to form the full element group.
+// ====
+
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=8`. +
+// Likewise, `vstart` must be a multiple of `EGS=8`.
+
+[NOTE]
+====
+Preventing overlap between `vd` and `vs2` simplifies implementations with `VLEN < EGW`.
+This restriction should not have any coding impact since the algorithm requires these
+values to be preserved for generating the next 8 words.
+====
+
+Operation::
+[source,sail]
+--
+function clause execute (VSM3ME(vs2, vs1)) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ foreach (i from eg_start to eg_len-1) {
+ let w[7:0] : bits(256) = get_velem(vs1, 256, i);
+ let w[15:8] : bits(256) = get_velem(vs2, 256, i);
+
+ // Byte Swap inputs from big-endian to little-endian
+ let w15 = rev8(w[15]);
+ let w14 = rev8(w[14]);
+ let w13 = rev8(w[13]);
+ let w12 = rev8(w[12]);
+ let w11 = rev8(w[11]);
+ let w10 = rev8(w[10]);
+ let w9 = rev8(w[9]);
+ let w8 = rev8(w[8]);
+ let w7 = rev8(w[7]);
+ let w6 = rev8(w[6]);
+ let w5 = rev8(w[5]);
+ let w4 = rev8(w[4]);
+ let w3 = rev8(w[3]);
+ let w2 = rev8(w[2]);
+ let w1 = rev8(w[1]);
+ let w0 = rev8(w[0]);
+
+ // Note that some of the newly computed words are used in later invocations.
+ let w[16] = ZVKSH_W(w0 @ w7 @ w13 @ w3 @ w10);
+ let w[17] = ZVKSH_W(w1 @ w8 @ w14 @ w4 @ w11);
+ let w[18] = ZVKSH_W(w2 @ w9 @ w15 @ w5 @ w12);
+ let w[19] = ZVKSH_W(w3 @ w10 @ w16 @ w6 @ w13);
+ let w[20] = ZVKSH_W(w4 @ w11 @ w17 @ w7 @ w14);
+ let w[21] = ZVKSH_W(w5 @ w12 @ w18 @ w8 @ w15);
+ let w[22] = ZVKSH_W(w6 @ w13 @ w19 @ w9 @ w16);
+ let w[23] = ZVKSH_W(w7 @ w14 @ w20 @ w10 @ w17);
+
+ // Byte swap outputs from little-endian back to big-endian
+ let w16 : Bits(32) = rev8(W[16]);
+ let w17 : Bits(32) = rev8(W[17]);
+ let w18 : Bits(32) = rev8(W[18]);
+ let w19 : Bits(32) = rev8(W[19]);
+ let w20 : Bits(32) = rev8(W[20]);
+ let w21 : Bits(32) = rev8(W[21]);
+ let w22 : Bits(32) = rev8(W[22]);
+ let w23 : Bits(32) = rev8(W[23]);
+
+
+ // Update the destination register.
+ set_velem(vd, 256, i, {w23 @ w22 @ w21 @ w20 @ w19 @ w18 @ w17 @ w16});
+ }
+ RETIRE_SUCCESS
+ }
+}
+
+ function P_1(X) ((X) ^ ROL32((X), 15) ^ ROL32((X), 23))
+
+ function ZVKSH_W(M16, M9, M3, M13, M6) = \
+ (P1( (M16) ^ (M9) ^ ROL32((M3), 15) ) ^ ROL32((M13), 7) ^ (M6))
+--
+
+Included in::
+<<zvks>>, <<zvksc>>, <<zvksg>>, <<zvksh>>
+
+<<<
+
+[[insns-vsm4k, Vector SM4 Key Expansion]]
+==== vsm4k.vi
+
+Synopsis::
+Vector SM4 KeyExpansion
+
+Mnemonic::
+vsm4k.vi vd, vs2, uimm
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: 'uimm'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '100001'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| uimm | input | - | - | - | Round group (rnd)
+| Vs2 | input | 128 | 4 | 32 | Current 4 round keys rK[0:3]
+| Vd | output | 128 | 4 | 32 | Next 4 round keys rK'[0:3]
+|===
+
+Description::
+Four rounds of the SM4 Key Expansion are performed.
+
+Four round keys are read in as a 4-element group from `vs2`. Each of the next four round keys are generated
+by iteratively XORing the last three round keys with a constant that is indexed by the Round Group Number,
+performing a byte-wise substitution, and then performing XORs between rotated versions of this value
+and the corresponding current round key.
+
+The Round group number (`rnd`) comes from `uimm[2:0]`; the bits in `uimm[4:3]` are ignored.
+Round group numbers range from 0 to 7 and indicate which
+group of four round keys are being generated. Round Keys range from 0-31.
+For example, if `rnd`=1, then round keys 4, 5, 6, and 7 are being generated.
+
+// vs2 = {rK[i-4], rK[i-3],rK[i-2], rK[i-1]} // last 4 round keys
+// rnd = 0 to 7; // group of 4 rounds
+// vd (out) = {rK[i], rK[i+1],rK[i+2], rK[i+3]} // next 4 rounds keys
+
+// Each of the 32 rounds consumes the last 4 32-bit keys along with a round constant and
+// produces the next 32-bit key.
+
+
+[NOTE]
+====
+Software needs to generate the initial round keys. This is done by XORing the 128-bit encryption key with
+the system parameters: FK[0:3]
+====
+
+.System Parameters
+[%autowidth]
+[%header,cols="^2,^2"]
+|===
+|FK
+|constant
+
+| 0 | A3B1BAC6
+| 1 | 56AA3350
+| 2 | 677D9197
+| 3 | B27022DC
+|===
+
+
+////
+.System Parameters
+[%autowidth]
+[%header,cols="^2,^2"]
+|===
+|FK
+|constant
+
+| 0 | A3B1BAC6
+| 1 | 56AA3350
+| 2 | 677D9197
+| 3 | B27022DC
+|===
+////
+
+// MK = {MK[0], MK[1], MK[2], MK[3]} // Encryption Key
+// rK[-4,-1] = K[0:3] = MK[0:3] ^ FK[0:3]
+
+
+// The round keys are rK[0] to rK[31]
+// B = (rK[i-3] XOR rK[i-2] XOR rK[i-1] XOR CK[round]); +
+// S = subBytes(B); +
+// rK[i]= rK[i-4] XOR S XOR ROTL13(S) XOR ROTR23(S); +
+//
+// The round constants and the S-box are described below and can be found at https://datatracker.ietf.org/doc/id/// draft-crypto-sm4-00
+
+[NOTE]
+====
+Implementation Hint
+
+The round constants (CK) can be generated on the fly fairly cheaply.
+If the bytes of the constants are assigned an incrementing index from 0 to 127, the value of each byte is equal to its index multiplied by 7 modulo 256.
+Since the results are all limited to 8 bits, the modulo operation occurs for free:
+
+ B[n] = n + 2n + 4n;
+ = 8n + ~n + 1;
+====
+
+// This instruction only returns the generated keys to the same element group as the source.
+// If it is desired to have the same key in all vector groups, either the input vector groups
+// need to contain the same values, or the output from a particular group needs to be "broadcast"
+// to the other groups using an instruction such as vrgather.
+
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`.
+
+////
+.System Parameters
+[%autowidth]
+[%header,cols="^2,^2"]
+|===
+|FK
+|constant
+
+| 0 | A3B1BAC6
+| 1 | 56AA3350
+| 2 | 677D9197
+| 3 | B27022DC
+|===
+////
+
+Operation::
+[source,sail]
+--
+
+function clause execute (vsm4k(uimm, vs2)) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ let B : bits(32) = 0;
+ let S : bits(32) = 0;
+ let rk4 : bits(32) = 0;
+ let rk5 : bits(32) = 0;
+ let rk6 : bits(32) = 0;
+ let rk7 : bits(32) = 0;
+ let rnd : bits(3) = uimm[2:0]; // Lower 3 bits
+
+ foreach (i from eg_start to eg_len-1) {
+ let (rk3 @ rk2 @ rk1 @ rk0) : bits(128) = get_velem(vs2, 128, i);
+
+ B = rk1 ^ rk2 ^ rk3 ^ ck(4 * rnd);
+ S = sm4_subword(B);
+ rk4 = ROUND_KEY(rk0, S);
+
+ B = rk2 ^ rk3 ^ rk4 ^ ck(4 * rnd + 1);
+ S = sm4_subword(B);
+ rk5 = ROUND_KEY(rk1, S);
+
+ B = rk3 ^ rk4 ^ rk5 ^ ck(4 * rnd + 2);
+ S = sm4_subword(B);
+ rk6 = ROUND_KEY(rk2, S);
+
+ B = rk4 ^ rk5 ^ rk6 ^ ck(4 * rnd + 3);
+ S = sm4_subword(B);
+ rk7 = ROUND_KEY(rk3, S);
+
+ // Update the destination register.
+ set_velem(vd, EGW=128, i, (rk7 @ rk6 @ rk5 @ rk4));
+ }
+ RETIRE_SUCCESS
+ }
+}
+
+val round_key : bits(32) -> bits(32)
+function ROUND_KEY(X, S) = ((X) ^ ((S) ^ ROL32((S), 13) ^ ROL32((S), 23)))
+
+// SM4 Constant Key (CK)
+let ck : list(bits(32)) = [|
+ 0x00070E15, 0x1C232A31, 0x383F464D, 0x545B6269,
+ 0x70777E85, 0x8C939AA1, 0xA8AFB6BD, 0xC4CBD2D9,
+ 0xE0E7EEF5, 0xFC030A11, 0x181F262D, 0x343B4249,
+ 0x50575E65, 0x6C737A81, 0x888F969D, 0xA4ABB2B9,
+ 0xC0C7CED5, 0xDCE3EAF1, 0xF8FF060D, 0x141B2229,
+ 0x30373E45, 0x4C535A61, 0x686F767D, 0x848B9299,
+ 0xA0A7AEB5, 0xBCC3CAD1, 0xD8DFE6ED, 0xF4FB0209,
+ 0x10171E25, 0x2C333A41, 0x484F565D, 0x646B7279
+ |]
+};
+
+
+--
+
+Included in::
+<<zvks>>, <<zvksc>>, <<zvksed>>, <<zvksg>>
+
+<<<
+
+[[insns-vsm4r, SM4 Block Cipher Rounds]]
+==== vsm4r.[vv,vs]
+
+Synopsis::
+Vector SM4 Rounds
+
+Mnemonic::
+vsm4r.vv vd, vs2 +
+vsm4r.vs vd, vs2
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '10000'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101000'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-VE'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPMVV'},
+{bits: 5, name: '10000'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: '1'},
+{bits: 6, name: '101001'},
+]}
+....
+Reserved Encodings::
+* `SEW` is any value other than 32
+* Only for the `.vs` form: the `vd` register group overlaps the `vs2` register
+
+Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2,2,2"]
+|===
+|Register
+|Direction
+|EGW
+|EGS
+|EEW
+|Definition
+
+| Vd | input | 128 | 4 | 32 | Current state X[0:3]
+| Vs2 | input | 128 | 4 | 32 | Round keys rk[0:3]
+| Vd | output | 128 | 4 | 32 | Next state X'[0:3]
+|===
+
+Description::
+Four rounds of SM4 Encryption/Decryption are performed.
+
+The four words of current state are read as a 4-element group from 'vd'
+and the round keys are read from either the corresponding 4-element group
+in `vs2` (vector-vector form) or the scalar element group in `vs2`
+(vector-scalar form).
+The next four words of state are generated
+by iteratively XORing the last three words of the state with
+the corresponding round key, performing
+a byte-wise substitution, and then performing XORs between rotated
+versions of this value and the corresponding current state.
+
+[NOTE]
+====
+In SM4, encryption and decryption are identical except that decryption consumes the round keys in the reverse order.
+====
+
+[NOTE]
+====
+For the first four rounds of encryption, the _current state_ is the plain text.
+For the first four rounds of decryption, the _current state_ is the cipher text.
+For all subsequent rounds, the _current state_ is the _next state_ from the
+previous four rounds.
+====
+
+// The number of element groups to be processed is `vl`/`EGS`.
+// `vl` must be set to the number of `SEW=32` elements to be processed and
+// therefore must be a multiple of `EGS=4`. +
+// Likewise, `vstart` must be a multiple of `EGS=4`.
+
+Operation::
+[source,pseudocode]
+--
+function clause execute (VSM4R(vd, vs2)) = {
+ if(LMUL*VLEN < EGW) then {
+ handle_illegal(); // illegal-instruction exception
+ RETIRE_FAIL
+ } else {
+
+ eg_len = (vl/EGS)
+ eg_start = (vstart/EGS)
+
+ let B : bits(32) = 0;
+ let S : bits(32) = 0;
+ let rk0 : bits(32) = 0;
+ let rk1 : bits(32) = 0;
+ let rk2 : bits(32) = 0;
+ let rk3 : bits(32) = 0;
+ let x0 : bits(32) = 0;
+ let x1 : bits(32) = 0;
+ let x2 : bits(32) = 0;
+ let x3 : bits(32) = 0;
+ let x4 : bits(32) = 0;
+ let x5 : bits(32) = 0;
+ let x6 : bits(32) = 0;
+ let x7 : bits(32) = 0;
+
+ let keyelem : bits(32) = 0;
+
+ foreach (i from eg_start to eg_len-1) {
+ keyelem = if suffix == "vv" then i else 0;
+ {rk3 @ rk2 @ rk1 @ rk0} : bits(128) = get_velem(vs2, EGW=128, keyelem);
+ {x3 @ x2 @ x1 @ x0} : bits(128) = get_velem(vd, EGW=128, i);
+
+ B = x1 ^ x2 ^ x3 ^ rk0;
+ S = sm4_subword(B);
+ x4 = sm4_round(x0, S);
+
+ B = x2 ^ x3 ^ x4 ^ rk1;
+ S = sm4_subword(B);
+ x5= sm4_round(x1, S);
+
+ B = x3 ^ x4 ^ x5 ^ rk2;
+ S = sm4_subword(B);
+ x6 = sm4_round(x2, S);
+
+ B = x4 ^ x5 ^ x6 ^ rk3;
+ S = sm4_subword(B);
+ x7 = sm4_round(x3, S);
+
+ set_velem(vd, EGW=128, i, (x7 @ x6 @ x5 @ x4));
+
+ }
+ RETIRE_SUCCESS
+ }
+}
+
+val sm4_round : bits(32) -> bits(32)
+function sm4_round(X, S) = \
+ ((X) ^ ((S) ^ ROL32((S), 2) ^ ROL32((S), 10) ^ ROL32((S), 18) ^ ROL32((S), 24)))
+
+--
+
+Included in::
+<<zvks>>, <<zvksc>>, <<zvksed>>, <<zvksg>>
+
+<<<
+
+[[insns-vwsll, Vector Widening Shift Left Logical]]
+==== vwsll.[vv,vx,vi]
+
+Synopsis::
+Vector widening shift left logical by vector/scalar/immediate.
+
+Mnemonic::
+vwsll.vv vd, vs2, vs1, vm +
+vwsll.vx vd, vs2, rs1, vm +
+vwsll.vi vd, vs2, uimm, vm
+
+Encoding (Vector-Vector)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPIVV'},
+{bits: 5, name: 'vs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '110101'},
+]}
+....
+
+Encoding (Vector-Scalar)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPIVX'},
+{bits: 5, name: 'rs1'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '110101'},
+]}
+....
+
+Encoding (Vector-Immediate)::
+[wavedrom, , svg]
+....
+{reg:[
+{bits: 7, name: 'OP-V'},
+{bits: 5, name: 'vd'},
+{bits: 3, name: 'OPIVI'},
+{bits: 5, name: 'uimm[4:0]'},
+{bits: 5, name: 'vs2'},
+{bits: 1, name: 'vm'},
+{bits: 6, name: '110101'},
+]}
+....
+
+Vector-Vector Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2"]
+|===
+|Register
+|Direction
+|Definition
+
+| Vs1 | input | Shift amount
+| Vs2 | input | Data
+| Vd | output | Shifted data
+|===
+
+Vector-Scalar/Immediate Arguments::
+
+[%autowidth]
+[%header,cols="4,2,2,2"]
+|===
+|Register
+|Direction
+|EEW
+|Definition
+
+| Rs1/imm | input | SEW | Shift amount
+| Vs2 | input | SEW | Data
+| Vd | output | 2*SEW | Shifted data
+|===
+
+
+Description::
+A widening logical shift left is performed on each element of `vs2`.
+
+The elements in `vs2` are zero-extended to 2*`SEW` bits, then shifted left
+by the shift amount specified by either
+the corresponding elements of `vs1` (vector-vector), integer register `rs1`
+(vector-scalar), or an immediate value (vector-immediate).
+Only the low log2(2*`SEW`) bits of the shift-amount value are used, all other
+bits are ignored.
+
+Operation::
+[source,sail]
+--
+function clause execute (VWSLL_VV(vs2, vs1, vd)) = {
+ foreach (i from vstart to vl - 1) {
+ set_velem(vd, EEW=2*SEW, i,
+ get_velem(vs2, i) << (get_velem(vs1, i) & ((2*SEW)-1))
+ )
+ }
+ RETIRE_SUCCESS
+}
+
+function clause execute (VWSLL_VX(vs2, rs1, vd)) = {
+ foreach (i from vstart to vl - 1) {
+ set_velem(vd, EEW=2*SEW, i,
+ get_velem(vs2, i) << (X(rs1) & ((2*SEW)-1))
+ )
+ }
+ RETIRE_SUCCESS
+}
+
+function clause execute (VWSLL_VI(vs2, uimm[4:0], vd)) = {
+ foreach (i from vstart to vl - 1) {
+ set_velem(vd, EEW=2*SEW, i,
+ get_velem(vs2, i) << (uimm[4:0] & ((2*SEW)-1))
+ )
+ }
+ RETIRE_SUCCESS
+}
+--
+
+Included in::
+<<zvbb>>
+
+<<<
+
+
+[[crypto_vector_instructions]]
+=== Crypto Vector Cryptographic Instructions
+
+OP-VE (0x77)
+Crypto Vector instructions except Zvbb and Zvbc
+
+// [cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+[cols="4,1,1,1,1,4,1,1,1,4,1,1,1"]
+|===
+5+^|Integer 4+^|Integer 4+^| FP
+
+| funct3 | | | | | funct3 | | | | funct3 | | |
+| OPIVV |V| | | | OPMVV |V| | | OPFVV |V| |
+| OPIVX | |X| | | OPMVX | |X| | OPFVF | |F|
+| OPIVI | | |I| | | | | | | | |
+|===
+
+// [cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+[cols="6,1,1,1,1,6,1,1,6,6,1,1,1"]
+
+|===
+5+^| funct6 4+^| funct6 4+^| funct6
+
+|100000||||| 100000 |V| | vsm3me | 100000 | | |
+| 100001 | | | | | 100001 |V| | vsm4k.vi | 100001 | | |
+| 100010 | | | | | 100010 |V| | vaeskf1.vi | 100010 | | |
+| 100011 | | | | | 100011 | | | | 100011 | | |
+| 100100 | | | | | 100100 | | | | 100100 | | |
+| 100101 | | | | | 100101 | | | | 100101 | | |
+| 100110 | | | | | 100110 | | | | 100110 | | |
+| 100111 | | | | | 100111 | | | | 100111 | | |
+| | | | | | | | | | | | |
+| 101000 | | | | | 101000 |V| | *VAES.vv* | 101000 | | |
+| 101001 | | | | | 101001 |V| | *VAES.vs* | 101001 | | |
+| 101010 | | | | | 101010 |V| | vaeskf2.vi | 101010 | | |
+| 101011 | | | | | 101011 |V| | vsm3c.vi | 101011 | | |
+| 101100 | | | | | 101100 |V| | vghsh | 101100 | | |
+| 101101 | | | | | 101101 |V| | vsha2ms | 101101 | | |
+| 101110 | | | | | 101110 |V| | vsha2ch | 101110 | | |
+| 101111 | | | | | 101111 |V| | vsha2cl | 101111 | | |
+|===
+
+<<<
+
+.VAES.vv and VAES.vs encoding space
+[cols="2,14"]
+|===
+|vs1|
+
+| 00000 | vaesdm
+| 00001 | vaesdf
+| 00010 | vaesem
+| 00011 | vaesef
+| 00111 | vaesz
+| 10000 | vsm4r
+| 10001 | vgmul
+|===
+
+[[crypto_vector_instructions_Zvbb_Zvbc]]
+=== Vector Bitmanip and Carryless Multiply Instructions
+
+OP-V (0x57)
+*Zvbb*, *Zvkb*, and *Zvbc* Vector instructions *in bold*
+//[%auto-width]
+[%autowidth,cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+|===
+5+| Integer 4+| Integer 4+| FP
+
+| funct3 | | | | | funct3 | | | | funct3 | | |
+| OPIVV |V| | | | OPMVV |V| | | OPFVV |V| |
+| OPIVX | |X| | | OPMVX | |X| | OPFVF | |F|
+| OPIVI | | |I| | | | | | | | |
+|===
+
+//[%auto-width]
+[%autowidth,cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+|===
+5+| funct6 4+| funct6 4+| funct6
+
+| 000000 |V|X|I| vadd | 000000 |V| | vredsum | 000000 |V|F| vfadd
+| 000001 |V|X| | *vandn* | 000001 |V| | vredand | 000001 |V| | vfredusum
+| 000010 |V|X| | vsub | 000010 |V| | vredor | 000010 |V|F| vfsub
+| 000011 | |X|I| vrsub | 000011 |V| | vredxor | 000011 |V| | vfredosum
+| 000100 |V|X| | vminu | 000100 |V| | vredminu | 000100 |V|F| vfmin
+| 000101 |V|X| | vmin | 000101 |V| | vredmin | 000101 |V| | vfredmin
+| 000110 |V|X| | vmaxu | 000110 |V| | vredmaxu | 000110 |V|F| vfmax
+| 000111 |V|X| | vmax | 000111 |V| | vredmax | 000111 |V| | vfredmax
+| 001000 | | | | | 001000 |V|X| vaaddu | 001000 |V|F| vfsgnj
+| 001001 |V|X|I| vand | 001001 |V|X| vaadd | 001001 |V|F| vfsgnjn
+| 001010 |V|X|I| vor | 001010 |V|X| vasubu | 001010 |V|F| vfsgnjx
+| 001011 |V|X|I| vxor | 001011 |V|X| vasub | 001011 | | |
+| 001100 |V|X|I| vrgather | 001100 |V|X| *vclmul* | 001100 | | |
+| 001101 | | | | | 001101 |V|X| *vclmulh* | 001101 | | |
+| 001110 | |X|I| vslideup | 001110 | |X| vslide1up | 001110 | |F| vfslide1up
+| 001110 |V| | | vrgatherei16| | | | | | | |
+| 001111 | |X|I| vslidedown | 001111 | |X| vslide1down | 001111 | |F| vfslide1down
+|===
+
+[%autowidth,cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+|===
+5+| funct6 4+| funct6 4+| funct6
+
+| 010000 |V|X|I| vadc | 010000 |V| | VWXUNARY0 | 010000 |V| | VWFUNARY0
+| | | | | | 010000 | |X| VRXUNARY0 | 010000 | |F| VRFUNARY0
+| 010001 |V|X|I| vmadc | 010001 | | | | 010001 | | |
+| 010010 |V|X| | vsbc | 010010 |V| | VXUNARY0 | 010010 |V| | VFUNARY0
+| 010011 |V|X| | vmsbc | 010011 | | | | 010011 |V| | VFUNARY1
+| 010100 |V|X| | *vror* | 010100 |V| | VMUNARY0 | 010100 | | |
+| 010101 |V|X| | *vrol* | 010101 | | | | 010101 | | |
+| 01010x | | |I| *vror* | | | | | | | |
+| 010110 | | | | | 010110 | | | | 010110 | | |
+| 010111 |V|X|I| vmerge/vmv | 010111 |V| | vcompress | 010111 | |F| vfmerge/vfmv
+| 011000 |V|X|I| vmseq | 011000 |V| | vmandn | 011000 |V|F| vmfeq
+| 011001 |V|X|I| vmsne | 011001 |V| | vmand | 011001 |V|F| vmfle
+| 011010 |V|X| | vmsltu | 011010 |V| | vmor | 011010 | | |
+| 011011 |V|X| | vmslt | 011011 |V| | vmxor | 011011 |V|F| vmflt
+| 011100 |V|X|I| vmsleu | 011100 |V| | vmorn | 011100 |V|F| vmfne
+| 011101 |V|X|I| vmsle | 011101 |V| | vmnand | 011101 | |F| vmfgt
+| 011110 | |X|I| vmsgtu | 011110 |V| | vmnor | 011110 | | |
+| 011111 | |X|I| vmsgt | 011111 |V| | vmxnor | 011111 | |F| vmfge
+|===
+
+[%autowidth,cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+|===
+5+| funct6 4+| funct6 4+| funct6
+
+| 100000 |V|X|I| vsaddu | 100000 |V|X| vdivu | 100000 |V|F| vfdiv
+| 100001 |V|X|I| vsadd | 100001 |V|X| vdiv | 100001 | |F| vfrdiv
+| 100010 |V|X| | vssubu | 100010 |V|X| vremu | 100010 | | |
+| 100011 |V|X| | vssub | 100011 |V|X| vrem | 100011 | | |
+| 100100 | | | | | 100100 |V|X| vmulhu | 100100 |V|F| vfmul
+| 100101 |V|X|I| vsll | 100101 |V|X| vmul | 100101 | | |
+| 100110 | | | | | 100110 |V|X| vmulhsu | 100110 | | |
+| 100111 |V|X| | vsmul | 100111 |V|X| vmulh | 100111 | |F| vfrsub
+| | | |I| vmv<nr>r | | | | | | | |
+| 101000 |V|X|I| vsrl | 101000 | | | | 101000 |V|F| vfmadd
+| 101001 |V|X|I| vsra | 101001 |V|X| vmadd | 101001 |V|F| vfnmadd
+| 101010 |V|X|I| vssrl | 101010 | | | | 101010 |V|F| vfmsub
+| 101011 |V|X|I| vssra | 101011 |V|X| vnmsub | 101011 |V|F| vfnmsub
+| 101100 |V|X|I| vnsrl | 101100 | | | | 101100 |V|F| vfmacc
+| 101101 |V|X|I| vnsra | 101101 |V|X| vmacc | 101101 |V|F| vfnmacc
+| 101110 |V|X|I| vnclipu | 101110 | | | | 101110 |V|F| vfmsac
+| 101111 |V|X|I| vnclip | 101111 |V|X| vnmsac | 101111 |V|F| vfnmsac
+|===
+
+[%autowidth,cols="4,1,1,1,8,4,1,1,8,4,1,1,8"]
+|===
+5+| funct6 4+| funct6 4+| funct6
+
+| 110000 |V| | | vwredsumu | 110000 |V|X| vwaddu | 110000 |V|F| vfwadd
+| 110001 |V| | | vwredsum | 110001 |V|X| vwadd | 110001 |V| | vfwredusum
+| 110010 | | | | | 110010 |V|X| vwsubu | 110010 |V|F| vfwsub
+| 110011 | | | | | 110011 |V|X| vwsub | 110011 |V| | vfwredosum
+| 110100 | | | | | 110100 |V|X| vwaddu.w | 110100 |V|F| vfwadd.w
+| 110101 |V|X|I| *vwsll* | 110101 |V|X| vwadd.w | 110101 | | |
+| 110110 | | | | | 110110 |V|X| vwsubu.w | 110110 |V|F| vfwsub.w
+| 110111 | | | | | 110111 |V|X| vwsub.w | 110111 | | |
+| 111000 | | | | | 111000 |V|X| vwmulu | 111000 |V|F| vfwmul
+| 111001 | | | | | 111001 | | | | 111001 | | |
+| 111010 | | | | | 111010 |V|X| vwmulsu | 111010 | | |
+| 111011 | | | | | 111011 |V|X| vwmul | 111011 | | |
+| 111100 | | | | | 111100 |V|X| vwmaccu | 111100 |V|F| vfwmacc
+| 111101 | | | | | 111101 |V|X| vwmacc | 111101 |V|F| vfwnmacc
+| 111110 | | | | | 111110 | |X| vwmaccus | 111110 |V|F| vfwmsac
+| 111111 | | | | | 111111 |V|X| vwmaccsu | 111111 |V|F| vfwnmsac
+|===
+
+<<<
+
+//[%auto-width]
+.VXUNARY0 encoding space
+[%autowidth,cols="2,14"]
+|===
+| vs1 |
+
+| 00010 | vzext.vf8
+| 00011 | vsext.vf8
+| 00100 | vzext.vf4
+| 00101 | vsext.vf4
+| 00110 | vzext.vf2
+| 00111 | vsext.vf2
+| 01000 | *vbrev8*
+| 01001 | *vrev8*
+| 01010 | *vbrev*
+| 01100 | *vclz*
+| 01101 | *vctz*
+| 01110 | *vcpop*
+
+|===
+
+[[crypto_vector_appx_sail]]
+=== Supporting Sail Code
+
+This section contains the supporting Sail code referenced by the
+instruction descriptions throughout the specification.
+The
+link:https://alasdair.github.io/manual.html[Sail Manual]
+is recommended reading in order to best understand the supporting code.
+
+[source,sail]
+----
+/* Auxiliary function for performing GF multiplication */
+val xt2 : bits(8) -> bits(8)
+function xt2(x) = {
+ (x << 1) ^ (if bit_to_bool(x[7]) then 0x1b else 0x00)
+}
+
+val xt3 : bits(8) -> bits(8)
+function xt3(x) = x ^ xt2(x)
+
+/* Multiply 8-bit field element by 4-bit value for AES MixCols step */
+val gfmul : (bits(8), bits(4)) -> bits(8)
+function gfmul( x, y) = {
+ (if bit_to_bool(y[0]) then x else 0x00) ^
+ (if bit_to_bool(y[1]) then xt2( x) else 0x00) ^
+ (if bit_to_bool(y[2]) then xt2(xt2( x)) else 0x00) ^
+ (if bit_to_bool(y[3]) then xt2(xt2(xt2(x))) else 0x00)
+}
+
+/* 8-bit to 32-bit partial AES Mix Column - forwards */
+val aes_mixcolumn_byte_fwd : bits(8) -> bits(32)
+function aes_mixcolumn_byte_fwd(so) = {
+ gfmul(so, 0x3) @ so @ so @ gfmul(so, 0x2)
+}
+
+/* 8-bit to 32-bit partial AES Mix Column - inverse*/
+val aes_mixcolumn_byte_inv : bits(8) -> bits(32)
+function aes_mixcolumn_byte_inv(so) = {
+ gfmul(so, 0xb) @ gfmul(so, 0xd) @ gfmul(so, 0x9) @ gfmul(so, 0xe)
+}
+
+/* 32-bit to 32-bit AES forward MixColumn */
+val aes_mixcolumn_fwd : bits(32) -> bits(32)
+function aes_mixcolumn_fwd(x) = {
+ let s0 : bits (8) = x[ 7.. 0];
+ let s1 : bits (8) = x[15.. 8];
+ let s2 : bits (8) = x[23..16];
+ let s3 : bits (8) = x[31..24];
+ let b0 : bits (8) = xt2(s0) ^ xt3(s1) ^ (s2) ^ (s3);
+ let b1 : bits (8) = (s0) ^ xt2(s1) ^ xt3(s2) ^ (s3);
+ let b2 : bits (8) = (s0) ^ (s1) ^ xt2(s2) ^ xt3(s3);
+ let b3 : bits (8) = xt3(s0) ^ (s1) ^ (s2) ^ xt2(s3);
+ b3 @ b2 @ b1 @ b0 /* Return value */
+}
+
+/* 32-bit to 32-bit AES inverse MixColumn */
+val aes_mixcolumn_inv : bits(32) -> bits(32)
+function aes_mixcolumn_inv(x) = {
+ let s0 : bits (8) = x[ 7.. 0];
+ let s1 : bits (8) = x[15.. 8];
+ let s2 : bits (8) = x[23..16];
+ let s3 : bits (8) = x[31..24];
+ let b0 : bits (8) = gfmul(s0, 0xE) ^ gfmul(s1, 0xB) ^ gfmul(s2, 0xD) ^ gfmul(s3, 0x9);
+ let b1 : bits (8) = gfmul(s0, 0x9) ^ gfmul(s1, 0xE) ^ gfmul(s2, 0xB) ^ gfmul(s3, 0xD);
+ let b2 : bits (8) = gfmul(s0, 0xD) ^ gfmul(s1, 0x9) ^ gfmul(s2, 0xE) ^ gfmul(s3, 0xB);
+ let b3 : bits (8) = gfmul(s0, 0xB) ^ gfmul(s1, 0xD) ^ gfmul(s2, 0x9) ^ gfmul(s3, 0xE);
+ b3 @ b2 @ b1 @ b0 /* Return value */
+}
+
+val aes_decode_rcon : bits(4) -> bits(32)
+function aes_decode_rcon(r) = {
+ match r {
+ 0x0 => 0x00000001,
+ 0x1 => 0x00000002,
+ 0x2 => 0x00000004,
+ 0x3 => 0x00000008,
+ 0x4 => 0x00000010,
+ 0x5 => 0x00000020,
+ 0x6 => 0x00000040,
+ 0x7 => 0x00000080,
+ 0x8 => 0x0000001b,
+ 0x9 => 0x00000036,
+ 0xA => 0x00000000,
+ 0xB => 0x00000000,
+ 0xC => 0x00000000,
+ 0xD => 0x00000000,
+ 0xE => 0x00000000,
+ 0xF => 0x00000000
+ }
+}
+
+/* SM4 SBox - only one sbox for forwards and inverse */
+let sm4_sbox_table : list(bits(8)) = [|
+0xD6, 0x90, 0xE9, 0xFE, 0xCC, 0xE1, 0x3D, 0xB7, 0x16, 0xB6, 0x14, 0xC2, 0x28,
+0xFB, 0x2C, 0x05, 0x2B, 0x67, 0x9A, 0x76, 0x2A, 0xBE, 0x04, 0xC3, 0xAA, 0x44,
+0x13, 0x26, 0x49, 0x86, 0x06, 0x99, 0x9C, 0x42, 0x50, 0xF4, 0x91, 0xEF, 0x98,
+0x7A, 0x33, 0x54, 0x0B, 0x43, 0xED, 0xCF, 0xAC, 0x62, 0xE4, 0xB3, 0x1C, 0xA9,
+0xC9, 0x08, 0xE8, 0x95, 0x80, 0xDF, 0x94, 0xFA, 0x75, 0x8F, 0x3F, 0xA6, 0x47,
+0x07, 0xA7, 0xFC, 0xF3, 0x73, 0x17, 0xBA, 0x83, 0x59, 0x3C, 0x19, 0xE6, 0x85,
+0x4F, 0xA8, 0x68, 0x6B, 0x81, 0xB2, 0x71, 0x64, 0xDA, 0x8B, 0xF8, 0xEB, 0x0F,
+0x4B, 0x70, 0x56, 0x9D, 0x35, 0x1E, 0x24, 0x0E, 0x5E, 0x63, 0x58, 0xD1, 0xA2,
+0x25, 0x22, 0x7C, 0x3B, 0x01, 0x21, 0x78, 0x87, 0xD4, 0x00, 0x46, 0x57, 0x9F,
+0xD3, 0x27, 0x52, 0x4C, 0x36, 0x02, 0xE7, 0xA0, 0xC4, 0xC8, 0x9E, 0xEA, 0xBF,
+0x8A, 0xD2, 0x40, 0xC7, 0x38, 0xB5, 0xA3, 0xF7, 0xF2, 0xCE, 0xF9, 0x61, 0x15,
+0xA1, 0xE0, 0xAE, 0x5D, 0xA4, 0x9B, 0x34, 0x1A, 0x55, 0xAD, 0x93, 0x32, 0x30,
+0xF5, 0x8C, 0xB1, 0xE3, 0x1D, 0xF6, 0xE2, 0x2E, 0x82, 0x66, 0xCA, 0x60, 0xC0,
+0x29, 0x23, 0xAB, 0x0D, 0x53, 0x4E, 0x6F, 0xD5, 0xDB, 0x37, 0x45, 0xDE, 0xFD,
+0x8E, 0x2F, 0x03, 0xFF, 0x6A, 0x72, 0x6D, 0x6C, 0x5B, 0x51, 0x8D, 0x1B, 0xAF,
+0x92, 0xBB, 0xDD, 0xBC, 0x7F, 0x11, 0xD9, 0x5C, 0x41, 0x1F, 0x10, 0x5A, 0xD8,
+0x0A, 0xC1, 0x31, 0x88, 0xA5, 0xCD, 0x7B, 0xBD, 0x2D, 0x74, 0xD0, 0x12, 0xB8,
+0xE5, 0xB4, 0xB0, 0x89, 0x69, 0x97, 0x4A, 0x0C, 0x96, 0x77, 0x7E, 0x65, 0xB9,
+0xF1, 0x09, 0xC5, 0x6E, 0xC6, 0x84, 0x18, 0xF0, 0x7D, 0xEC, 0x3A, 0xDC, 0x4D,
+0x20, 0x79, 0xEE, 0x5F, 0x3E, 0xD7, 0xCB, 0x39, 0x48
+|]
+
+let aes_sbox_fwd_table : list(bits(8)) = [|
+0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5, 0x30, 0x01, 0x67, 0x2b, 0xfe,
+0xd7, 0xab, 0x76, 0xca, 0x82, 0xc9, 0x7d, 0xfa, 0x59, 0x47, 0xf0, 0xad, 0xd4,
+0xa2, 0xaf, 0x9c, 0xa4, 0x72, 0xc0, 0xb7, 0xfd, 0x93, 0x26, 0x36, 0x3f, 0xf7,
+0xcc, 0x34, 0xa5, 0xe5, 0xf1, 0x71, 0xd8, 0x31, 0x15, 0x04, 0xc7, 0x23, 0xc3,
+0x18, 0x96, 0x05, 0x9a, 0x07, 0x12, 0x80, 0xe2, 0xeb, 0x27, 0xb2, 0x75, 0x09,
+0x83, 0x2c, 0x1a, 0x1b, 0x6e, 0x5a, 0xa0, 0x52, 0x3b, 0xd6, 0xb3, 0x29, 0xe3,
+0x2f, 0x84, 0x53, 0xd1, 0x00, 0xed, 0x20, 0xfc, 0xb1, 0x5b, 0x6a, 0xcb, 0xbe,
+0x39, 0x4a, 0x4c, 0x58, 0xcf, 0xd0, 0xef, 0xaa, 0xfb, 0x43, 0x4d, 0x33, 0x85,
+0x45, 0xf9, 0x02, 0x7f, 0x50, 0x3c, 0x9f, 0xa8, 0x51, 0xa3, 0x40, 0x8f, 0x92,
+0x9d, 0x38, 0xf5, 0xbc, 0xb6, 0xda, 0x21, 0x10, 0xff, 0xf3, 0xd2, 0xcd, 0x0c,
+0x13, 0xec, 0x5f, 0x97, 0x44, 0x17, 0xc4, 0xa7, 0x7e, 0x3d, 0x64, 0x5d, 0x19,
+0x73, 0x60, 0x81, 0x4f, 0xdc, 0x22, 0x2a, 0x90, 0x88, 0x46, 0xee, 0xb8, 0x14,
+0xde, 0x5e, 0x0b, 0xdb, 0xe0, 0x32, 0x3a, 0x0a, 0x49, 0x06, 0x24, 0x5c, 0xc2,
+0xd3, 0xac, 0x62, 0x91, 0x95, 0xe4, 0x79, 0xe7, 0xc8, 0x37, 0x6d, 0x8d, 0xd5,
+0x4e, 0xa9, 0x6c, 0x56, 0xf4, 0xea, 0x65, 0x7a, 0xae, 0x08, 0xba, 0x78, 0x25,
+0x2e, 0x1c, 0xa6, 0xb4, 0xc6, 0xe8, 0xdd, 0x74, 0x1f, 0x4b, 0xbd, 0x8b, 0x8a,
+0x70, 0x3e, 0xb5, 0x66, 0x48, 0x03, 0xf6, 0x0e, 0x61, 0x35, 0x57, 0xb9, 0x86,
+0xc1, 0x1d, 0x9e, 0xe1, 0xf8, 0x98, 0x11, 0x69, 0xd9, 0x8e, 0x94, 0x9b, 0x1e,
+0x87, 0xe9, 0xce, 0x55, 0x28, 0xdf, 0x8c, 0xa1, 0x89, 0x0d, 0xbf, 0xe6, 0x42,
+0x68, 0x41, 0x99, 0x2d, 0x0f, 0xb0, 0x54, 0xbb, 0x16
+|]
+
+let aes_sbox_inv_table : list(bits(8)) = [|
+0x52, 0x09, 0x6a, 0xd5, 0x30, 0x36, 0xa5, 0x38, 0xbf, 0x40, 0xa3, 0x9e, 0x81,
+0xf3, 0xd7, 0xfb, 0x7c, 0xe3, 0x39, 0x82, 0x9b, 0x2f, 0xff, 0x87, 0x34, 0x8e,
+0x43, 0x44, 0xc4, 0xde, 0xe9, 0xcb, 0x54, 0x7b, 0x94, 0x32, 0xa6, 0xc2, 0x23,
+0x3d, 0xee, 0x4c, 0x95, 0x0b, 0x42, 0xfa, 0xc3, 0x4e, 0x08, 0x2e, 0xa1, 0x66,
+0x28, 0xd9, 0x24, 0xb2, 0x76, 0x5b, 0xa2, 0x49, 0x6d, 0x8b, 0xd1, 0x25, 0x72,
+0xf8, 0xf6, 0x64, 0x86, 0x68, 0x98, 0x16, 0xd4, 0xa4, 0x5c, 0xcc, 0x5d, 0x65,
+0xb6, 0x92, 0x6c, 0x70, 0x48, 0x50, 0xfd, 0xed, 0xb9, 0xda, 0x5e, 0x15, 0x46,
+0x57, 0xa7, 0x8d, 0x9d, 0x84, 0x90, 0xd8, 0xab, 0x00, 0x8c, 0xbc, 0xd3, 0x0a,
+0xf7, 0xe4, 0x58, 0x05, 0xb8, 0xb3, 0x45, 0x06, 0xd0, 0x2c, 0x1e, 0x8f, 0xca,
+0x3f, 0x0f, 0x02, 0xc1, 0xaf, 0xbd, 0x03, 0x01, 0x13, 0x8a, 0x6b, 0x3a, 0x91,
+0x11, 0x41, 0x4f, 0x67, 0xdc, 0xea, 0x97, 0xf2, 0xcf, 0xce, 0xf0, 0xb4, 0xe6,
+0x73, 0x96, 0xac, 0x74, 0x22, 0xe7, 0xad, 0x35, 0x85, 0xe2, 0xf9, 0x37, 0xe8,
+0x1c, 0x75, 0xdf, 0x6e, 0x47, 0xf1, 0x1a, 0x71, 0x1d, 0x29, 0xc5, 0x89, 0x6f,
+0xb7, 0x62, 0x0e, 0xaa, 0x18, 0xbe, 0x1b, 0xfc, 0x56, 0x3e, 0x4b, 0xc6, 0xd2,
+0x79, 0x20, 0x9a, 0xdb, 0xc0, 0xfe, 0x78, 0xcd, 0x5a, 0xf4, 0x1f, 0xdd, 0xa8,
+0x33, 0x88, 0x07, 0xc7, 0x31, 0xb1, 0x12, 0x10, 0x59, 0x27, 0x80, 0xec, 0x5f,
+0x60, 0x51, 0x7f, 0xa9, 0x19, 0xb5, 0x4a, 0x0d, 0x2d, 0xe5, 0x7a, 0x9f, 0x93,
+0xc9, 0x9c, 0xef, 0xa0, 0xe0, 0x3b, 0x4d, 0xae, 0x2a, 0xf5, 0xb0, 0xc8, 0xeb,
+0xbb, 0x3c, 0x83, 0x53, 0x99, 0x61, 0x17, 0x2b, 0x04, 0x7e, 0xba, 0x77, 0xd6,
+0x26, 0xe1, 0x69, 0x14, 0x63, 0x55, 0x21, 0x0c, 0x7d
+|]
+
+/* Lookup function - takes an index and a list, and retrieves the
+ * x'th element of that list.
+ */
+val sbox_lookup : (bits(8), list(bits(8))) -> bits(8)
+function sbox_lookup(x, table) = {
+ match (x, table) {
+ (0x00, t0::tn) => t0,
+ ( y, t0::tn) => sbox_lookup(x - 0x01, tn)
+ }
+}
+
+/* Easy function to perform a forward AES SBox operation on 1 byte. */
+val aes_sbox_fwd : bits(8) -> bits(8)
+function aes_sbox_fwd(x) = sbox_lookup(x, aes_sbox_fwd_table)
+
+/* Easy function to perform an inverse AES SBox operation on 1 byte. */
+val aes_sbox_inv : bits(8) -> bits(8)
+function aes_sbox_inv(x) = sbox_lookup(x, aes_sbox_inv_table)
+
+/* AES SubWord function used in the key expansion
+ * - Applies the forward sbox to each byte in the input word.
+ */
+val aes_subword_fwd : bits(32) -> bits(32)
+function aes_subword_fwd(x) = {
+ aes_sbox_fwd(x[31..24]) @
+ aes_sbox_fwd(x[23..16]) @
+ aes_sbox_fwd(x[15.. 8]) @
+ aes_sbox_fwd(x[ 7.. 0])
+}
+
+/* AES Inverse SubWord function.
+ * - Applies the inverse sbox to each byte in the input word.
+ */
+val aes_subword_inv : bits(32) -> bits(32)
+function aes_subword_inv(x) = {
+ aes_sbox_inv(x[31..24]) @
+ aes_sbox_inv(x[23..16]) @
+ aes_sbox_inv(x[15.. 8]) @
+ aes_sbox_inv(x[ 7.. 0])
+}
+
+/* Easy function to perform an SM4 SBox operation on 1 byte. */
+val sm4_sbox : bits(8) -> bits(8)
+function sm4_sbox(x) = sbox_lookup(x, sm4_sbox_table)
+
+val aes_get_column : (bits(128), nat) -> bits(32)
+function aes_get_column(state,c) = (state >> (to_bits(7, 32 * c)))[31..0]
+
+/* 64-bit to 64-bit function which applies the AES forward sbox to each byte
+ * in a 64-bit word.
+ */
+val aes_apply_fwd_sbox_to_each_byte : bits(64) -> bits(64)
+function aes_apply_fwd_sbox_to_each_byte(x) = {
+ aes_sbox_fwd(x[63..56]) @
+ aes_sbox_fwd(x[55..48]) @
+ aes_sbox_fwd(x[47..40]) @
+ aes_sbox_fwd(x[39..32]) @
+ aes_sbox_fwd(x[31..24]) @
+ aes_sbox_fwd(x[23..16]) @
+ aes_sbox_fwd(x[15.. 8]) @
+ aes_sbox_fwd(x[ 7.. 0])
+}
+
+/* 64-bit to 64-bit function which applies the AES inverse sbox to each byte
+ * in a 64-bit word.
+ */
+val aes_apply_inv_sbox_to_each_byte : bits(64) -> bits(64)
+function aes_apply_inv_sbox_to_each_byte(x) = {
+ aes_sbox_inv(x[63..56]) @
+ aes_sbox_inv(x[55..48]) @
+ aes_sbox_inv(x[47..40]) @
+ aes_sbox_inv(x[39..32]) @
+ aes_sbox_inv(x[31..24]) @
+ aes_sbox_inv(x[23..16]) @
+ aes_sbox_inv(x[15.. 8]) @
+ aes_sbox_inv(x[ 7.. 0])
+}
+
+/*
+ * AES full-round transformation functions.
+ */
+
+val getbyte : (bits(64), int) -> bits(8)
+function getbyte(x, i) = (x >> to_bits(6, i * 8))[7..0]
+
+val aes_rv64_shiftrows_fwd : (bits(64), bits(64)) -> bits(64)
+function aes_rv64_shiftrows_fwd(rs2, rs1) = {
+ getbyte(rs1, 3) @
+ getbyte(rs2, 6) @
+ getbyte(rs2, 1) @
+ getbyte(rs1, 4) @
+ getbyte(rs2, 7) @
+ getbyte(rs2, 2) @
+ getbyte(rs1, 5) @
+ getbyte(rs1, 0)
+}
+
+val aes_rv64_shiftrows_inv : (bits(64), bits(64)) -> bits(64)
+function aes_rv64_shiftrows_inv(rs2, rs1) = {
+ getbyte(rs2, 3) @
+ getbyte(rs2, 6) @
+ getbyte(rs1, 1) @
+ getbyte(rs1, 4) @
+ getbyte(rs1, 7) @
+ getbyte(rs2, 2) @
+ getbyte(rs2, 5) @
+ getbyte(rs1, 0)
+}
+
+/* 128-bit to 128-bit implementation of the forward AES ShiftRows transform.
+ * Byte 0 of state is input column 0, bits 7..0.
+ * Byte 5 of state is input column 1, bits 15..8.
+ */
+val aes_shift_rows_fwd : bits(128) -> bits(128)
+function aes_shift_rows_fwd(x) = {
+ let ic3 : bits(32) = aes_get_column(x, 3);
+ let ic2 : bits(32) = aes_get_column(x, 2);
+ let ic1 : bits(32) = aes_get_column(x, 1);
+ let ic0 : bits(32) = aes_get_column(x, 0);
+ let oc0 : bits(32) = ic3[31..24] @ ic2[23..16] @ ic1[15.. 8] @ ic0[ 7.. 0];
+ let oc1 : bits(32) = ic0[31..24] @ ic3[23..16] @ ic2[15.. 8] @ ic1[ 7.. 0];
+ let oc2 : bits(32) = ic1[31..24] @ ic0[23..16] @ ic3[15.. 8] @ ic2[ 7.. 0];
+ let oc3 : bits(32) = ic2[31..24] @ ic1[23..16] @ ic0[15.. 8] @ ic3[ 7.. 0];
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* 128-bit to 128-bit implementation of the inverse AES ShiftRows transform.
+ * Byte 0 of state is input column 0, bits 7..0.
+ * Byte 5 of state is input column 1, bits 15..8.
+ */
+val aes_shift_rows_inv : bits(128) -> bits(128)
+function aes_shift_rows_inv(x) = {
+ let ic3 : bits(32) = aes_get_column(x, 3); /* In column 3 */
+ let ic2 : bits(32) = aes_get_column(x, 2);
+ let ic1 : bits(32) = aes_get_column(x, 1);
+ let ic0 : bits(32) = aes_get_column(x, 0);
+ let oc0 : bits(32) = ic1[31..24] @ ic2[23..16] @ ic3[15.. 8] @ ic0[ 7.. 0];
+ let oc1 : bits(32) = ic2[31..24] @ ic3[23..16] @ ic0[15.. 8] @ ic1[ 7.. 0];
+ let oc2 : bits(32) = ic3[31..24] @ ic0[23..16] @ ic1[15.. 8] @ ic2[ 7.. 0];
+ let oc3 : bits(32) = ic0[31..24] @ ic1[23..16] @ ic2[15.. 8] @ ic3[ 7.. 0];
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* Applies the forward sub-bytes step of AES to a 128-bit vector
+ * representation of its state.
+ */
+val aes_subbytes_fwd : bits(128) -> bits(128)
+function aes_subbytes_fwd(x) = {
+ let oc0 : bits(32) = aes_subword_fwd(aes_get_column(x, 0));
+ let oc1 : bits(32) = aes_subword_fwd(aes_get_column(x, 1));
+ let oc2 : bits(32) = aes_subword_fwd(aes_get_column(x, 2));
+ let oc3 : bits(32) = aes_subword_fwd(aes_get_column(x, 3));
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* Applies the inverse sub-bytes step of AES to a 128-bit vector
+ * representation of its state.
+ */
+val aes_subbytes_inv : bits(128) -> bits(128)
+function aes_subbytes_inv(x) = {
+ let oc0 : bits(32) = aes_subword_inv(aes_get_column(x, 0));
+ let oc1 : bits(32) = aes_subword_inv(aes_get_column(x, 1));
+ let oc2 : bits(32) = aes_subword_inv(aes_get_column(x, 2));
+ let oc3 : bits(32) = aes_subword_inv(aes_get_column(x, 3));
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* Applies the forward MixColumns step of AES to a 128-bit vector
+ * representation of its state.
+ */
+val aes_mixcolumns_fwd : bits(128) -> bits(128)
+function aes_mixcolumns_fwd(x) = {
+ let oc0 : bits(32) = aes_mixcolumn_fwd(aes_get_column(x, 0));
+ let oc1 : bits(32) = aes_mixcolumn_fwd(aes_get_column(x, 1));
+ let oc2 : bits(32) = aes_mixcolumn_fwd(aes_get_column(x, 2));
+ let oc3 : bits(32) = aes_mixcolumn_fwd(aes_get_column(x, 3));
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* Applies the inverse MixColumns step of AES to a 128-bit vector
+ * representation of its state.
+ */
+val aes_mixcolumns_inv : bits(128) -> bits(128)
+function aes_mixcolumns_inv(x) = {
+ let oc0 : bits(32) = aes_mixcolumn_inv(aes_get_column(x, 0));
+ let oc1 : bits(32) = aes_mixcolumn_inv(aes_get_column(x, 1));
+ let oc2 : bits(32) = aes_mixcolumn_inv(aes_get_column(x, 2));
+ let oc3 : bits(32) = aes_mixcolumn_inv(aes_get_column(x, 3));
+ (oc3 @ oc2 @ oc1 @ oc0) /* Return value */
+}
+
+/* Performs the word rotation for AES key schedule
+*/
+
+val aes_rotword : bits(32) -> bits(32)
+function aes_rotword(x) = {
+ let a0 : bits (8) = x[ 7.. 0];
+ let a1 : bits (8) = x[15.. 8];
+ let a2 : bits (8) = x[23..16];
+ let a3 : bits (8) = x[31..24];
+ (a0 @ a3 @ a2 @ a1) /* Return Value */
+}
+
+val brev : bits(SEW) -> bits(SEW)
+function brev(x) = {
+ let output : bits(SEW) = 0;
+ foreach (i from 0 to SEW-8 by 8)
+ output[i+7..i] = reverse_bits_in_byte(input[i+7..i]);
+ output /* Return Value */
+}
+
+val reverse_bits_in_byte : bits(8) -> bits(8)
+function reverse_bits_in_byte(x) = {
+ let output : bits(8) = 0;
+ foreach (i from 0 to 7)
+ output[i] = x[7-i]);
+ output /* Return Value */
+}
+
+val rev8 : bits(SEW) -> bits(SEW)
+function rev8(x) = { // endian swap
+ let output : bits(SEW) = 0;
+ let j = SEW - 1;
+ foreach (k from 0 to (SEW - 8) by 8) {
+ output[k..(k + 7)] = x[(j - 7)..j];
+ j = j - 8;
+ output /* Return Value */
+ }
+ RETIRE_SUCCESS
+
+
+val rol32 : bits(32) -> bits(32)
+function ROL32(x,n) = (X << N) | (X >> (32 - N))
+
+val sm4_subword : bits(32) -> bits(32)
+function sm4_subword(x) = {
+ sm4_sbox(x[31..24]) @
+ sm4_sbox(x[23..16]) @
+ sm4_sbox(x[15.. 8]) @
+ sm4_sbox(x[ 7.. 0])
+}
+----
diff --git a/src/vector-examples.adoc b/src/vector-examples.adoc
new file mode 100644
index 0000000..41d81ea
--- /dev/null
+++ b/src/vector-examples.adoc
@@ -0,0 +1,125 @@
+[appendix]
+== Vector Assembly Code Examples
+
+The following are provided as non-normative text to help explain the vector ISA.
+
+=== Vector-vector add example
+
+----
+include::example/vvaddint32.s[lines=4..-1]
+----
+
+=== Example with mixed-width mask and compute.
+
+----
+# Code using one width for predicate and different width for masked
+# compute.
+# int8_t a[]; int32_t b[], c[];
+# for (i=0; i<n; i++) { b[i] = (a[i] < 5) ? c[i] : 1; }
+#
+# Mixed-width code that keeps SEW/LMUL=8
+ loop:
+ vsetvli a4, a0, e8, m1, ta, ma # Byte vector for predicate calc
+ vle8.v v1, (a1) # Load a[i]
+ add a1, a1, a4 # Bump pointer.
+ vmslt.vi v0, v1, 5 # a[i] < 5?
+
+ vsetvli x0, a0, e32, m4, ta, mu # Vector of 32-bit values.
+ sub a0, a0, a4 # Decrement count
+ vmv.v.i v4, 1 # Splat immediate to destination
+ vle32.v v4, (a3), v0.t # Load requested elements of C, others undisturbed
+ sll t1, a4, 2
+ add a3, a3, t1 # Bump pointer.
+ vse32.v v4, (a2) # Store b[i].
+ add a2, a2, t1 # Bump pointer.
+ bnez a0, loop # Any more?
+----
+
+=== Memcpy example
+
+----
+include::example/memcpy.s[lines=4..-1]
+----
+
+=== Conditional example
+
+----
+# (int16) z[i] = ((int8) x[i] < 5) ? (int16) a[i] : (int16) b[i];
+#
+
+loop:
+ vsetvli t0, a0, e8, m1, ta, ma # Use 8b elements.
+ vle8.v v0, (a1) # Get x[i]
+ sub a0, a0, t0 # Decrement element count
+ add a1, a1, t0 # x[i] Bump pointer
+ vmslt.vi v0, v0, 5 # Set mask in v0
+ vsetvli x0, x0, e16, m2, ta, mu # Use 16b elements.
+ slli t0, t0, 1 # Multiply by 2 bytes
+ vle16.v v2, (a2), v0.t # z[i] = a[i] case
+ vmnot.m v0, v0 # Invert v0
+ add a2, a2, t0 # a[i] bump pointer
+ vle16.v v2, (a3), v0.t # z[i] = b[i] case
+ add a3, a3, t0 # b[i] bump pointer
+ vse16.v v2, (a4) # Store z
+ add a4, a4, t0 # z[i] bump pointer
+ bnez a0, loop
+----
+=== SAXPY example
+
+----
+include::example/saxpy.s[lines=4..-1]
+----
+
+=== SGEMM example
+
+----
+include::example/sgemm.S[lines=4..-1]
+----
+
+=== Division approximation example
+
+----
+# v1 = v1 / v2 to almost 23 bits of precision.
+
+vfrec7.v v3, v2 # Estimate 1/v2
+ li t0, 0x3f800000
+vmv.v.x v4, t0 # Splat 1.0
+vfnmsac.vv v4, v2, v3 # 1.0 - v2 * est(1/v2)
+vfmadd.vv v3, v4, v3 # Better estimate of 1/v2
+vmv.v.x v4, t0 # Splat 1.0
+vfnmsac.vv v4, v2, v3 # 1.0 - v2 * est(1/v2)
+vfmadd.vv v3, v4, v3 # Better estimate of 1/v2
+vfmul.vv v1, v1, v3 # Estimate of v1/v2
+----
+
+=== Square root approximation example
+
+----
+# v1 = sqrt(v1) to more than 23 bits of precision.
+
+ fmv.w.x ft0, x0 # Mask off zero inputs
+vmfne.vf v0, v1, ft0 # to avoid DZ exception
+vfrsqrt7.v v2, v1, v0.t # Estimate r ~= 1/sqrt(v1)
+vmfne.vf v0, v2, ft0, v0.t # Mask off +inf to avoid NV
+ li t0, 0x3f800000
+ fli.s ft0, 0.5
+vmv.v.x v5, t0 # Splat 1.0
+vfmul.vv v3, v1, v2, v0.t # t = v1 r
+vfmul.vf v4, v2, ft0, v0.t # 0.5 r
+vfmsub.vv v3, v2, v5, v0.t # t r - 1
+vfnmsac.vv v2, v3, v4, v0.t # r - (0.5 r) (t r - 1)
+ # Better estimate of 1/sqrt(v1)
+vfmul.vv v1, v1, v2, v0.t # t = v1 r
+vfmsub.vv v2, v1, v5, v0.t # t r - 1
+vfmul.vf v3, v1, ft0, v0.t # 0.5 t
+vfnmsac.vv v1, v2, v3, v0.t # t - (0.5 t) (t r - 1)
+ # ~ sqrt(v1) to about 23.3 bits
+----
+
+=== C standard library strcmp example
+
+----
+include::example/strcmp.s[lines=4..-1]
+----
+
+include::fraclmul.adoc[]
diff --git a/src/xcolor.sty b/src/xcolor.sty
deleted file mode 100644
index 96e8761..0000000
--- a/src/xcolor.sty
+++ /dev/null
@@ -1,1449 +0,0 @@
-%%
-%% This is file `xcolor.sty',
-%% generated with the docstrip utility.
-%%
-%% The original source files were:
-%%
-%% xcolor.dtx (with options: `package')
-%%
-%% IMPORTANT NOTICE:
-%%
-%% For the copyright see the source file.
-%%
-%% Any modified versions of this file must be renamed
-%% with new filenames distinct from xcolor.sty.
-%%
-%% For distribution of the original source see the terms
-%% for copying and modification in the file xcolor.dtx.
-%%
-%% This generated file may be distributed as long as the
-%% original source files, as listed above, are part of the
-%% same distribution. (The sources need not necessarily be
-%% in the same archive or directory.)
-%%
-\ProvidesPackage{xcolor}
- [2007/01/21 v2.11 LaTeX color extensions (UK)]
-%%
-%% ----------------------------------------------------------------
-%% Copyright (C) 2003-2007 by Dr. Uwe Kern <xcolor at ukern dot de>
-%% ----------------------------------------------------------------
-%%
-%% Please send error reports and suggestions for
-%% improvements to the above email address.
-%%
-%% This package contains code copied from
-%%
-%% color.dtx [1999/02/16 v1.0i Standard LaTeX Color (DPC)]
-%% Copyright (C) 1994--1999 David Carlisle
-%%
-%% which is part of the Standard LaTeX `Graphics Bundle'.
-%%
-\NeedsTeXFormat{LaTeX2e}
-\expandafter\edef\csname XC@catcodes\endcsname
- {\catcode33 \the\catcode33 % !
- \catcode34 \the\catcode34 % "
- \catcode39 \the\catcode39 % '
- \catcode42 \the\catcode42 % *
- \catcode44 \the\catcode44 % ,
- \catcode45 \the\catcode45 % -
- \catcode46 \the\catcode46 % .
- \catcode47 \the\catcode47 % /
- \catcode58 \the\catcode58 % :
- \catcode59 \the\catcode59 % ;
- \catcode60 \the\catcode60 % <
- \catcode61 \the\catcode61 % =
- \catcode62 \the\catcode62 % >
- \catcode63 \the\catcode63 % ?
- \catcode64 \the\catcode64 % @
- \catcode94 \the\catcode94 % ^
- \catcode96 \the\catcode96 % `
- \catcode`\noexpand\^^A\the\catcode`\^^A\relax}
-\catcode64 11 %
-\@makeother\! \@makeother\" \@makeother\' \@makeother\* \@makeother\,
-\@makeother\- \@makeother\. \@makeother\/ \@makeother\: \@makeother\;
-\@makeother\< \@makeother\= \@makeother\> \@makeother\? \@makeother\`
-\catcode94 7 %
-\catcode`\^^A=14 %
-\edef\XC@@{\expandafter\noexpand\csname\string\XC@@\endcsname}
-\newif\ifcolors@ \colors@true
-\newif\ifcolorerrors@
-\newif\ifglobalcolors \globalcolorsfalse
-\newif\ifdefinecolors \definecolorstrue
-\newif\ifconvertcolorsD
-\newif\ifconvertcolorsU
-\newif\ifblendcolors
-\newif\ifmaskcolors
-\newif\ifXC@@fbox \XC@@fboxtrue
-\newif\ifXC@@tst
-\def\c@lor@error#1%
- {\ifcolorerrors@\PackageError{xcolor}{Undefined color #1}\@ehc
- \else\PackageWarning{xcolor}{Undefined color #1}\fi}
-\def\XC@append#1#2%
- {\ifx#1\@undefined\def#1{#2}\else\ifx#1\relax\def#1{#2}\else
- \toks@\expandafter{#1#2}\edef#1{\the\toks@}\fi\fi}
-\def\XC@let@cc#1{\expandafter\XC@let@Nc\csname#1\endcsname}
-\providecommand*\@namelet[1]{\expandafter\XC@let@Nc\csname#1\endcsname}
-\def\XC@let@Nc#1#2{\expandafter\let\expandafter#1\csname#2\endcsname}
-\def\XC@let@cN#1{\expandafter\let\csname#1\endcsname}
-\def\@namexdef#1{\expandafter\xdef\csname #1\endcsname}
-\def\aftergroupdef#1#2%
- {\expandafter\endgroup\expandafter\def\expandafter#1\expandafter{#2}}
-\def\aftergroupedef#1#2%
- {\edef\@@tmp{\def\noexpand#1{#2}}\expandafter\endgroup\@@tmp}
-\begingroup
-\catcode`\!=13 \catcode`\:=13 \catcode`\-=13 \catcode`\+=13
-\catcode`\;=13 \catcode`\/=13 \catcode`\"=13 \catcode`\>=13
-\gdef\XC@edef#1#2%
- {\begingroup
- \ifnum\catcode`\!=13 \edef!{\string!}\fi
- \ifnum\catcode`\:=13 \edef:{\string:}\fi
- \ifnum\catcode`\-=13 \edef-{\string-}\fi
- \ifnum\catcode`\+=13 \edef+{\string+}\fi
- \ifnum\catcode`\;=13 \edef;{\string;}\fi
- \ifnum\catcode`\"=13 \edef"{\string"}\fi
- \ifnum\catcode`\>=13 \edef>{\string>}\fi
- \edef#1{#2}\@onelevel@sanitize#1\aftergroupdef#1#1}
-\gdef\XC@mdef#1#2%
- {\begingroup
- \ifnum\catcode`\/=13 \edef/{\string/}\fi
- \ifnum\catcode`\:=13 \edef:{\string:}\fi
- \edef#1{#2}\@onelevel@sanitize#1\aftergroupdef#1#1}
-\endgroup
-\def\XC@sdef#1#2{\edef#1{#2}\@onelevel@sanitize#1}
-\def\@ifxempty#1{\@@ifxempty#1\@@ifxempty\XC@@}
-\def\@@ifxempty#1#2\XC@@
- {\ifx#1\@@ifxempty
- \expandafter\@firstoftwo\else\expandafter\@secondoftwo\fi}
-\long\def\XC@ifxcase#1#2#3%
- {\long\def\@@tmp##1##2%
- {\ifx#1##1%
- \toks@{##2}\expandafter\remove@to@nnil\else\expandafter\@@tmp\fi}%
- \@@tmp#2#1{#3}\@nnil\the\toks@}
-\long\def\XC@ifcase#1#2#3%
- {\long\def\@@tmp##1##2%
- {\@expandtwoargs\in@{,#1,}{,##1,}\ifin@
- \toks@{##2}\expandafter\remove@to@nnil\else\expandafter\@@tmp\fi}%
- \@@tmp#2{#1}{#3}\@nnil\the\toks@}
-\def\XC@@opt{,}
-\def\@ifXCopt#1%
- {\@expandtwoargs\in@{,#1,}{\XC@@opt}%
- \ifin@\expandafter\@firstoftwo\else\expandafter\@secondoftwo\fi}
-\let\XC@@pkg\relax
-\let\XC@declareoption\@declareoption
-\long\def\@declareoption#1#2%
- {\XC@declareoption{#1}{\edef\XC@@opt{\XC@@opt#1,}#2}}
-\def\selectcolormodel#1%
- {\@ifundefined{XC@mod@#1}%
- {\c@lor@error{target model `#1'}}%
- {\expandafter\ifx\csname XC@mod@#1\endcsname\XC@mod@natural
- \def\XC@tgt@mod##1{##1}\convertcolorsDfalse\convertcolorsUfalse
- \else\expandafter\ifx\csname XC@mod@#1\endcsname\XC@mod@named
- \c@lor@error{target model `#1'}
- \else
- \edef\XC@tgt@mod##1{#1}\convertcolorsDtrue\convertcolorsUtrue
- \fi\fi}}
-\@tfor\@@tmp:={Hsb}{tHsb}{ignore}{named}{ps}{wave}\do
- {\expandafter\XC@sdef\csname XC@mod@\@@tmp\endcsname{\@@tmp}}
-\@tfor\@@tmp:={natural}{rgb}{cmy}{cmyk}{hsb}{gray}{RGB}{HTML}{HSB}{Gray}\do
- {\expandafter\XC@sdef\csname XC@mod@\@@tmp\endcsname{\@@tmp}%
- \edef\@@tmp
- {\noexpand\DeclareOption{\@@tmp}{\noexpand\selectcolormodel{\@@tmp}}}%
- \@@tmp}
-\DeclareOption{monochrome}
- {\ExecuteOptions{hideerrors}%
- \AtEndOfPackage
- {\colors@false
- \def\set@color{\c@lor@special\m@ne
- {color push \current@color}\aftergroup\reset@color}%
- \def\reset@color{\c@lor@special\m@ne{color pop}}%
- \def\set@page@color{\c@lor@special\m@ne{background \current@color}}}}
-\let\XC@@names\relax
-\providecommand*\colornameprefix{XC@}
-\let\XC@@nameprefix\colornameprefix
-\def\XC@declarenames#1#2#3%
- {\DeclareOption{#1}{\XC@append\XC@@names
- {#3\definecolorstrue\input{#2.def}\definecolorstrue
- \let\colornameprefix\XC@@nameprefix}}
- \DeclareOption{#1*}{\XC@append\XC@@names
- {#3\definecolorsfalse\input{#2.def}\definecolorstrue
- \let\colornameprefix\XC@@nameprefix}}}
-\XC@declarenames{dvipsnames}{dvipsnam}{\let\colornameprefix\@empty}
-\XC@declarenames{svgnames}{svgnam}{}
-\XC@declarenames{x11names}{x11nam}{}
-\XC@declarenames{hksnames}%
- {hks\ifcase\paperquality k\or n\or k\or z\else n\fi nam}{}
-\XC@declarenames{pmsnames}{pmsnam}{}
-\XC@declarenames{ralnames}{ralnam}{}
-\DeclareOption{table}{\XC@append\XC@@pkg{\RequirePackage{colortbl}}}
-\DeclareOption{fixpdftex}{\XC@append\XC@@pkg{\RequirePackage{pdfcolmk}}}
-\DeclareOption{hyperref}
- {\@tfor\@@tmp:={cite}{file}{link}{menu}{page}{run}{url}\do
- {\expandafter\edef\csname KV@Hyp@x\@@tmp bordercolor\endcsname #1%
- {\noexpand\XC@bordercolor{\@@tmp}{#1}}}%
- \AtEndOfPackage
- {\GetGinDriver\def\KV@Hyp@xpdfborder#1{\edef\@pdfborder{#1}}%
- \@tfor\@@tmp:={dvips}\do
- {\ifx\GinDriver\@@tmp
- \def\KV@Hyp@xpdfborder#1%
- {\edef\@pdfborder{#1}\expandafter\XC@pdfborder\@pdfborder\relax}%
- \@break@tfor\fi}}}
-\providecommand*\Gin@driver{}
-\@tfor\@@tmp:={dvipdf}{dvipdfm}{dvipdfmx}{dvips}{dvipsone}{dviwin}%
- {emtex}{pctex32}{pctexhp}{pctexps}{pctexwin}{pdftex}%
- {tcidvi}{textures}{truetex}{vtex}{xetex}\do
- {\edef\@@tmp{\noexpand\DeclareOption{\@@tmp}%
- {\def\noexpand\Gin@driver{\@@tmp.def}}}%
- \@@tmp}
-\DeclareOption{dviwindo}{\ExecuteOptions{dvipsone}}
-\DeclareOption{oztex}{\ExecuteOptions{dvips}}
-\DeclareOption{xdvi}{\ExecuteOptions{dvips,monochrome}}
-\DeclareOption{xcdraw}{\def\XC@@xcd@{1}}
-\DeclareOption{noxcdraw}{\def\XC@@xcd@{-1}}
-\DeclareOption{fixinclude}{\def\XC@@xcf@{1}}
-\DeclareOption{prologue}{\def\XC@@xcp@{1}}
-\DeclareOption{kernelfbox}{\XC@@fboxfalse}
-\DeclareOption{showerrors}{\colorerrors@true}
-\DeclareOption{hideerrors}{\colorerrors@false}
-\DeclareOption{debugshow}{\catcode`\^^A=9 \let\GDebug\typeout}
-\DeclareOption*%
- {\PackageInfo{xcolor}{Package option `\CurrentOption' ignored}}
-\def\XC@@xcd@{-1}
-\def\XC@@xcf@{-1}
-\def\XC@@xcp@{-1}
-\ExecuteOptions{natural,showerrors}
-\InputIfFileExists{color.cfg}{}{}
-\let\@declareoption\XC@declareoption
-\ProcessOptions\relax
-\edef\Gin@driver{\Gin@driver}
-\if!\Gin@driver!
- \PackageError{xcolor}
- {No driver specified}
- {You should make a default driver option in a file \MessageBreak
- color.cfg\MessageBreak
- eg: \protect\ExecuteOptions{dvips}}
-\else
- \PackageInfo{xcolor}{Driver file: \Gin@driver}
- \@ifundefined{ver@\Gin@driver}{\input{\Gin@driver}}{}
- \def\@@tmp#1.def{\def\XC@@drv{#1}}
- \expandafter\@@tmp\Gin@driver
-\fi
-\count@\XC@@xcd@ \advance\count@\XC@@xcf@ \advance\count@\XC@@xcp@\relax
-\ifnum\count@>-3
- \XC@ifcase\XC@@drv
- {{dvips,pctex32}%
- {\def\@tempa{0}
- \def\XC@special#1{\special{ps:XC!b}\special{"#1}\special{ps:XC!e}}}%
- {pdftex}%
- {\def\@tempa{1}
- \def\XC@special#1{\pdfliteral{ q #1 Q }}}%
- {dvipdfm}%
- {\def\@tempa{1}
- \def\XC@special#1{\special{pdf: content #1}}}%
- }{\def\@tempa{-1}}
- \ifnum\XC@@xcd@>\m@ne\let\XC@@xcd@\@tempa\fi
- \ifnum\XC@@xcf@>\m@ne\let\XC@@xcf@\@tempa\fi
- \ifnum\XC@@xcp@>\m@ne\let\XC@@xcp@\@tempa\fi
- \ifnum\@tempa=0 \AtBeginDvi{\special{header=xcolor.pro}}\fi
- \ifcase\XC@@xcf@
- \AtBeginDvi{\special{! XCfixnormalscale}}
- \fi
- \ifcase\XC@@xcp@
- \AtBeginDvi{\special{header=\jobname.xcp}}
- \newwrite\XC@@xcp\immediate\openout\XC@@xcp=\jobname.xcp
- \immediate\write\XC@@xcp{\@percentchar!}
- \immediate\write\XC@@xcp{TeXDict begin}
- \AtEndDocument
- {\immediate\write\XC@@xcp{end}\immediate\closeout\XC@@xcp}
- \fi
-\fi
-\@namedef{ver@color.sty}{1999/02/16}
-\XC@@pkg
-\long\def\@secondoffive#1#2#3#4#5{#2}
-\long\def\@thirdoffive#1#2#3#4#5{#3}
-\def\xglobal{\xglobal@stop\begingroup\futurelet\@@tok\xglobal@test}
-\def\xglobal@test
- {\expandafter\@tfor\expandafter\@@tmp
- \expandafter:\expandafter=\xglobal@list\do
- {\expandafter\ifx\@@tmp\@@tok
- \aftergroup\let\aftergroup\xglobal@\@break@tfor\fi}%
- \endgroup\global}
-\def\xglobal@stop{\let\xglobal@\@empty}
-\xglobal@stop
-\def\xglobal@list
- {\definecolor\definecolors\definecolorset\colorlet\providecolor
- \providecolors\providecolorset\blendcolors\maskcolors
- \substitutecolormodel}
-\def\xglobalize@#1{\ifx\xglobal@\global\global\let#1#1\fi}
-\def\GetGinDriver
- {\@tempswafalse
- \@tfor\@@tmp:={dvips}{pdftex}{dvipdf}{dvipdfm}{dvipsone}{vtex}{textures}%
- \do{\ifx\XC@@drv\@@tmp\@tempswatrue\@break@tfor\fi}%
- \edef\GinDriver{\if@tempswa\XC@@drv\else hypertex\fi}}
-\def\@hex@Hex#1{\ifx#1\relax\else\expandafter\@hex@@Hex\expandafter#1\fi}
-\def\@hex@@Hex#1%
- {\if a#1A\else \if b#1B\else \if c#1C\else \if d#1D\else
- \if e#1E\else \if f#1f\else #1\fi\fi\fi\fi\fi\fi \@hex@Hex}
-\def\XC@strip@comma#1,#2%
- {\ifx,#2%
- #1\expandafter\remove@to@nnil\else#1 \expandafter\XC@strip@comma\fi
- #2}
-{\catcode`Q=3
- \gdef\XC@replace#1#2#3%
- {\begingroup
- \def\XC@repl@ce##1#2##2Q##3%
- {\@ifxempty{##2}{\XC@r@pl@ce##1Q}{\XC@repl@ce##1##3##2Q{##3}}}%
- \def\XC@r@pl@ce##1\@empty Q%
- {\expandafter\endgroup\expandafter\def\expandafter#1\expandafter{##1}}%
- \expandafter\XC@repl@ce\expandafter\@empty #1\@empty#2Q{#3}}
-}
-\def\XC@clean#1%
- {\edef#1{ #1 }%
- \XC@cle@n#1,{ }\XC@cle@n#1{. }{ }\XC@cle@n#1{ },%
- \edef#1{\expandafter\@gobbletwo#1}}
-\def\XC@cle@n#1#2#3%
- {\def\XC@cl@@n##1#2##2{#3##1\ifx##2\@empty\else\expandafter\XC@cl@@n\fi##2}%
- \edef#1{\expandafter\XC@cl@@n#1#2\@empty}}%
-\def\rdivide#1#2%
- {\begingroup\toks@{#1}\edef\@@tmp{\noexpand\@tempdima\the#1}%
- \@defaultunits\@tempdimb=#2pt\relax\@nnil \@@tmp\relax
- \ifdim\@tempdima<\z@ \@tempdima-\@tempdima\def\@sign{-}\else
- \def\@sign{}\fi
- \ifdim\@tempdimb<\z@ \@tempdimb-\@tempdimb\edef\@sign{\@sign-}\fi
- \ifdim\@tempdima<.1\maxdimen \ifdim\@tempdimb<.01\maxdimen
- \lshift\@tempdima \lshift\@tempdimb \fi\fi
- \@tempcnta=\@tempdima \@tempcntb=\@tempdimb
- \count@=\@tempcnta \divide\count@\@tempcntb
- \edef\@@tmp{\number\count@.}%
- \@tempswatrue \@rdivide \@rdivide \@rdivide \@rdivide \@rdivide
- \@tempswafalse \@rdivide
- \dimen@\@@tmp\p@ \ifnum\count@>4\advance\dimen@1sp\fi
- \dimen@\@sign\dimen@
- \edef\@@tmp{\the\toks@\the\dimen@}%
- \expandafter\endgroup\@@tmp}
-\def\@rdivide
- {\multiply\count@\@tempcntb \advance\@tempcnta-\count@
- \multiply\@tempcnta10 \count@=\@tempcnta \divide\count@\@tempcntb
- \if@tempswa\edef\@@tmp{\@@tmp\number\count@}\fi}
-\def\rmultiply#1#2%
- {\begingroup
- \edef\@@mul{#2}\@tempdima\the#1\relax
- \afterassignment\@tempdimb\@tempcntb=\@@mul\p@
- \ifdim\@tempdima<\z@ \@tempdima-\@tempdima\def\@sign{-}\else
- \def\@sign{}\fi
- \ifnum\@tempcntb<\z@ \@tempcntb-\@tempcntb\edef\@sign{\@sign-}\fi
- \lshift\@tempdima \dimen@\z@
- \expandafter\@rmultiply\@@mul.0.\@nil
- \advance\dimen@\@tempcntb\@tempdima \rshift\dimen@
- \dimen@\@sign\dimen@
- \edef\@@tmp{#1\the\dimen@}%
- \expandafter\endgroup\@@tmp}
-\def\@rmultiply#1.#2.#3\@nil
- {\def\@@tmp{}%
- \@tfor\@@mul:=#2\do
- {\edef\@@tmp
- {\advance\dimen@\@@mul\@tempdima \divide\dimen@10 \@@tmp}}%
- \@@tmp}
-\def\lshift#1{#1\expandafter\lshift@\the#1}
-\def\llshift#1{\lshift#1\lshift#1}
-\def\lshiftnum#1{\expandafter\lshiftnum@#1.00.:}
-\def\lshiftnum@#1.#2#3.#4:{#1#2\ifnum0#3>\z@.#3\fi}
-\def\llshiftnum#1{\expandafter\llshiftnum@#1\@empty.00.:}
-\def\llshiftnum@#1.#2#3#4.#5:%
- {#1#2\ifnum0#3>\z@#3\else0\fi\ifnum0#4>\z@.#4\fi}
-\def\lshiftset#1#2{\edef\@@XC{\noexpand\lshiftnum{#2}}#1\@@XC\p@}
-\def\llshiftset#1#2{\edef\@@XC{\noexpand\llshiftnum{#2}}#1\@@XC\p@}
-\def\rshift#1{#1\expandafter\rshift@\the#1}
-\def\rrshift#1{\rshift#1\rshift#1}
-\begingroup
-\catcode`P=12
-\catcode`T=12
-\lowercase
- {\def\@@tmp{\def\lshift@##1.##2##3PT{##1##2\ifnum0##3>\z@.##3\fi\p@}
- \def\rshift@##1.##2PT{\rshift@@##1\relax##2\p@}}}
-\expandafter\endgroup\@@tmp
-\def\rshift@@#1#2%
- {\ifx#2\relax.#1\else#1\expandafter\rshift@@\expandafter#2\fi}
-\def\XC@inflate#1#2#3#4%
- {\edef#4{#2,\ifx#1\XC@mod@cmyk #3\else
- \ifx#1\XC@mod@gray ,,,#3,,,\else ,#3,\fi\fi}}
-\def\XC@vec#1,#2,#3,#4,#5,#6,#7,#8,#9%
- {\def\@@tmp{}%
- \XC@vec@{#1}{#5}%
- \ifx,#2,\else
- \XC@vec@{#2}{#6}\XC@vec@{#3}{#7}\ifx,#4,\else\XC@vec@{#4}{#8}\fi\fi
- \aftergroupdef#9\@@tmp}
-\def\XC@vec@@{\edef\@@tmp{\ifx\@@tmp\@empty\else\@@tmp,\fi\strip@pt\dimen@}}
-\def\XC@add{\begingroup \let\XC@vec@\XC@add@ \XC@vec}
-\def\XC@add@#1#2%
- {\llshiftset\dimen@{#1}\llshiftset\@tempdima{#2}%
- \advance\dimen@\@tempdima \rrshift\dimen@ \XC@vec@@}
-\def\XC@sub{\begingroup \let\XC@vec@\XC@sub@ \XC@vec}
-\def\XC@sub@#1#2{\XC@add@{#1}{-#2}}
-\def\XC@mul{\begingroup \let\XC@vec@\XC@mul@ \XC@vec}
-\def\XC@mul@#1#2%
- {\llshiftset\dimen@{#1}\rmultiply\dimen@{#2}\rrshift\dimen@ \XC@vec@@}
-\def\XC@mix%
- {\begingroup
- \@tempdima\dimen@ \@tempdimb100\p@ \advance\@tempdimb-\@tempdima
- \let\XC@vec@\XC@mix@ \XC@vec}
-\def\XC@mix@#1#2%
- {\dimen@#1\@tempdima \advance\dimen@#2\@tempdimb \rrshift\dimen@ \XC@vec@@}
-\def\XC@calc@#1,#2,#3,#4,#5:#6%
- {\XC@let@Nc\@@cmd{XC@calc#6}\@@cmd{#1}\@@tmp
- \ifx,#2,\else
- \@@cmd{#2}\@tempa\@@cmd{#3}\@tempb
- \ifx,#4,%
- \edef\@@tmp{\@@tmp,\@tempa,\@tempb}\else
- \@@cmd{#4}\@tempc\edef\@@tmp{\@@tmp,\@tempa,\@tempb,\@tempc}\fi\fi}
-\def\XC@calcC#1#2%
- {\llshiftset\dimen@{-#1}\advance\dimen@100\p@
- \rrshift\dimen@ \XC@calcN{\strip@pt\dimen@}#2}
-\def\XC@calcD{\XC@c@lcD\@@scl{}}
-\def\XC@c@lcD#1#2#3#4%
- {\dimen@#3\p@ \rdivide\dimen@{#1}\edef#4{\strip@pt\dimen@#2}}
-\def\XC@calcF#1#2%
- {\edef#2{#1}\expandafter\XC@c@lcF#2.0.:#2}
-\def\XC@c@lcF#1.#2.#3:#4%
- {\edef#4{\XC@c@@cR#200000:}%
- \dimen@#1.5\p@ \afterassignment\dimen@\count@=\the\dimen@
- \edef#4%
- {\ifnum#4>0 \ifnum\count@=0 \ifdim#1.5\p@<\z@ -\fi\fi\fi
- \number\count@.#4}}
-\def\XC@calcH#1#2%
- {\count@#1 \divide\count@\sixt@@n \edef\XC@@tmp{\hexnumber@\count@}%
- \multiply\count@-\sixt@@n \advance\count@#1
- \edef#2{\XC@@tmp\hexnumber@\count@}}
-\def\XC@calcM#1#2%
- {\dimen@#1\p@ \dimen@\@@scl\dimen@ \advance\dimen@.5\p@
- \afterassignment\dimen@\count@=\the\dimen@ \edef#2{\number\count@}}
-\def\XC@calcN#1#2%
- {\XC@calcR{#1}#2\edef#2{\expandafter\XC@c@lcN#200000:}}
-\def\XC@c@lcN#1.#200000#3:{#1\ifnum0#2=0 \else.#2\fi}
-\def\XC@calcR#1#2{\edef#2{#1}\edef#2{\expandafter\XC@c@lcR#2.0.:}}
-\def\XC@c@lcR#1.#2.#3:%
- {\ifnum#10>0 1.00000\else 0.\ifnum#11<0 00000\else
- \XC@c@@cR#200000:\fi\fi}
-\def\XC@c@@cR#1#2#3#4#5#6:{#1#2#3#4#5}
-\def\XC@calcS{\XC@c@lcS\@@scl{}}
-\def\XC@c@lcS#1#2#3#4%
- {\lshiftset\dimen@{#3}%
- \ifdim#1\p@<100\p@
- \dimen@\lshiftnum#1\dimen@ \rrshift\dimen@ \else
- \dimen@#1\dimen@ \rshift\dimen@ \fi
- \edef#4{\strip@pt\dimen@#2}}
-\def\XC@calcT#1#2%
- {\lshiftset\dimen@{#1}\advance\dimen@\lshiftnum\@@arg\p@ \rshift\dimen@
- \edef#2%
- {\ifdim\dimen@>\p@1\else\ifdim\dimen@<\z@0\else\strip@pt\dimen@\fi\fi}}
-\def\XC@calcU#1#2%
- {\dimen@#1\p@
- \ifdim\dimen@=\p@\else
- \afterassignment\dimen@\count@=\the\dimen@
- \relax\ifdim\dimen@=\z@\else
- \ifdim#1\p@<\z@ \dimen@-\dimen@ \advance\dimen@\p@ \fi
- \fi
- \fi
- \edef#2{\strip@pt\dimen@}}
-\providecommand*\rangeRGB{255}
-\providecommand*\rangeHSB{240}
-\providecommand*\rangeHsb{360}
-\providecommand*\rangetHsb{60,30;120,60;180,120;210,180;240,240}
-\providecommand*\rangeGray{15}
-\providecommand*\adjustUCRBG{1,1,1,1}
-\providecommand*\paperquality{1}
-\providecommand*\colorseriescycle{16}
-\def\XC@clr@rgb@white{1,1,1}
-\def\XC@clr@cmy@white{0,0,0}
-\def\XC@clr@cmyk@white{0,0,0,0}
-\def\XC@clr@hsb@white{\@@hue,0,1}
-\def\XC@clr@hsb@gray{\@@hue,0,0.5}
-\def\XC@clr@hsb@black{\@@hue,0,0}
-\def\XC@clr@gray@white{1}
-\@tfor\@@tmp:={grad}{last}{step}\do
- {\XC@let@cN{XC@met@\@@tmp}\@@tmp}
-\def\definecolor{\@testopt{\XC@definecolor}{}}
-\def\XC@definecolor[#1]#2%
- {\@testopt{\XC@definec@lor[#1]{#2}}\colornameprefix}
-\def\XC@definec@lor[#1]#2[#3]#4#5%
- {\begingroup
- \XC@sdef\@@cls{#1}\XC@edef\@@nam{#2}\edef\colornameprefix{#3}%
- \XC@logdef\@@nam
- \XC@getmodclr02{#4}{#5}{\let\@@tmp\relax}%
- {\ifx\@@mod\XC@mod@named
- \XC@c@l@rlet\@@nam\@@clr
- \else
- \ifx\@@cls\XC@mod@ps
- \edef\@@drv{\@@mod\space\@@clr}\def\@@hue{0}%
- \edef\@@clr{\@nameuse{XC@clr@\@@mod @white}}%
- \else
- \ifconvertcolorsD
- \let\@@tmp\@@mod\XC@sdef\@@mod{\XC@tgt@mod\@@tmp}%
- \convertcolorspec\@@tmp\@@clr\@@mod\@@clr
- \fi
- \XC@coremodel\@@mod\@@clr
- \csname color@\@@mod\expandafter\endcsname
- \expandafter\@@drv\expandafter{\@@clr}%
- \ifcase\XC@@xcp@
- \immediate\write\XC@@xcp{/\colornameprefix\@@nam{\expandafter
- \XC@strip@comma\@@clr,,\@nnil}XC\@@mod}%
- \let\@@cls\XC@mod@named
- \fi
- \ifx\@@cls\@empty\else
- \let\@@tmp\@@cls
- \@nameuse{define@color@\@@cls}\@@nam\@@drv
- \csname color@\@@tmp\expandafter\endcsname
- \expandafter\@@drv\expandafter{\@@nam}%
- \fi
- \fi
- \toks@\expandafter{\@@drv}%
- \edef\@@tmp
- {\ifglobalcolors\global\else\xglobal@\fi
- \noexpand\@namedef{\string\color@\@@nam}%
- {\noexpand\xcolor@{\@@cls}{\the\toks@}{\@@mod}{\@@clr}}}%
- \fi}%
- \expandafter\endgroup\@@tmp\xglobal@stop}
-\def\XC@getmodclr#1#2#3#4%
- {\ifnum\ifcase#1 \ifXC@@getmod1\else0 \fi \or1 \fi>0
- \XC@mdef\@@mod{#3}\expandafter\XC@getmod\@@mod////////\XC@@
- \@ifundefinedmodel\@@Mod{\let\@@Mod\XC@mod@ignore}{}\fi
- \@ifundefined{XC@mod@\@@mod}%
- {\c@lor@error{model `\@@mod'}\@firstoftwo}%
- {\ifcase#2\else
- \XC@mdef\@@clr{#4}%
- \edef\@@clr{\expandafter\XC@getclr\@@clr////////\XC@@}%
- \ifx\@@cls\XC@mod@ps\else\XC@clean\@@clr\fi
- \ifx\@@Mod\XC@mod@ignore\else
- \convertcolorspec\@@mod\@@clr\@@Mod\@@clr
- \ifnum#2>1 \let\@@mod\@@Mod\fi
- \fi
- \fi \@secondoftwo}}
-\def\XC@getmod#1/#2/#3/#4/#5/#6/#7/#8/#9\XC@@
- {\XC@g@tm@d0#1::\XC@@ \XC@getm@d1{#2}\XC@getm@d2{#3}%
- \XC@getm@d3{#4}\XC@getm@d4{#5}\XC@getm@d5{#6}\XC@getm@d6{#7}%
- \XC@getm@d7{#8}\def\XC@@pos{0}\def\@@mod{#1}\@gobble\@nnil}%
-\def\XC@getm@d#1#2%
- {\edef\XC@@pos{#2}\XC@sdef\@@mod{\XC@tgt@mod\XC@@pos}%
- \ifx\XC@@pos\@@mod\def\XC@@pos{#1}\expandafter\remove@to@nnil\fi}%
-\def\XC@g@tm@d#1#2:#3:#4\XC@@
- {\@ifxempty{#3}{\let\@@Mod\XC@mod@ignore\XC@getm@d0{#2}}%
- {\def\@@Mod{#2}\XC@getm@d0{#3}}}%
-\def\XC@getclr#1/#2/#3/#4/#5/#6/#7/#8/#9\XC@@
- {\ifcase\XC@@pos\space #1\or#2\or#3\or#4\or#5\or#6\or#7\or#8\fi}
-\newif\ifXC@@getmod \XC@@getmodtrue
-\let\xdefinecolor\definecolor
-\def\providecolor{\@testopt{\XC@providecolor}{}}
-\def\XC@providecolor[#1]#2%
- {\@testopt{\XC@providec@lor[#1]{#2}}\colornameprefix}
-\def\XC@providec@lor[#1]#2[#3]%
- {\XC@edef\XC@@tmp{#2}%
- \@ifundefinedcolor\XC@@tmp{\XC@definecolor[#1]{#2}[#3]}%
- {\ifnum\XC@tracing>0
- \PackageInfo{xcolor}{Ignoring color definition `\XC@@tmp'}\fi
- \@gobbletwo}}
-\def\xcolor@#1#2#3#4{#2}
-\def\colorlet{\@testopt{\XC@colorlet}{}}
-\def\XC@colorlet[#1]#2{\@testopt{\XC@col@rlet[#1]{#2}}{}}
-\def\XC@col@rlet[#1]#2[#3]#4%
- {\begingroup
- \edef\@@cls{#1}\XC@edef\@@nam{#2}\XC@sdef\@@mod{#3}\XC@edef\@@clr{#4}%
- \XC@info\@@clr\@@tmp\XC@@tstfalse
- \ifnum\@@tmp=\@ne\ifx\@@mod\@empty
- \ifx\@@cls\@empty
- \XC@@tsttrue
- \else
- \edef\@@tmp
- {\expandafter\expandafter\expandafter\@secondoffive
- \csname\string\color@\@@clr\endcsname}%
- \ifx\@@cls\@@tmp\XC@@tsttrue\fi
- \fi
- \fi\fi
- \ifXC@@tst
- \XC@logdef\@@nam\XC@c@l@rlet\@@nam\@@clr
- \else
- \extractcolorspec\@@clr\@@clr
- \ifx\@@mod\@empty\else
- \expandafter\convertcolorspec\@@clr\@@mod\@@clr
- \edef\@@clr{{\@@mod}{\@@clr}}\fi
- \edef\@@tmp{\noexpand\XC@definecolor[\@@cls]{\@@nam}\@@clr}%
- \fi
- \expandafter\endgroup\@@tmp\xglobal@stop}
-\def\XC@c@l@rlet#1#2%
- {\@ifundefinedcolor{#2}%
- {\c@lor@error{`#2'}\let\@@tmp\@empty}%
- {\edef\@@tmp
- {\ifglobalcolors\global\else\xglobal@\fi
- \noexpand\XC@let@cc{\string\color@#1}{\string\color@#2}}}}
-\def\DefineNamedColor#1%
- {\@nameuse{XC@\ifdefinecolors defin\else prepar\fi ecolor}[#1]}
-\def\preparecolor{\@testopt{\XC@preparecolor}{}}
-\def\XC@preparecolor[#1]#2%
- {\@testopt{\XC@preparec@lor[#1]{#2}}\colornameprefix}
-\def\XC@preparec@lor[#1]#2[#3]#4#5%
- {\XC@sdef\@@cls{#1}\XC@edef\@@nam{#2}%
- \XC@getmodclr01{#4}{#5}{}%
- {\xdef\XC@@stack
- {\ifx\XC@@stack\@empty\else\XC@@stack,\fi{#1}{\@@nam}{#3}%
- {\ifx\@@Mod\XC@mod@ignore\@@mod\else\@@Mod\fi}{\@@clr}}}}
-\let\XC@@stack\@empty
-\def\definecolors#1%
- {\let\XC@@cmd\definecolor\let\XC@@glb\xglobal@
- \expandafter\XC@definecolors#1,,}
-\def\XC@definecolors#1,%
- {\@ifxempty{#1}{}{\expandafter\XC@definec@lors#1=#1=:\XC@definecolors}}
-\def\XC@definec@lors#1=#2=#3:%
- {\XC@edef\@@nam{#1}\XC@edef\@@arg{#2}%
- \let\next\XC@definec@l@rs\expandafter\next\XC@@stack,,\@nnil}
-\def\XC@definec@l@rs#1,%
- {\ifx,#1,\let\next\remove@to@nnil\else\XC@defin@c@l@rs#1\fi\next}
-\def\XC@defin@c@l@rs#1#2#3#4#5%
- {\def\@@tmp{#2}%
- \ifx\@@tmp\@@arg
- \let\xglobal@\XC@@glb\XC@@cmd[#1]{\@@nam}[#3]{#4}{#5}%
- \let\next\remove@to@nnil
- \fi}
-\def\providecolors#1%
- {\let\XC@@cmd\providecolor\let\XC@@glb\xglobal@
- \expandafter\XC@definecolors#1,,}
-\def\definecolorset
- {\let\XC@@cmd\definecolor\@testopt{\XC@definecolorset}{}}
-\def\XC@definecolorset[#1]#2#3#4#5%
- {\XC@getmodclr10{#2}{}{}%
- {\XC@@getmodfalse\XC@edef\XC@@tmp{#5}\let\XC@@glb\xglobal@
- \def\XC@definec@lorset##1,##2;%
- {\@ifxempty{##1}{}%
- {\let\xglobal@\XC@@glb
- \XC@@cmd[#1]{#3##1#4}{\@@mod}{##2}\XC@definec@lorset}}%
- \expandafter\XC@definec@lorset\XC@@tmp;,;\XC@@getmodtrue}}
-\def\providecolorset
- {\let\XC@@cmd\providecolor\@testopt{\XC@definecolorset}{}}
-\def\preparecolorset
- {\ifdefinecolors\let\XC@@cmd\definecolor\else\let\XC@@cmd\preparecolor\fi
- \@testopt{\XC@definecolorset}{}}
-\def\definecolorseries#1#2#3%
- {\@testopt{\XC@definecolorseries{#1}{#2}{#3}}{}}
-\def\XC@definecolorseries#1#2#3[#4]#5%
- {\@testopt{\XC@definec@lorseries{#1}{#2}{#3}[#4]{#5}}{}}
-\def\XC@definec@lorseries#1#2#3[#4]#5[#6]#7%
- {\begingroup
- \XC@sdef\@@mod{#2}%
- \@ifxempty{#4}{\extractcolorspec{#5}\@@clr}{\edef\@@clr{{#4}{#5}}}%
- \expandafter\convertcolorspec\@@clr\@@mod\@@clr
- \@namexdef{\string\colorB@#1}{{\@@mod}{\@@clr}}%
- \edef\@@met{#3}%
- \ifx\@@met\XC@met@last
- \@ifxempty{#6}{\extractcolorspec{#7}\@@tmp}{\edef\@@tmp{{#6}{#7}}}%
- \expandafter\convertcolorspec\@@tmp\@@mod\@@tmp
- \XC@inflate\@@mod\@@tmp\@@clr\@@tmp
- \expandafter\XC@sub\@@tmp,\@@tmp
- \else
- \edef\@@tmp{#7}%
- \fi
- \@namexdef{\string\colorD@#1}{{\@@met}{\@@tmp}}%
- \endgroup}
-\def\resetcolorseries{\@testopt{\XC@resetcolorseries}{}}
-\def\XC@resetcolorseries[#1]#2%
- {\begingroup
- \@namexdef
- {\string\color@#2}{\noexpand\xcolor@{}{}\@nameuse{\string\colorB@#2}}%
- \XC@let@Nc\@@tmp{\string\colorD@#2}%
- \edef\@@met{\expandafter\@firstoftwo\@@tmp}%
- \edef\@@tmp{\expandafter\@secondoftwo\@@tmp}%
- \ifx\@@met\XC@met@step\else
- \edef\@@scl{\@ifxempty{#1}\colorseriescycle{#1}}%
- \expandafter\XC@calc@\@@tmp,,,,:D%
- \fi
- \@namexdef{\string\colorS@#2}{\@@tmp}%
- \endgroup}
-\def\XC@step#1%
- {\let\xcolor@\@gobbletwo\edef\@@tmp{\@nameuse{\string\color@#1}}%
- \expandafter\XC@st@p\@@tmp{#1}%
- \@namexdef{\string\color@#1}{\noexpand\xcolor@{}{}{\@@mod}{\@@tmp}}}
-\def\XC@st@p#1#2#3%
- {\def\@@mod{#1}\def\@@tmp{#2}\edef\@@vec{\@nameuse{\string\colorS@#3}}%
- \@whilenum\@tempcnta>\z@\do
- {\XC@inflate\@@mod\@@tmp\@@vec\@@tmp
- \expandafter\XC@add\@@tmp,\@@tmp \expandafter\XC@calc@\@@tmp,,,,:U%
- \advance\@tempcnta\m@ne}}
-\def\XC@stepabs#1%
- {\edef\@@tmp{\@nameuse{\string\colorB@#1}}%
- \expandafter\XC@st@p\@@tmp{#1}%
- \edef\@@tmp
- {\def\noexpand\@@mod{\@@mod}\def\noexpand\@@clr{\@@tmp}}}
-\def\blendcolors{\@ifstar{\XC@blendcolors\colorblend}{\XC@blendcolors{}}}
-\def\XC@blendcolors#1#2%
- {\edef\colorblend{#1}\XC@edef\XC@@tmp{#2}%
- \ifx\XC@@tmp\@empty
- \xglobal@\blendcolorsfalse
- \else
- \xglobal@\blendcolorstrue
- \expandafter\XC@blendc@lors\XC@@tmp!!\@nil
- \fi
- \xglobalize@\colorblend \xglobal@stop}
-\def\XC@blendc@lors!#1!#2!#3\@nil
- {\@ifxempty{#1}{}%
- {\@ifxempty{#2}%
- {\edef\colorblend{\colorblend!#1!white}}%
- {\edef\colorblend{\colorblend!#1!#2}\XC@blendc@lors!#3!\@nil}}}
-\blendcolors{}
-\def\maskcolors{\@testopt{\XC@maskcolors}{}}
-\def\XC@maskcolors[#1]#2%
- {\XC@edef\colormask{#2}%
- \ifx\colormask\@empty
- \xglobal@\maskcolorsfalse \def\XC@mmod{}\def\XC@mclr{}%
- \else
- \xglobal@\maskcolorstrue \extractcolorspecs\colormask\XC@mmod\XC@mclr
- \@ifxempty{#1}{}%
- {\convertcolorspec\XC@mmod\XC@mclr{#1}\XC@mclr \XC@sdef\XC@mmod{#1}}%
- \XC@coremodel\XC@mmod\XC@mclr
- \fi
- \xglobalize@\colormask \xglobalize@\XC@mmod \xglobalize@\XC@mclr
- \xglobal@stop}
-\maskcolors{}
-\DeclareRobustCommand\color
- {\@ifnextchar[\@undeclaredcolor\@declaredcolor}
-\def\@undeclaredcolor[#1]#2%
- {\begingroup
- \let\@@cls\@empty
- \XC@getmodclr12{#1}{#2}{}%
- {\ifblendcolors
- \ifx\colorblend\@empty\else
- \edef\@@mix{\expandafter\@gobble\colorblend}\@tempswafalse
- \XC@coremodel\@@mod\@@clr\@xcolor@{}{}\@@mod\@@clr
- \fi
- \fi
- \ifconvertcolorsU
- \edef\@@tmp{\XC@tgt@mod{\@@mod}}%
- \convertcolorspec\@@mod\@@clr\@@tmp\@@clr \let\@@mod\@@tmp
- \fi
- \ifmaskcolors
- \convertcolorspec\@@mod\@@clr\XC@mmod\@@clr
- \let\@@mod\XC@mmod
- \XC@inflate\@@mod\XC@mclr\@@clr\@@tmp
- \expandafter\XC@mul\@@tmp,\@@clr
- \fi
- \edef\@@tmp{\noexpand\XC@undeclaredcolor{\@@mod}{\@@clr}}%
- \expandafter\endgroup\@@tmp}}
-\def\XC@undeclaredcolor#1#2%
- {\@ifundefinedmodel{#1}%
- {\c@lor@error{model `#1'}}%
- {\@nameuse{color@#1}\current@color{#2}%
- \edef\XC@current@color{\noexpand\xcolor@{}{\current@color}{#1}{#2}}%
- \XC@display}}
-\def\@declaredcolor#1%
- {\XC@edef\XC@@tmp{#1}\XC@@tstfalse
- \ifcase\XC@type\XC@@tmp\relax \XC@@tsttrue\or \relax\else
- \ifblendcolors\XC@@tsttrue\fi \ifmaskcolors\XC@@tsttrue\fi
- \ifconvertcolorsU\XC@@tsttrue\fi
- \fi
- \ifXC@@tst
- \expandafter\XC@declaredcolor\else
- \expandafter\XC@declaredc@lor\fi}
-\def\XC@declaredcolor
- {\XC@split\XC@@tmp
- \edef\@@tmp{\noexpand\@undeclaredcolor[\@@mod]{\@@clr}}%
- \expandafter\endgroup\@@tmp}
-\def\XC@declaredc@lor
- {\XC@let@Nc\XC@current@color{\string\color@\XC@@tmp}%
- \edef\current@color{\XC@current@color}%
- \XC@display}
-\def\textcolor#1#{\@textcolor{#1}}
-\def\@textcolor#1#2#3{\protect\leavevmode{\color#1{#2}#3}}
-\def\pagecolor
- {\begingroup
- \let\ignorespaces\endgroup \let\set@color\set@page@color
- \color}
-\def\colorbox#1#{\protect\color@box{#1}}
-\def\color@box#1#2{\color@b@x\relax{\color#1{#2}}}
-\def\fcolorbox#1#{\color@fbox{#1}}
-\def\color@fbox#1#2#3#{\protect\color@fb@x{#1}{#2}{#3}}
-\def\color@fb@x#1#2#3#4%
- {\color@b@x{\fboxsep\z@\color#1{#2}\XC@fbox}%
- {\@ifxempty{#3}{\color#1}{\color#3}{#4}}}
-\long\def\color@b@x#1#2#3%
- {\leavevmode
- \setbox\z@\hbox{\kern\fboxsep{\set@color#3}\kern\fboxsep}%
- \dimen@\ht\z@\advance\dimen@\fboxsep\ht\z@\dimen@
- \dimen@\dp\z@\advance\dimen@\fboxsep\dp\z@\dimen@
- {#1{#2\color@block{\wd\z@}{\ht\z@}{\dp\z@}\box\z@}}}
-\def\XC@frameb@x#1%
- {\hbox
- {\@tempdima\fboxrule \advance\@tempdima\fboxsep
- \advance\@tempdima\dp\@tempboxa
- \setbox\@tempboxa\hbox
- {\lower\@tempdima\hbox
- {\vbox
- {\kern\fboxrule
- \hbox{\kern\fboxrule#1%
- \vbox{\kern\fboxsep\box\@tempboxa\kern\fboxsep}%
- #1\kern\fboxrule}%
- \kern\fboxrule}}}%
- \@tempdima\wd\@tempboxa
- \edef\@tempa{{\the\@tempdima}{\the\ht\@tempboxa}{\the\dp\@tempboxa}}%
- \box\@tempboxa\kern-\@tempdima\expandafter\boxframe\@tempa}}
-\ifXC@@fbox
- \let\@frameb@x\XC@frameb@x \let\XC@fbox\fbox
-\else
- \def\XC@fbox{\let\@frameb@x\XC@frameb@x\fbox}
-\fi
-
-\ifnum\XC@@xcd@>\m@ne
-\def\XC@boxframe#1#2#3#4%
- {\hbox{\sbox\z@{\ifdim\fboxrule>\z@ #4\fi}%
- \wd\z@#1\relax\ht\z@#2\relax\dp\z@#3\relax\box\z@}}
-\fi
-\ifcase\XC@@xcd@
-\providecommand*\color@block[3]%
- {{\set@color\hbox
- {\dimen@#3\edef\@tempa{ \number\dimen@\space}%
- \dimen@#2\edef\@tempa{ \number\dimen@\@tempa}%
- \dimen@#1\relax
- \XC@special{\number\dimen@\@tempa XCcolorblock}}}}
-\providecommand*\boxframe[3]%
- {\XC@boxframe{#1}{#2}{#3}%
- {\dimen@#3\edef\@tempa{ \number\dimen@\space}%
- \dimen@#2\edef\@tempa{ \number\dimen@\@tempa}%
- \dimen@#1\relax
- \XC@special{\number\fboxrule\space\number\dimen@\@tempa XCboxframe}}}
-\or
-\providecommand*\boxframe[3]%
- {\XC@boxframe{#1}{#2}{#3}%
- {\dimen@#3\edef\@tempa{ 0 -\strip@pt\dimen@\space}%
- \edef\@tempb{\advance\dimen@\the\dimen@}%
- \dimen@#2\advance\dimen@-\fboxrule\@tempb
- \edef\@tempb{ \strip@pt\dimen@\space re s}%
- \dimen@#1\advance\dimen@-\fboxrule
- \edef\@tempb{ cm\@tempa\strip@pt\dimen@\@tempb}%
- \dimen@.5\fboxrule\edef\@tempa{ \strip@pt\dimen@}%
- \XC@special
- {0.996264 0 0 0.996264 0 0 cm
- \strip@pt\fboxrule\space w [] 0 d 2 J 0 j 4 M
- 1 0 0 1\@tempa\@tempa\@tempb}}}
-\fi
-\providecommand*\color@block[3]%
- {{\set@color\rlap{\ifcolors@\vrule\@width#1\@height#2\@depth#3\fi}}}
-\providecommand*\boxframe[3]%
- {\hbox
- {\dimen@#2\advance\dimen@#3\relax
- \lower#3\vbox
- {\hrule\@height\fboxrule
- \@tempdima-0.5\fboxrule \ifodd\fboxrule\advance\@tempdima\m@ne sp\fi
- \kern\@tempdima
- \hbox
- {\advance\dimen@-\fboxrule
- \vrule\@width\fboxrule\@height\dimen@\@depth\z@
- \@tempdima#1\advance\@tempdima-\tw@\fboxrule \kern\@tempdima
- \vrule\@width\fboxrule\@height\dimen@\@depth\z@}%
- \kern-0.5\fboxrule
- \hrule\@height\fboxrule}}}
-\def\@xcolor@#1#2#3#4%
- {\XC@sdef\@@mod{#3}\edef\@@clr{#4}%
- \ifx\@@mix\@empty\else\expandafter\@xcolor@@\@@mix!!!!\@nil\fi
- \if@tempswa
- \XC@let@Nc\@@tmp{XC@cnv@\@@mod @compl}%
- \ifx\@@tmp\relax \expandafter\XC@calc@\@@clr,,,,:C\else
- \expandafter\@@tmp\@@clr,\fi
- \let\@@clr\@@tmp
- \fi}
-\def\@xcolor@@#1!#2!#3!#4!#5\@nil
- {\dimen@\@ifxempty{#1}{100}{#1}\p@
- \edef\@@mix{\@ifxempty{#2}{white}{#2}}%
- \ifdim\dimen@=100\p@
- \expandafter\XC@postfix\@@mix]\relax
- \else\ifdim\dimen@=\z@
- \extractcolorspecs\@@mix\@@mod\@@clr
- \else
- \XC@let@Nc\@@tmp{XC@clr@\@@mod @\@@mix}%
- \ifx\@@tmp\relax
- \extractcolorspec\@@mix\@@tmp
- \ifx\@@mod\XC@mod@gray
- \edef\@@mod{\expandafter\@firstoftwo\@@tmp}%
- \edef\@@tmp{\expandafter\@secondoftwo\@@tmp}%
- \convertcolorspec\XC@mod@gray\@@clr\@@mod\@@clr
- \else
- \expandafter\convertcolorspec\@@tmp\@@mod\@@tmp
- \fi
- \else
- \ifx\@@mod\XC@mod@hsb\expandafter\XC@extract@hue\@@clr:\@@hue\fi
- \fi
- \XC@inflate\@@mod\@@clr\@@tmp\@@tmp
- \expandafter\XC@mix\@@tmp,\@@clr
- \fi\fi
- \@ifxempty{#3}%
- {\@ifxempty{#4}{}{\@xcolor@@!#4!#5\@nil}}%
- {\@xcolor@@#3!#4!#5\@nil}}
-\def\XC@split#1%
- {\begingroup\XC@edef\@@tmp{#1}\expandafter\XC@split@i\@@tmp>>\@nnil}
-\def\XC@split@i#1>%
- {\def\@@tmp{#1}\XC@split@ii#1:\@nil \XC@func}
-\def\XC@split@ii#1:#2\@nil
- {\@ifxempty{#2}{\XC@split@vi}{\XC@split@iii#1,,:#2}}
-\def\XC@split@iii#1,#2,#3:#4:%
- {\edef\XC@@mod{#1}\let\@tempa\@empty
- \ifx,#2,\XC@@tsttrue\@tempdima\z@\else\XC@@tstfalse\@tempdima#2\p@\fi
- \XC@split@iv#4;,;}
-\def\XC@split@iv#1,#2;%
- {\@ifxempty{#1}%
- {\let\XC@@clr\@empty \@tempa \expandafter\XC@calc@\XC@@clr,,,,:U%
- \let\@@mod\XC@@mod \let\@@clr\@@tmp}
- {\XC@append\@tempa{\XC@split@v{#1}{#2}}%
- \ifXC@@tst\advance\@tempdima#2\p@\fi
- \XC@split@iv}}
-\def\XC@split@v#1#2%
- {\def\@@tmp{#1}\XC@split@vi
- \ifx\@@mod\XC@@mod\else
- \convertcolorspec\@@mod\@@clr\XC@@mod\@@clr
- \fi
- \dimen@#2\p@ \rdivide\dimen@\@tempdima
- \edef\@@scl{\strip@pt\dimen@}%
- \expandafter\XC@calc@\@@clr,,,,:S%
- \ifx\XC@@clr\@empty\let\XC@@clr\@@tmp\else
- \XC@inflate\XC@@mod\XC@@clr\@@tmp\@@tmp
- \expandafter\XC@add\@@tmp,\XC@@clr
- \fi}
-\def\XC@split@vi{\count@\z@ \expandafter\XC@split@vii\@@tmp!\@nil}
-\def\XC@split@vii#1%
- {\ifx#1-\advance\count@\@ne\expandafter\XC@split@vii
- \else\expandafter\XC@split@viii\expandafter#1\fi}
-\def\XC@split@viii#1!#2\@nil
- {\edef\@@nam{#1}\edef\@@mix{#2}%
- \ifodd\count@\@tempswatrue\else\@tempswafalse\fi
- \@ifundefinedcolor\@@nam
- {\c@lor@error{`\@@nam'}\def\@@nam{black}}{}%
- \let\xcolor@\@xcolor@\@nameuse{\string\color@\@@nam}}
-\def\XC@postfix#1#2]#3\relax
- {\begingroup
- \if[#1\@tempcnta#2\relax\XC@stepabs\@@nam
- \else\@tempcnta\z@
- \@tfor\@@tok:=#1#2\do
- {\if+\@@tok\advance\@tempcnta\@ne
- \else\if-\@@tok\advance\@tempcnta\m@ne
- \else\@tempcnta\z@\expandafter\@break@tfor\fi\fi}%
- \ifnum\@tempcnta=\z@\relax\else\XC@step\@@nam\fi
- \let\@@tmp\@empty
- \fi\expandafter\endgroup\@@tmp}
-\def\XC@func#1>{\@ifxempty{#1}{\remove@to@nnil}{\XC@fun@#1,>\XC@func}}
-\def\XC@fun@#1,#2>{\@nameuse{XC@func@#1}#2,,>}
-\def\XC@func@wheel#1,#2,#3>{\XC@func@wh@el{#1}{#2}0}
-\def\XC@func@twheel#1,#2,#3>{\XC@func@wh@el{#1}{#2}1}
-\def\XC@func@wh@el#1#2#3%
- {\convertcolorspec\@@mod\@@clr
- {\ifcase#3 \XC@mod@Hsb\or\XC@mod@tHsb\fi}\@@clr
- \expandafter\XC@extract@hue\@@clr:\@@hue \dimen@#1\p@
- \@ifxempty{#2}{}%
- {\rdivide\dimen@{#2}\lshift\dimen@
- \dimen@\rangeHsb\dimen@\rshift\dimen@}%
- \advance\dimen@\@@hue\p@ \rdivide\dimen@\rangeHsb
- \edef\@@hue{\strip@pt\dimen@}\XC@calcU\@@hue\@@hue
- \ifcase#3
- \expandafter\XC@replace@hue\@@clr:\@@hue,\@@clr
- \or
- \XC@c@lcS\rangeHsb{}\@@hue\@@hue
- \expandafter\XC@replace@hue\@@clr:\@@hue,\@@clr
- \convertcolorspec\XC@mod@tHsb\@@clr\XC@mod@hsb\@@clr
- \fi
- \let\@@mod\XC@mod@hsb}
-\def\XC@display
- {\XC@bcolor\XC@let@cN{\string\color@.}\XC@current@color
- \ifnum\XC@type{.}=1
- \PackageWarning{xcolor}{Incompatible color definition}\else
- \ifnum\XC@tracing>2
- \begingroup \let\xcolor@\@empty \def\@nil{\string\@nil}%
- \PackageInfo{xcolor}{Setting color `\XC@current@color'}%
- \endgroup
- \fi\fi
- \XC@mcolor\set@color\XC@ecolor\ignorespaces}
-\let\XC@bcolor\relax
-\let\XC@mcolor\relax
-\let\XC@ecolor\relax
-\def\XC@bordercolor#1#2%
- {\extractcolorspec{#2}\XC@@tmp
- \expandafter\convertcolorspec\XC@@tmp\XC@mod@rgb\XC@@tmp
- \expandafter\edef\csname @#1bordercolor\endcsname
- {\expandafter\XC@strip@comma\XC@@tmp,,\@nnil}}
-\def\XC@pdfborder#1 #2 #3\relax
- {\def\@@scl{80}\XC@calc@#1,#2,#3,,:S%
- \edef\@pdfborder{\expandafter\XC@strip@comma\@@tmp,,\@nnil}}
-\@ifXCopt{table}{%
- \def\rowcolors
- {\@ifstar{\@rowcmdfalse\rowc@lors}{\@rowcmdtrue\rowc@lors}}
- \def\rowc@lors{\@testopt{\rowc@l@rs}{}}
- \def\rowc@l@rs[#1]#2#3#4%
- {\global\rownum=\z@
- \global\@rowcolorstrue
- \@ifxempty{#3}%
- {\def\@oddrowcolor{\@norowcolor}}%
- {\def\@oddrowcolor{\gdef\CT@row@color{\CT@color{#3}}}}%
- \@ifxempty{#4}%
- {\def\@evenrowcolor{\@norowcolor}}%
- {\def\@evenrowcolor{\gdef\CT@row@color{\CT@color{#4}}}}%
- \if@rowcmd
- \def\@rowcolors
- {#1\if@rowcolors
- \noalign{\relax\ifnum\rownum<#2\@norowcolor\else
- \ifodd\rownum\@oddrowcolor\else\@evenrowcolor\fi\fi}%
- \fi}%
- \else
- \def\@rowcolors
- {\if@rowcolors
- \ifnum\rownum<#2\noalign{\@norowcolor}\else
- #1\noalign{\ifodd\rownum\@oddrowcolor\else\@evenrowcolor\fi}\fi
- \fi}%
- \fi
- \CT@everycr{\@rowc@lors\the\everycr}%
- \ignorespaces}
- \def\@rowc@lors{\noalign{\global\advance\rownum\@ne}\@rowcolors}
- \let\@rowcolors\@empty
- \def\showrowcolors{\noalign{\global\@rowcolorstrue}\@rowcolors}
- \def\hiderowcolors{\noalign{\global\@rowcolorsfalse\@norowcolor}}
- \def\@norowcolor{\global\let\CT@row@color\relax}
- \@norowcolor
- \newif\if@rowcolors
- \newif\if@rowcmd
- \@ifundefined{rownum}{\newcount\rownum}{}
- \def\CT@extract#1\columncolor#2#3\@nil
- {\if!#2%
- \let\CT@column@color\@empty
- \else
- \if[#2%
- \expandafter\CT@extractb
- \else
- \XC@edef\XC@@tmp{#2}%
- \edef\CT@column@color{\noexpand\CT@color{\XC@@tmp}}%
- \expandafter\CT@extractd
- \fi
- {#1}#3\@nil
- \fi}
-}{}
-\def\extractcolorspec#1#2%
- {\XC@split{#1}\edef\@@tmp{{\@@mod}{\@@clr}}\aftergroupdef#2\@@tmp}
-\def\extractcolorspecs#1#2#3%
- {\extractcolorspec{#1}#3%
- \edef#2{\expandafter\@firstoftwo#3}%
- \edef#3{\expandafter\@secondoftwo#3}}
-\def\XC@extract@hue#1,#2:#3{\edef#3{#1}}
-\def\XC@replace@hue#1,#2:#3,#4{\edef#4{#3,#2}}
-\def\@ifundefinedcolor#1{\@ifundefined{\string\color@#1}}
-\def\@ifundefinedmodel#1{\@ifundefined{color@#1}}
-\def\XC@type#1%
- {\expandafter\expandafter\expandafter\XC@typ@
- \csname\string\color@#1\endcsname\@empty\@empty\@empty\XC@@}
-\def\XC@typ@#1#2#3#4\XC@@
- {\ifx#1\relax 0\else
- \ifx#1\xcolor@
- \ifx$#2$%
- \ifx$#3$4\else3\fi\@gobbletwo
- \else2\fi\@gobbletwo
- \else1\fi
- \fi}
-\def\XC@info#1#2%
- {\XC@edef#2{#1}%
- \if.#2\def#2{0}\else\expandafter\in@\expandafter>\expandafter{#2}%
- \ifin@\def#2{4}\else\expandafter\in@\expandafter:\expandafter{#2}%
- \ifin@\def#2{3}\else\expandafter\in@\expandafter!\expandafter{#2}%
- \ifin@\def#2{2}\else\edef#2{\noexpand\in@{/-}{/#2}}#2%
- \edef#2{\ifin@2\else1\fi}\fi\fi\fi\fi}
-\def\tracingcolors{\begingroup\afterassignment\XC@tracingcolors\count@}
-\def\XC@tracingcolors{\aftergroupdef\XC@tracing{\the\count@}}
-\tracingcolors=0
-\def\XC@logdef#1%
- {\ifnum\XC@tracing>1
- \@ifundefinedcolor{#1}%
- {\ifnum\XC@tracing>2
- \PackageInfo{xcolor}{Defining color `#1'}%
- \fi}%
- {\PackageInfo{xcolor}{Redefining color `#1'}}%
- \fi}
-\newenvironment*{testcolors}[1][rgb,cmyk,hsb,HTML]%
- {\let\@@nam\@empty\count@\z@
- \@for\@@tmp:=#1\do
- {\advance\count@\@ne
- \XC@sdef\@@tmp{\@@tmp}\edef\@@nam{\@@nam{\@@tmp}}}%
- \edef\@@num{\the\count@}%
- \def\XC@@gt{\textgreater}\def\@@tmp{OT1}%
- \ifx\f@encoding\@@tmp
- \@expandtwoargs\in@{,\f@family,}{,cmtt,pcr,}%
- \ifin@\def\XC@@gt{>}\fi
- \fi
- \def\XC@@xcp@{-1}\ifnum\XC@tracing>1 \def\XC@tracing{1}\fi
- \def\testcolor{\@testopt{\@testcolor}{}}%
- \def\@testcolor[##1]##2%
- {\XC@mdef\@@mod{##1}\XC@edef\@@clr{##2}%
- \ifx\@@mod\@empty
- \let\@@arg\@@clr\XC@replace\@@arg>\XC@@gt\else
- \edef\@@arg{[\@@mod]{\@@clr}}\XC@definecolor[]{*}\@@mod\@@clr
- \def\@@clr{*}\fi
- \XC@append\@@arg{&}\extractcolorspecs\@@clr\@@mod\@@clr
- \@testc@lor}%
- \def\@testc@lor
- {\count@\z@
- \expandafter\@tfor\expandafter\@@tmp\expandafter:\expandafter=\@@nam\do
- {\ifx\@@clr\@empty
- \edef\@@cmd{\noexpand\textbf{\@@tmp}}%
- \else
- \convertcolorspec\@@mod\@@clr\@@tmp\@@cmd
- \edef\@@cmd
- {\noexpand\@testc@l@r{\@@tmp}{\@@cmd}%
- \ifx\@@mod\@@tmp\noexpand\underline\fi
- {\expandafter\XC@strip@comma\@@cmd,,\@nnil}}%
- \fi
- \expandafter\XC@append\expandafter\@@arg\expandafter{\@@cmd}%
- \advance\count@\@ne
- \ifnum\count@=\@@num\XC@append\@@arg{\\}\else\XC@append\@@arg{&}\fi}%
- \@@arg}%
- \def\@testc@l@r##1##2%
- {\fboxsep\z@\fbox{\colorbox[##1]{##2}{\phantom{XX}}} }%
- \tabular{@{}l*{\@@num}{l}@{}}%
- \def\@@arg{\textbf{color}& }\let\@@clr\@empty\@testc@lor}%
- {\endtabular\ignorespacesafterend}
-\def\color@setgroup{\begingroup\set@color}
-\let\color@begingroup\begingroup
-\def\color@endgroup{\endgraf\endgroup}
-\def\color@hbox{\hbox\bgroup\color@begingroup}
-\def\color@vbox{\vbox\bgroup\color@begingroup}
-\def\color@endbox{\color@endgroup\egroup}
-\def\convertcolorspec#1#2#3#4%
- {\begingroup
- \XC@sdef\sm{#1}\XC@sdef\tm{#3}\edef\@@tmp{#2}%
- \ifx\sm\XC@mod@named\extractcolorspecs\@@tmp\sm\@@tmp\fi
- \ifx\sm\tm\else\csname XC@cnv@\sm\expandafter\endcsname\@@tmp,\fi
- \aftergroupdef#4\@@tmp}
-\def\XC@coremodel#1#2%
- {\XC@ifxcase#1%
- {\XC@mod@RGB {\convertcolorspec#1#2\XC@mod@rgb#2\let#1\XC@mod@rgb}%
- \XC@mod@HTML{\convertcolorspec#1#2\XC@mod@rgb#2\let#1\XC@mod@rgb}%
- \XC@mod@Hsb {\convertcolorspec#1#2\XC@mod@hsb#2\let#1\XC@mod@hsb}%
- \XC@mod@tHsb{\convertcolorspec#1#2\XC@mod@hsb#2\let#1\XC@mod@hsb}%
- \XC@mod@HSB {\convertcolorspec#1#2\XC@mod@hsb#2\let#1\XC@mod@hsb}%
- \XC@mod@Gray{\convertcolorspec#1#2\XC@mod@gray#2\let#1\XC@mod@gray}%
- \XC@mod@wave{\convertcolorspec#1#2\XC@mod@hsb#2\let#1\XC@mod@hsb}%
- \XC@mod@named{}%
- \XC@mod@ps{}}%
- {\expandafter\XC@calc@#2,,,,:N\let#2\@@tmp}}
-\def\XC@cnv@rgb#1,#2,#3,%
- {\XC@ifxcase\tm
- {\XC@mod@cmy {\XC@calc@#1,#2,#3,,:C}%
- \XC@mod@cmyk
- {\XC@calc@#1,#2,#3,,:C\expandafter\XC@cnv@cmy@cmyk\@@tmp,}%
- \XC@mod@RGB {\edef\@@scl{\rangeRGB}\XC@calc@#1,#2,#3,,:M}%
- \XC@mod@HTML{\edef\@@scl{\@cclv}\XC@calc@#1,#2,#3,,:M%
- \expandafter\XC@calc@\@@tmp,,:H%
- \expandafter\XC@cnv@rgb@HTML\@@tmp,}%
- \XC@mod@gray{\XC@cnv@rgb@gray#1,#2,#3,}%
- \XC@mod@Gray{\XC@cnv@rgb@gray#1,#2,#3,\XC@cnv@gray\@@tmp,}}%
- {\XC@cnv@rgb@hsb#1,#2,#3,\XC@cnv@hsb@}}
-\def\XC@cnv@rgb@
- {\ifx\tm\XC@mod@rgb\else\expandafter\XC@cnv@rgb\@@tmp,\fi}
-\def\XC@cnv@rgb@hsb#1,#2,#3,%
- {\count@\z@
- \ifdim#2\p@>#1\p@ \else\advance\count@4 \fi
- \ifdim#3\p@>#2\p@ \else\advance\count@2 \fi
- \ifdim#1\p@>#3\p@ \else\advance\count@1 \fi
- \ifcase\count@\or
- \XC@c@v@rgb@hsb{#3}{#2}{#1}3{}\or
- \XC@c@v@rgb@hsb{#2}{#1}{#3}1{}\or
- \XC@c@v@rgb@hsb{#2}{#3}{#1}3-\or
- \XC@c@v@rgb@hsb{#1}{#3}{#2}5{}\or
- \XC@c@v@rgb@hsb{#3}{#1}{#2}5-\or
- \XC@c@v@rgb@hsb{#1}{#2}{#3}1-\or
- \def\@tempa{0}\def\@tempb{0}\XC@calcN{#3}\@tempc
- \fi
- \edef\@@tmp{\@tempa,\@tempb,\@tempc}}
-\def\XC@c@v@rgb@hsb#1#2#3#4#5%
- {\XC@calcN{#1}\@tempc \llshiftset\dimen@{#1}%
- \llshiftset\@tempdimb{-#3}\advance\@tempdimb\dimen@
- \llshiftset\@tempdima{-#5#2}\advance\@tempdima#5\dimen@
- \advance\@tempdima#4\@tempdimb \rdivide\@tempdima{6\@tempdimb}%
- \edef\@tempa{\ifdim\@tempdima>\p@1\else\strip@pt\@tempdima\fi}%
- \rdivide\@tempdimb\dimen@
- \edef\@tempb{\strip@pt\@tempdimb}}
-\def\XC@cnv@rgb@gray#1,#2,#3,%
- {\llshiftset\dimen@{#1}\@tempdima30\dimen@
- \llshiftset\dimen@{#2}\advance\@tempdima59\dimen@
- \llshiftset\dimen@{#3}\advance\@tempdima11\dimen@
- \rrshift\@tempdima \rdivide\@tempdima{100}%
- \edef\@@tmp{\strip@pt\@tempdima}}
-\def\XC@cnv@rgb@HTML#1,#2,#3,%
- {\edef\@@tmp{#1#2#3}}
-\def\XC@cnv@cmy#1,#2,#3,%
- {\XC@ifxcase\tm
- {\XC@mod@cmyk{\XC@cnv@cmy@cmyk#1,#2,#3,}%
- \XC@mod@gray{\XC@cnv@rgb@gray#1,#2,#3,\XC@calcC\@@tmp\@@tmp}%
- \XC@mod@Gray{\XC@cnv@rgb@gray#1,#2,#3,\XC@calcC\@@tmp\@@tmp
- \XC@cnv@gray\@@tmp,}}%
- {\XC@calc@#1,#2,#3,,:C\XC@cnv@rgb@}}
-\def\XC@cnv@cmy@cmyk#1,#2,#3,%
- {\edef\@@scl
- {\ifdim#1\p@<#2\p@
- \ifdim#1\p@<#3\p@ #1\else #3\fi \else
- \ifdim#2\p@<#3\p@ #2\else #3\fi \fi}%
- \expandafter\XC@calc@\adjustUCRBG,:S%
- \expandafter\XC@c@v@cmy@cmyk\@@tmp,#1,#2,#3,}
-\def\XC@c@v@cmy@cmyk#1,#2,#3,#4,#5,#6,#7,%
- {\XC@add#5,#6,#7,,-#1,-#2,-#3,,\@@tmp \edef\@@tmp{\@@tmp,#4}%
- \expandafter\XC@calc@\@@tmp,:N}
-\def\XC@cnv@cmyk#1,#2,#3,#4,%
- {\XC@ifxcase\tm
- {\XC@mod@gray{\XC@cnv@rgb@gray#1,#2,#3,\edef\@@arg{#4}%
- \XC@calcT\@@tmp\@@tmp \XC@calcC\@@tmp\@@tmp}%
- \XC@mod@Gray{\XC@cnv@rgb@gray#1,#2,#3,\edef\@@arg{#4}%
- \XC@calcT\@@tmp\@@tmp \XC@calcC\@@tmp\@@tmp \XC@cnv@gray\@@tmp,}}%
- {\XC@cnv@cmyk@cmy#1,#2,#3,#4,%
- \ifx\tm\XC@mod@cmy\else\expandafter\XC@cnv@cmy\@@tmp,\fi}}
-\def\XC@cnv@cmyk@cmy#1,#2,#3,#4,%
- {\edef\@@arg{#4}\XC@calc@#1,#2,#3,,:T}
-\def\XC@cnv@hsb#1,#2,#3,%
- {\XC@ifxcase\tm
- {\XC@mod@Hsb {\XC@cnv@hsb@Hsb#1,#2,#3,}%
- \XC@mod@tHsb{\XC@cnv@hsb@Hsb#1,#2,#3,\expandafter\XC@cnv@Hsb\@@tmp,}%
- \XC@mod@HSB {\edef\@@scl{\rangeHSB}\XC@calc@#1,#2,#3,,:M}}%
- {\XC@cnv@hsb@rgb#1,#2,#3,\XC@cnv@rgb@}}
-\def\XC@cnv@hsb@
- {\ifx\tm\XC@mod@hsb\else\expandafter\XC@cnv@hsb\@@tmp,\fi}
-\def\XC@cnv@hsb@rgb#1,#2,#3,%
- {\llshiftset\dimen@{#1}\dimen@6\dimen@ \rrshift\dimen@
- \afterassignment\dimen@\count@=\the\dimen@
- \edef\@@tmp{\strip@pt\dimen@}%
- \ifodd\count@\else\XC@calcC\@@tmp\@@tmp\fi
- \edef\@@tmp
- {\ifcase\count@ 0,\@@tmp,1\or \@@tmp,0,1\or 1,0,\@@tmp\or
- 1,\@@tmp,0\or \@@tmp,1,0\or 0,1,\@@tmp\or 0,\@@tmp,1\fi}%
- \edef\@@scl{#2}\expandafter\XC@calc@\@@tmp,,:S%
- \expandafter\XC@calc@\@@tmp,,:C%
- \edef\@@scl{#3}\expandafter\XC@calc@\@@tmp,,:S%
- \expandafter\XC@calc@\@@tmp,,:N}
-\def\XC@cnv@hsb@Hsb#1,#2,#3,%
- {\XC@c@lcS\rangeHsb{,#2,#3}{#1}\@@tmp}
-\def\XC@cnv@gray#1,%
- {\XC@ifxcase\tm
- {\XC@mod@rgb {\XC@calcN{#1}\@@tmp \edef\@@tmp{\@@tmp,\@@tmp,\@@tmp}}%
- \XC@mod@cmy {\XC@calcC{#1}\@@tmp \edef\@@tmp{\@@tmp,\@@tmp,\@@tmp}}%
- \XC@mod@cmyk{\XC@calcC{#1}\@@tmp \edef\@@tmp{0,0,0,\@@tmp}}%
- \XC@mod@RGB {\edef\@@scl{\rangeRGB}\XC@calcM{#1}\@@tmp
- \edef\@@tmp{\@@tmp,\@@tmp,\@@tmp}}%
- \XC@mod@HTML{\edef\@@scl{\@cclv}\XC@calcM{#1}\@@tmp
- \XC@calcH\@@tmp\@@tmp \edef\@@tmp{\@@tmp\@@tmp\@@tmp}}%
- \XC@mod@HSB {\edef\@@scl{\rangeHSB}\XC@calcM{#1}\@@tmp
- \edef\@@tmp{0,0,\@@tmp}}%
- \XC@mod@Gray{\edef\@@scl{\rangeGray}\XC@calcM{#1}\@@tmp}}%
- {\XC@calcN{#1}\@@tmp \edef\@@tmp{0,0,\@@tmp}}}
-\def\XC@cnv@RGB#1,#2,#3,%
- {\edef\@@scl{\rangeRGB}\XC@calc@#1,#2,#3,,:D\XC@cnv@rgb@}
-\def\XC@cnv@HTML#1,%
- {\edef\@@tmp{\expandafter\@hex@Hex#1\relax}\expandafter\XC@cnv@HTML@\@@tmp
- \edef\@@scl{\@cclv}\expandafter\XC@calc@\@@tmp,,:D\XC@cnv@rgb@}
-\def\XC@cnv@HTML@#1#2#3#4#5#6%
- {\edef\@@tmp{\number"#1#2,\number"#3#4,\number"#5#6}}
-\def\XC@cnv@Hsb#1,#2,#3,%
- {\ifx\tm\XC@mod@tHsb\XC@cnv@@Hsb#1,#2,#3,\XC@cnv@Hsb@
- \else\XC@cnv@Hsb@hsb#1,#2,#3,\XC@cnv@hsb@\fi}
-\def\XC@cnv@Hsb@hsb#1,#2,#3,%
- {\XC@c@lcD\rangeHsb{,#2,#3}{#1}\@@tmp}
-\def\XC@cnv@@Hsb#1,#2,#3,#4%
- {\dimen@\rangeHsb\p@ \advance\dimen@\p@ \edef\@@tmp{\strip@pt\dimen@}%
- \edef\@@tmp{0,0;\rangetHsb;\rangeHsb,\rangeHsb;\@@tmp,\@@tmp;}%
- \dimen@#1\p@ \expandafter#4\@@tmp\@nnil
- \edef\@@tmp{\strip@pt\dimen@,#2,#3}}
-\def\XC@cnv@Hsb@#1,#2;#3,#4;%
- {\ifdim\dimen@<#4\p@
- \@tempdima#3\p@ \advance\@tempdima-#1\p@
- \@tempdimb#4\p@ \advance\@tempdimb-#2\p@
- \rdivide\@tempdima\@tempdimb
- \advance\dimen@-#2\p@ \rmultiply\dimen@{\strip@pt\@tempdima}%
- \advance\dimen@#1\p@ \expandafter\remove@to@nnil
- \else
- \def\@@tmp{\XC@cnv@Hsb@#3,#4;}\expandafter\@@tmp
- \fi}
-\def\XC@cnv@tHsb#1,#2,#3,%
- {\XC@cnv@@Hsb#1,#2,#3,\XC@cnv@tHsb@
- \ifx\tm\XC@mod@Hsb\else\expandafter\XC@cnv@Hsb\@@tmp,\fi}
-\def\XC@cnv@tHsb@#1,#2;#3,#4;%
- {\ifdim\dimen@<#3\p@
- \@tempdima#4\p@ \advance\@tempdima-#2\p@
- \@tempdimb#3\p@ \advance\@tempdimb-#1\p@
- \rdivide\@tempdima\@tempdimb
- \advance\dimen@-#1\p@ \rmultiply\dimen@{\strip@pt\@tempdima}%
- \advance\dimen@#2\p@ \expandafter\remove@to@nnil
- \else
- \def\@@tmp{\XC@cnv@tHsb@#3,#4;}\expandafter\@@tmp
- \fi}
-\def\XC@cnv@HSB#1,#2,#3,%
- {\edef\@@scl{\rangeHSB}\XC@calc@#1,#2,#3,,:D\XC@cnv@hsb@}
-\def\XC@cnv@Gray#1,%
- {\XC@c@lcD\rangeGray{}{#1}\@@tmp \XC@cnv@gray\@@tmp,}
-\def\XC@cnv@wave#1,%
- {\XC@cnv@wave@hsb#1,\XC@cnv@hsb@}
-\def\XC@cnv@wave@hsb#1,%
- {\@tempdima#1\p@
- \ifdim\@tempdima<440\p@
- \XC@c@v@wave@hsb{-.0166667}{7.33333}4{}\else
- \ifdim\@tempdima<490\p@
- \XC@c@v@wave@hsb{.02}{-8.8}4-\else
- \ifdim\@tempdima<510\p@
- \XC@c@v@wave@hsb{-.05}{25.5}2{}\else
- \ifdim\@tempdima<580\p@
- \XC@c@v@wave@hsb{.0142857}{-7.28571}2-\else
- \ifdim\@tempdima<645\p@
- \XC@c@v@wave@hsb{-.0153846}{9.92308}0{}\else
- \dimen@\z@ \fi\fi\fi\fi\fi
- \divide\dimen@6\relax
- \edef\@@tmp{\strip@pt\dimen@,1,}%
- \ifdim\@tempdima<420\p@
- \XC@c@v@wave@hsb{.0175}{-6.35}0{}\else
- \ifdim\@tempdima>700\p@
- \XC@c@v@wave@hsb{-.00875}{7.125}0{}\else
- \dimen@\p@ \fi\fi
- \edef\@@tmp{\@@tmp\strip@pt\dimen@}}
-\def\XC@c@v@wave@hsb#1#2#3#4%
- {\dimen@#1\@tempdima \advance\dimen@#2\p@
- \XC@calcR{\strip@pt\dimen@}\@tempa
- \dimen@#4\@tempa\p@ \advance\dimen@#3\p@}
-\def\XC@cnv@cmyk@compl#1,#2,#3,#4,%
- {\XC@cnv@cmyk@cmy#1,#2,#3,#4,%
- \expandafter\XC@calc@\@@tmp,,:C\expandafter\XC@cnv@cmy@cmyk\@@tmp,}
-\def\XC@cnv@hsb@compl#1,#2,#3,%
- {\lshiftset\dimen@{#1}\advance\dimen@\ifdim\dimen@<5\p@-\fi-5\p@
- \rshift\dimen@ \edef\@@tmp{\strip@pt\dimen@}%
- \lshiftset\dimen@{#3}\@tempdima#2\dimen@
- \@tempdimb\@tempdima \advance\@tempdimb10\p@ \advance\@tempdimb-\dimen@
- \ifdim\@tempdimb=\z@
- \edef\@@tmp{\@@tmp,0,0}%
- \else
- \rdivide\@tempdima\@tempdimb \rshift\@tempdimb
- \edef\@@tmp{\@@tmp,\strip@pt\@tempdima,\strip@pt\@tempdimb}%
- \fi}
-\def\substitutecolormodel#1#2%
- {\XC@sdef\XC@@tmp{\expandafter\XC@substitutecolormodel#2/ignore/\@nnil}%
- \ifx\XC@@tmp\XC@mod@ignore
- \XC@let@cN{color@#1}\color@ignore
- \else
- \expandafter\edef\csname color@#1\endcsname##1##2%
- {\noexpand\convertcolorspec
- \expandafter\noexpand\csname XC@mod@#1\endcsname{##2}%
- \expandafter\noexpand\csname XC@mod@\XC@@tmp\endcsname
- \noexpand\XC@@tmp\noexpand\expandafter
- \expandafter\noexpand\csname color@\XC@@tmp\endcsname
- \noexpand\expandafter##1\noexpand\expandafter{\noexpand\XC@@tmp}}%
- \fi
- \expandafter\xglobalize@\csname color@#1\endcsname \xglobal@stop
- \PackageInfo{xcolor}{Model `#1' substituted by `\XC@@tmp'}}
-\def\XC@substitutecolormodel#1/%
- {\@ifundefinedmodel{#1}{\XC@substitutecolormodel}{#1\remove@to@nnil}}
-\def\color@ignore#1#2{\def#1{}}
-\@ifundefinedmodel{rgb}%
- {\substitutecolormodel{rgb}{RGB/HTML/hsb/Hsb/HSB/cmy/cmyk/gray/Gray}}{}
-\@ifundefinedmodel{cmyk}{\substitutecolormodel{cmyk}{cmy/rgb}}{}
-\@ifundefinedmodel{cmy}%
- {\PackageInfo{xcolor}{Model `cmy' substituted by `cmy0'}
- \def\color@cmy#1#2{\color@cmyk#1{#2,0}}}{}
-\@ifundefinedmodel{hsb}{\@tempswatrue}%
- {\XC@ifcase\XC@@drv{{dvipdfm,textures}\@tempswatrue}\@tempswafalse}
-\if@tempswa
- \substitutecolormodel{hsb}{Hsb/HSB/rgb}
-\fi
-\@ifundefinedmodel{RGB}%
- {\substitutecolormodel{RGB}{HTML/rgb}}
- {\PackageInfo{xcolor}{Model `RGB' extended}
- \let\XC@color@RGB\color@RGB
- \def\color@RGB#1#2%
- {\relax\ifnum\rangeRGB=255
- \XC@color@RGB#1{#2}%
- \else
- \convertcolorspec\XC@mod@RGB{#2}\XC@mod@rgb\XC@@tmp
- \expandafter\color@rgb\expandafter#1\expandafter{\XC@@tmp}%
- \fi}}
-\@ifundefinedmodel{gray}{\substitutecolormodel{gray}{Gray/rgb}}{}
-\@ifundefinedmodel{HTML}{\substitutecolormodel{HTML}{rgb}}{}
-\@ifundefinedmodel{Hsb}{\substitutecolormodel{Hsb}{hsb}}{}
-\@ifundefinedmodel{tHsb}{\substitutecolormodel{tHsb}{hsb}}{}
-\@ifundefinedmodel{HSB}{\substitutecolormodel{HSB}{hsb}}{}
-\@ifundefinedmodel{Gray}{\substitutecolormodel{Gray}{gray}}{}
-\@ifundefinedmodel{wave}{\substitutecolormodel{wave}{hsb}}{}
-\def\XC@getcolor#1#2%
- {\begingroup\toks@{#1}\XC@getc@lor#1\XC@@\aftergroupdef#2{\@@tmp}}
-\def\XC@getc@lor#1#2\XC@@
- {\@ifxempty{#2}%
- {\expandafter\XC@getc@l@r#1\XC@@}%
- {\let\set@color\relax
- \ifx#1[%
- \expandafter\@undeclaredcolor\the\toks@\else
- \expandafter\@declaredcolor\expandafter{\the\toks@}\fi
- \let\@@tmp\XC@current@color}}
-\def\XC@getc@l@r#1#2\XC@@
- {\ifx#1\xcolor@
- \def\@@tmp{\xcolor@#2}%
- \else
- \let\set@color\relax
- \expandafter\@declaredcolor\expandafter{\the\toks@}%
- \let\@@tmp\XC@current@color
- \fi}
-\def\XC@usecolor#1{\expandafter\XC@usec@lor#1\XC@@}
-\def\XC@usec@lor#1#2\XC@@
- {\ifx#1\xcolor@
- \expandafter\expandafter\expandafter\c@lor@to@ps#1#2\@@
- \else
- \expandafter\expandafter\expandafter\expandafter\expandafter\expandafter
- \expandafter\c@lor@to@ps\csname\string\color@#1#2\endcsname\@@
- \fi
- \space}
-\let\XC@c@lor@to@ps\XC@usecolor
-\let\pst@getcolor\XC@getcolor
-\let\pst@usecolor\XC@usecolor
-\def\c@lor@special#1#2{\edef\@tempa{\write#1{#2}}\@tempa}
-\def\normalcolor{\let\current@color\default@color\set@color}
-\AtBeginDocument{\let\default@color\current@color}
-\XC@ifcase\XC@@drv
- {{dvipdf,dvipdfm,dvipdfmx,dvips,pctex32}%
- {\def\c@lor@@named#1,#2,#3\@@#4%
- {\edef#4{\expandafter\expandafter\expandafter\@thirdoffive
- \csname\string\color@#1\endcsname}}
- \def\define@color@named#1#2%
- {\@namedef{\string\color@#1}{{}{}{ \colornameprefix#1}{}{}}}}%
- {dvipsone,pctexps,pdftex,tcidvi,truetex,vtex,xetex}%
- {\def\c@lor@@named#1,#2,#3\@@#4%
- {\edef#4{\expandafter\expandafter\expandafter\@thirdoffive
- \csname\string\color@#1\endcsname}}
- \def\define@color@named#1#2%
- {\let\@@cls\@empty\@namedef{\string\color@#1}{{}{}{#2}{}{}}}}%
- {textures}%
- {\def\c@lor@@named#1,#2,#3\@@#4%
- {\edef\@tempa{\color@P@custom{#1}{\if!#2!1\else#2\fi}}%
- \expandafter\def\expandafter#4\@tempa}
- \def\define@color@named#1#2%
- {\edef\@tempa{{#1}{#2}}\expandafter\AddCustomColor\@tempa}
- \def\c@lor@ps@#1 #2\@@
- {\expandafter\expandafter\expandafter\expandafter\expandafter
- \expandafter\expandafter\c@lor@to@ps@
- \csname\string\color@#1\expandafter\endcsname\space
- #2. \@@{#1}}}%
- }{}
-\definecolorset{rgb/hsb/cmyk/gray}{}{}%
- {red,1,0,0/0,1,1/0,1,1,0/.3;%
- green,0,1,0/.33333,1,1/1,0,1,0/.59;%
- blue,0,0,1/.66667,1,1/1,1,0,0/.11;%
- brown,.75,.5,.25/.083333,.66667,.75/0,.25,.5,.25/.5475;%
- lime,.75,1,0/.20833,1,1/.25,0,1,0/.815;%
- orange,1,.5,0/.083333,1,1/0,.5,1,0/.595;%
- pink,1,.75,.75/0,.25,1/0,.25,.25,0/.825;%
- purple,.75,0,.25/.94444,1,.75/0,.75,.5,.25/.2525;%
- teal,0,.5,.5/.5,1,.5/.5,0,0,.5/.35;%
- violet,.5,0,.5/.83333,1,.5/0,.5,0,.5/.205}%
-\definecolorset{cmyk/rgb/hsb/gray}{}{}%
- {cyan,1,0,0,0/0,1,1/.5,1,1/.7;%
- magenta,0,1,0,0/1,0,1/.83333,1,1/.41;%
- yellow,0,0,1,0/1,1,0/.16667,1,1/.89;%
- olive,0,0,1,.5/.5,.5,0/.16667,1,.5/.39}
-\definecolorset{gray/rgb/hsb/cmyk}{}{}%
- {black,0/0,0,0/0,0,0/0,0,0,1;%
- darkgray,.25/.25,.25,.25/0,0,.25/0,0,0,.75;%
- gray,.5/.5,.5,.5/0,0,.5/0,0,0,.5;%
- lightgray,.75/.75,.75,.75/0,0,.75/0,0,0,.25;%
- white,1/1,1,1/0,0,1/0,0,0,0}
-\XC@@names
-\AtBeginDocument{\let\XC@@stack\@empty}
-\let\colornameprefix\XC@@nameprefix
-\XC@catcodes
-\csname xcolorcmd\endcsname
-\color{black}
-\endinput
-%%
-%% End of file `xcolor.sty'.
diff --git a/src/zabha.adoc b/src/zabha.adoc
new file mode 100644
index 0000000..a802908
--- /dev/null
+++ b/src/zabha.adoc
@@ -0,0 +1,68 @@
+== "Zabha" Extension for Byte and Halfword Atomic Memory Operations, Version 1.0
+
+The A-extension offers atomic memory operation (AMO) instructions for _words_,
+_doublewords_, and _quadwords_ (only for `AMOCAS`). The absence of atomic
+operations for subword data types necessitates emulation strategies. For bitwise
+operations, this emulation can be performed via word-sized bitwise AMO*
+instructions. For non-bitwise operations, emulation is achievable using
+word-sized `LR`/`SC` instructions.
+
+Several limitations arise from this emulation approach:
+
+. In systems with large-scale or Non-Uniform Memory Access (NUMA)
+ configurations, emulation based on `LR`/`SC` introduces issues related to
+ scalability and fairness, particularly under conditions of high contention.
+
+. Emulation of narrower AMOs through wider AMO* instructions on non-idempotent
+ IO memory regions may result in unintended side effects.
+
+. Utilizing wider AMO* instructions for emulating narrower AMOs risks activating
+ extraneous breakpoints or watchpoints.
+
+. In the absence of native support for subword atomics, compilers often resort
+ to inlining code sequences to provide the required emulation. This practice
+ contributes to an increase in code size, with consequent impacts on system
+ performance and memory utilization.
+
+The Zabha extension addresses these limitations by adding support for _byte_ and
+_halfword_ atomic memory operations to the RISC-V Unprivileged ISA. The Zabha
+extension depends upon the Zaamo standard extension.
+
+=== Byte and Halfword Atomic Memory Operation Instructions
+
+Zabha extension provides the `AMO[ADD|AND|OR|XOR|SWAP|MIN[U]|MAX[U]].[B|H]`
+instructions. If Zacas extension is also implemented, Zabha further provides the
+`AMOCAS.[B|H]` instructions.
+
+[wavedrom, zabha-ext-wavedrom-reg,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr:['AMO','AMO','AMO','AMO','AMO','AMO','AMO','AMO']},
+ {bits: 5, name: 'rd', attr:['dest','dest','dest','dest','dest','dest','dest','dest']},
+ {bits: 3, name: 'funct3', attr:['width=0/1','width=0/1','width=0/1','width=0/1','width=0/1','width=0/1','width=0/1','width=0/1']},
+ {bits: 5, name: 'rs1', attr:['addr','addr','addr','addr','addr','addr','addr','addr']},
+ {bits: 5, name: 'rs2', attr:['src','src','src','src','src','src','src','src']},
+ {bits: 1, name: 'rl'},
+ {bits: 1, name: 'aq', attr:['ordering','ordering','ordering','ordering','ordering','ordering','ordering','ordering']},
+ {bits: 5, name: 'funct5', attr:['AMOSWAP.B/H','AMOADD.B/H','AMOAND.B/H','AMOOR.B/H','AMOXOR.B/H','AMOMAX[U].B/H','AMOMIN[U].B/H','AMOCAS.B/H']},
+], config:{lanes: 1, hspace:1024}}
+....
+
+Byte and halfword AMOs always sign-extend the value placed in `rd`, and ignore
+the stem:[XLEN-1:2^{(width + 3)}] bits of the original value in `rs2`. The
+`AMOCAS.[B|H]` instructions similarly ignore the stem:[XLEN-1:2^{(width + 3)}]
+bits of the original value in `rd`.
+
+Similar to the AMOs specified in the A extension, the Zabha extension mandates
+that the address contained in the `rs1` register must be naturally aligned to
+the size of the operand. The same exception options as specified in the A
+extension are applicable in cases where the address is not naturally aligned.
+
+Similar to the AMOs specified in the A and Zacas extensions, the AMOs in the
+Zabha extension optionally provide release consistency semantics, using the `aq`
+and `rl` bits, to help implement multiprocessor synchronization.
+
+[NOTE]
+====
+Zabha omits _byte_ and _halfword_ support for `LR` and `SC` due to low utility.
+====
diff --git a/src/zacas.adoc b/src/zacas.adoc
new file mode 100644
index 0000000..8abf67b
--- /dev/null
+++ b/src/zacas.adoc
@@ -0,0 +1,259 @@
+== "Zacas" Extension for Atomic Compare-and-Swap (CAS) Instructions, Version 1.0.0
+
+Compare-and-Swap (CAS) provides an easy and typically faster way to perform
+thread synchronization operations when supported as a hardware instruction. CAS
+is typically used by lock-free and wait-free algorithms. This extension defines
+CAS instructions to operate on 32-bit, 64-bit, and 128-bit (RV64 only) data
+values. The CAS instruction supports the C++11 atomic compare and exchange
+operation.
+
+While compare-and-swap for XLEN wide data may be accomplished using LR/SC, the
+CAS atomic instructions scale better to highly parallel systems than LR/SC.
+Many lock-free algorithms, such as a lock-free queue, require manipulation of
+pointer variables. A simple CAS operation may not be sufficient to guard against
+what is commonly referred to as the ABA problem in such algorithms that
+manipulate pointer variables. To avoid the ABA problem, the algorithms associate
+a reference counter with the pointer variable and perform updates using a
+quadword compare and swap (of both the pointer and the counter). The double and
+quadword CAS instructions support implementation of algorithms for ABA problem
+avoidance.
+
+The Zacas extension depends upon the Zaamo extension.
+
+=== Word/Doubleword/Quadword CAS (AMOCAS.W/D/Q) Instructions
+
+[wavedrom, , svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr:'AMO'},
+ {bits: 5, name: 'rd', attr:'dest'},
+ {bits: 3, name: 'funct3', attr:['010', '011', '100']},
+ {bits: 5, name: 'rs1', attr:'addr'},
+ {bits: 5, name: 'rs2', attr:'src'},
+ {bits: 1, name: 'rl'},
+ {bits: 1, name: 'aq'},
+ {bits: 5, name: '00101', attr:['AMOCAS.W', 'AMOCAS.D', 'AMOCAS.Q']},
+], config:{lanes: 1, hspace:1024}}
+....
+
+For RV32, `AMOCAS.W` atomically loads a 32-bit data value from address in `rs1`,
+compares the loaded value to the 32-bit value held in `rd`, and if the comparison
+is bitwise equal, then stores the 32-bit value held in `rs2` to the original
+address in `rs1`. The value loaded from memory is placed into register `rd`. The
+operation performed by `AMOCAS.W` for RV32 is as follows:
+
+[listing]
+----
+ temp = mem[X(rs1)]
+ if ( temp == X(rd) )
+ mem[X(rs1)] = X(rs2)
+ X(rd) = temp
+----
+
+`AMOCAS.D` is similar to `AMOCAS.W` but operates on 64-bit data values.
+
+For RV32, `AMOCAS.D` atomically loads 64-bits of a data value from address in
+`rs1`, compares the loaded value to a 64-bit value held in a register pair
+consisting of `rd` and `rd+1`, and if the comparison is bitwise equal, then
+stores the 64-bit value held in the register pair `rs2` and `rs2+1` to the
+original address in `rs1`. The value loaded from memory is placed into the
+register pair `rd` and `rd+1`. The instruction requires the first register in
+the pair to be even numbered; encodings with odd numbered registers specified
+in `rs2` and `rd` are reserved. When the first register of a source register
+pair is `x0`, then both halves of the pair read as zero. When the first
+register of a destination register pair is `x0`, then the entire register
+result is discarded and neither destination register is written.
+The operation performed by `AMOCAS.D` for RV32 is as follows:
+
+<<<
+
+[listing]
+ temp0 = mem[X(rs1)+0]
+ temp1 = mem[X(rs1)+4]
+ comp0 = (rd == x0) ? 0 : X(rd)
+ comp1 = (rd == x0) ? 0 : X(rd+1)
+ swap0 = (rs2 == x0) ? 0 : X(rs2)
+ swap1 = (rs2 == x0) ? 0 : X(rs2+1)
+ if ( temp0 == comp0 ) && ( temp1 == comp1 )
+ mem[X(rs1)+0] = swap0
+ mem[X(rs1)+4] = swap1
+ endif
+ if ( rd != x0 )
+ X(rd) = temp0
+ X(rd+1) = temp1
+ endif
+
+For RV64, `AMOCAS.W` atomically loads a 32-bit data value from address in
+`rs1`, compares the loaded value to the lower 32 bits of the value held in `rd`,
+and if the comparison is bitwise equal, then stores the lower 32 bits of the
+value held in `rs2` to the original address in `rs1`. The 32-bit value loaded
+from memory is sign-extended and is placed into register `rd`. The operation
+performed by `AMOCAS.W` for RV64 is as follows:
+
+[listing]
+ temp[31:0] = mem[X(rs1)]
+ if ( temp[31:0] == X(rd)[31:0] )
+ mem[X(rs1)] = X(rs2)[31:0]
+ X(rd) = SignExtend(temp[31:0])
+
+For RV64, `AMOCAS.D` atomically loads 64-bits of a data value from address in
+`rs1`, compares the loaded value to a 64-bit value held in `rd`, and if the
+comparison is bitwise equal, then stores the 64-bit value held in `rs2` to the
+original address in `rs1`. The value loaded from memory is placed into register
+`rd`. The operation performed by `AMOCAS.D` for RV64 is as follows:
+[listing]
+ temp = mem[X(rs1)]
+ if ( temp == X(rd) )
+ mem[X(rs1)] = X(rs2)
+ X(rd) = temp
+
+`AMOCAS.Q` (RV64 only) atomically loads 128-bits of a data value from address in
+`rs1`, compares the loaded value to a 128-bit value held in a register pair
+consisting of `rd` and `rd+1`, and if the comparison is bitwise equal, then
+stores the 128-bit value held in the register pair `rs2` and `rs2+1` to the
+original address in `rs1`. The value loaded from memory is placed into the
+register pair `rd` and `rd+1`. The instruction requires the first register in
+the pair to be even numbered; encodings with odd numbered registers specified in
+`rs2` and `rd` are reserved. When the first register of a source register pair
+is `x0`, then both halves of the pair read as zero. When the first register of a
+destination register pair is `x0`, then the entire register result is discarded
+and neither destination register is written. The operation performed by
+`AMOCAS.Q` is as follows:
+
+<<<
+
+[listing]
+ temp0 = mem[X(rs1)+0]
+ temp1 = mem[X(rs1)+8]
+ comp0 = (rd == x0) ? 0 : X(rd)
+ comp1 = (rd == x0) ? 0 : X(rd+1)
+ swap0 = (rs2 == x0) ? 0 : X(rs2)
+ swap1 = (rs2 == x0) ? 0 : X(rs2+1)
+ if ( temp0 == comp0 ) && ( temp1 == comp1 )
+ mem[X(rs1)+0] = swap0
+ mem[X(rs1)+8] = swap1
+ endif
+ if ( rd != x0 )
+ X(rd) = temp0
+ X(rd+1) = temp1
+ endif
+
+[NOTE]
+====
+Some algorithms may load the previous data value of a memory location into the
+register used as the compare data value source by a Zacas instruction. When
+using a Zacas instruction that uses a register pair to source the compare value,
+the two registers may be loaded using two individual loads. The two individual
+loads may read an inconsistent pair of values but that is not an issue since the
+`AMOCAS` operation itself uses an atomic load-pair from memory to obtain the
+data value for its comparison.
+
+The following example code sequence illustrates the use of `AMOCAS.D` in a RV32
+implementation to atomically increment a 64-bit counter.
+[listing]
+# a0 - address of the counter.
+increment:
+ lw a2, (a0) # Load current counter value using
+ lw a3, 4(a0) # two individual loads.
+retry:
+ mv a6, a2 # Save the low 32 bits of the current value.
+ mv a7, a3 # Save the high 32 bits of the current value.
+ addi a4, a2, 1 # Increment the low 32 bits.
+ sltu a1, a4, a2 # Determine if there is a carry out.
+ add a5, a3, a1 # Add the carry if any to high 32 bits.
+ amocas.d.aqrl a2, a4, (a0)
+ bne a2, a6, retry # If amocas.d failed then retry
+ bne a3, a7, retry # using current values loaded by amocas.d.
+ ret
+====
+
+Just as for AMOs in the A extension, `AMOCAS.W/D/Q` requires that the address
+held in `rs1` be naturally aligned to the size of the operand (i.e., 16-byte
+aligned for _quadwords_, eight-byte aligned for _doublewords_, and four-byte
+aligned for _words_). And the same exception options apply if the address
+is not naturally aligned.
+
+Just as for AMOs in the A extension, the `AMOCAS.W/D/Q` optionally provide
+release consistency semantics, using the `aq` and `rl` bits, to help implement
+multiprocessor synchronization. The memory operation performed by an
+`AMOCAS.W/D/Q`, when successful, has acquire semantics if `aq` bit is 1 and has
+release semantics if `rl` bit is 1. The memory operation performed by an
+`AMOCAS.W/D/Q`, when not successful, has acquire semantics if `aq` bit is 1 but
+does not have release semantics, regardless of `rl`.
+
+A FENCE instruction may be used to order the memory read access and, if
+produced, the memory write access by an `AMOCAS.W/D/Q` instruction.
+
+[NOTE]
+====
+An unsuccessful `AMOCAS.W/D/Q` may either not perform a memory write or may
+write back the old value loaded from memory. The memory write, if produced, does
+not have release semantics, regardless of `rl`.
+Irrespective of whether a write is actually performed, the instruction is
+treated as an AMO for the purposes of the RVWMO PPO rules.
+====
+
+An `AMOCAS.W/D/Q` instruction always requires write permissions.
+
+[NOTE]
+====
+The following example code sequence illustrates the use of `AMOCAS.Q` to
+implement the _enqueue_ operation for a non-blocking concurrent queue using the
+algorithm outlined in cite:[queue]. The algorithm atomically operates on a
+pointer and its associated modification counter using the `AMOCAS.Q` instruction
+to avoid the ABA problem.
+
+[listing]
+# Enqueue operation of a non-blocking concurrent queue.
+# Data structures used by the queue:
+# structure pointer_t {ptr: node_t *, count: uint64_t}
+# structure node_t {next: pointer_t, value: data type}
+# structure queue_t {Head: pointer_t, Tail: pointer_t}
+# Inputs to the procedure:
+# a0 - address of Tail variable
+# a4 - address of a new node to insert at tail
+enqueue:
+ ld a6, (a0) # a6 = Tail.ptr
+ ld a7, 8(a0) # a7 = Tail.count
+ ld a2, (a6) # a2 = Tail.ptr->next.ptr
+ ld a3, 8(a6) # a3 = Tail.ptr->next.count
+ ld t1, (a0)
+ ld t2, 8(a0)
+ bne a6, t1, enqueue # Retry if Tail & next are not consistent
+ bne a7, t2, enqueue # Retry if Tail & next are not consistent
+ bne a2, x0, move_tail # Was tail pointing to the last node?
+ mv t1, a2 # Save Tail.ptr->next.ptr
+ mv t2, a3 # Save Tail.ptr->next.count
+ addi a5, a3, 1 # Link the node at the end of the list
+ amocas.q.aqrl a2, a4, (a6)
+ bne a2, t1, enqueue # Retry if CAS failed
+ bne a3, t2, enqueue # Retry if CAS failed
+ addi a5, a7, 1 # Update Tail to the inserted node
+ amocas.q.aqrl a6, a4, (a0)
+ ret # Enqueue done
+move_tail: # Tail was not pointing to the last node
+ addi a3, a7, 1 # Try to swing Tail to the next node
+ amocas.q.aqrl a6, a2, (a0)
+ j enqueue # Retry
+
+====
+
+<<<
+
+=== Additional AMO PMAs
+
+There are four levels of PMA support defined for AMOs in the A extension. Zacas
+defines three additional levels of support: `AMOCASW`, `AMOCASD`, and `AMOCASQ`.
+
+`AMOCASW` indicates that in addition to instructions indicated by `AMOArithmetic`
+level support, the `AMOCAS.W` instruction is supported. `AMOCASD` indicates that
+in addition to instructions indicated by `AMOCASW` level support, the `AMOCAS.D`
+instruction is supported. `AMOCASQ` indicates that in addition to instructions
+indicated by `AMOCASD` level support, the `AMOCAS.Q` instruction is supported.
+
+[NOTE]
+====
+`AMOCASW/D/Q` require `AMOArithmetic` level support as the `AMOCAS.W/D/Q`
+instructions require ability to perform an arithmetic comparison and a swap
+operation.
+====
diff --git a/src/zam.tex b/src/zam.tex
deleted file mode 100644
index a193869..0000000
--- a/src/zam.tex
+++ /dev/null
@@ -1,26 +0,0 @@
-\chapter{``Zam'' Standard Extension for Misaligned Atomics, v0.1}
-\label{sec:zam}
-
-This chapter defines the ``Zam'' extension, which extends the ``A'' extension by standardizing support for misaligned atomic memory operations (AMOs).
-On platforms implementing ``Zam'', misaligned AMOs need only execute atomically with respect
-to other accesses (including non-atomic loads and stores) to the same address and of the same size.
-More precisely, execution environments implementing ``Zam'' are subject to the following axiom:
-
-\newcommand{\misalignedatomicityaxiom}{If $r$ and $w$ are paired misaligned load and store instructions from a hart $h$ with the same address and of the same size, then there can be no store instruction $s$ from a hart other than $h$ with the same address and of the same size as $r$ and $w$ such that a store operation generated by $s$ lies in between memory operations generated by $r$ and $w$ in the global memory order. Furthermore, there can be no load instruction $l$ from a hart other than $h$ with the same address and of the same size as $r$ and $w$ such that a load operation generated by $l$ lies between two memory operations generated by $r$ or by $w$ in the global memory order.}
-
-\vspace{-0.2in}
-\paragraph{Atomicity Axiom for misaligned atomics}
-\label{rvwmo:ax:misaligned}
-\misalignedatomicityaxiom
-
-This restricted form of atomicity is intended to balance the needs of applications which require support for misaligned atomics and the ability of the implementation to actually provide the necessary degree of atomicity.
-
-Aligned instructions under ``Zam'' continue to behave as they normally do under RVWMO.
-
-\begin{commentary}
- The intention of ``Zam'' is that it can be implemented in one of two ways:
- \begin{enumerate}
- \item On hardware that natively supports atomic misaligned accesses to the address and size in question (e.g., for misaligned accesses within a single cache line): by simply following the same rules that would be applied for aligned AMOs.
- \item On hardware that does not natively support misaligned accesses to the address and size in question: by trapping on all instructions (including loads) with that address and size and executing them (via any number of memory operations) inside a mutex that is a function of the given memory address and access size. AMOs may be emulated by splitting them into separate load and store operations, but all preserved program order rules (e.g., incoming and outgoing syntactic dependencies) must behave as if the AMO is still a single memory operation.
- \end{enumerate}
-\end{commentary}
diff --git a/src/zawrs.adoc b/src/zawrs.adoc
new file mode 100644
index 0000000..ef95417
--- /dev/null
+++ b/src/zawrs.adoc
@@ -0,0 +1,103 @@
+== "Zawrs" Extension for Wait-on-Reservation-Set instructions, Version 1.01
+
+The Zawrs extension defines a pair of instructions to be used in polling loops
+that allows a core to enter a low-power state and wait on a store to a memory
+location. Waiting for a memory location to be updated is a common pattern in
+many use cases such as:
+
+. Contenders for a lock waiting for the lock variable to be updated.
+
+. Consumers waiting on the tail of an empty queue for the producer to queue
+ work/data. The producer may be code executing on a RISC-V hart, an accelerator
+ device, an external I/O agent.
+
+. Code waiting on a flag to be set in memory indicative of an event occurring.
+ For example, software on a RISC-V hart may wait on a "done" flag to be set in
+ memory by an accelerator device indicating completion of a job previously
+ submitted to the device.
+
+Such use cases involve polling on memory locations, and such busy loops can be a
+wasteful expenditure of energy. To mitigate the wasteful looping in such usages,
+a `WRS.NTO` (WRS-with-no-timeout) instruction is provided. Instead of polling
+for a store to a specific memory location, software registers a reservation set
+that includes all the bytes of the memory location using the `LR` instruction.
+Then a subsequent `WRS.NTO` instruction would cause the hart to temporarily
+stall execution in a low-power state until a store occurs to the reservation set
+or an interrupt is observed.
+
+Sometimes the program waiting on a memory update may also need to carry out a
+task at a future time or otherwise place an upper bound on the wait. To support
+such use cases a second instruction `WRS.STO` (WRS-with-short-timeout) is
+provided that works like `WRS.NTO` but bounds the stall duration to an
+implementation-define short timeout such that the stall is terminated on the
+timeout if no other conditions have occurred to terminate the stall. The
+program using this instruction may then determine if its deadline has been
+reached.
+
+[NOTE]
+====
+The instructions in the Zawrs extension are only useful in conjunction with the
+LR instruction, which is provided by the Zalrsc component of the A extension.
+====
+[[Zawrs]]
+=== Wait-on-Reservation-Set Instructions
+
+The `WRS.NTO` and `WRS.STO` instructions cause the hart to temporarily stall
+execution in a low-power state as long as the reservation set is valid and no
+pending interrupts, even if disabled, are observed. For `WRS.STO` the stall
+duration is bounded by an implementation defined short timeout. These
+instructions are available in all privilege modes.
+
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 'opcode', attr: ['SYSTEM(0x73)'] },
+ {bits: 5, name: 'rd', attr: ['0'] },
+ {bits: 3, name: 'funct3', attr: ['0'] },
+ {bits: 5, name: 'rs1', attr: ['0'] },
+ {bits: 12, name: 'funct12', attr:['WRS.NTO(0x0d)', 'WRS.STO(0x1d)'] },
+], config:{lanes: 1, hspace:1024}}
+....
+
+<<<
+
+Hart execution may be stalled while the following conditions are all satisfied:
+[loweralpha]
+ . The reservation set is valid
+ . If `WRS.STO`, a "short" duration since start of stall has not elapsed
+ . No pending interrupt is observed (see the rules below)
+
+While stalled, an implementation is permitted to occasionally terminate the
+stall and complete execution for any reason.
+
+`WRS.NTO` and `WRS.STO` instructions follow the rules of the `WFI` instruction
+for resuming execution on a pending interrupt.
+
+When the `TW` (Timeout Wait) bit in `mstatus` is set and `WRS.NTO` is executed
+in any privilege mode other than M mode, and it does not complete within an
+implementation-specific bounded time limit, the `WRS.NTO` instruction will cause
+an illegal-instruction exception.
+
+When executing in VS or VU mode, if the `VTW` bit is set in `hstatus`, the
+`TW` bit in `mstatus` is clear, and the `WRS.NTO` does not complete within an
+implementation-specific bounded time limit, the `WRS.NTO` instruction will cause
+a virtual-instruction exception.
+
+[NOTE]
+====
+Since the `WRS.STO` and `WRS.NTO` instructions can complete execution for
+reasons other than stores to the reservation set, software will likely need
+a means of looping until the required stores have occurred.
+
+The duration of a `WRS.STO` instruction's timeout may vary significantly within
+and among implementations. In typical implementations this duration should be
+roughly in the range of 10 to 100 times an on-chip cache miss latency or a
+cacheless access to main memory.
+
+`WRS.NTO`, unlike `WFI`, is not specified to cause an illegal-instruction
+exception if executed in U-mode when the governing `TW` bit is 0. `WFI` is
+typically not expected to be used in U-mode and on many systems may promptly
+cause an illegal-instruction exception if used at U-mode. Unlike `WFI`,
+`WRS.NTO` is expected to be used by software in U-mode when waiting on
+memory but without a deadline for that wait.
+====
diff --git a/src/zc.adoc b/src/zc.adoc
new file mode 100644
index 0000000..1a1758e
--- /dev/null
+++ b/src/zc.adoc
@@ -0,0 +1,2589 @@
+[#Zc]
+== "Zc*" Extension for Code Size Reduction, Version 1.0.0
+
+=== Zc* Overview
+
+Zc* is a group of extensions that define subsets of the existing C extension (Zca, Zcd, Zcf) and new extensions which only contain 16-bit encodings.
+
+Zcm* all reuse the encodings for _c.fld_, _c.fsd_, _c.fldsp_, _c.fsdsp_.
+
+.Zc* extension overview
+[width="100%",options=header,cols="3,1,1,1,1,1,1"]
+|====================================================================================
+|Instruction |Zca |Zcf |Zcd |Zcb |Zcmp |Zcmt
+7+|*The Zca extension is added as way to refer to instructions in the C extension that do not include the floating-point loads and stores*
+|C excl. c.f* |yes | | | | |
+7+|*The Zcf extension is added as a way to refer to compressed single-precision floating-point load/stores*
+|c.flw | |rv32 | | | |
+|c.flwsp | |rv32 | | | |
+|c.fsw | |rv32 | | | |
+|c.fswsp | |rv32 | | | |
+7+|*The Zcd extension is added as a way to refer to compressed double-precision floating-point load/stores*
+|c.fld | | |yes | | |
+|c.fldsp | | |yes | | |
+|c.fsd | | |yes | | |
+|c.fsdsp | | |yes | | |
+7+|*Simple operations for use on all architectures*
+|c.lbu | | | |yes | |
+|c.lh | | | |yes | |
+|c.lhu | | | |yes | |
+|c.sb | | | |yes | |
+|c.sh | | | |yes | |
+|c.zext.b | | | |yes | |
+|c.sext.b | | | |yes | |
+|c.zext.h | | | |yes | |
+|c.sext.h | | | |yes | |
+|c.zext.w | | | |yes | |
+|c.mul | | | |yes | |
+|c.not | | | |yes | |
+7+|*PUSH/POP and double move which overlap with _c.fsdsp_. Complex operations intended for embedded CPUs*
+|cm.push | | | | |yes |
+|cm.pop | | | | |yes |
+|cm.popret | | | | |yes |
+|cm.popretz | | | | |yes |
+|cm.mva01s | | | | |yes |
+|cm.mvsa01 | | | | |yes |
+7+|*Table jump which overlaps with _c.fsdsp_. Complex operations intended for embedded CPUs*
+|cm.jt | | | | | |yes
+|cm.jalt | | | | | |yes
+|====================================================================================
+
+[#C]
+=== C
+
+The C extension is the superset of the following extensions:
+
+* Zca
+* Zcf if F is specified (RV32 only)
+* Zcd if D is specified
+
+As C defines the same instructions as Zca, Zcf, and Zcd, the rule is that:
+
+* C always implies Zca
+* C+F implies Zcf (RV32 only)
+* C+D implies Zcd
+
+[reftext="Zce"]
+=== Zce
+
+The Zce extension is intended to be used for microcontrollers, and includes all relevant Zc extensions.
+
+* Specifying Zce on RV32 without F includes Zca, Zcb, Zcmp, Zcmt
+* Specifying Zce on RV32 with F includes Zca, Zcb, Zcmp, Zcmt _and_ Zcf
+* Specifying Zce on RV64 always includes Zca, Zcb, Zcmp, Zcmt
+** Zcf doesn't exist for RV64
+
+Therefore common ISA strings can be updated as follows to include the relevant Zc extensions, for example:
+
+* RV32IMC becomes RV32IM_Zce
+* RV32IMCF becomes RV32IMF_Zce
+
+[#misaC]
+=== MISA.C
+
+MISA.C is set if the following extensions are selected:
+
+* Zca and not F
+* Zca, Zcf and F (but not D) is specified (RV32 only)
+* Zca, Zcf and Zcd if D is specified (RV32 only)
+** this configuration excludes Zcmp, Zcmt
+* Zca, Zcd if D is specified (RV64 only)
+** this configuration excludes Zcmp, Zcmt
+
+[reftext="Zca"]
+=== Zca
+
+The Zca extension is added as way to refer to instructions in the C extension that do not include the floating-point loads and stores.
+
+Therefore it _excluded_ all 16-bit floating point loads and stores: _c.flw_, _c.flwsp_, _c.fsw_, _c.fswsp_, _c.fld_, _c.fldsp_, _c.fsd_, _c.fsdsp_.
+
+[NOTE]
+====
+the C extension only includes F/D instructions when D and F are also specified
+====
+
+[reftext="Zcf"]
+=== Zcf (RV32 only)
+
+Zcf is the existing set of compressed single precision floating point loads and stores: _c.flw_, _c.flwsp_, _c.fsw_, _c.fswsp_.
+
+Zcf is only relevant to RV32, it cannot be specified for RV64.
+
+The Zcf extension depends on the <<Zca>> and F extensions.
+
+[reftext="Zcd"]
+=== Zcd
+
+Zcd is the existing set of compressed double precision floating point loads and stores: _c.fld_, _c.fldsp_, _c.fsd_, _c.fsdsp_.
+
+The Zcd extension depends on the <<Zca>> and D extensions.
+
+[reftext="Zcb"]
+=== Zcb
+
+Zcb has simple code-size saving instructions which are easy to implement on all CPUs.
+
+All encodings are currently reserved for all architectures, and have no conflicts with any existing extensions.
+
+NOTE: Zcb can be implemented on _any_ CPU as the instructions are 16-bit versions of existing 32-bit instructions from the application class profile.
+
+The Zcb extension depends on the <<Zca>> extension.
+
+As shown on the individual instruction pages, many of the instructions in Zcb depend upon another extension being implemented. For example, _c.mul_ is only implemented if M or Zmmul is implemented, and _c.sext.b_ is only implemented if Zbb is implemented.
+
+The _c.mul_ encoding uses the CA register format along with other instructions such as _c.sub_, _c.xor_ etc.
+
+[NOTE]
+
+ _c.sext.w_ is a pseudoinstruction for _c.addiw rd, 0_ (RV64)
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|yes
+|yes
+|c.lbu _rd'_, uimm(_rs1'_)
+|<<#insns-c_lbu>>
+
+|yes
+|yes
+|c.lhu _rd'_, uimm(_rs1'_)
+|<<#insns-c_lhu>>
+
+|yes
+|yes
+|c.lh _rd'_, uimm(_rs1'_)
+|<<#insns-c_lh>>
+
+|yes
+|yes
+|c.sb _rs2'_, uimm(_rs1'_)
+|<<#insns-c_sb>>
+
+|yes
+|yes
+|c.sh _rs2'_, uimm(_rs1'_)
+|<<#insns-c_sh>>
+
+|yes
+|yes
+|c.zext.b _rsd'_
+|<<#insns-c_zext_b>>
+
+|yes
+|yes
+|c.sext.b _rsd'_
+|<<#insns-c_sext_b>>
+
+|yes
+|yes
+|c.zext.h _rsd'_
+|<<#insns-c_zext_h>>
+
+|yes
+|yes
+|c.sext.h _rsd'_
+|<<#insns-c_sext_h>>
+
+|
+|yes
+|c.zext.w _rsd'_
+|<<#insns-c_zext_w>>
+
+|yes
+|yes
+|c.not _rsd'_
+|<<#insns-c_not>>
+
+|yes
+|yes
+|c.mul _rsd'_, _rs2'_
+|<<#insns-c_mul>>
+
+|===
+
+<<<
+
+[#Zcmp]
+=== Zcmp
+
+The Zcmp extension is a set of instructions which may be executed as a series of existing 32-bit RISC-V instructions.
+
+This extension reuses some encodings from _c.fsdsp_. Therefore it is _incompatible_ with <<Zcd>>,
+ which is included when C and D extensions are both present.
+
+NOTE: Zcmp is primarily targeted at embedded class CPUs due to implementation complexity. Additionally, it is not compatible with application class profiles.
+
+The Zcmp extension depends on the <<Zca>> extension.
+
+The PUSH/POP assembly syntax uses several variables, the meaning of which are:
+
+* _reg_list_ is a list containing 1 to 13 registers (ra and 0 to 12 s registers)
+** valid values: {ra}, {ra, s0}, {ra, s0-s1}, {ra, s0-s2}, ..., {ra, s0-s8}, {ra, s0-s9}, {ra, s0-s11}
+** note that {ra, s0-s10} is _not_ valid, giving 12 lists not 13 for better encoding
+* _stack_adj_ is the total size of the stack frame.
+** valid values vary with register list length and the specific encoding, see the instruction pages for details.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|yes
+|yes
+|cm.push _{reg_list}, -stack_adj_
+|<<#insns-cm_push>>
+
+|yes
+|yes
+|cm.pop _{reg_list}, stack_adj_
+|<<#insns-cm_pop>>
+
+|yes
+|yes
+|cm.popret _{reg_list}, stack_adj_
+|<<#insns-cm_popret>>
+
+|yes
+|yes
+|cm.popretz _{reg_list}, stack_adj_
+|<<#insns-cm_popretz>>
+
+|yes
+|yes
+|cm.mva01s _rs1', rs2'_
+|<<#insns-cm_mva01s>>
+
+|yes
+|yes
+|cm.mvsa01 _r1s', r2s'_
+|<<#insns-cm_mvsa01>>
+
+|===
+
+<<<
+
+[#Zcmt]
+=== Zcmt
+
+Zcmt adds the table jump instructions and also adds the jvt CSR. The jvt CSR requires a
+state enable if Smstateen is implemented. See <<csrs-jvt>> for details.
+
+This extension reuses some encodings from _c.fsdsp_. Therefore it is _incompatible_ with <<Zcd>>,
+ which is included when C and D extensions are both present.
+
+NOTE: Zcmt is primarily targeted at embedded class CPUs due to implementation complexity. Additionally, it is not compatible with RVA profiles.
+
+The Zcmt extension depends on the <<Zca>> and Zicsr extensions.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|yes
+|yes
+|cm.jt _index_
+|<<#insns-cm_jt>>
+
+|yes
+|yes
+|cm.jalt _index_
+|<<#insns-cm_jalt>>
+
+|===
+
+[#Zc_formats]
+=== Zc instruction formats
+
+Several instructions in this specification use the following new instruction formats.
+
+[%header,cols="2,3,2,1,1,1,1,1,1,1,1,1,1"]
+|=====================================================================
+| Format | instructions | 15:10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
+| CLB | c.lbu | funct6 3+| rs1' 2+| uimm 3+| rd' 2+| op
+| CSB | c.sb | funct6 3+| rs1' 2+| uimm 3+| rs2' 2+| op
+| CLH | c.lhu, c.lh | funct6 3+| rs1' | funct1 | uimm 3+| rd' 2+| op
+| CSH | c.sh | funct6 3+| rs1' | funct1 | uimm 3+| rs2' 2+| op
+| CU | c.[sz]ext.*, c.not | funct6 3+| rd'/rs1' 5+| funct5 2+| op
+| CMMV | cm.mvsa01 cm.mva01s| funct6 3+| r1s' 2+| funct2 3+| r2s' 2+| op
+| CMJT | cm.jt cm.jalt | funct6 8+| index 2+| op
+| CMPP | cm.push*, cm.pop* | funct6 2+| funct2 4+| urlist 2+| spimm 2+| op
+|=====================================================================
+
+[NOTE]
+====
+c.mul uses the existing CA format.
+====
+
+<<<
+
+[#Zcb_instructions]
+=== Zcb instructions
+
+[#insns-c_lbu,reftext="Load unsigned byte, 16-bit encoding"]
+==== c.lbu
+
+Synopsis::
+
+Load unsigned byte, 16-bit encoding
+
+Mnemonic::
+
+c.lbu _rd'_, _uimm_(_rs1'_)
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x0, attr: ['C0'] },
+ { bits: 3, name: 'rd\'' },
+ { bits: 2, name: 'uimm[0|1]' },
+ { bits: 3, name: 'rs1\'' },
+ { bits: 3, name: 0x0 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+The immediate offset is formed as follows:
+
+[source,sail]
+--
+ uimm[31:2] = 0;
+ uimm[1] = encoding[5];
+ uimm[0] = encoding[6];
+--
+
+Description::
+
+This instruction loads a byte from the memory address formed by adding _rs1'_ to the zero extended immediate _uimm_. The resulting byte is zero extended to XLEN bits and is written to _rd'_.
+
+[NOTE]
+====
+_rd'_ and _rs1'_ are from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+None
+//32-bit equivalent:
+//<<insns-lbu>>
+
+Operation::
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+X(rdc) = EXTZ(mem[X(rs1c)+EXTZ(uimm)][7..0]);
+----
+
+<<<
+[#insns-c_lhu,reftext="Load unsigned halfword, 16-bit encoding"]
+==== c.lhu
+
+Synopsis::
+
+Load unsigned halfword, 16-bit encoding
+
+Mnemonic::
+
+c.lhu _rd'_, _uimm_(_rs1'_)
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x0, attr: ['C0'] },
+ { bits: 3, name: 'rd\'' },
+ { bits: 1, name: 'uimm[1]' },
+ { bits: 1, name: 0x0 },
+ { bits: 3, name: 'rs1\'' },
+ { bits: 3, name: 0x1 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+The immediate offset is formed as follows:
+
+[source,sail]
+----
+ uimm[31:2] = 0;
+ uimm[1] = encoding[5];
+ uimm[0] = 0;
+----
+
+Description::
+
+This instruction loads a halfword from the memory address formed by adding _rs1'_ to the zero extended immediate _uimm_. The resulting halfword is zero extended to XLEN bits and is written to _rd'_.
+
+[NOTE]
+====
+_rd'_ and _rs1'_ are from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+None
+//32-bit equivalent:
+//
+//<<insns-lhu>>
+
+Operation::
+
+[source,sail]
+--
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+X(rdc) = EXTZ(load_mem[X(rs1c)+EXTZ(uimm)][15..0]);
+--
+
+<<<
+[#insns-c_lh,reftext="Load signed halfword, 16-bit encoding"]
+==== c.lh
+
+Synopsis::
+
+Load signed halfword, 16-bit encoding
+
+Mnemonic::
+
+c.lh _rd'_, _uimm_(_rs1'_)
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x0, attr: ['C0'] },
+ { bits: 3, name: 'rd\'' },
+ { bits: 1, name: 'uimm[1]' },
+ { bits: 1, name: 0x1 },
+ { bits: 3, name: 'rs1\'' },
+ { bits: 3, name: 0x1 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+The immediate offset is formed as follows:
+
+[source,sail]
+----
+ uimm[31:2] = 0;
+ uimm[1] = encoding[5];
+ uimm[0] = 0;
+----
+
+Description::
+
+This instruction loads a halfword from the memory address formed by adding _rs1'_ to the zero extended immediate _uimm_. The resulting halfword is sign extended to XLEN bits and is written to _rd'_.
+
+[NOTE]
+====
+_rd'_ and _rs1'_ are from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+None
+//32-bit equivalent:
+//
+//<<insns-lh>>
+
+Operation::
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+X(rdc) = EXTS(load_mem[X(rs1c)+EXTZ(uimm)][15..0]);
+----
+
+<<<
+[#insns-c_sb,reftext="Store byte, 16-bit encoding"]
+==== c.sb
+
+Synopsis::
+
+Store byte, 16-bit encoding
+
+Mnemonic::
+
+c.sb _rs2'_, _uimm_(_rs1'_)
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x0, attr: ['C0'] },
+ { bits: 3, name: 'rs2\'' },
+ { bits: 2, name: 'uimm[0|1]' },
+ { bits: 3, name: 'rs1\'' },
+ { bits: 3, name: 0x2 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+The immediate offset is formed as follows:
+
+[source,sail]
+----
+ uimm[31:2] = 0;
+ uimm[1] = encoding[5];
+ uimm[0] = encoding[6];
+----
+
+Description::
+
+This instruction stores the least significant byte of _rs2'_ to the memory address formed by adding _rs1'_ to the zero extended immediate _uimm_.
+
+[NOTE]
+====
+_rs1'_ and _rs2'_ are from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+None
+//
+//32-bit equivalent:
+//
+//<<insns-sb>>
+
+Operation::
+
+[source,sail]
+--
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+mem[X(rs1c)+EXTZ(uimm)][7..0] = X(rs2c)
+--
+
+<<<
+[#insns-c_sh,reftext="Store halfword, 16-bit encoding"]
+==== c.sh
+
+Synopsis::
+
+Store halfword, 16-bit encoding
+
+Mnemonic::
+
+c.sh _rs2'_, _uimm_(_rs1'_)
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x0, attr: ['C0'] },
+ { bits: 3, name: 'rs2\'' },
+ { bits: 1, name: 'uimm[1]' },
+ { bits: 1, name: '0' },
+ { bits: 3, name: 'rs1\'' },
+ { bits: 3, name: 0x3 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+The immediate offset is formed as follows:
+
+[source,sail]
+----
+ uimm[31:2] = 0;
+ uimm[1] = encoding[5];
+ uimm[0] = 0;
+----
+
+Description::
+
+This instruction stores the least significant halfword of _rs2'_ to the memory address formed by adding _rs1'_ to the zero extended immediate _uimm_.
+
+[NOTE]
+====
+_rs1'_ and _rs2'_ are from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+None
+//
+//32-bit equivalent:
+//
+//<<insns-sh>>
+
+Operation::
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+mem[X(rs1c)+EXTZ(uimm)][15..0] = X(rs2c)
+----
+
+<<<
+[#insns-c_zext_b,reftext="Zero extend byte, 16-bit encoding"]
+==== c.zext.b
+
+Synopsis::
+
+Zero extend byte, 16-bit encoding
+
+Mnemonic::
+
+c.zext.b _rd'/rs1'_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x1, attr: ['C1'] },
+ { bits: 3, name: 0x0, attr: ['C.ZEXT.B'] },
+ { bits: 2, name: 0x3, attr: ['FUNCT2'] },
+ { bits: 3, name: 'rd\'/rs1\'', attr: ['SRCDST'] },
+ { bits: 3, name: 0x7 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+Description::
+
+This instruction takes a single source/destination operand.
+It zero-extends the least-significant byte of the operand to XLEN bits by inserting zeros into all of
+the bits more significant than 7.
+
+[NOTE]
+====
+_rd'/rs1'_ is from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+None
+
+32-bit equivalent:
+
+[source,asm]
+----
+andi rd'/rs1', rd'/rs1', 0xff
+----
+
+[NOTE]
+====
+The SAIL module variable for _rd'/rs1'_ is called _rsdc_.
+====
+
+Operation::
+
+[source,sail]
+----
+X(rsdc) = EXTZ(X(rsdc)[7..0]);
+----
+
+<<<
+[#insns-c_sext_b,reftext="Sign extend byte, 16-bit encoding"]
+==== c.sext.b
+
+Synopsis::
+
+Sign extend byte, 16-bit encoding
+
+Mnemonic::
+
+c.sext.b _rd'/rs1'_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x1, attr: ['C1'] },
+ { bits: 3, name: 0x1, attr: ['C.SEXT.B'] },
+ { bits: 2, name: 0x3, attr: ['FUNCT2'] },
+ { bits: 3, name: 'rd\'/rs1\'', attr: ['SRCDST'] },
+ { bits: 3, name: 0x7 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+Description::
+
+This instruction takes a single source/destination operand.
+It sign-extends the least-significant byte in the operand to XLEN bits by copying the most-significant bit
+in the byte (i.e., bit 7) to all of the more-significant bits.
+
+[NOTE]
+====
+_rd'/rs1'_ is from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+Zbb is also required.
+//
+//32-bit equivalent:
+//
+//<<insns-sext_b>> from Zbb
+
+[NOTE]
+
+The SAIL module variable for _rd'/rs1'_ is called _rsdc_.
+
+Operation::
+
+[source,sail]
+----
+X(rsdc) = EXTS(X(rsdc)[7..0]);
+----
+
+<<<
+[#insns-c_zext_h,reftext="Zero extend halfword, 16-bit encoding"]
+==== c.zext.h
+
+Synopsis::
+
+Zero extend halfword, 16-bit encoding
+
+Mnemonic::
+
+c.zext.h _rd'/rs1'_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x1, attr: ['C1'] },
+ { bits: 3, name: 0x2, attr: ['C.ZEXT.H'] },
+ { bits: 2, name: 0x3, attr: ['FUNCT2'] },
+ { bits: 3, name: 'rd\'/rs1\'', attr: ['SRCDST'] },
+ { bits: 3, name: 0x7 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+Description::
+
+This instruction takes a single source/destination operand.
+It zero-extends the least-significant halfword of the operand to XLEN bits by inserting zeros into all of
+the bits more significant than 15.
+
+[NOTE]
+====
+_rd'/rs1'_ is from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+Zbb is also required.
+//
+//32-bit equivalent:
+//
+//<<insns-zext_h>> from Zbb
+
+[NOTE]
+====
+The SAIL module variable for _rd'/rs1'_ is called _rsdc_.
+====
+
+Operation::
+
+[source,sail]
+----
+X(rsdc) = EXTZ(X(rsdc)[15..0]);
+----
+
+<<<
+[#insns-c_sext_h,reftext="Sign extend halfword, 16-bit encoding"]
+==== c.sext.h
+
+Synopsis::
+
+Sign extend halfword, 16-bit encoding
+
+Mnemonic::
+
+c.sext.h _rd'/rs1'_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x1, attr: ['C1'] },
+ { bits: 3, name: 0x3, attr: ['C.SEXT.H'] },
+ { bits: 2, name: 0x3, attr: ['FUNCT2'] },
+ { bits: 3, name: 'rd\'/rs1\'', attr: ['SRCDST'] },
+ { bits: 3, name: 0x7 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+Description::
+
+This instruction takes a single source/destination operand.
+It sign-extends the least-significant halfword in the operand to XLEN bits by copying the most-significant bit
+in the halfword (i.e., bit 15) to all of the more-significant bits.
+
+[NOTE]
+====
+_rd'/rs1'_ is from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+Zbb is also required.
+//
+//32-bit equivalent:
+//
+//<<insns-sext_h>> from Zbb
+
+[NOTE]
+====
+The SAIL module variable for _rd'/rs1'_ is called _rsdc_.
+====
+
+Operation::
+
+[source,sail]
+----
+X(rsdc) = EXTS(X(rsdc)[15..0]);
+----
+
+<<<
+[#insns-c_zext_w,reftext="Zero extend word, 16-bit encoding"]
+==== c.zext.w
+
+Synopsis::
+
+Zero extend word, 16-bit encoding
+
+Mnemonic::
+
+c.zext.w _rd'/rs1'_
+
+Encoding (RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x1, attr: ['C1'] },
+ { bits: 3, name: 0x4, attr: ['C.ZEXT.W'] },
+ { bits: 2, name: 0x3, attr: ['FUNCT2'] },
+ { bits: 3, name: 'rd\'/rs1\'', attr: ['SRCDST'] },
+ { bits: 3, name: 0x7 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+Description::
+
+This instruction takes a single source/destination operand.
+It zero-extends the least-significant word of the operand to XLEN bits by inserting zeros into all of
+the bits more significant than 31.
+
+[NOTE]
+====
+_rd'/rs1'_ is from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+Zba is also required.
+
+32-bit equivalent:
+
+[source,asm]
+----
+add.uw rd'/rs1', rd'/rs1', zero
+----
+
+[NOTE]
+====
+The SAIL module variable for _rd'/rs1'_ is called _rsdc_.
+====
+
+Operation::
+
+[source,sail]
+----
+X(rsdc) = EXTZ(X(rsdc)[31..0]);
+----
+
+<<<
+[#insns-c_not,reftext="Bitwise not, 16-bit encoding"]
+==== c.not
+
+Synopsis::
+
+Bitwise not, 16-bit encoding
+
+Mnemonic::
+
+c.not _rd'/rs1'_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x1, attr: ['C1'] },
+ { bits: 3, name: 0x5, attr: ['C.NOT'] },
+ { bits: 2, name: 0x3, attr: ['FUNCT2'] },
+ { bits: 3, name: 'rd\'/rs1\'', attr: ['SRCDST'] },
+ { bits: 3, name: 0x7 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+Description::
+
+This instruction takes the one's complement of _rd'/rs1'_ and writes the result to the same register.
+
+[NOTE]
+====
+rd'/rs1' is from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+None
+
+32-bit equivalent:
+
+[source,asm]
+----
+xori rd'/rs1', rd'/rs1', -1
+----
+
+[NOTE]
+====
+The SAIL module variable for _rd'/rs1'_ is called _rsdc_.
+====
+
+Operation::
+
+[source,sail]
+----
+X(rsdc) = X(rsdc) XOR -1;
+----
+
+<<<
+[#insns-c_mul,reftext="Multiply, 16-bit encoding"]
+==== c.mul
+
+Synopsis::
+
+Multiply, 16-bit encoding
+
+Mnemonic::
+
+c.mul _rsd'_, _rs2'_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x1, attr: ['C1'] },
+ { bits: 3, name: 'rs2\'', attr: ['SRC2'] },
+ { bits: 2, name: 0x2, attr: ['FUNCT2'] },
+ { bits: 3, name: 'rd\'/rs1\'', attr: ['SRCDST'] },
+ { bits: 3, name: 0x7 },
+ { bits: 3, name: 0x4, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+Description::
+
+This instruction multiplies XLEN bits of the source operands from _rsd'_ and _rs2'_ and writes the lowest XLEN bits of the result to _rsd'_.
+
+[NOTE]
+====
+_rd'/rs1'_ and _rs2'_ are from the standard 8-register set x8-x15.
+====
+
+Prerequisites::
+
+M or Zmmul must be configured.
+//
+//32-bit equivalent:
+//
+//<<insns-mul>>
+
+[NOTE]
+====
+The SAIL module variable for _rd'/rs1'_ is called _rsdc_, and for _rs2'_ is called _rs2c_.
+====
+
+Operation::
+
+[source,sail]
+----
+let result_wide = to_bits(2 * sizeof(xlen), signed(X(rsdc)) * signed(X(rs2c)));
+X(rsdc) = result_wide[(sizeof(xlen) - 1) .. 0];
+----
+
+<<<
+
+[#insns-pushpop,reftext="PUSH/POP Register Instructions"]
+=== PUSH/POP register instructions
+
+These instructions are collectively referred to as PUSH/POP:
+
+* <<#insns-cm_push>>
+* <<#insns-cm_pop>>
+* <<#insns-cm_popret>>
+* <<#insns-cm_popretz>>
+
+The term PUSH refers to _cm.push_.
+
+The term POP refers to _cm.pop_.
+
+The term POPRET refers to _cm.popret and cm.popretz_.
+
+Common details for these instructions are in this section.
+
+==== PUSH/POP functional overview
+
+PUSH, POP, POPRET are used to reduce the size of function prologues and epilogues.
+
+. The PUSH instruction
+** adjusts the stack pointer to create the stack frame
+** pushes (stores) the registers specified in the register list to the stack frame
+
+. The POP instruction
+** pops (loads) the registers in the register list from the stack frame
+** adjusts the stack pointer to destroy the stack frame
+
+. The POPRET instructions
+** pop (load) the registers in the register list from the stack frame
+** _cm.popretz_ also moves zero into _a0_ as the return value
+** adjust the stack pointer to destroy the stack frame
+** execute a _ret_ instruction to return from the function
+
+<<<
+==== Example usage
+
+This example gives an illustration of the use of PUSH and POPRET.
+
+The function _processMarkers_ in the EMBench benchmark picojpeg in the following file on github: https://github.com/embench/embench-iot/blob/master/src/picojpeg/libpicojpeg.c[libpicojpeg.c]
+
+The prologue and epilogue compile with GCC10 to:
+
+[source,asm]
+----
+
+ 0001098a <processMarkers>:
+ 1098a: 711d addi sp,sp,-96 ;#cm.push(1)
+ 1098c: c8ca sw s2,80(sp) ;#cm.push(2)
+ 1098e: c6ce sw s3,76(sp) ;#cm.push(3)
+ 10990: c4d2 sw s4,72(sp) ;#cm.push(4)
+ 10992: ce86 sw ra,92(sp) ;#cm.push(5)
+ 10994: cca2 sw s0,88(sp) ;#cm.push(6)
+ 10996: caa6 sw s1,84(sp) ;#cm.push(7)
+ 10998: c2d6 sw s5,68(sp) ;#cm.push(8)
+ 1099a: c0da sw s6,64(sp) ;#cm.push(9)
+ 1099c: de5e sw s7,60(sp) ;#cm.push(10)
+ 1099e: dc62 sw s8,56(sp) ;#cm.push(11)
+ 109a0: da66 sw s9,52(sp) ;#cm.push(12)
+ 109a2: d86a sw s10,48(sp);#cm.push(13)
+ 109a4: d66e sw s11,44(sp);#cm.push(14)
+...
+ 109f4: 4501 li a0,0 ;#cm.popretz(1)
+ 109f6: 40f6 lw ra,92(sp) ;#cm.popretz(2)
+ 109f8: 4466 lw s0,88(sp) ;#cm.popretz(3)
+ 109fa: 44d6 lw s1,84(sp) ;#cm.popretz(4)
+ 109fc: 4946 lw s2,80(sp) ;#cm.popretz(5)
+ 109fe: 49b6 lw s3,76(sp) ;#cm.popretz(6)
+ 10a00: 4a26 lw s4,72(sp) ;#cm.popretz(7)
+ 10a02: 4a96 lw s5,68(sp) ;#cm.popretz(8)
+ 10a04: 4b06 lw s6,64(sp) ;#cm.popretz(9)
+ 10a06: 5bf2 lw s7,60(sp) ;#cm.popretz(10)
+ 10a08: 5c62 lw s8,56(sp) ;#cm.popretz(11)
+ 10a0a: 5cd2 lw s9,52(sp) ;#cm.popretz(12)
+ 10a0c: 5d42 lw s10,48(sp);#cm.popretz(13)
+ 10a0e: 5db2 lw s11,44(sp);#cm.popretz(14)
+ 10a10: 6125 addi sp,sp,96 ;#cm.popretz(15)
+ 10a12: 8082 ret ;#cm.popretz(16)
+----
+
+<<<
+
+with the GCC option _-msave-restore_ the output is the following:
+
+[source,asm]
+----
+0001080e <processMarkers>:
+ 1080e: 73a012ef jal t0,11f48 <__riscv_save_12>
+ 10812: 1101 addi sp,sp,-32
+...
+ 10862: 4501 li a0,0
+ 10864: 6105 addi sp,sp,32
+ 10866: 71e0106f j 11f84 <__riscv_restore_12>
+----
+
+with PUSH/POPRET this reduces to
+
+[source,asm]
+----
+0001080e <processMarkers>:
+ 1080e: b8fa cm.push {ra,s0-s11},-96
+...
+ 10866: bcfa cm.popretz {ra,s0-s11}, 96
+----
+
+The prologue / epilogue reduce from 60-bytes in the original code, to 14-bytes with _-msave-restore_,
+and to 4-bytes with PUSH and POPRET.
+As well as reducing the code-size PUSH and POPRET eliminate the branches from
+calling the millicode _save/restore_ routines and so may also perform better.
+
+[NOTE]
+====
+The calls to _<riscv_save_0>/<riscv_restore_0>_ become 64-bit when the target functions are out of the ±1{nbsp}MB range, increasing the prologue/epilogue size to 22-bytes.
+====
+
+[NOTE]
+====
+POP is typically used in tail-calling sequences where _ret_ is not used to return to _ra_ after destroying the stack frame.
+====
+
+[#pushpop-areg-list]
+
+===== Stack pointer adjustment handling
+
+The instructions all automatically adjust the stack pointer by enough to cover the memory required for the registers being saved or restored.
+Additionally the _spimm_ field in the encoding allows the stack pointer to be adjusted in additional increments of 16-bytes. There is only a small restricted
+range available in the encoding; if the range is insufficient then a separate _c.addi16sp_ can be used to increase the range.
+
+===== Register list handling
+
+There is no support for the _{ra, s0-s10}_ register list without also adding _s11_. Therefore the _{ra, s0-s11}_ register list must be used in this case.
+
+[#pushpop-idempotent-memory]
+==== PUSH/POP Fault handling
+
+Correct execution requires that _sp_ refers to idempotent memory (also see <<pushpop_non-idem-mem>>), because the core must be able to
+handle traps detected during the sequence.
+The entire PUSH/POP sequence is re-executed after returning from the trap handler, and multiple traps are possible during the sequence.
+
+If a trap occurs during the sequence then _xEPC_ is updated with the PC of the instruction, _xTVAL_ (if not read-only-zero) updated with the bad address if it was an access fault and _xCAUSE_ updated with the type of trap.
+
+NOTE: It is implementation defined whether interrupts can also be taken during the sequence execution.
+
+[#pushpop-software-view]
+==== Software view of execution
+
+===== Software view of the PUSH sequence
+
+From a software perspective the PUSH sequence appears as:
+
+* A sequence of stores writing the bytes required by the pseudocode
+** The bytes may be written in any order.
+** The bytes may be grouped into larger accesses.
+** Any of the bytes may be written multiple times.
+* A stack pointer adjustment
+
+[NOTE]
+====
+If an implementation allows interrupts during the sequence, and the interrupt handler uses _sp_ to allocate stack memory, then any stores which were executed before the interrupt may be overwritten by the handler. This is safe because the memory is idempotent and the stores will be re-executed when execution resumes.
+====
+
+The stack pointer adjustment must only be committed only when it is certain that the entire PUSH instruction will commit.
+
+Stores may also return imprecise faults from the bus.
+It is platform defined whether the core implementation waits for the bus responses before continuing to the final stage of the sequence,
+or handles errors responses after completing the PUSH instruction.
+
+<<<
+
+For example:
+
+[source,asm]
+----
+cm.push {ra, s0-s5}, -64
+----
+
+Appears to software as:
+
+[source,asm]
+----
+# any bytes from sp-1 to sp-28 may be written multiple times before
+# the instruction completes therefore these updates may be visible in
+# the interrupt/exception handler below the stack pointer
+sw s5, -4(sp)
+sw s4, -8(sp)
+sw s3,-12(sp)
+sw s2,-16(sp)
+sw s1,-20(sp)
+sw s0,-24(sp)
+sw ra,-28(sp)
+
+# this must only execute once, and will only execute after all stores
+# completed without any precise faults, therefore this update is only
+# visible in the interrupt/exception handler if cm.push has completed
+addi sp, sp, -64
+----
+
+===== Software view of the POP/POPRET sequence
+
+From a software perspective the POP/POPRET sequence appears as:
+
+* A sequence of loads reading the bytes required by the pseudocode.
+** The bytes may be loaded in any order.
+** The bytes may be grouped into larger accesses.
+** Any of the bytes may be loaded multiple times.
+* A stack pointer adjustment
+* An optional `li a0, 0`
+* An optional `ret`
+
+If a trap occurs during the sequence, then any loads which were executed before the trap may update architectural state.
+The loads will be re-executed once the trap handler completes, so the values will be overwritten.
+Therefore it is permitted for an implementation to update some of the destination registers before taking a fault.
+
+The optional `li a0, 0`, stack pointer adjustment and optional `ret` must only be committed only when it is certain that the entire POP/POPRET instruction will commit.
+
+For POPRET once the stack pointer adjustment has been committed the `ret` must execute.
+
+<<<
+For example:
+
+[source,asm]
+----
+cm.popretz {ra, s0-s3}, 32;
+----
+
+Appears to software as:
+
+[source,asm]
+----
+# any or all of these load instructions may execute multiple times
+# therefore these updates may be visible in the interrupt/exception handler
+lw s3, 28(sp)
+lw s2, 24(sp)
+lw s1, 20(sp)
+lw s0, 16(sp)
+lw ra, 12(sp)
+
+# these must only execute once, will only execute after all loads
+# complete successfully all instructions must execute atomically
+# therefore these updates are not visible in the interrupt/exception handler
+li a0, 0
+addi sp, sp, 32
+ret
+----
+
+[[pushpop_non-idem-mem,Non-idempotent memory handling]]
+==== Non-idempotent memory handling
+
+An implementation may have a requirement to issue a PUSH/POP instruction to non-idempotent memory.
+
+If the core implementation does not support PUSH/POP to non-idempotent memories, the core may use an idempotency PMA to detect it and take a
+load (POP/POPRET) or store (PUSH) access-fault exception in order to avoid unpredictable results.
+
+Software should only use these instructions on non-idempotent memory regions when software can tolerate the required memory accesses
+being issued repeatedly in the case that they cause exceptions.
+
+<<<
+
+==== Example RV32I PUSH/POP sequences
+
+The examples are included show the load/store series expansion and the stack adjustment.
+Examples of _cm.popret_ and _cm.popretz_ are not included, as the difference in the expanded sequence from _cm.pop_ is trivial in all cases.
+
+===== cm.push {ra, s0-s2}, -64
+
+Encoding: _rlist_=7, _spimm_=3
+
+expands to:
+
+[source,asm]
+----
+sw s2, -4(sp);
+sw s1, -8(sp);
+sw s0, -12(sp);
+sw ra, -16(sp);
+addi sp, sp, -64;
+----
+
+===== cm.push {ra, s0-s11}, -112
+
+Encoding: _rlist_=15, _spimm_=3
+
+expands to:
+
+[source,asm]
+----
+sw s11, -4(sp);
+sw s10, -8(sp);
+sw s9, -12(sp);
+sw s8, -16(sp);
+sw s7, -20(sp);
+sw s6, -24(sp);
+sw s5, -28(sp);
+sw s4, -32(sp);
+sw s3, -36(sp);
+sw s2, -40(sp);
+sw s1, -44(sp);
+sw s0, -48(sp);
+sw ra, -52(sp);
+addi sp, sp, -112;
+----
+
+<<<
+
+===== cm.pop {ra}, 16
+
+Encoding: _rlist_=4, _spimm_=0
+
+expands to:
+
+[source,asm]
+----
+lw ra, 12(sp);
+addi sp, sp, 16;
+----
+
+===== cm.pop {ra, s0-s3}, 48
+
+Encoding: _rlist_=8, _spimm_=1
+
+expands to:
+
+[source,asm]
+----
+lw s3, 44(sp);
+lw s2, 40(sp);
+lw s1, 36(sp);
+lw s0, 32(sp);
+lw ra, 28(sp);
+addi sp, sp, 48;
+----
+
+===== cm.pop {ra, s0-s4}, 64
+
+Encoding: _rlist_=9, _spimm_=2
+
+expands to:
+
+[source,asm]
+----
+lw s4, 60(sp);
+lw s3, 56(sp);
+lw s2, 52(sp);
+lw s1, 48(sp);
+lw s0, 44(sp);
+lw ra, 40(sp);
+addi sp, sp, 64;
+----
+
+
+<<<
+[#insns-cm_push,reftext="cm.push"]
+==== cm.push
+
+Synopsis::
+
+Create stack frame: store ra and 0 to 12 saved registers to the stack frame, optionally allocate additional stack space.
+
+Mnemonic::
+
+cm.push _{reg_list}, -stack_adj_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x2, attr: ['C2'] },
+ { bits: 2, name: 'spimm', attr: [] },
+ { bits: 4, name: 'rlist', attr: [] },
+ { bits: 5, name: 0x18, attr: [] },
+ { bits: 3, name: 0x5, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+[NOTE]
+====
+_rlist_ values 0 to 3 are reserved for a future EABI variant called _cm.push.e_
+====
+
+Assembly Syntax:
+
+[source,asm]
+--
+cm.push {reg_list}, -stack_adj
+cm.push {xreg_list}, -stack_adj
+--
+
+The variables used in the assembly syntax are defined below.
+
+[source,sail]
+----
+RV32E:
+
+switch (rlist){
+ case 4: {reg_list="ra"; xreg_list="x1";}
+ case 5: {reg_list="ra, s0"; xreg_list="x1, x8";}
+ case 6: {reg_list="ra, s0-s1"; xreg_list="x1, x8-x9";}
+ default: reserved();
+}
+stack_adj = stack_adj_base + spimm * 16;
+----
+
+[source,sail]
+----
+RV32I, RV64:
+
+switch (rlist){
+ case 4: {reg_list="ra"; xreg_list="x1";}
+ case 5: {reg_list="ra, s0"; xreg_list="x1, x8";}
+ case 6: {reg_list="ra, s0-s1"; xreg_list="x1, x8-x9";}
+ case 7: {reg_list="ra, s0-s2"; xreg_list="x1, x8-x9, x18";}
+ case 8: {reg_list="ra, s0-s3"; xreg_list="x1, x8-x9, x18-x19";}
+ case 9: {reg_list="ra, s0-s4"; xreg_list="x1, x8-x9, x18-x20";}
+ case 10: {reg_list="ra, s0-s5"; xreg_list="x1, x8-x9, x18-x21";}
+ case 11: {reg_list="ra, s0-s6"; xreg_list="x1, x8-x9, x18-x22";}
+ case 12: {reg_list="ra, s0-s7"; xreg_list="x1, x8-x9, x18-x23";}
+ case 13: {reg_list="ra, s0-s8"; xreg_list="x1, x8-x9, x18-x24";}
+ case 14: {reg_list="ra, s0-s9"; xreg_list="x1, x8-x9, x18-x25";}
+ //note - to include s10, s11 must also be included
+ case 15: {reg_list="ra, s0-s11"; xreg_list="x1, x8-x9, x18-x27";}
+ default: reserved();
+}
+stack_adj = stack_adj_base + spimm * 16;
+----
+
+[source,sail]
+----
+RV32E:
+
+stack_adj_base = 16;
+Valid values:
+stack_adj = [16|32|48|64];
+----
+
+[source,sail]
+----
+RV32I:
+
+switch (rlist) {
+ case 4.. 7: stack_adj_base = 16;
+ case 8..11: stack_adj_base = 32;
+ case 12..14: stack_adj_base = 48;
+ case 15: stack_adj_base = 64;
+}
+
+Valid values:
+switch (rlist) {
+ case 4.. 7: stack_adj = [16|32|48| 64];
+ case 8..11: stack_adj = [32|48|64| 80];
+ case 12..14: stack_adj = [48|64|80| 96];
+ case 15: stack_adj = [64|80|96|112];
+}
+----
+
+[source,sail]
+----
+RV64:
+
+switch (rlist) {
+ case 4.. 5: stack_adj_base = 16;
+ case 6.. 7: stack_adj_base = 32;
+ case 8.. 9: stack_adj_base = 48;
+ case 10..11: stack_adj_base = 64;
+ case 12..13: stack_adj_base = 80;
+ case 14: stack_adj_base = 96;
+ case 15: stack_adj_base = 112;
+}
+
+Valid values:
+switch (rlist) {
+ case 4.. 5: stack_adj = [ 16| 32| 48| 64];
+ case 6.. 7: stack_adj = [ 32| 48| 64| 80];
+ case 8.. 9: stack_adj = [ 48| 64| 80| 96];
+ case 10..11: stack_adj = [ 64| 80| 96|112];
+ case 12..13: stack_adj = [ 80| 96|112|128];
+ case 14: stack_adj = [ 96|112|128|144];
+ case 15: stack_adj = [112|128|144|160];
+}
+----
+
+<<<
+Description::
+
+This instruction pushes (stores) the registers in _reg_list_ to the memory below the stack pointer,
+and then creates the stack frame by decrementing the stack pointer by _stack_adj_,
+including any additional stack space requested by the value of _spimm_.
+
+
+[NOTE]
+====
+All ABI register mappings are for the UABI. An EABI version is planned once the EABI is frozen.
+====
+
+For further information see <<insns-pushpop>>.
+
+Stack Adjustment Calculation:
+
+_stack_adj_base_ is the minimum number of bytes, in multiples of 16-byte address increments, required to cover the registers in the list.
+
+_spimm_ is the number of additional 16-byte address increments allocated for the stack frame.
+
+The total stack adjustment represents the total size of the stack frame, which is _stack_adj_base_ added to _spimm_ scaled by 16,
+as defined above.
+
+Prerequisites::
+
+None
+
+32-bit equivalent:
+
+No direct equivalent encoding exists
+
+Operation::
+
+The first section of pseudocode may be executed multiple times before the instruction successfully completes.
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+if (XLEN==32) bytes=4; else bytes=8;
+
+addr=sp-bytes;
+for(i in 27,26,25,24,23,22,21,20,19,18,9,8,1) {
+ //if register i is in xreg_list
+ if (xreg_list[i]) {
+ switch(bytes) {
+ 4: asm("sw x[i], 0(addr)");
+ 8: asm("sd x[i], 0(addr)");
+ }
+ addr-=bytes;
+ }
+}
+----
+
+The final section of pseudocode executes atomically, and only executes if the section above completes without any exceptions or interrupts.
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+sp-=stack_adj;
+----
+
+<<<
+[#insns-cm_pop,reftext="cm.pop"]
+==== cm.pop
+
+Synopsis::
+
+Destroy stack frame: load ra and 0 to 12 saved registers from the stack frame, deallocate the stack frame.
+
+Mnemonic::
+
+cm.pop _{reg_list}, stack_adj_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x2, attr: ['C2'] },
+ { bits: 2, name: 'spimm', attr: [] },
+ { bits: 4, name: 'rlist', attr: [] },
+ { bits: 5, name: 0x1a, attr: [] },
+ { bits: 3, name: 0x5, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+[NOTE]
+====
+_rlist_ values 0 to 3 are reserved for a future EABI variant called _cm.pop.e_
+====
+
+Assembly Syntax:
+
+[source,asm]
+----
+cm.pop {reg_list}, stack_adj
+cm.pop {xreg_list}, stack_adj
+----
+
+The variables used in the assembly syntax are defined below.
+
+[source,sail]
+----
+RV32E:
+
+switch (rlist){
+ case 4: {reg_list="ra"; xreg_list="x1";}
+ case 5: {reg_list="ra, s0"; xreg_list="x1, x8";}
+ case 6: {reg_list="ra, s0-s1"; xreg_list="x1, x8-x9";}
+ default: reserved();
+}
+stack_adj = stack_adj_base + spimm * 16;
+----
+
+[source,sail]
+----
+RV32I, RV64:
+
+switch (rlist){
+ case 4: {reg_list="ra"; xreg_list="x1";}
+ case 5: {reg_list="ra, s0"; xreg_list="x1, x8";}
+ case 6: {reg_list="ra, s0-s1"; xreg_list="x1, x8-x9";}
+ case 7: {reg_list="ra, s0-s2"; xreg_list="x1, x8-x9, x18";}
+ case 8: {reg_list="ra, s0-s3"; xreg_list="x1, x8-x9, x18-x19";}
+ case 9: {reg_list="ra, s0-s4"; xreg_list="x1, x8-x9, x18-x20";}
+ case 10: {reg_list="ra, s0-s5"; xreg_list="x1, x8-x9, x18-x21";}
+ case 11: {reg_list="ra, s0-s6"; xreg_list="x1, x8-x9, x18-x22";}
+ case 12: {reg_list="ra, s0-s7"; xreg_list="x1, x8-x9, x18-x23";}
+ case 13: {reg_list="ra, s0-s8"; xreg_list="x1, x8-x9, x18-x24";}
+ case 14: {reg_list="ra, s0-s9"; xreg_list="x1, x8-x9, x18-x25";}
+ //note - to include s10, s11 must also be included
+ case 15: {reg_list="ra, s0-s11"; xreg_list="x1, x8-x9, x18-x27";}
+ default: reserved();
+}
+stack_adj = stack_adj_base + spimm * 16;
+----
+
+[source,sail]
+----
+RV32E:
+
+stack_adj_base = 16;
+Valid values:
+stack_adj = [16|32|48|64];
+----
+
+[source,sail]
+----
+RV32I:
+
+switch (rlist) {
+ case 4.. 7: stack_adj_base = 16;
+ case 8..11: stack_adj_base = 32;
+ case 12..14: stack_adj_base = 48;
+ case 15: stack_adj_base = 64;
+}
+
+Valid values:
+switch (rlist) {
+ case 4.. 7: stack_adj = [16|32|48| 64];
+ case 8..11: stack_adj = [32|48|64| 80];
+ case 12..14: stack_adj = [48|64|80| 96];
+ case 15: stack_adj = [64|80|96|112];
+}
+----
+
+[source,sail]
+----
+RV64:
+
+switch (rlist) {
+ case 4.. 5: stack_adj_base = 16;
+ case 6.. 7: stack_adj_base = 32;
+ case 8.. 9: stack_adj_base = 48;
+ case 10..11: stack_adj_base = 64;
+ case 12..13: stack_adj_base = 80;
+ case 14: stack_adj_base = 96;
+ case 15: stack_adj_base = 112;
+}
+
+Valid values:
+switch (rlist) {
+ case 4.. 5: stack_adj = [ 16| 32| 48| 64];
+ case 6.. 7: stack_adj = [ 32| 48| 64| 80];
+ case 8.. 9: stack_adj = [ 48| 64| 80| 96];
+ case 10..11: stack_adj = [ 64| 80| 96|112];
+ case 12..13: stack_adj = [ 80| 96|112|128];
+ case 14: stack_adj = [ 96|112|128|144];
+ case 15: stack_adj = [112|128|144|160];
+}
+----
+
+<<<
+
+Description::
+
+This instruction pops (loads) the registers in _reg_list_ from stack memory,
+and then adjusts the stack pointer by _stack_adj_.
+
+[NOTE]
+====
+All ABI register mappings are for the UABI. An EABI version is planned once the EABI is frozen.
+====
+
+For further information see <<insns-pushpop>>.
+
+Stack Adjustment Calculation:
+
+_stack_adj_base_ is the minimum number of bytes, in multiples of 16-byte address increments, required to cover the registers in the list.
+
+_spimm_ is the number of additional 16-byte address increments allocated for the stack frame.
+
+The total stack adjustment represents the total size of the stack frame, which is _stack_adj_base_ added to _spimm_ scaled by 16,
+as defined above.
+
+Prerequisites::
+
+None
+
+32-bit equivalent:
+
+No direct equivalent encoding exists
+
+Operation::
+
+The first section of pseudocode may be executed multiple times before the instruction successfully completes.
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+if (XLEN==32) bytes=4; else bytes=8;
+
+addr=sp+stack_adj-bytes;
+for(i in 27,26,25,24,23,22,21,20,19,18,9,8,1) {
+ //if register i is in xreg_list
+ if (xreg_list[i]) {
+ switch(bytes) {
+ 4: asm("lw x[i], 0(addr)");
+ 8: asm("ld x[i], 0(addr)");
+ }
+ addr-=bytes;
+ }
+}
+----
+
+The final section of pseudocode executes atomically, and only executes if the section above completes without any exceptions or interrupts.
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+sp+=stack_adj;
+----
+
+<<<
+[#insns-cm_popretz,reftext="cm.popretz"]
+==== cm.popretz
+
+Synopsis::
+
+Destroy stack frame: load ra and 0 to 12 saved registers from the stack frame, deallocate the stack frame, move zero into a0, return to ra.
+
+Mnemonic::
+
+cm.popretz _{reg_list}, stack_adj_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x2, attr: ['C2'] },
+ { bits: 2, name: 'spimm\[5:4\]', attr: [] },
+ { bits: 4, name: 'rlist', attr: [] },
+ { bits: 5, name: 0x1c, attr: [] },
+ { bits: 3, name: 0x5, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+[NOTE]
+====
+_rlist_ values 0 to 3 are reserved for a future EABI variant called _cm.popretz.e_
+====
+
+Assembly Syntax:
+
+[source,sail]
+----
+cm.popretz {reg_list}, stack_adj
+cm.popretz {xreg_list}, stack_adj
+----
+
+[source,sail]
+----
+RV32E:
+
+switch (rlist){
+ case 4: {reg_list="ra"; xreg_list="x1";}
+ case 5: {reg_list="ra, s0"; xreg_list="x1, x8";}
+ case 6: {reg_list="ra, s0-s1"; xreg_list="x1, x8-x9";}
+ default: reserved();
+}
+stack_adj = stack_adj_base + spimm * 16;
+----
+
+[source,sail]
+----
+RV32I, RV64:
+
+switch (rlist){
+ case 4: {reg_list="ra"; xreg_list="x1";}
+ case 5: {reg_list="ra, s0"; xreg_list="x1, x8";}
+ case 6: {reg_list="ra, s0-s1"; xreg_list="x1, x8-x9";}
+ case 7: {reg_list="ra, s0-s2"; xreg_list="x1, x8-x9, x18";}
+ case 8: {reg_list="ra, s0-s3"; xreg_list="x1, x8-x9, x18-x19";}
+ case 9: {reg_list="ra, s0-s4"; xreg_list="x1, x8-x9, x18-x20";}
+ case 10: {reg_list="ra, s0-s5"; xreg_list="x1, x8-x9, x18-x21";}
+ case 11: {reg_list="ra, s0-s6"; xreg_list="x1, x8-x9, x18-x22";}
+ case 12: {reg_list="ra, s0-s7"; xreg_list="x1, x8-x9, x18-x23";}
+ case 13: {reg_list="ra, s0-s8"; xreg_list="x1, x8-x9, x18-x24";}
+ case 14: {reg_list="ra, s0-s9"; xreg_list="x1, x8-x9, x18-x25";}
+ //note - to include s10, s11 must also be included
+ case 15: {reg_list="ra, s0-s11"; xreg_list="x1, x8-x9, x18-x27";}
+ default: reserved();
+}
+stack_adj = stack_adj_base + spimm * 16;
+----
+
+[source,sail]
+----
+RV32E:
+
+stack_adj_base = 16;
+Valid values:
+stack_adj = [16|32|48|64];
+----
+
+[source,sail]
+----
+RV32I:
+
+switch (rlist) {
+ case 4.. 7: stack_adj_base = 16;
+ case 8..11: stack_adj_base = 32;
+ case 12..14: stack_adj_base = 48;
+ case 15: stack_adj_base = 64;
+}
+
+Valid values:
+switch (rlist) {
+ case 4.. 7: stack_adj = [16|32|48| 64];
+ case 8..11: stack_adj = [32|48|64| 80];
+ case 12..14: stack_adj = [48|64|80| 96];
+ case 15: stack_adj = [64|80|96|112];
+}
+----
+
+[source,sail]
+----
+RV64:
+
+switch (rlist) {
+ case 4.. 5: stack_adj_base = 16;
+ case 6.. 7: stack_adj_base = 32;
+ case 8.. 9: stack_adj_base = 48;
+ case 10..11: stack_adj_base = 64;
+ case 12..13: stack_adj_base = 80;
+ case 14: stack_adj_base = 96;
+ case 15: stack_adj_base = 112;
+}
+
+Valid values:
+switch (rlist) {
+ case 4.. 5: stack_adj = [ 16| 32| 48| 64];
+ case 6.. 7: stack_adj = [ 32| 48| 64| 80];
+ case 8.. 9: stack_adj = [ 48| 64| 80| 96];
+ case 10..11: stack_adj = [ 64| 80| 96|112];
+ case 12..13: stack_adj = [ 80| 96|112|128];
+ case 14: stack_adj = [ 96|112|128|144];
+ case 15: stack_adj = [112|128|144|160];
+}
+----
+
+<<<
+
+Description::
+
+This instruction pops (loads) the registers in _reg_list_ from stack memory, adjusts the stack pointer by _stack_adj_, moves zero into a0 and then returns to _ra_.
+
+[NOTE]
+====
+All ABI register mappings are for the UABI. An EABI version is planned once the EABI is frozen.
+====
+
+For further information see <<insns-pushpop>>.
+
+Stack Adjustment Calculation:
+
+_stack_adj_base_ is the minimum number of bytes, in multiples of 16-byte address increments, required to cover the registers in the list.
+
+_spimm_ is the number of additional 16-byte address increments allocated for the stack frame.
+
+The total stack adjustment represents the total size of the stack frame, which is _stack_adj_base_ added to _spimm_ scaled by 16, as defined above.
+
+Prerequisites::
+
+None
+
+32-bit equivalent:
+
+No direct equivalent encoding exists
+
+
+Operation::
+
+The first section of pseudocode may be executed multiple times before the instruction successfully completes.
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+if (XLEN==32) bytes=4; else bytes=8;
+
+addr=sp+stack_adj-bytes;
+for(i in 27,26,25,24,23,22,21,20,19,18,9,8,1) {
+ //if register i is in xreg_list
+ if (xreg_list[i]) {
+ switch(bytes) {
+ 4: asm("lw x[i], 0(addr)");
+ 8: asm("ld x[i], 0(addr)");
+ }
+ addr-=bytes;
+ }
+}
+----
+
+The final section of pseudocode executes atomically, and only executes if the section above completes without any exceptions or interrupts.
+
+[NOTE]
+====
+The _li a0, 0_ *could* be executed more than once, but is included in the atomic section for convenience.
+====
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+asm("li a0, 0");
+sp+=stack_adj;
+asm("ret");
+----
+
+<<<
+[#insns-cm_popret,reftext="cm.popret"]
+==== cm.popret
+
+Synopsis::
+
+Destroy stack frame: load ra and 0 to 12 saved registers from the stack frame, deallocate the stack frame, return to ra.
+
+Mnemonic::
+
+cm.popret _{reg_list}, stack_adj_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x2, attr: ['C2'] },
+ { bits: 2, name: 'spimm', attr: [] },
+ { bits: 4, name: 'rlist', attr: [] },
+ { bits: 5, name: 0x1e, attr: [] },
+ { bits: 3, name: 0x5, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+[NOTE]
+====
+_rlist_ values 0 to 3 are reserved for a future EABI variant called _cm.popret.e_
+====
+
+Assembly Syntax:
+
+[source,sail]
+----
+cm.popret {reg_list}, stack_adj
+cm.popret {xreg_list}, stack_adj
+----
+
+The variables used in the assembly syntax are defined below.
+
+[source,sail]
+----
+RV32E:
+
+switch (rlist){
+ case 4: {reg_list="ra"; xreg_list="x1";}
+ case 5: {reg_list="ra, s0"; xreg_list="x1, x8";}
+ case 6: {reg_list="ra, s0-s1"; xreg_list="x1, x8-x9";}
+ default: reserved();
+}
+stack_adj = stack_adj_base + spimm * 16;
+----
+
+[source,sail]
+----
+RV32I, RV64:
+
+switch (rlist){
+ case 4: {reg_list="ra"; xreg_list="x1";}
+ case 5: {reg_list="ra, s0"; xreg_list="x1, x8";}
+ case 6: {reg_list="ra, s0-s1"; xreg_list="x1, x8-x9";}
+ case 7: {reg_list="ra, s0-s2"; xreg_list="x1, x8-x9, x18";}
+ case 8: {reg_list="ra, s0-s3"; xreg_list="x1, x8-x9, x18-x19";}
+ case 9: {reg_list="ra, s0-s4"; xreg_list="x1, x8-x9, x18-x20";}
+ case 10: {reg_list="ra, s0-s5"; xreg_list="x1, x8-x9, x18-x21";}
+ case 11: {reg_list="ra, s0-s6"; xreg_list="x1, x8-x9, x18-x22";}
+ case 12: {reg_list="ra, s0-s7"; xreg_list="x1, x8-x9, x18-x23";}
+ case 13: {reg_list="ra, s0-s8"; xreg_list="x1, x8-x9, x18-x24";}
+ case 14: {reg_list="ra, s0-s9"; xreg_list="x1, x8-x9, x18-x25";}
+ //note - to include s10, s11 must also be included
+ case 15: {reg_list="ra, s0-s11"; xreg_list="x1, x8-x9, x18-x27";}
+ default: reserved();
+}
+stack_adj = stack_adj_base + spimm * 16;
+----
+
+[source,sail]
+----
+RV32E:
+
+stack_adj_base = 16;
+Valid values:
+stack_adj = [16|32|48|64];
+----
+
+[source,sail]
+----
+RV32I:
+
+switch (rlist) {
+ case 4.. 7: stack_adj_base = 16;
+ case 8..11: stack_adj_base = 32;
+ case 12..14: stack_adj_base = 48;
+ case 15: stack_adj_base = 64;
+}
+
+Valid values:
+switch (rlist) {
+ case 4.. 7: stack_adj = [16|32|48| 64];
+ case 8..11: stack_adj = [32|48|64| 80];
+ case 12..14: stack_adj = [48|64|80| 96];
+ case 15: stack_adj = [64|80|96|112];
+}
+----
+
+[source,sail]
+----
+RV64:
+
+switch (rlist) {
+ case 4.. 5: stack_adj_base = 16;
+ case 6.. 7: stack_adj_base = 32;
+ case 8.. 9: stack_adj_base = 48;
+ case 10..11: stack_adj_base = 64;
+ case 12..13: stack_adj_base = 80;
+ case 14: stack_adj_base = 96;
+ case 15: stack_adj_base = 112;
+}
+
+Valid values:
+switch (rlist) {
+ case 4.. 5: stack_adj = [ 16| 32| 48| 64];
+ case 6.. 7: stack_adj = [ 32| 48| 64| 80];
+ case 8.. 9: stack_adj = [ 48| 64| 80| 96];
+ case 10..11: stack_adj = [ 64| 80| 96|112];
+ case 12..13: stack_adj = [ 80| 96|112|128];
+ case 14: stack_adj = [ 96|112|128|144];
+ case 15: stack_adj = [112|128|144|160];
+}
+----
+
+<<<
+
+Description::
+
+This instruction pops (loads) the registers in _reg_list_ from stack memory, adjusts the stack pointer by _stack_adj_ and then returns to _ra_.
+
+[NOTE]
+====
+All ABI register mappings are for the UABI. An EABI version is planned once the EABI is frozen.
+====
+
+For further information see <<insns-pushpop>>.
+
+Stack Adjustment Calculation:
+
+_stack_adj_base_ is the minimum number of bytes, in multiples of 16-byte address increments, required to cover the registers in the list.
+
+_spimm_ is the number of additional 16-byte address increments allocated for the stack frame.
+
+The total stack adjustment represents the total size of the stack frame, which is _stack_adj_base_ added to _spimm_ scaled by 16, as defined above.
+
+Prerequisites::
+
+None
+
+32-bit equivalent:
+
+No direct equivalent encoding exists
+
+Operation::
+
+The first section of pseudocode may be executed multiple times before the instruction successfully completes.
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+if (XLEN==32) bytes=4; else bytes=8;
+
+addr=sp+stack_adj-bytes;
+for(i in 27,26,25,24,23,22,21,20,19,18,9,8,1) {
+ //if register i is in xreg_list
+ if (xreg_list[i]) {
+ switch(bytes) {
+ 4: asm("lw x[i], 0(addr)");
+ 8: asm("ld x[i], 0(addr)");
+ }
+ addr-=bytes;
+ }
+}
+----
+
+The final section of pseudocode executes atomically, and only executes if the section above completes without any exceptions or interrupts.
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+sp+=stack_adj;
+asm("ret");
+----
+
+<<<
+
+[#insns-cm_mvsa01,reftext="Move a0-a1 into two different s0-s7 registers"]
+==== cm.mvsa01
+
+Synopsis::
+
+Move a0-a1 into two registers of s0-s7
+
+Mnemonic::
+
+cm.mvsa01 _r1s'_, _r2s'_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x2, attr: ['C2'] },
+ { bits: 3, name: 'r2s\'', attr: [] },
+ { bits: 2, name: 0x1, attr: [] },
+ { bits: 3, name: 'r1s\'', attr: [] },
+ { bits: 3, name: 0x3, attr: [] },
+ { bits: 3, name: 0x5, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+[NOTE]
+====
+For the encoding to be legal _r1s'_ != _r2s'_.
+====
+
+Assembly Syntax:
+
+[source,asm]
+----
+cm.mvsa01 r1s', r2s'
+----
+
+Description::
+This instruction moves _a0_ into _r1s'_ and _a1_ into _r2s'_. _r1s'_ and _r2s'_ must be different.
+The execution is atomic, so it is not possible to observe state where only one of _r1s'_ or _r2s'_ has been updated.
+
+The encoding uses _sreg_ number specifiers instead of _xreg_ number specifiers to save encoding space.
+The mapping between them is specified in the pseudocode below.
+
+[NOTE]
+====
+The _s_ register mapping is taken from the UABI, and may not match the currently unratified EABI. _cm.mvsa01.e_ may be included in the future.
+====
+
+Prerequisites::
+
+None
+
+32-bit equivalent:
+
+No direct equivalent encoding exists.
+
+Operation::
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+if (RV32E && (r1sc>1 || r2sc>1)) {
+ reserved();
+}
+xreg1 = {r1sc[2:1]>0,r1sc[2:1]==0,r1sc[2:0]};
+xreg2 = {r2sc[2:1]>0,r2sc[2:1]==0,r2sc[2:0]};
+X[xreg1] = X[10];
+X[xreg2] = X[11];
+----
+
+<<<
+
+[#insns-cm_mva01s,reftext="Move two s0-s7 registers into a0-a1"]
+==== cm.mva01s
+
+Synopsis::
+
+Move two s0-s7 registers into a0-a1
+
+Mnemonic::
+
+cm.mva01s _r1s'_, _r2s'_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x2, attr: ['C2'] },
+ { bits: 3, name: 'r2s\'', attr: [] },
+ { bits: 2, name: 0x3, attr: [] },
+ { bits: 3, name: 'r1s\'', attr: [] },
+ { bits: 3, name: 0x3, attr: [] },
+ { bits: 3, name: 0x5, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+Assembly Syntax:
+
+[source,asm]
+----
+cm.mva01s r1s', r2s'
+----
+
+Description::
+This instruction moves _r1s'_ into _a0_ and _r2s'_ into _a1_.
+The execution is atomic, so it is not possible to observe state where only one of _a0_ or _a1_ have been updated.
+
+The encoding uses _sreg_ number specifiers instead of _xreg_ number specifiers to save encoding space.
+The mapping between them is specified in the pseudocode below.
+
+[NOTE]
+====
+The _s_ register mapping is taken from the UABI, and may not match the currently unratified EABI. _cm.mva01s.e_ may be included in the future.
+====
+
+Prerequisites::
+
+None
+
+32-bit equivalent:
+
+No direct equivalent encoding exists.
+
+Operation::
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+if (RV32E && (r1sc>1 || r2sc>1)) {
+ reserved();
+}
+xreg1 = {r1sc[2:1]>0,r1sc[2:1]==0,r1sc[2:0]};
+xreg2 = {r2sc[2:1]>0,r2sc[2:1]==0,r2sc[2:0]};
+X[10] = X[xreg1];
+X[11] = X[xreg2];
+----
+
+<<<
+
+[#insns-tablejump,reftext="Table Jump Overview"]
+=== Table Jump Overview
+
+_cm.jt_ (<<#insns-cm_jt>>) and _cm.jalt_ (<<#insns-cm_jalt>>) are referred to as table jump.
+
+Table jump uses a 256-entry XLEN wide table in instruction memory to contain function addresses.
+The table must be a minimum of 64-byte aligned.
+
+Table entries follow the current data endianness. This is different from normal instruction fetch which is always little-endian.
+
+_cm.jt_ and _cm.jalt_ encodings index the table, giving access to functions within the full XLEN wide address space.
+
+This is used as a form of dictionary compression to reduce the code size of _jal_ / _auipc+jalr_ / _jr_ / _auipc+jr_ instructions.
+
+Table jump allows the linker to replace the following instruction sequences with a _cm.jt_ or _cm.jalt_ encoding, and an entry in the table:
+
+* 32-bit _j_ calls
+* 32-bit _jal_ ra calls
+* 64-bit _auipc+jr_ calls to fixed locations
+* 64-bit _auipc+jalr ra_ calls to fixed locations
+** The _auipc+jr/jalr_ sequence is used because the offset from the PC is out of the ±1{nbsp}MB range.
+
+If a return address stack is implemented, then as _cm.jalt_ is equivalent to _jal ra_, it pushes to the stack.
+
+==== jvt
+
+The base of the table is in the jvt CSR (see <<csrs-jvt>>), each table entry is XLEN bits.
+
+If the same function is called with and without linking then it must have two entries in the table.
+This is typically caused by the same function being called with and without tail calling.
+
+[#tablejump-fault-handling]
+==== Table Jump Fault handling
+
+For a table jump instruction, the table entry that the instruction selects is considered an extension of the instruction itself.
+Hence, the execution of a table jump instruction involves two instruction fetches, the first to read the instruction (_cm.jt_/_cm.jalt_)
+and the second to read from the jump vector table (JVT). Both instruction fetches are _implicit_ reads, and both require
+execute permission; read permission is irrelevant. It is recommended that the second fetch be ignored for hardware triggers and breakpoints.
+
+Memory writes to the jump vector table require an instruction barrier (_fence.i_) to guarantee that they are visible to the instruction fetch.
+
+Multiple contexts may have different jump vector tables. JVT may be switched between them without an instruction barrier
+if the tables have not been updated in memory since the last _fence.i_.
+
+If an exception occurs on either instruction fetch, xEPC is set to the PC of the table jump instruction, xCAUSE is set as expected for the type of fault and xTVAL (if not set to zero) contains the fetch address which caused the fault.
+
+<<<
+[#csrs-jvt,reftext="jvt CSR, table jump base vector and control register"]
+==== jvt CSR
+
+Synopsis::
+
+Table jump base vector and control register
+
+Address:
+
+0x017
+
+Permissions:
+
+URW
+
+Format (RV32):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 6, name: 'mode', attr: ['6'] },
+ { bits: 26, name: 'base[XLEN-1:6] (WARL)', attr: ['XLEN-6'] },
+],config:{bits:32}}
+....
+
+Format (RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 6, name: 'mode', attr: ['6'] },
+ { bits: 58, name: 'base[XLEN-1:6] (WARL)', attr: ['XLEN-6'] },
+],config:{bits:64}}
+....
+
+Description::
+
+The _jvt_ register is an XLEN-bit *WARL* read/write register that holds the jump table configuration, consisting of the jump table base address (BASE) and the jump table mode (MODE).
+
+If <<Zcmt>> is implemented then _jvt_ must also be implemented, but can contain a read-only value. If _jvt_ is writable, the set of values the register may hold can vary by implementation. The value in the BASE field must always be aligned on a 64-byte boundary.
+Note that the CSR contains only bits XLEN-1 through 6 of the address _base_. When computing jump-table accesses, the lower six bits of _base_ are filled with zeroes to obtain an XLEN-bit jump-table base address _jvt.base_ that is always aligned on a 64-byte boundary.
+
+_jvt.base_ is a virtual address, whenever virtual memory is enabled.
+
+The memory pointed to by _jvt.base_ is treated as instruction memory for the purpose of executing table jump instructions, implying execute access permission.
+
+[#JVT-config-table]
+._jvt.mode_ definition
+[width="60%",options=header]
+|=============================================================================================
+| jvt.mode | Comment
+| 000000 | Jump table mode
+| others | *reserved for future standard use*
+|=============================================================================================
+
+_jvt.mode_ is a *WARL* field, so can only be programmed to modes which are implemented. Therefore the discovery mechanism is to
+attempt to program different modes and read back the values to see which are available. Jump table mode _must_ be implemented.
+
+[NOTE]
+====
+in future the RISC-V Unified Discovery method will report the available modes.
+====
+
+Architectural State:
+
+_jvt_ CSR adds architectural state to the system software context (such as an OS process), therefore must be saved/restored on context switches.
+
+State Enable:
+
+If the Smstateen extension is implemented, then bit 2 in _mstateen0_, _sstateen0_, and _hstateen0_ is implemented. If bit 2 of a controlling _stateen0_ CSR is zero, then access to the _jvt_ CSR and execution of a _cm.jalt_ or _cm.jt_ instruction by a lower privilege level results in an illegal-instruction trap (or, if appropriate, a virtual-instruction trap).
+
+<<<
+[#insns-cm_jt,reftext="Jump via table"]
+==== cm.jt
+
+Synopsis::
+
+jump via table
+
+Mnemonic::
+
+cm.jt _index_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x2, attr: ['C2'] },
+ { bits: 8, name: 'index', attr: [] },
+ { bits: 3, name: 0x0, attr: [] },
+ { bits: 3, name: 0x5, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+[NOTE]
+====
+For this encoding to decode as _cm.jt_, _index<32_, otherwise it decodes as _cm.jalt_, see <<insns-cm_jalt>>.
+====
+
+[NOTE]
+====
+If jvt.mode = 0 (Jump Table Mode) then _cm.jt_ behaves as specified here. If jvt.mode is a reserved value, then _cm.jt_ is also reserved. In the future other defined values of jvt.mode may change the behaviour of _cm.jt_.
+====
+
+Assembly Syntax:
+
+[source,asm]
+----
+cm.jt index
+----
+
+Description::
+
+_cm.jt_ reads an entry from the jump vector table in memory and jumps to the address that was read.
+
+For further information see <<insns-tablejump>>.
+
+Prerequisites::
+
+None
+
+32-bit equivalent:
+
+No direct equivalent encoding exists.
+
+<<<
+
+[#insns-cm_jt-SAIL,reftext="cm.jt SAIL code"]
+Operation::
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+# target_address is temporary internal state, it doesn't represent a real register
+# InstMemory is byte indexed
+
+switch(XLEN) {
+ 32: table_address[XLEN-1:0] = jvt.base + (index<<2);
+ 64: table_address[XLEN-1:0] = jvt.base + (index<<3);
+}
+
+//fetch from the jump table
+target_address[XLEN-1:0] = InstMemory[table_address][XLEN-1:0];
+
+j target_address[XLEN-1:0]&~0x1;
+
+----
+
+<<<
+[#insns-cm_jalt,reftext="Jump and link via table"]
+==== cm.jalt
+
+Synopsis::
+
+jump via table with optional link
+
+Mnemonic::
+
+cm.jalt _index_
+
+Encoding (RV32, RV64):
+
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 2, name: 0x2, attr: ['C2'] },
+ { bits: 8, name: 'index', attr: [] },
+ { bits: 3, name: 0x0, attr: [] },
+ { bits: 3, name: 0x5, attr: ['FUNCT3'] },
+],config:{bits:16}}
+....
+
+[NOTE]
+====
+For this encoding to decode as _cm.jalt_, _index>=32_, otherwise it decodes as _cm.jt_, see <<insns-cm_jt>>.
+====
+
+[NOTE]
+====
+If jvt.mode = 0 (Jump Table Mode) then _cm.jalt_ behaves as specified here. If jvt.mode is a reserved value, then _cm.jalt_ is also reserved. In the future other defined values of jvt.mode may change the behaviour of _cm.jalt_.
+====
+
+Assembly Syntax:
+
+[source,asm]
+----
+cm.jalt index
+----
+
+Description::
+
+_cm.jalt_ reads an entry from the jump vector table in memory and jumps to the address that was read, linking to _ra_.
+
+For further information see <<insns-tablejump>>.
+
+Prerequisites::
+
+None
+
+32-bit equivalent:
+
+No direct equivalent encoding exists.
+
+<<<
+
+[#insns-cm_jalt-SAIL,reftext="cm.jalt SAIL code"]
+Operation::
+
+[source,sail]
+----
+//This is not SAIL, it's pseudocode. The SAIL hasn't been written yet.
+
+# target_address is temporary internal state, it doesn't represent a real register
+# InstMemory is byte indexed
+
+switch(XLEN) {
+ 32: table_address[XLEN-1:0] = jvt.base + (index<<2);
+ 64: table_address[XLEN-1:0] = jvt.base + (index<<3);
+}
+
+//fetch from the jump table
+target_address[XLEN-1:0] = InstMemory[table_address][XLEN-1:0];
+
+jal ra, target_address[XLEN-1:0]&~0x1;
+
+----
diff --git a/src/zfa.adoc b/src/zfa.adoc
new file mode 100644
index 0000000..8aee4d5
--- /dev/null
+++ b/src/zfa.adoc
@@ -0,0 +1,239 @@
+[[zfa]]
+== "Zfa" Extension for Additional Floating-Point Instructions, Version 1.0
+
+This chapter describes the Zfa standard extension, which adds
+instructions for immediate loads, IEEE 754-2019 minimum and maximum
+operations, round-to-integer operations, and quiet floating-point
+comparisons. For RV32D, the Zfa extension also adds instructions to
+transfer double-precision floating-point values to and from integer
+registers, and for RV64Q, it adds analogous instructions for
+quad-precision floating-point values. The Zfa extension depends on the F
+extension.
+
+=== Load-Immediate Instructions
+
+The FLI.S instruction loads one of 32 single-precision floating-point
+constants, encoded in the _rs1_ field, into floating-point register
+_rd_. The correspondence of _rs1_ field values and single-precision
+floating-point values is shown in <<tab:flis>>. FLI.S is encoded
+like FMV.W.X, but with _rs2_=1.
+
+[[tab:flis]]
+.Immediate values loaded by the FLI.S instruction.
+[%autowidth,float="center",align="center",cols=">,>,^,^,^",options="header",]
+|===
+|_rs1_ |Value |Sign |Exponent |Significand
+|0 |−1.0 |`1` |`01111111` |`000...000`
+|1 |_Minimum positive normal_ |`0` |`00000001` |`000...000`
+|2 |1.0 × 2^−16^ |`0` |`01101111` |`000...000`
+|3 |1.0 × 2^−15^ |`0` |`01110000` |`000...000`
+|4 |1.0 × 2^−8^ |`0` |`01110111` |`000...000`
+|5 |1.0 × 2^−7^ |`0` |`01111000` |`000...000`
+|6 |0.0625 (2^−4^) |`0` |`01111011` |`000...000`
+|7 |0.125 (2^−3^) |`0` |`01111100` |`000...000`
+|8 |0.25 |`0` |`01111101` |`000...000`
+|9 |0.3125 |`0` |`01111101` |`010...000`
+|10 |0.375 |`0` |`01111101` |`100...000`
+|11 |0.4375 |`0` |`01111101` |`110...000`
+|12 |0.5 |`0` |`01111110` |`000...000`
+|13 |0.625 |`0` |`01111110` |`010...000`
+|14 |0.75 |`0` |`01111110` |`100...000`
+|15 |0.875 |`0` |`01111110` |`110...000`
+|16 |1.0 |`0` |`01111111` |`000...000`
+|17 |1.25 |`0` |`01111111` |`010...000`
+|18 |1.5 |`0` |`01111111` |`100...000`
+|19 |1.75 |`0` |`01111111` |`110...000`
+|20 |2.0 |`0` |`10000000` |`000...000`
+|21 |2.5 |`0` |`10000000` |`010...000`
+|22 |3 |`0` |`10000000` |`100...000`
+|23 |4 |`0` |`10000001` |`000...000`
+|24 |8 |`0` |`10000010` |`000...000`
+|25 |16 |`0` |`10000011` |`000...000`
+|26 |128 (2^7^) |`0` |`10000110` |`000...000`
+|27 |256 (2^8^) |`0` |`10000111` |`000...000`
+|28 |2^15^ |`0` |`10001110` |`000...000`
+|29 |2^16^ |`0` |`10001111` |`000...000`
+|30 |+{inf} |`0` |`11111111` |`000...000`
+|31 |_Canonical NaN_ |`0` |`11111111` |`100...000`
+|===
+
+[NOTE]
+====
+The preferred assembly syntax for entries 1, 30, and 31 is `min`, `inf`,
+and `nan`, respectively. For entries 0 through 29 (including entry 1),
+the assembler will accept decimal constants in C-like syntax.
+====
+[NOTE]
+====
+The set of 32 constants was chosen by examining floating-point
+libraries, including the C standard math library, and to optimize
+fixed-point to floating-point conversion.
+
+Entries 8-22 follow a regular encoding pattern. No entry sets mantissa
+bits other than the two most significant ones.
+====
+
+If the D extension is implemented, FLI.D performs the analogous
+operation, but loads a double-precision value into floating-point
+register _rd_. Note that entry 1 (corresponding to the minimum positive
+normal value) has a numerically different value for double-precision
+than for single-precision. FLI.D is encoded like FLI.S, but with
+_fmt_=D.
+
+If the Q extension is implemented, FLI.Q performs the analogous
+operation, but loads a quad-precision value into floating-point register
+_rd_. Note that entry 1 (corresponding to the minimum positive normal
+value) has a numerically different value for quad-precision. FLI.Q is
+encoded like FLI.S, but with _fmt_=Q.
+
+If the Zfh or Zvfh extension is implemented, FLI.H performs the
+analogous operation, but loads a half-precision floating-point value
+into register _rd_. Note that entry 1 (corresponding to the minimum
+positive normal value) has a numerically different value for
+half-precision. Furthermore, since 2^16^ is not
+representable in half-precision floating-point, entry 29 in the table
+instead loads positive infinity—i.e., it is redundant with entry 30.
+FLI.H is encoded like FLI.S, but with _fmt_=H.
+[NOTE]
+====
+Additionally, since 2^−16^ and 2^−15^ are subnormal in half-precision, entry 1 is numerically greater than entries 2 and 3 for FLI.H.
+====
+The FLI._fmt_ instructions never set any floating-point exception flags.
+
+=== Minimum and Maximum Instructions
+
+The FMINM.S and FMAXM.S instructions are defined like the FMIN.S and
+FMAX.S instructions, except that if either input is NaN, the result is
+the canonical NaN.
+
+If the D extension is implemented, FMINM.D and FMAXM.D instructions are
+analogously defined to operate on double-precision numbers.
+
+If the Zfh extension is implemented, FMINM.H and FMAXM.H instructions
+are analogously defined to operate on half-precision numbers.
+
+If the Q extension is implemented, FMINM.Q and FMAXM.Q instructions are
+analogously defined to operate on quad-precision numbers.
+
+These instructions are encoded like their FMIN and FMAX counterparts,
+but with instruction bit 13 set to 1.
+[NOTE]
+====
+These instructions implement the IEEE 754-2019 minimum and maximum
+operations.
+====
+=== Round-to-Integer Instructions
+
+The FROUND.S instruction rounds the single-precision floating-point
+number in floating-point register _rs1_ to an integer, according to the
+rounding mode specified in the instruction's _rm_ field. It then writes
+that integer, represented as a single-precision floating-point number,
+to floating-point register _rd_. Zero and infinite inputs are copied to
+_rd_ unmodified. Signaling NaN inputs cause the invalid operation
+exception flag to be set; no other exception flags are set. FROUND.S is
+encoded like FCVT.S.D, but with _rs2_=4.
+
+The FROUNDNX.S instruction is defined similarly, but it also sets the
+inexact exception flag if the input differs from the rounded result and
+is not NaN. FROUNDNX.S is encoded like FCVT.S.D, but with _rs2_=5.
+
+If the D extension is implemented, FROUND.D and FROUNDNX.D instructions
+are analogously defined to operate on double-precision numbers. They are
+encoded like FCVT.D.S, but with _rs2_=4 and 5, respectively,
+
+If the Zfh extension is implemented, FROUND.H and FROUNDNX.H
+instructions are analogously defined to operate on half-precision
+numbers. They are encoded like FCVT.H.S, but with _rs2_=4 and 5,
+respectively,
+
+If the Q extension is implemented, FROUND.Q and FROUNDNX.Q instructions
+are analogously defined to operate on quad-precision numbers. They are
+encoded like FCVT.Q.S, but with _rs2_=4 and 5, respectively,
+[NOTE]
+====
+The FROUNDNX._fmt_ instructions implement the IEEE 754-2019
+roundToIntegralExact operation, and the FROUND._fmt_ instructions
+implement the other operations in the roundToIntegral family.
+====
+=== Modular Convert-to-Integer Instruction
+
+The FCVTMOD.W.D instruction is defined similarly to the FCVT.W.D
+instruction, with the following differences. FCVTMOD.W.D always rounds
+towards zero. Bits 31:0 are taken from the rounded, unbounded two's
+complement result, then sign-extended to XLEN bits and written to
+integer register _rd_. ±{inf} and NaN are converted to
+zero.
+
+Floating-point exception flags are raised the same as they would be for
+FCVT.W.D with the same input operand.
+
+This instruction is only provided if the D extension is implemented. It
+is encoded like FCVT.W.D, but with the rs2 field set to 8 and the _rm_
+field set to 1 (RTZ). Other _rm_ values are _reserved_.
+[NOTE]
+====
+The assembly syntax requires the RTZ rounding mode to be explicitly
+specified, i.e., `fcvtmod.w.d rd, rs1, rtz`.
+
+The FCVTMOD.W.D instruction was added principally to accelerate the
+processing of JavaScript Numbers. Numbers are double-precision
+values, but some operators implicitly truncate them to signed integers
+mod 2^32^.
+====
+=== Move Instructions
+
+For RV32 only, if the D extension is implemented, the FMVH.X.D
+instruction moves bits 63:32 of floating-point register _rs1_ into
+integer register _rd_. It is encoded in the OP-FP major opcode with
+_funct3_=0, _rs2_=1, and _funct7_=1110001.
+[NOTE]
+====
+FMVH.X.D is used in conjunction with the existing FMV.X.W instruction to
+move a double-precision floating-point number to a pair of x-registers.
+====
+For RV32 only, if the D extension is implemented, the FMVP.D.X
+instruction moves a double-precision number from a pair of integer
+registers into a floating-point register. Integer registers _rs1_ and
+_rs2_ supply bits 31:0 and 63:32, respectively; the result is written to
+floating-point register _rd_. FMVP.D.X is encoded in the OP-FP major
+opcode with _funct3_=0 and _funct7_=1011001.
+
+For RV64 only, if the Q extension is implemented, the FMVH.X.Q
+instruction moves bits 127:64 of floating-point register _rs1_ into
+integer register _rd_. It is encoded in the OP-FP major opcode with
+_funct3_=0, _rs2_=1, and _funct7_=1110011.
+[NOTE]
+====
+FMVH.X.Q is used in conjunction with the existing FMV.X.D instruction to
+move a quad-precision floating-point number to a pair of x-registers.
+====
+For RV64 only, if the Q extension is implemented, the FMVP.Q.X
+instruction moves a double-precision number from a pair of integer
+registers into a floating-point register. Integer registers _rs1_ and
+_rs2_ supply bits 63:0 and 127:64, respectively; the result is written
+to floating-point register _rd_. FMVP.Q.X is encoded in the OP-FP major
+opcode with _funct3_=0 and _funct7_=1011011.
+
+=== Comparison Instructions
+
+The FLEQ.S and FLTQ.S instructions are defined like the FLE.S and FLT.S
+instructions, except that quiet NaN inputs do not cause the invalid
+operation exception flag to be set.
+
+If the D extension is implemented, FLEQ.D and FLTQ.D instructions are
+analogously defined to operate on double-precision numbers.
+
+If the Zfh extension is implemented, FLEQ.H and FLTQ.H instructions are
+analogously defined to operate on half-precision numbers.
+
+If the Q extension is implemented, FLEQ.Q and FLTQ.Q instructions are
+analogously defined to operate on quad-precision numbers.
+
+These instructions are encoded like their FLE and FLT counterparts, but
+with instruction bit 14 set to 1.
+[NOTE]
+====
+We do not expect analogous comparison instructions will be added to the
+vector ISA, since they can be reasonably efficiently emulated using
+masking.
+====
diff --git a/src/zfh.adoc b/src/zfh.adoc
new file mode 100644
index 0000000..af29dd2
--- /dev/null
+++ b/src/zfh.adoc
@@ -0,0 +1,176 @@
+[[chap:zfh]]
+== "Zfh" and "Zfhmin" Extensions for Half-Precision Floating-Point, Version 1.0
+
+This chapter describes the Zfh standard extension for 16-bit
+half-precision binary floating-point instructions compliant with the
+IEEE 754-2008 arithmetic standard. The Zfh extension depends on the
+single-precision floating-point extension, F. The NaN-boxing scheme
+described in <<nanboxing>> is extended to allow a
+half-precision value to be NaN-boxed inside a single-precision value
+(which may be recursively NaN-boxed inside a double- or quad-precision
+value when the D or Q extension is present).
+
+[NOTE]
+====
+This extension primarily provides instructions that consume
+half-precision operands and produce half-precision results. However, it
+is also common to compute on half-precision data using higher
+intermediate precision. Although this extension provides explicit
+conversion instructions that suffice to implement that pattern, future
+extensions might further accelerate such computation with additional
+instructions that implicitly widen their operands—e.g.,
+half{times}half+single->single—or
+implicitly narrow their results—e.g.,
+half+single->half.
+====
+=== Half-Precision Load and Store Instructions
+
+New 16-bit variants of LOAD-FP and STORE-FP instructions are added,
+encoded with a new value for the funct3 width field.
+
+include::images/wavedrom/sp-load-store.edn[]
+[[sp-load-store]]
+//.Half-precision load and store instructions
+
+FLH and FSH are only guaranteed to execute atomically if the effective
+address is naturally aligned.
+
+FLH and FSH do not modify the bits being transferred; in particular, the
+payloads of non-canonical NaNs are preserved. FLH NaN-boxes the result
+written to _rd_, whereas FSH ignores all but the lower 16 bits in _rs2_.
+
+=== Half-Precision Computational Instructions
+
+A new supported format is added to the format field of most
+instructions, as shown in <<tab:fpextfmth>>.
+
+[[tab:fpextfmth]]
+.Format field encoding.
+[%autowidth,float="center",align="center",cols="^,^,<",options="header",]
+|===
+|_fmt_ field |Mnemonic |Meaning
+|00 |S |32-bit single-precision
+|01 |D |64-bit double-precision
+|10 |H |16-bit half-precision
+|11 |Q |128-bit quad-precision
+|===
+
+The half-precision floating-point computational instructions are defined
+analogously to their single-precision counterparts, but operate on
+half-precision operands and produce half-precision results.
+
+include::images/wavedrom/spfloat-zfh.edn[]
+
+include::images/wavedrom/spfloat2-zfh.edn[]
+
+=== Half-Precision Conversion and Move Instructions
+
+New floating-point-to-integer and integer-to-floating-point conversion
+instructions are added. These instructions are defined analogously to
+the single-precision-to-integer and integer-to-single-precision
+conversion instructions. FCVT.W.H or FCVT.L.H converts a half-precision
+floating-point number to a signed 32-bit or 64-bit integer,
+respectively. FCVT.H.W or FCVT.H.L converts a 32-bit or 64-bit signed
+integer, respectively, into a half-precision floating-point number.
+FCVT.WU.H, FCVT.LU.H, FCVT.H.WU, and FCVT.H.LU variants convert to or
+from unsigned integer values. FCVT.L[U].H and FCVT.H.L[U] are RV64-only
+instructions.
+
+include::images/wavedrom/half-prec-conv-and-mv.edn[]
+[[half-prec-conv-and-mv]]
+
+New floating-point-to-floating-point conversion instructions are added.
+These instructions are defined analogously to the double-precision
+floating-point-to-floating-point conversion instructions. FCVT.S.H or
+FCVT.H.S converts a half-precision floating-point number to a
+single-precision floating-point number, or vice-versa, respectively. If
+the D extension is present, FCVT.D.H or FCVT.H.D converts a
+half-precision floating-point number to a double-precision
+floating-point number, or vice-versa, respectively. If the Q extension
+is present, FCVT.Q.H or FCVT.H.Q converts a half-precision
+floating-point number to a quad-precision floating-point number, or
+vice-versa, respectively.
+
+include::images/wavedrom/half-prec-flpt-to-flpt-conv.edn[]
+[[half-prec-flpt-to-flpt-conv]]
+
+Floating-point to floating-point sign-injection instructions, FSGNJ.H,
+FSGNJN.H, and FSGNJX.H are defined analogously to the single-precision
+sign-injection instruction.
+
+include::images/wavedrom/flt-to-flt-sgn-inj-instr.edn[]
+[[flt-to-flt-sgn-inj-instr]]
+
+Instructions are provided to move bit patterns between the
+floating-point and integer registers. FMV.X.H moves the half-precision
+value in floating-point register _rs1_ to a representation in IEEE
+754-2008 standard encoding in integer register _rd_, filling the upper
+XLEN-16 bits with copies of the floating-point number's sign bit.
+
+FMV.H.X moves the half-precision value encoded in IEEE 754-2008 standard
+encoding from the lower 16 bits of integer register _rs1_ to the
+floating-point register _rd_, NaN-boxing the result.
+
+FMV.X.H and FMV.H.X do not modify the bits being transferred; in
+particular, the payloads of non-canonical NaNs are preserved.
+
+include::images/wavedrom/flt-pt-to-int-move.edn[]
+[[flt-pt-to-int-move]]
+
+=== Half-Precision Floating-Point Compare Instructions
+
+The half-precision floating-point compare instructions are defined
+analogously to their single-precision counterparts, but operate on
+half-precision operands.
+
+include::images/wavedrom/half-pr-flt-pt-compare.edn[]
+[[half-pr-flt-pt-compare]]
+
+=== Half-Precision Floating-Point Classify Instruction
+
+The half-precision floating-point classify instruction, FCLASS.H, is
+defined analogously to its single-precision counterpart, but operates on
+half-precision operands.
+
+include::images/wavedrom/half-pr-flt-pt-class.edn[]
+[[half-pr-flt-class]]
+
+=== "Zfhmin" Standard Extension for Minimal Half-Precision Floating-Point
+
+This section describes the Zfhmin standard extension, which provides
+minimal support for 16-bit half-precision binary floating-point
+instructions. The Zfhmin extension is a subset of the Zfh extension,
+consisting only of data transfer and conversion instructions. Like Zfh,
+the Zfhmin extension depends on the single-precision floating-point
+extension, F. The expectation is that Zfhmin software primarily uses the
+half-precision format for storage, performing most computation in higher
+precision.
+
+The Zfhmin extension includes the following instructions from the Zfh
+extension: FLH, FSH, FMV.X.H, FMV.H.X, FCVT.S.H, and FCVT.H.S. If the D
+extension is present, the FCVT.D.H and FCVT.H.D instructions are also
+included. If the Q extension is present, the FCVT.Q.H and FCVT.H.Q
+instructions are additionally included.
+
+[NOTE]
+====
+Zfhmin does not include the FSGNJ.H instruction, because it suffices to
+instead use the FSGNJ.S instruction to move half-precision values
+between floating-point registers.
+
+Half-precision addition, subtraction, multiplication, division, and
+square-root operations can be faithfully emulated by converting the
+half-precision operands to single-precision, performing the operation
+using single-precision arithmetic, then converting back to
+half-precision. cite:[roux:hal-01091186] Performing half-precision fused multiply-addition using
+this method incurs a 1-ulp error on some inputs for the RNE and RMM
+rounding modes.
+
+Conversion from 8- or 16-bit integers to half-precision can be emulated
+by first converting to single-precision, then converting to
+half-precision. Conversion from 32-bit integer can be emulated by first
+converting to double-precision. If the D extension is not present and a
+1-ulp error under RNE or RMM is tolerable, 32-bit integers can be first
+converted to single-precision instead. The same remark applies to
+conversions from 64-bit integers without the Q extension.
+====
diff --git a/src/zfinx.adoc b/src/zfinx.adoc
new file mode 100644
index 0000000..a1dda00
--- /dev/null
+++ b/src/zfinx.adoc
@@ -0,0 +1,148 @@
+[[sec:zfinx]]
+== "Zfinx", "Zdinx", "Zhinx", "Zhinxmin" Extensions for Floating-Point in Integer Registers, Version 1.0
+
+This chapter defines the "Zfinx" extension (pronounced "z-f-in-x")
+that provides instructions similar to those in the standard
+floating-point F extension for single-precision floating-point
+instructions but which operate on the `x` registers instead of the `f`
+registers. This chapter also defines the "Zdinx", "Zhinx", and
+"Zhinxmin" extensions that provide similar instructions for other
+floating-point precisions.
+
+[NOTE]
+====
+The F extension uses separate `f` registers for floating-point
+computation, to reduce register pressure and simplify the provision of
+register-file ports for wide superscalars. However, the additional
+architectural state increases the minimal implementation cost. By
+eliminating the `f` registers, the Zfinx extension substantially reduces
+the cost of simple RISC-V implementations with floating-point
+instruction-set support. Zfinx also reduces context-switch cost.
+
+In general, software that assumes the presence of the F extension is
+incompatible with software that assumes the presence of the Zfinx
+extension, and vice versa.
+====
+
+The Zfinx extension adds all of the instructions that the F extension
+adds, _except_ for the transfer instructions FLW, FSW, FMV.W.X, FMV.X.W,
+C.FLW[SP], and C.FSW[SP].
+
+[NOTE]
+====
+Zfinx software uses integer loads and stores to transfer floating-point
+values from and to memory. Transfers between registers use either
+integer arithmetic or floating-point sign-injection instructions.
+====
+The Zfinx variants of these F-extension instructions have the same
+semantics, except that whenever such an instruction would have accessed
+an `f` register, it instead accesses the `x` register with the same
+number.
+
+The Zfinx extension depends on the "Zicsr" extension for control and status register access.
+
+=== Processing of Narrower Values
+
+Floating-point operands of width _w_ < XLEN bits occupy
+bits _w_-1:0 of an `x` register. Floating-point operations on _w_-bit
+operands ignore operand bits XLEN-1: _w_.
+
+Floating-point operations that produce _w_ < XLEN-bit
+results fill bits XLEN-1: _w_ with copies of bit _w_-1 (the sign bit).
+
+[NOTE]
+====
+The NaN-boxing scheme employed in the `f` registers was designed to
+efficiently support recoded floating-point formats. Recoding is less
+practical for Zfinx, though, since the same registers hold both
+floating-point and integer operands. Hence, the need for NaN boxing is
+diminished.
+
+Sign-extending 32-bit floating-point numbers when held in RV64 `x`
+registers is compatible with the existing RV64 calling conventions, which leave bits 63-32 undefined when passing a 32-bit floating point value in `x` registers. To keep the architecture more regular, we extend this pattern to 16-bit floating-point numbers in both RV32 and RV64.
+====
+=== Zdinx
+
+The Zdinx extension provides analogous double-precision floating-point
+instructions. The Zdinx extension depends upon the Zfinx extension.
+
+The Zdinx extension adds all of the instructions that the D extension
+adds, _except_ for the transfer instructions FLD, FSD, FMV.D.X, FMV.X.D,
+C.FLD[SP], and C.FSD[SP].
+
+The Zdinx variants of these D-extension instructions have the same
+semantics, except that whenever such an instruction would have accessed
+an `f` register, it instead accesses the `x` register with the same
+number.
+
+=== Processing of Wider Values
+
+Double-precision operands in RV32Zdinx are held in aligned `x`-register
+pairs, i.e., register numbers must be even. Use of misaligned
+(odd-numbered) registers for double-width floating-point operands is
+_reserved_.
+
+Regardless of endianness, the lower-numbered register holds the
+low-order bits, and the higher-numbered register holds the high-order
+bits: e.g., bits 31:0 of a double-precision operand in RV32Zdinx might
+be held in register `x14`, with bits 63:32 of that operand held in
+`x15`.
+
+When a double-width floating-point result is written to `x0`, the entire
+write takes no effect: e.g., for RV32Zdinx, writing a double-precision
+result to `x0` does not cause `x1` to be written.
+
+When `x0` is used as a double-width floating-point operand, the entire
+operand is zero—i.e., `x1` is not accessed.
+
+[NOTE]
+====
+Load-pair and store-pair instructions are contained in a separate extension
+(see Section <<sec:zilsd,Extensions for Load/Store pair for RV32>>).
+In case this is not available, transferring double-precision operands in
+RV32Zdinx from or to memory requires two loads or stores. Register moves need
+only a single FSGNJ.D instruction, however.
+====
+=== Zhinx
+
+The Zhinx extension provides analogous half-precision floating-point
+instructions. The Zhinx extension depends upon the Zfinx extension.
+
+The Zhinx extension adds all of the instructions that the Zfh extension
+adds, _except_ for the transfer instructions FLH, FSH, FMV.H.X, and
+FMV.X.H.
+
+The Zhinx variants of these Zfh-extension instructions have the same
+semantics, except that whenever such an instruction would have accessed
+an `f` register, it instead accesses the `x` register with the same
+number.
+
+=== Zhinxmin
+
+The Zhinxmin extension provides minimal support for 16-bit
+half-precision floating-point instructions that operate on the `x`
+registers. The Zhinxmin extension depends upon the Zfinx extension.
+
+The Zhinxmin extension includes the following instructions from the
+Zhinx extension: FCVT.S.H and FCVT.H.S. If the Zdinx extension is
+present, the FCVT.D.H and FCVT.H.D instructions are also included.
+[NOTE]
+====
+In the future, an RV64Zqinx quad-precision extension could be defined
+analogously to RV32Zdinx. An RV32Zqinx extension could also be defined
+but would require quad-register groups.
+====
+=== Privileged Architecture Implications
+
+In the standard privileged architecture defined in Volume II, the
+`mstatus` field FS is hardwired to 0 if the Zfinx extension is
+implemented, and FS no longer affects the trapping behavior of
+floating-point instructions or `fcsr` accesses.
+
+The `misa` bits F, D, and Q are hardwired to 0 when the Zfinx extension
+is implemented.
+[NOTE]
+====
+A future discoverability mechanism might be used to probe the existence
+of the Zfinx, Zhinx, and Zdinx extensions.
+====
diff --git a/src/zicond.adoc b/src/zicond.adoc
new file mode 100644
index 0000000..83c702a
--- /dev/null
+++ b/src/zicond.adoc
@@ -0,0 +1,183 @@
+[[Zicond]]
+== "Zicond" Extension for Integer Conditional Operations, Version 1.0.0
+
+The Zicond extension defines two R-type instructions that support branchless
+conditional operations.
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|&#10003;
+|&#10003;
+|czero.eqz _rd_, _rs1_, _rs2_
+|<<#insns-czero-eqz>>
+
+|&#10003;
+|&#10003;
+|czero.nez _rd_, _rs1_, _rs2_
+|<<#insns-czero-nez>>
+
+|===
+
+=== Instructions (in alphabetical order)
+
+[#insns-czero-eqz,reftext="Conditional zero, if condition is equal to zero"]
+==== czero.eqz
+
+Synopsis::
+Moves zero to a register _rd_, if the condition _rs2_ is equal to zero, otherwise moves _rs1_ to _rd_.
+
+Mnemonic::
+czero.eqz _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x5, attr: ['CZERO.EQZ']},
+ { bits: 5, name: 'rs1', attr: ['value'] },
+ { bits: 5, name: 'rs2', attr: ['condition'] },
+ { bits: 7, name: 0x7, attr: ['CZERO'] },
+]}
+....
+
+Description::
+If _rs2_ contains the value zero, this instruction writes the value zero to _rd_. Otherwise, this instruction copies the contents of _rs1_ to _rd_.
+
+This instruction carries a syntactic dependency from both _rs1_ and _rs2_ to _rd_.
+Furthermore, if the Zkt extension is implemented, this instruction's timing is independent of the data values in _rs1_ and _rs2_.
+
+SAIL code::
+[source,sail]
+--
+ let condition = X(rs2);
+ result : xlenbits = if (condition == zeros()) then zeros()
+ else X(rs1);
+ X(rd) = result;
+--
+
+<<<
+
+[#insns-czero-nez,reftext="Conditional zero, if condition is nonzero"]
+==== czero.nez
+
+Synopsis::
+Moves zero to a register _rd_, if the condition _rs2_ is nonzero, otherwise moves _rs1_ to _rd_.
+
+Mnemonic::
+czero.nez _rd_, _rs1_, _rs2_
+
+Encoding::
+[wavedrom, , svg]
+....
+{reg:[
+ { bits: 7, name: 0x33, attr: ['OP'] },
+ { bits: 5, name: 'rd' },
+ { bits: 3, name: 0x7, attr: ['CZERO.NEZ']},
+ { bits: 5, name: 'rs1', attr: ['value'] },
+ { bits: 5, name: 'rs2', attr: ['condition'] },
+ { bits: 7, name: 0x7, attr: ['CZERO'] },
+]}
+....
+
+Description::
+If _rs2_ contains a nonzero value, this instruction writes the value zero to _rd_. Otherwise, this instruction copies the contents of _rs1_ to _rd_.
+
+This instruction carries a syntactic dependency from both _rs1_ and _rs2_ to _rd_.
+Furthermore, if the Zkt extension is implemented, this instruction's timing is independent of the data values in _rs1_ and _rs2_.
+
+SAIL code::
+[source,sail]
+--
+ let condition = X(rs2);
+ result : xlenbits = if (condition != zeros()) then zeros()
+ else X(rs1);
+ X(rd) = result;
+--
+
+=== Usage examples
+
+The instructions from this extension can be used to construct sequences that perform conditional-arithmetic, conditional-bitwise-logical, and conditional-select operations.
+
+==== Instruction sequences
+
+[%header,cols="4,.^3l,^2"]
+|===
+|Operation
+|Instruction sequence
+|Length
+
+|*Conditional add, if zero* +
+`rd = (rc == 0) ? (rs1 + rs2) : rs1`
+|czero.nez rd, rs2, rc
+add rd, rs1, rd
+.8+.^|2 insns
+
+|*Conditional add, if non-zero* +
+`rd = (rc != 0) ? (rs1 + rs2) : rs1`
+|czero.eqz rd, rs2, rc
+add rd, rs1, rd
+
+|*Conditional subtract, if zero* +
+`rd = (rc == 0) ? (rs1 - rs2) : rs1`
+|czero.nez rd, rs2, rc
+sub rd, rs1, rd
+
+|*Conditional subtract, if non-zero* +
+`rd = (rc != 0) ? (rs1 - rs2) : rs1`
+|czero.eqz rd, rs2, rc
+sub rd, rs1, rd
+
+|*Conditional bitwise-or, if zero* +
+`rd = (rc == 0) ? (rs1 \| rs2) : rs1`
+|czero.nez rd, rs2, rc
+or rd, rs1, rd
+
+|*Conditional bitwise-or, if non-zero* +
+`rd = (rc != 0) ? (rs1 \| rs2) : rs1`
+|czero.eqz rd, rs2, rc
+or rd, rs1, rd
+
+|*Conditional bitwise-xor, if zero* +
+`rd = (rc == 0) ? (rs1 ^ rs2) : rs1`
+|czero.nez rd, rs2, rc
+xor rd, rs1, rd
+
+|*Conditional bitwise-xor, if non-zero* +
+`rd = (rc != 0) ? (rs1 ^ rs2) : rs1`
+|czero.eqz rd, rs2, rc
+xor rd, rs1, rd
+
+|*Conditional bitwise-and, if zero* +
+`rd = (rc == 0) ? (rs1 & rs2) : rs1`
+|and rd, rs1, rs2
+czero.eqz rtmp, rs1, rc
+or rd, rd, rtmp
+.4+.^|3 insns +
+(requires 1 temporary)
+
+|*Conditional bitwise-and, if non-zero* +
+`rd = (rc != 0) ? (rs1 & rs2) : rs1`
+|and rd, rs1, rs2
+czero.nez rtmp, rs1, rc
+or rd, rd, rtmp
+
+|*Conditional select, if zero* +
+`rd = (rc == 0) ? rs1 : rs2`
+|czero.nez rd, rs1, rc
+czero.eqz rtmp, rs2, rc
+add rd, rd, rtmp
+
+|*Conditional select, if non-zero* +
+`rd = (rc != 0) ? rs1 : rs2`
+|czero.eqz rd, rs1, rc
+czero.nez rtmp, rs2, rc
+add rd, rd, rtmp
+
+|===
diff --git a/src/zicsr.adoc b/src/zicsr.adoc
new file mode 100644
index 0000000..7a77cbf
--- /dev/null
+++ b/src/zicsr.adoc
@@ -0,0 +1,237 @@
+[[csrinsts]]
+== "Zicsr", Extension for Control and Status Register (CSR) Instructions, Version 2.0
+
+RISC-V defines a separate address space of 4096 Control and Status
+registers associated with each hart. This chapter defines the full set
+of CSR instructions that operate on these CSRs.
+
+[NOTE]
+====
+While CSRs are primarily used by the privileged architecture, there are
+several uses in unprivileged code including for counters and timers, and
+for floating-point status.
+
+The counters and timers are no longer considered mandatory parts of the
+standard base ISAs, and so the CSR instructions required to access them
+have been moved out of <<rv32>> into this separate
+chapter.
+====
+
+=== CSR Instructions
+
+All CSR instructions atomically read-modify-write a single CSR, whose
+CSR specifier is encoded in the 12-bit _csr_ field of the instruction
+held in bits 31-20. The immediate forms use a 5-bit zero-extended
+immediate encoded in the _rs1_ field.
+
+include::images/wavedrom/csr-instr.edn[]
+
+The CSRRW (Atomic Read/Write CSR) instruction atomically swaps values in
+the CSRs and integer registers. CSRRW reads the old value of the CSR,
+zero-extends the value to XLEN bits, then writes it to integer register
+_rd_. The initial value in _rs1_ is written to the CSR. If _rd_=`x0`,
+then the instruction shall not read the CSR and shall not cause any of
+the side effects that might occur on a CSR read.
+
+The CSRRS (Atomic Read and Set Bits in CSR) instruction reads the value
+of the CSR, zero-extends the value to XLEN bits, and writes it to
+integer register _rd_. The initial value in integer register _rs1_ is
+treated as a bit mask that specifies bit positions to be set in the CSR.
+Any bit that is high in _rs1_ will cause the corresponding bit to be set
+in the CSR, if that CSR bit is writable.
+
+The CSRRC (Atomic Read and Clear Bits in CSR) instruction reads the
+value of the CSR, zero-extends the value to XLEN bits, and writes it to
+integer register _rd_. The initial value in integer register _rs1_ is
+treated as a bit mask that specifies bit positions to be cleared in the
+CSR. Any bit that is high in _rs1_ will cause the corresponding bit to
+be cleared in the CSR, if that CSR bit is writable.
+
+For both CSRRS and CSRRC, if _rs1_=`x0`, then the instruction will not
+write to the CSR at all, and so shall not cause any of the side effects
+that might otherwise occur on a CSR write, nor raise illegal-instruction
+exceptions on accesses to read-only CSRs. Both CSRRS and CSRRC always
+read the addressed CSR and cause any read side effects regardless of
+_rs1_ and _rd_ fields.
+Note that if _rs1_ specifies a register other than `x0`, and that register
+holds a zero value, the instruction will not action any attendant per-field
+side effects, but will action any side effects caused by writing to the entire
+CSR.
+
+A CSRRW with _rs1_=`x0` will attempt to write zero to the destination CSR.
+
+The CSRRWI, CSRRSI, and CSRRCI variants are similar to CSRRW, CSRRS, and
+CSRRC respectively, except they update the CSR using an XLEN-bit value
+obtained by zero-extending a 5-bit unsigned immediate (uimm[4:0]) field
+encoded in the _rs1_ field instead of a value from an integer register.
+For CSRRSI and CSRRCI, if the uimm[4:0] field is zero, then these
+instructions will not write to the CSR, and shall not cause any of the
+side effects that might otherwise occur on a CSR write, nor raise
+illegal-instruction exceptions on accesses to read-only CSRs. For
+CSRRWI, if _rd_=`x0`, then the instruction shall not read the CSR and
+shall not cause any of the side effects that might occur on a CSR read.
+Both CSRRSI and CSRRCI will always read the CSR and cause any read side
+effects regardless of _rd_ and _rs1_ fields.
+
+[[csrsideeffects]]
+.Conditions determining whether a CSR instruction reads or writes the specified CSR.
+[%autowidth,float="center",align="center",cols="<,^,^,^,^",options="header",]
+|===
+5+^|*Register operand*
+|Instruction |_rd_ is `x0` |_rs1_ is `x0` |Reads CSR |Writes CSR
+
+|CSRRW |Yes |- |No |Yes
+
+|CSRRW |No |- |Yes |Yes
+
+|CSRRS/CSRRC |- |Yes |Yes |No
+
+|CSRRS/CSRRC |- |No |Yes |Yes
+
+5+^|*Immediate operand*
+
+|Instruction |_rd_ is `x0` |_uimm_=0 |Reads CSR |Writes
+CSR
+
+|CSRRWI |Yes |- |No |Yes
+
+|CSRRWI |No |- |Yes |Yes
+
+|CSRRSI/CSRRCI |- |Yes |Yes |No
+
+|CSRRSI/CSRRCI |- |No |Yes |Yes
+|===
+
+<<csrsideeffects>> summarizes the behavior of the CSR
+instructions with respect to whether they read and/or write the CSR.
+
+In addition to side effects that occur as a consequence of reading or
+writing a CSR, individual fields within a CSR might have side effects
+when written. The CSRRW[I] instructions action side effects for all
+such fields within the written CSR. The CSRRS[I] an CSRRC[I] instructions
+only action side effects for fields for which the _rs1_ or _uimm_ argument
+has at least one bit set corresponding to that field.
+[NOTE]
+====
+As of this writing, no standard CSRs have side effects on field writes.
+Hence, whether a standard CSR access has any side effects can be determined
+solely from the opcode.
+
+Defining CSRs with side effects on field writes is not recommended.
+====
+
+For any event or consequence that occurs due to a CSR having a
+particular value, if a write to the CSR gives it that value, the
+resulting event or consequence is said to be an _indirect effect_ of the
+write. Indirect effects of a CSR write are not considered by the RISC-V
+ISA to be side effects of that write.
+[NOTE]
+====
+An example of side effects for CSR accesses would be if reading from a
+specific CSR causes a light bulb to turn on, while writing an odd value
+to the same CSR causes the light to turn off. Assume writing an even
+value has no effect. In this case, both the read and write have side
+effects controlling whether the bulb is lit, as this condition is not
+determined solely from the CSR value. (Note that after writing an odd
+value to the CSR to turn off the light, then reading to turn the light
+on, writing again the same odd value causes the light to turn off again.
+Hence, on the last write, it is not a change in the CSR value that turns
+off the light.)
+
+On the other hand, if a bulb is rigged to light whenever the value of a
+particular CSR is odd, then turning the light on and off is not
+considered a side effect of writing to the CSR but merely an indirect
+effect of such writes.
+
+More concretely, the RISC-V privileged architecture defined in Volume II
+specifies that certain combinations of CSR values cause a trap to occur.
+When an explicit write to a CSR creates the conditions that trigger the
+trap, the trap is not considered a side effect of the write but merely
+an indirect effect.
+
+Standard CSRs do not have any side effects on reads. Standard CSRs may
+have side effects on writes. Custom extensions might add CSRs for which
+accesses have side effects on either reads or writes.
+====
+Some CSRs, such as the instructions-retired counter, `instret`, may be
+modified as side effects of instruction execution. In these cases, if a
+CSR access instruction reads a CSR, it reads the value prior to the
+execution of the instruction. If a CSR access instruction writes such a
+CSR, the explicit write is done instead of the update from the side effect.
+In particular, a value
+written to `instret` by one instruction will be the value read by the
+following instruction.
+
+The assembler pseudoinstruction to read a CSR, CSRR _rd, csr_, is
+encoded as CSRRS _rd, csr, x0_. The assembler pseudoinstruction to write
+a CSR, CSRW _csr, rs1_, is encoded as CSRRW _x0, csr, rs1_, while CSRWI
+_csr, uimm_, is encoded as CSRRWI _x0, csr, uimm_.
+
+Further assembler pseudoinstructions are defined to set and clear bits
+in the CSR when the old value is not required: CSRS/CSRC _csr, rs1_;
+CSRSI/CSRCI _csr, uimm_.
+
+==== CSR Access Ordering
+
+Each RISC-V hart normally observes its own CSR accesses, including its
+implicit CSR accesses, as performed in program order. In particular,
+unless specified otherwise, a CSR access is performed after the
+execution of any prior instructions in program order whose behavior
+modifies or is modified by the CSR state and before the execution of any
+subsequent instructions in program order whose behavior modifies or is
+modified by the CSR state. Furthermore, an explicit CSR read returns the
+CSR state before the execution of the instruction, while an explicit CSR
+write suppresses and overrides any implicit writes or modifications to
+the same CSR by the same instruction.
+
+Likewise, any side effects from an explicit CSR access are normally
+observed to occur synchronously in program order. Unless specified
+otherwise, the full consequences of any such side effects are observable
+by the very next instruction, and no consequences may be observed
+out-of-order by preceding instructions. (Note the distinction made
+earlier between side effects and indirect effects of CSR writes.)
+
+For the RVWMO memory consistency model (<<memorymodel>>), CSR accesses are weakly
+ordered by default, so other harts or devices may observe CSR accesses
+in an order different from program order. In addition, CSR accesses are
+not ordered with respect to explicit memory accesses, unless a CSR
+access modifies the execution behavior of the instruction that performs
+the explicit memory access or unless a CSR access and an explicit memory
+access are ordered by either the syntactic dependencies defined by the
+memory model or the ordering requirements defined by the Memory-Ordering
+PMAs section in Volume II of this manual. To enforce ordering in all
+other cases, software should execute a FENCE instruction between the
+relevant accesses. For the purposes of the FENCE instruction, CSR read
+accesses are classified as device input (I), and CSR write accesses are
+classified as device output (O).
+[NOTE]
+====
+Informally, the CSR space acts as a weakly ordered memory-mapped I/O
+region, as defined by the Memory-Ordering PMAs section in Volume II of
+this manual. As a result, the order of CSR accesses with respect to all
+other accesses is constrained by the same mechanisms that constrain the
+order of memory-mapped I/O accesses to such a region.
+
+These CSR-ordering constraints are imposed to support ordering main
+memory and memory-mapped I/O accesses with respect to CSR accesses that
+are visible to, or affected by, devices or other harts. Examples include
+the `time`, `cycle`, and `mcycle` CSRs, in addition to CSRs that reflect
+pending interrupts, like `mip` and `sip`. Note that implicit reads of
+such CSRs (e.g., taking an interrupt because of a change in `mip`) are
+also ordered as device input.
+
+Most CSRs (including, e.g., the `fcsr`) are not visible to other harts;
+their accesses can be freely reordered in the global memory order with
+respect to FENCE instructions without violating this specification.
+====
+The hardware platform may define that accesses to certain CSRs are
+strongly ordered, as defined by the Memory-Ordering PMAs section in
+Volume II of this manual. Accesses to strongly ordered CSRs have
+stronger ordering constraints with respect to accesses to both weakly
+ordered CSRs and accesses to memory-mapped I/O regions.
+
+[NOTE]
+====
+The rules for the reordering of CSR accesses in the global memory order
+should probably be moved to <<memorymodel>> concerning the RVWMO memory consistency model.
+====
diff --git a/src/zifencei.adoc b/src/zifencei.adoc
new file mode 100644
index 0000000..591b546
--- /dev/null
+++ b/src/zifencei.adoc
@@ -0,0 +1,127 @@
+[[zifencei]]
+== "Zifencei" Extension for Instruction-Fetch Fence, Version 2.0
+This chapter defines the "Zifencei" extension, which includes the
+FENCE.I instruction that provides explicit synchronization between
+writes to instruction memory and instruction fetches on the same hart.
+Currently, this instruction is the only standard mechanism to ensure
+that stores visible to a hart will also be visible to its instruction
+fetches.
+(((store instruction word, not included)))
+
+[NOTE]
+====
+We considered but did not include a "store instruction word"
+instruction as in cite:[majc]. JIT compilers may generate a large trace of
+instructions before a single FENCE.I, and amortize any instruction cache
+snooping/invalidation overhead by writing translated instructions to
+memory regions that are known not to reside in the I-cache.
+====
+'''
+[NOTE]
+====
+The FENCE.I instruction was designed to support a wide variety of
+implementations. A simple implementation can flush the local instruction
+cache and the instruction pipeline when the FENCE.I is executed. A more
+complex implementation might snoop the instruction (data) cache on every
+data (instruction) cache miss, or use an inclusive unified private L2
+cache to invalidate lines from the primary instruction cache when they
+are being written by a local store instruction. If instruction and data
+caches are kept coherent in this way, or if the memory system consists
+of only uncached RAMs, then just the fetch pipeline needs to be flushed
+at a FENCE.I.
+
+The FENCE.I instruction was previously part of the base I instruction
+set. Two main issues are driving moving this out of the mandatory base,
+although at time of writing it is still the only standard method for
+maintaining instruction-fetch coherence.
+
+First, it has been recognized that on some systems, FENCE.I will be
+expensive to implement and alternate mechanisms are being discussed in
+the memory model task group. In particular, for designs that have an
+incoherent instruction cache and an incoherent data cache, or where the
+instruction cache refill does not snoop a coherent data cache, both
+caches must be completely flushed when a FENCE.I instruction is
+encountered. This problem is exacerbated when there are multiple levels
+of I and D cache in front of a unified cache or outer memory system.
+
+Second, the instruction is not powerful enough to make available at user
+level in a Unix-like operating system environment. The FENCE.I only
+synchronizes the local hart, and the OS can reschedule the user hart to
+a different physical hart after the FENCE.I. This would require the OS
+to execute an additional FENCE.I as part of every context migration. For
+this reason, the standard Linux ABI has removed FENCE.I from user-level
+and now requires a system call to maintain instruction-fetch coherence,
+which allows the OS to minimize the number of FENCE.I executions
+required on current systems and provides forward-compatibility with
+future improved instruction-fetch coherence mechanisms.
+
+Future approaches to instruction-fetch coherence under discussion
+include providing more restricted versions of FENCE.I that only target a
+given address specified in _rs1_, and/or allowing software to use an ABI
+that relies on machine-mode cache-maintenance operations.
+====
+
+include::images/wavedrom/zifencei-ff.edn[]
+[[zifencei-ff]]
+//.FENCE.I instruction
+(((FENCE.I, synchronization)))
+
+The FENCE.I instruction is used to synchronize the instruction and data
+streams. RISC-V does not guarantee that stores to instruction memory
+will be made visible to instruction fetches on a RISC-V hart until that
+hart executes a FENCE.I instruction. A FENCE.I instruction ensures that
+a subsequent instruction fetch on a RISC-V hart will see any previous
+data stores already visible to the same RISC-V hart. FENCE.I does _not_
+ensure that other RISC-V harts' instruction fetches will observe the
+local hart's stores in a multiprocessor system. To make a store to
+instruction memory visible to all RISC-V harts, the writing hart also
+has to execute a data FENCE before requesting that all remote RISC-V
+harts execute a FENCE.I.
+
+A FENCE.I instruction orders all explicit memory accesses that precede the
+FENCE.I in program order before all instruction fetches that follow the
+FENCE.I in program order.
+
+[NOTE]
+====
+In the following litmus test, for example, the outcome `a0`=1, `a1`=0 on
+the consumer hart is forbidden, assuming little-endian RV32IC harts:
+
+```
+Initially, flag = 0.
+
+Producer hart: Consumer hart:
+
+la t0, patch_me la t2, flag
+li t1, 0x4585 lw a0, (t2)
+sh t1, (t0) # patch_me := c.li a1, 1 fence.i
+fence w, w # order flag write patch_me:
+la t0, flag c.li a1, 0
+li t1, 1
+sw t1, (t0) # flag := 1
+```
+
+Note that this example is only meant to illustrate the aforementioned ordering
+property.
+In a realistic producer-consumer code-generation scheme, the consumer would loop
+until `flag` becomes 1 before executing the FENCE.I instruction.
+====
+
+An instruction fetch is always ordered before any explicit memory accesses
+that instruction gives rise to.
+
+The unused fields in the FENCE.I instruction, _funct12_, _rs1_, and
+_rd_, are reserved for finer-grain fences in future extensions. For
+forward compatibility, base implementations shall ignore these fields,
+and standard software shall zero these fields.
+(((FENCE.I, finer-grained)))
+(((FENCE.I, forward compatibility)))
+
+[NOTE]
+====
+Because FENCE.I only orders stores with a hart's own instruction
+fetches, application code should only rely upon FENCE.I if the
+application thread will not be migrated to a different hart. The EEI can
+provide mechanisms for efficient multiprocessor instruction-stream
+synchronization.
+====
diff --git a/src/zifencei.tex b/src/zifencei.tex
deleted file mode 100644
index d152c6d..0000000
--- a/src/zifencei.tex
+++ /dev/null
@@ -1,111 +0,0 @@
-\chapter{``Zifencei'' Instruction-Fetch Fence, Version 2.0}
-\label{chap:zifencei}
-
-This chapter defines the ``Zifencei'' extension, which includes the
-FENCE.I instruction that provides explicit synchronization between
-writes to instruction memory and instruction fetches on the same hart.
-Currently, this instruction is the only standard mechanism to ensure
-an instruction modified by a store on a hart will be visible to a
-subsequent instruction fetch on the same hart.
-
-\begin{commentary}
-We considered but did not include a ``store instruction word''
-instruction (as in MAJC~\cite{majc}). JIT compilers may generate a
-large trace of instructions before a single FENCE.I, and amortize any
-instruction cache snooping/invalidation overhead by writing translated
-instructions to memory regions that are known not to reside in the
-I-cache.
-\end{commentary}
-
-\begin{commentary}
-The FENCE.I instruction was designed to support a wide variety of
-implementations. A simple implementation can flush the local
-instruction cache and the instruction pipeline when the FENCE.I is
-executed. A more complex implementation might snoop the instruction
-(data) cache on every data (instruction) cache miss, or use an
-inclusive unified private L2 cache to invalidate lines from the
-primary instruction cache when they are being written by a local store
-instruction. If instruction and data caches are kept coherent in this
-way, or if the memory system consists of only uncached RAMs, then just
-the fetch pipeline needs to be flushed at a FENCE.I.
-
-The FENCE.I instruction was previously part of the base I instruction
-set. Two main issues are driving moving this out of the mandatory
-base, although at time of writing it is still the only standard method
-for maintaining instruction-fetch coherence.
-
-First, it has been recognized that on some systems, FENCE.I will be
-expensive to implement and alternate mechanisms are being discussed in
-the memory model task group. In particular, for designs that have an
-incoherent instruction cache and an incoherent data cache, or where
-the instruction cache refill does not snoop a coherent data cache,
-both caches must be completely flushed when a FENCE.I instruction is
-encountered. This problem is exacerbated when there are multiple
-levels of I and D cache in front of a unified cache or outer memory
-system.
-
-Second, the instruction is not powerful enough to make available at
-user level in a Unix-like operating system environment. The FENCE.I
-only synchronizes the local hart, and the OS can reschedule the user
-hart to a different physical hart after the FENCE.I. This would
-require the OS to execute an additional FENCE.I as part of every
-context migration. For this reason, the standard Linux ABI has
-removed FENCE.I from user-level and now requires a system call to
-maintain instruction-fetch coherence, which allows the OS to minimize
-the number of FENCE.I executions required on current systems and
-provides forward-compatibility with future improved instruction-fetch
-coherence mechanisms.
-
-Future approaches to instruction-fetch coherence under discussion
-include providing more restricted versions of FENCE.I that only target
-a given address specified in {\em rs1}, and/or allowing software to use an
-ABI that relies on machine-mode cache-maintenance operations.
-\end{commentary}
-
-\vspace{-0.4in}
-\begin{center}
-\begin{tabular}{M@{}R@{}S@{}R@{}O}
-\\
-\instbitrange{31}{20} &
-\instbitrange{19}{15} &
-\instbitrange{14}{12} &
-\instbitrange{11}{7} &
-\instbitrange{6}{0} \\
-\hline
-\multicolumn{1}{|c|}{imm[11:0]} &
-\multicolumn{1}{c|}{rs1} &
-\multicolumn{1}{c|}{funct3} &
-\multicolumn{1}{c|}{rd} &
-\multicolumn{1}{c|}{opcode} \\
-\hline
-12 & 5 & 3 & 5 & 7 \\
-0 & 0 & FENCE.I & 0 & MISC-MEM \\
-\end{tabular}
-\end{center}
-
-The FENCE.I instruction is used to synchronize the instruction and
-data streams. RISC-V does not guarantee that stores to instruction
-memory will be made visible to instruction fetches on the same RISC-V
-hart until a FENCE.I instruction is executed. A FENCE.I instruction
-only ensures that a subsequent instruction fetch on a RISC-V hart
-will see any previous data stores already visible to the same RISC-V
-hart. FENCE.I does {\em not} ensure that other RISC-V harts'
-instruction fetches will observe the local hart's stores in a
-multiprocessor system. To make a store to instruction memory visible
-to all RISC-V harts, the writing hart has to execute a data FENCE
-before requesting that all remote RISC-V harts execute a FENCE.I.
-
-The unused fields in the FENCE.I instruction, {\em imm[11:0]}, {\em rs1}, and
-{\em rd}, are reserved for finer-grain fences in future extensions. For
-forward compatibility, base implementations shall ignore these fields, and
-standard software shall zero these fields.
-
-\begin{commentary}
-Because FENCE.I only orders stores with a hart's own instruction
-fetches, application code should only rely upon FENCE.I if the
-application thread will not be migrated to a different hart. The EEI
-can provide mechanisms for efficient multiprocessor instruction-stream
-synchronization.
-\end{commentary}
-
-
diff --git a/src/zihintntl.adoc b/src/zihintntl.adoc
new file mode 100644
index 0000000..3e40370
--- /dev/null
+++ b/src/zihintntl.adoc
@@ -0,0 +1,188 @@
+[[chap:zihintntl]]
+== "Zihintntl" Extension for Non-Temporal Locality Hints, Version 1.0
+
+The NTL instructions are HINTs that indicate that the explicit memory
+accesses of the immediately subsequent instruction (henceforth "target
+instruction") exhibit poor temporal locality of reference. The NTL
+instructions do not change architectural state, nor do they alter the
+architecturally visible effects of the target instruction. Four variants
+are provided:
+
+The NTL.P1 instruction indicates that the target instruction does not
+exhibit temporal locality within the capacity of the innermost level of
+private cache in the memory hierarchy. NTL.P1 is encoded as
+ADD _x0, x0, x2_.
+
+The NTL.PALL instruction indicates that the target instruction does not
+exhibit temporal locality within the capacity of any level of private
+cache in the memory hierarchy. NTL.PALL is encoded as ADD _x0, x0, x3_.
+
+The NTL.S1 instruction indicates that the target instruction does not
+exhibit temporal locality within the capacity of the innermost level of
+shared cache in the memory hierarchy. NTL.S1 is encoded as
+ADD _x0, x0, x4_.
+
+The NTL.ALL instruction indicates that the target instruction does not
+exhibit temporal locality within the capacity of any level of cache in
+the memory hierarchy. NTL.ALL is encoded as ADD _x0, x0, x5_.
+
+[NOTE]
+====
+The NTL instructions can be used to avoid cache pollution when streaming
+data or traversing large data structures, or to reduce latency in
+producer-consumer interactions.
+
+A microarchitecture might use the NTL instructions to inform the cache
+replacement policy, or to decide which cache to allocate into, or to
+avoid cache allocation altogether. For example, NTL.P1 might indicate
+that an implementation should not allocate a line in a private L1 cache,
+but should allocate in L2 (whether private or shared). In another
+implementation, NTL.P1 might allocate the line in L1, but in the
+least-recently used state.
+
+NTL.ALL will typically inform implementations not to allocate anywhere
+in the cache hierarchy. Programmers should use NTL.ALL for accesses that
+have no exploitable temporal locality.
+
+Like any HINTs, these instructions may be freely ignored. Hence,
+although they are described in terms of cache-based memory hierarchies,
+they do not mandate the provision of caches.
+
+Some implementations might respect these HINTs for some memory accesses
+but not others: e.g., implementations that implement LR/SC by acquiring
+a cache line in the exclusive state in L1 might ignore NTL instructions
+on LR and SC, but might respect NTL instructions for AMOs and regular
+loads and stores.
+====
+
+<<ntl-portable>> lists several software use cases and the recommended NTL variant that _portable_ software—i.e., software not tuned for any specific implementation's memory hierarchy—should use in each case.
+
+[[ntl-portable]]
+.Recommended NTL variant for portable software to employ in various scenarios.
+[%autowidth,float="center",align="center",cols="<,<",options="header",]
+|===
+|Scenario |Recommended NTL variant
+|Access to a working set between and in size |NTL.P1
+|Access to a working set between and in size |NTL.PALL
+|Access to a working set greater than in size |NTL.S1
+|Access with no exploitable temporal locality (e.g., streaming) |NTL.ALL
+|Access to a contended synchronization variable |NTL.PALL
+|===
+
+[NOTE]
+====
+The working-set sizes listed in <<ntl-portable>> are not meant to
+constrain implementers' cache-sizing decisions.
+Cache sizes will obviously vary between implementations, and so software
+writers should only take these working-set sizes as rough guidelines.
+====
+
+<<ntl>> lists several sample memory hierarchies and
+recommends how each NTL variant maps onto each cache level. The table
+also recommends which NTL variant that implementation-tuned software
+should use to avoid allocating in a particular cache level. For example,
+for a system with a private L1 and a shared L2, it is recommended that
+NTL.P1 and NTL.PALL indicate that temporal locality cannot be exploited
+by the L1, and that NTL.S1 and NTL.ALL indicate that temporal locality
+cannot be exploited by the L2. Furthermore, software tuned for such a
+system should use NTL.P1 to indicate a lack of temporal locality
+exploitable by the L1, or should use NTL.ALL indicate a lack of temporal
+locality exploitable by the L2.
+
+If the C or Zca extension is provided, compressed variants of these HINTs are
+also provided: C.NTL.P1 is encoded as C.ADD _x0, x2_; C.NTL.PALL is
+encoded as C.ADD _x0, x3_; C.NTL.S1 is encoded as C.ADD _x0, x4_; and
+C.NTL.ALL is encoded as C.ADD _x0, x5_.
+
+The NTL instructions affect all memory-access instructions except the
+cache-management instructions in the Zicbom extension.
+
+[NOTE]
+====
+As of this writing, there are no other exceptions to this rule, and so
+the NTL instructions affect all memory-access instructions defined in
+the base ISAs and the A, F, D, Q, C, and V standard extensions, as well
+as those defined within the hypervisor extension in Volume II.
+
+The NTL instructions can affect cache-management operations other than
+those in the Zicbom extension. For example, NTL.PALL followed by
+CBO.ZERO might indicate that the line should be allocated in L3 and
+zeroed, but not allocated in L1 or L2.
+====
+
+<<<
+
+[[ntl]]
+[%autowidth,float="center",align="center",cols="<,^,^,^,^,^,^,^,^",options="header"]
+.Mapping of NTL variants to various memory hierarchies.
+|===
+| Memory hierarchy 4+| Recommended mapping of NTL +
+variant to actual cache level 4+| Recommended NTL variant for +
+explicit cache management
+|
+|P1 |PALL |S1 |ALL
+|L1 |L2 |L3 |L4/L5
+ 9+^| Common Scenarios
+| No caches 4+|--- 4+|none
+|Private L1 only |L1 |L1 |L1 |L1| ALL |--- |--- |---
+|Private L1; shared L2 |L1 |L1 |L2 |L2 |P1|ALL|---|---
+|Private L1; shared L2/L3 |L1 | L1 | L2 | L3 |P1 |S1 |ALL |---
+|Private L1/L2 |L1 |L2 |L2 |L2 | P1 |ALL |--- |---
+|Private L1/L2; shared L3 |L1 | L2 | L3 | L3 | P1 | PALL| ALL |---
+|Private L1/L2; shared L3/L4 | L1 | L2| L3 | L4 | P1 | PALL | S1 | ALL
+ 9+^| Uncommon Scenarios
+|Private L1/L2/L3; shared L4 | L1 | L3 |L4 |L4 |P1 |P1 |PALL |ALL
+|Private L1; shared L2/L3/L4 |L1 | L1 |L2 |L4 |P1 |S1 |ALL |ALL
+|Private L1/L2; shared L3/L4/L5 |L1 | L2 | L3 | L5 |P1 | PALL |S1 |ALL
+|Private L1/L2/L3; shared L4/L5 |L1 |L3 |L4 |L5 |P1 |P1 |PALL |ALL
+|===
+
+When an NTL instruction is applied to a prefetch hint in the Zicbop
+extension, it indicates that a cache line should be prefetched into a
+cache that is _outer_ from the level specified by the NTL.
+
+[NOTE]
+====
+For example, in a system with a private L1 and shared L2, NTL.P1
+followed by PREFETCH.R might prefetch into L2 with read intent.
+
+To prefetch into the innermost level of cache, do not prefix the
+prefetch instruction with an NTL instruction.
+
+In some systems, NTL.ALL followed by a prefetch instruction might
+prefetch into a cache or prefetch buffer internal to a memory
+controller.
+====
+
+Software is discouraged from following an NTL instruction with an
+instruction that does not explicitly access memory. Nonadherence to this
+recommendation might reduce performance but otherwise has no
+architecturally visible effect.
+
+In the event that a trap is taken on the target instruction,
+implementations are discouraged from applying the NTL to the first
+instruction in the trap handler. Instead, implementations are
+recommended to ignore the HINT in this case.
+
+[NOTE]
+====
+If an interrupt occurs between the execution of an NTL instruction and
+its target instruction, execution will normally resume at the target
+instruction. That the NTL instruction is not re-executed does not change
+the semantics of the program.
+
+Some implementations might prefer not to process the NTL instruction
+until the target instruction is seen (e.g., so that the NTL can be fused
+with the memory access it modifies). Such implementations might
+preferentially take the interrupt before the NTL, rather than between
+the NTL and the memory access.
+====
+'''
+[NOTE]
+====
+Since the NTL instructions are encoded as ADDs, they can be used within
+LR/SC loops without voiding the forward-progress guarantee. But, since
+using other loads and stores within an LR/SC loop _does_ void the
+forward-progress guarantee, the only reason to use an NTL within such a
+loop is to modify the LR or the SC.
+====
diff --git a/src/zihintpause.adoc b/src/zihintpause.adoc
new file mode 100644
index 0000000..bf419db
--- /dev/null
+++ b/src/zihintpause.adoc
@@ -0,0 +1,56 @@
+[[zihintpause]]
+== "Zihintpause" Extension for Pause Hint, Version 2.0
+The PAUSE instruction is a HINT that indicates the current hart's rate
+of instruction retirement should be temporarily reduced or paused. The
+duration of its effect must be bounded and may be zero.
+(((PAUSE, HINT)))
+(((HINT, PAUSE)))
+
+[NOTE]
+====
+Software can use the PAUSE instruction to reduce energy consumption
+while executing spin-wait code sequences. Multithreaded cores might
+temporarily relinquish execution resources to other harts when PAUSE is
+executed. It is recommended that a PAUSE instruction generally be
+included in the code sequence for a spin-wait loop.
+(((PAUSE, energy consumption)))
+
+The duration of a PAUSE instruction's effect may vary significantly
+within and among implementations. In typical implementations this
+duration should be much less than the time to perform a context switch,
+probably more on the rough order of an on-chip cache miss latency or a
+cacheless access to main memory.
+(((PAUSE, duration)))
+
+A series of PAUSE instructions can be used to create a cumulative delay
+loosely proportional to the number of PAUSE instructions. In spin-wait
+loops in portable code, however, only one PAUSE instruction should be
+used before re-evaluating loop conditions, else the hart might stall
+longer than optimal on some implementations, degrading system
+performance.
+====
+
+PAUSE is encoded as a FENCE instruction with _pred_=`W`, _succ_=`0`, _fm_=`0`,
+_rd_=`x0`, and _rs1_=`x0`.
+
+//include::images/wavedrom/zihintpause-hint.edn[]
+//[zihintpause-hint]
+//.Zihintpause fence instructions
+
+[NOTE]
+====
+PAUSE is encoded as a hint within the FENCE opcode because some
+implementations are expected to deliberately stall the PAUSE instruction
+until outstanding memory transactions have completed. Because the
+successor set is null, however, PAUSE does not _mandate_ any particular
+memory ordering—hence, it truly is a HINT.
+(((PAUSE, encoding)))
+
+Like other FENCE instructions, PAUSE cannot be used within LR/SC
+sequences without voiding the forward-progress guarantee.
+(((PAUSE, LR/RC sequences)))
+
+The choice of a predecessor set of W is arbitrary, since the successor
+set is null. Other HINTs similar to PAUSE might be encoded with other
+predecessor sets.
+====
diff --git a/src/zilsd.adoc b/src/zilsd.adoc
new file mode 100644
index 0000000..c88f3de
--- /dev/null
+++ b/src/zilsd.adoc
@@ -0,0 +1,316 @@
+[[sec:zilsd]]
+== "Zilsd", "Zclsd" Extensions for Load/Store pair for RV32, Version 1.0
+
+The Zilsd & Zclsd extensions provide load/store pair instructions for RV32, reusing the existing RV64 doubleword load/store instruction encodings.
+
+[#norm:Zilsd_reg_pairs]#Operands containing `src` for store instructions and `dest` for load instructions are held in aligned `x`-register pairs, i.e., register numbers must be even.# Use of misaligned (odd-numbered) registers for these operands is _reserved_.
+
+[[norm:Zilsd_bits_to_pair]]
+Regardless of endianness, the lower-numbered register holds the
+low-order bits, and the higher-numbered register holds the high-order
+bits: e.g., bits 31:0 of an operand in Zilsd might be held in register `x14`, with bits 63:32 of that operand held in `x15`.
+
+[[zilsd, Zilsd]]
+=== Load/Store pair instructions (Zilsd)
+
+The Zilsd extension adds the following RV32-only instructions:
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|yes
+|no
+|ld rd, offset(rs1)
+|<<#insns-ld>>
+
+|yes
+|no
+|sd rs2, offset(rs1)
+|<<#insns-sd>>
+
+|===
+
+[#norm:Zilsd_align8_no_exc]#As the access size is 64-bit, accesses are only considered naturally aligned for effective addresses that are a multiple of 8.
+In this case, these instructions are guaranteed to not raise an address-misaligned exception.#
+[#norm:Zilsd_align8_atomic_unknown]#Even if naturally aligned, the memory access might not be performed atomically.#
+
+[#norm:Zilsd_align4_atomic]#If the effective address is a multiple of 4, then each word access is required to be performed atomically.#
+
+The following table summarizes the required behavior:
+
+[%header]
+|===
+|Alignment |Word accesses guaranteed atomic? |Can cause misaligned trap?
+|8{nbsp}B |yes |no
+|4{nbsp}B not 8{nbsp}B |yes |yes
+|else |no | yes
+|===
+
+[#norm:Zilsd_ld_resume_trap]#To ensure resumable trap handling is possible for the load instructions, the base register must
+have its original value if a trap is taken. The other register in the pair can have been updated.
+This affects x2 for the stack pointer relative instruction and rs1 otherwise.#
+
+[NOTE]
+====
+If an implementation performs a doubleword load access atomically and the register file implements write-back for even/odd register pairs,
+the mentioned atomicity requirements are inherently fulfilled.
+Otherwise, an implementation either needs to delay the write-back until the write can be performed atomically,
+or order sequential writes to the registers to ensure the requirement above is satisfied.
+====
+
+[[zclsd, Zclsd]]
+=== Compressed Load/Store pair instructions (Zclsd)
+
+Zclsd depends on Zilsd and Zca. It has overlapping encodings with Zcf and is thus incompatible with Zcf.
+
+Zclsd adds the following RV32-only instructions:
+
+[%header,cols="^1,^1,4,8"]
+|===
+|RV32
+|RV64
+|Mnemonic
+|Instruction
+
+|yes
+|no
+|c.ldsp rd, offset(sp)
+|<<#insns-cldsp>>
+
+|yes
+|no
+|c.sdsp rs2, offset(sp)
+|<<#insns-csdsp>>
+
+|yes
+|no
+|c.ld rd', offset(rs1')
+|<<#insns-cld>>
+
+|yes
+|no
+|c.sd rs2', offset(rs1')
+|<<#insns-csd>>
+
+|===
+
+=== Use of x0 as operand
+
+[[norm:Zilsd_ld_x0]]
+LD instructions with destination `x0` are processed as any other load, but the result is discarded entirely and x1 is not written.
+For C.LDSP, usage of `x0` as the destination is reserved.
+
+[[norm:Zilsd_sd_x0]]
+If using `x0` as `src` of SD or C.SDSP, the entire 64-bit operand is zero — i.e., register `x1` is not accessed.
+
+C.LD and C.SD instructions can only use `x8-15`.
+
+=== Exception Handling
+
+[#norm:Zilsd_RVWMO_exc_misaligned]#For the purposes of RVWMO and exception handling, LD and SD instructions are
+considered to be misaligned loads and stores#, with one additional constraint:
+[#norm:Zilsd_align4_two_4byte]#an LD or SD instruction whose effective address is a multiple of 4 gives rise
+to two 4-byte memory operations.#
+
+NOTE: This definition permits LD and SD instructions giving rise to exactly one
+memory access, regardless of alignment.
+If instructions with 4-byte-aligned effective address are decomposed
+into two 32b operations, there is no constraint on the order in which the
+operations are performed and each operation is guaranteed to be atomic.
+These decomposed sequences are interruptible.
+Exceptions might occur on subsequent operations, making the effects of previous
+operations within the same instruction visible.
+
+NOTE: Software should make no assumptions about the number or order of
+accesses these instructions might give rise to, beyond the 4-byte constraint
+mentioned above.
+For example, an interrupted store might overwrite the same bytes upon return
+from the interrupt handler.
+
+<<<
+
+=== Instructions
+[#insns-ld,reftext="Load doubleword to register pair, 32-bit encoding"]
+==== ld
+
+Synopsis::
+Load doubleword to even/odd register pair, 32-bit encoding
+
+Mnemonic::
+ld rd, offset(rs1)
+
+Encoding (RV32)::
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 0x3, attr: ['LOAD'], type: 8},
+ {bits: 5, name: 'rd', attr: ['dest, dest[0]=0'], type: 2},
+ {bits: 3, name: 0x3, attr: ['width=D'], type: 8},
+ {bits: 5, name: 'rs1', attr: ['base'], type: 4},
+ {bits: 12, name: 'imm[11:0]', attr: ['offset[11:0]'], type: 3},
+]}
+....
+
+Description::
+[[norm:Zilsd_ld_op]]
+Loads a 64-bit value into registers `rd` and `rd+1`.
+The effective address is obtained by adding register rs1 to the
+sign-extended 12-bit offset.
+
+Included in: <<zilsd>>
+
+<<<
+
+[#insns-sd,reftext="Store doubleword from register pair, 32-bit encoding"]
+==== sd
+
+Synopsis::
+Store doubleword from even/odd register pair, 32-bit encoding
+
+Mnemonic::
+sd rs2, offset(rs1)
+
+Encoding (RV32)::
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 7, name: 0x23, attr: ['STORE'], type: 8},
+ {bits: 5, name: 'imm[4:0]', attr: ['offset[4:0]'], type: 3},
+ {bits: 3, name: 0x3, attr: ['width=D'], type: 8},
+ {bits: 5, name: 'rs1', attr: ['base'], type: 4},
+ {bits: 5, name: 'rs2', attr: ['src, src[0]=0'], type: 4},
+ {bits: 7, name: 'imm[11:5]', attr: ['offset[11:5]'], type: 3},
+]}
+....
+
+Description::
+[[norm:Zilsd_sd_op]]
+Stores a 64-bit value from registers `rs2` and `rs2+1`.
+The effective address is obtained by adding register rs1 to the
+sign-extended 12-bit offset.
+
+Included in: <<zilsd>>
+
+<<<
+
+[#insns-cldsp,reftext="Stack-pointer based load doubleword to register pair, 16-bit encoding"]
+==== c.ldsp
+
+Synopsis::
+Stack-pointer based load doubleword to even/odd register pair, 16-bit encoding
+
+Mnemonic::
+c.ldsp rd, offset(sp)
+
+Encoding (RV32)::
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 0x2, type: 8, attr: ['C2']},
+ {bits: 5, name: 'imm', type: 3, attr: ['offset[4:3|8:6]']},
+ {bits: 5, name: 'rd', type: 2, attr: ['dest≠0, dest[0]=0']},
+ {bits: 1, name: 'imm', type: 3, attr: ['offset[5]']},
+ {bits: 3, name: 0x3, type: 8, attr: ['C.LDSP']},
+], config: {bits: 16}}
+....
+
+Description::
+[[norm:c-ldsp_op]]
+Loads stack-pointer relative 64-bit value into registers `rd'` and `rd'+1`. It computes its effective address by adding the zero-extended offset, scaled by 8, to the stack pointer, `x2`. It expands to `ld rd, offset(x2)`. C.LDSP is only valid when _rd_&#x2260;x0; the code points with _rd_=x0 are reserved.
+
+Included in: <<zclsd>>
+
+<<<
+
+[#insns-csdsp,reftext="Stack-pointer based store doubleword from register pair, 16-bit encoding"]
+==== c.sdsp
+
+Synopsis::
+Stack-pointer based store doubleword from even/odd register pair, 16-bit encoding
+
+Mnemonic::
+c.sdsp rs2, offset(sp)
+
+Encoding (RV32)::
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 0x2, type: 8, attr: ['C2']},
+ {bits: 5, name: 'rs2', type: 4, attr: ['src, src[0]=0']},
+ {bits: 6, name: 'imm', type: 3, attr: ['offset[5:3|8:6]']},
+ {bits: 3, name: 0x7, type: 8, attr: ['C.SDSP']},
+], config: {bits: 16}}
+....
+
+Description::
+[[norm:c-sdsp_op]]
+Stores a stack-pointer relative 64-bit value from registers `rs2'` and `rs2'+1`. It computes an effective address by adding the _zero_-extended offset, scaled by 8, to the stack pointer, `x2`. It expands to `sd rs2, offset(x2)`.
+
+Included in: <<zclsd>>
+
+<<<
+
+[#insns-cld,reftext="Load doubleword to register pair, 16-bit encoding"]
+==== c.ld
+
+Synopsis::
+Load doubleword to even/odd register pair, 16-bit encoding
+
+Mnemonic::
+c.ld rd', offset(rs1')
+
+Encoding (RV32)::
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 0x0, type: 8, attr: ['C0']},
+ {bits: 3, name: 'rd`', type: 2, attr: ['dest, dest[0]=0']},
+ {bits: 2, name: 'imm', type: 3, attr: ['offset[7:6]']},
+ {bits: 3, name: 'rs1`', type: 4, attr: ['base']},
+ {bits: 3, name: 'imm', type: 3, attr: ['offset[5:3]']},
+ {bits: 3, name: 0x3, type: 8, attr: ['C.LD']},
+], config: {bits: 16}}
+....
+
+Description::
+[[norm:c-ld_op]]
+Loads a 64-bit value into registers `rd'` and `rd'+1`.
+It computes an effective address by adding the zero-extended offset, scaled by 8, to the base address in register rs1'.
+
+Included in: <<zclsd>>
+
+<<<
+
+[#insns-csd,reftext="Store doubleword from register pair, 16-bit encoding"]
+==== c.sd
+
+Synopsis::
+Store doubleword from even/odd register pair, 16-bit encoding
+
+Mnemonic::
+c.sd rs2', offset(rs1')
+
+Encoding (RV32)::
+[wavedrom, ,svg]
+....
+{reg: [
+ {bits: 2, name: 0x0, type: 8, attr: ['C0']},
+ {bits: 3, name: 'rs2`', type: 4, attr: ['src, src[0]=0']},
+ {bits: 2, name: 'imm', type: 3, attr: ['offset[7:6]']},
+ {bits: 3, name: 'rs1`', type: 4, attr: ['base']},
+ {bits: 3, name: 'imm', type: 3, attr: ['offset[5:3]']},
+ {bits: 3, name: 0x7, type: 8, attr: ['C.SD']},
+], config: {bits: 16}}
+....
+
+Description::
+[[norm:c-sd_op]]
+Stores a 64-bit value from registers `rs2'` and `rs2'+1`.
+It computes an effective address by adding the zero-extended offset, scaled by 8, to the base address in register rs1'.
+It expands to `sd rs2', offset(rs1')`.
+
+Included in: <<zclsd>>
diff --git a/src/zimop.adoc b/src/zimop.adoc
new file mode 100644
index 0000000..307d9a1
--- /dev/null
+++ b/src/zimop.adoc
@@ -0,0 +1,110 @@
+[[zimop]]
+== "Zimop" Extension for May-Be-Operations, Version 1.0
+
+This chapter defines the "Zimop" extension, which introduces the concept of
+instructions that _may be operations_ (MOPs). MOPs are initially defined to
+simply write zero to `x[rd]`, but are designed to be redefined by later
+extensions to perform some other action.
+The Zimop extension defines an encoding space for 40 MOPs.
+
+[NOTE]
+====
+It is sometimes desirable to define instruction-set extensions whose
+instructions, rather than raising illegal-instruction exceptions when the extension is
+not implemented, take no useful action (beyond writing `x[rd]`).
+For example, programs with control-flow integrity checks can
+execute correctly on implementations without the corresponding extension,
+provided the checks are simply ignored. Implementing these checks as MOPs
+allows the same programs to run on implementations with or without the
+corresponding extension.
+
+Although similar in some respects to HINTs, MOPs cannot be encoded as HINTs,
+because unlike HINTs, MOPs are allowed to alter architectural state.
+
+Because MOPs may be redefined by later extensions, standard software should
+not execute a MOP unless it is deliberately targeting an extension that has
+redefined that MOP.
+====
+
+The Zimop extension defines 32 MOP instructions named MOP.R.__n__, where
+__n__ is an integer between 0 and 31, inclusive.
+Unless redefined by another extension, these instructions simply write 0 to
+`x[rd]`. Their encoding allows future extensions to define them to read `x[rs1]`,
+as well as write `x[rd]`.
+
+include::images/wavedrom/mop-r.edn[]
+[[mop-r]]
+
+The Zimop extension additionally defines 8 MOP instructions named
+MOP.RR.__n__, where __n__ is an integer between 0 and 7, inclusive.
+Unless redefined by another extension, these instructions simply
+write 0 to `x[rd]`. Their encoding allows future extensions to define them to
+read `x[rs1]` and `x[rs2]`, as well as write `x[rd]`.
+
+include::images/wavedrom/mop-rr.edn[]
+[[mop-rr]]
+
+NOTE: The recommended assembly syntax for MOP.R.__n__ is MOP.R.__n__ rd, rs1,
+with any `x`-register specifier being valid for either argument. Similarly for
+MOP.RR.__n__, the recommended syntax is MOP.RR.__n__ rd, rs1, rs2.
+The extension that redefines a MOP may define an alternate assembly mnemonic.
+
+NOTE: These MOPs are encoded in the SYSTEM major opcode in part because it is
+expected their behavior will be modulated by privileged CSR state.
+
+NOTE: These MOPs are defined to write zero to `x[rd]`, rather than performing
+no operation, to simplify instruction decoding and to allow testing the
+presence of features by branching on the zeroness of the result.
+
+The MOPs defined in the Zimop extension do not carry a syntactic dependency
+from `x[rs1]` or `x[rs2]` to `x[rd]`, though an extension that redefines the
+MOP may impose such a requirement.
+
+NOTE: Not carrying a syntactic dependency relieves straightforward
+implementations of reading `x[rs1]` and `x[rs2]`.
+
+=== "Zcmop" Compressed May-Be-Operations Extension, Version 1.0
+
+This section defines the "Zcmop" extension, which defines eight 16-bit MOP
+instructions named C.MOP.__n__, where __n__ is an odd integer between 1 and
+15, inclusive. C.MOP.__n__ is encoded in the reserved encoding space
+corresponding to C.LUI x__n__, 0, as shown in <<tab:c-mop>>.
+Unlike the MOPs defined in the Zimop extension, the C.MOP.__n__ instructions
+are defined to _not_ write any register.
+Their encoding allows future extensions to define them to read register
+`x[__n__]`.
+
+The Zcmop extension depends upon the Zca extension.
+
+include::images/wavedrom/c-mop.edn[]
+[[c-mop]]
+
+NOTE: Very few suitable 16-bit encoding spaces exist. This space was chosen
+because it already has unusual behavior with respect to the `rd`/`rs1`
+field--it encodes `c.addi16sp` when the field contains `x2`--and is
+therefore of lower value for most purposes.
+
+[[tab:c-mop]]
+.C.MOP.__n__ instruction encoding.
+
+|===
+|Mnemonic | Encoding | Redefinable to read register
+
+|C.MOP.1 | `0110000010000001` | `x1`
+|C.MOP.3 | `0110000110000001` | `x3`
+|C.MOP.5 | `0110001010000001` | `x5`
+|C.MOP.7 | `0110001110000001` | `x7`
+|C.MOP.9 | `0110010010000001` | `x9`
+|C.MOP.11 | `0110010110000001` | `x11`
+|C.MOP.13 | `0110011010000001` | `x13`
+|C.MOP.15 | `0110011110000001` | `x15`
+|===
+
+NOTE: The recommended assembly syntax for C.MOP.__n__ is simply the nullary
+C.MOP.__n__. The possibly accessed register is implicitly `x__n__`.
+
+NOTE: The expectation is that each Zcmop instruction is equivalent to some
+Zimop instruction, but the choice of expansion (if any) is left to the
+extension that redefines the MOP.
+Note, a Zcmop instruction that does not write a value can expand into a write
+to `x0`.
diff --git a/src/zpm.adoc b/src/zpm.adoc
new file mode 100644
index 0000000..79588be
--- /dev/null
+++ b/src/zpm.adoc
@@ -0,0 +1,302 @@
+[[Zpm]]
+== Pointer Masking Extensions, Version 1.0.0
+
+=== Introduction
+
+RISC-V Pointer Masking (PM) is a feature that, when enabled, causes the CPU to ignore the upper bits of the effective address (these terms will be defined more precisely in the Background section). This allows these bits to be used in whichever way the application chooses. The version of the extension being described here specifically targets **tag checks**: When an address is accessed, the tag stored in the masked bits can be compared against a range-based tag. This is used for dynamic safety checkers such as HWASAN cite:[HWASAN]. Such tools can be applied in all privilege modes (U, S, and M).
+
+HWASAN leverages tags in the upper bits of the address to identify memory errors such as use-after-free or buffer overflow errors. By storing a *pointer tag* in the upper bits of the address and checking it against a *memory tag* stored in a side table, it can identify whether a pointer is pointing to a valid location. Doing this without hardware support introduces significant overheads since the pointer tag needs to be manually removed for every conventional memory operation. Pointer masking support reduces these overheads.
+
+Pointer masking only adds the ability to ignore pointer tags during regular memory accesses. The tag checks themselves can be implemented in software or hardware. If implemented in software, pointer masking still provides performance benefits since non-checked accesses do not need to transform the address before every memory access. Hardware implementations are expected to provide even larger benefits due to performing tag checks out-of-band and hardening security guarantees derived from these checks. We anticipate that future extensions may build on pointer masking to support this functionality in hardware.
+
+It is worth mentioning that while HWASAN is the primary use-case for the current pointer masking extension, a number of other hardware/software features may be implemented leveraging Pointer Masking. Some of these use cases include sandboxing, object type checks and garbage collection bits in runtime systems. Note that the current version of the spec does not explicitly address these use cases, but future extensions may build on it to do so.
+
+While we describe the high-level concepts of pointer masking as if it was a single extension, it is, in reality, a family of extensions that implementations or profiles may choose to individually include or exclude (see <<_pointer_masking_extensions>>).
+
+=== Background
+
+==== Definitions
+
+We now define basic terms. Note that these rely on the definition of an “ignore” transformation, which is defined in <<sec-ignore-transform>>.
+
+* **Effective address (as defined in the RISC-V Base ISA):** A load/store effective address sent to the memory subsystem (e.g., as generated during the execution of load/store instructions). This does not include addresses corresponding to implicit accesses, such as page-table walks.
+
+* **Masked bits:** The upper PMLEN bits of an address, where PMLEN is a configurable parameter. We will use PMLEN consistently throughout this document to refer to this parameter.
+
+* **Transformed address:** An effective address after the ignore transformation has been applied.
+
+* **Address translation mode:** The MODE of the currently active address translation scheme as defined in the RISC-V privileged specification. This could, for example, refer to Bare, Sv39, Sv48, and Sv57. In accordance with the privileged specification, non-Bare translation modes are referred to as virtual-memory schemes. For the purpose of this specification, M-mode translation is treated as equivalent to Bare.
+
+* **Address validity:** The RISC-V privileged spec defines validity of addresses based on the address translation mode that is currently in use (e.g., Sv57, Sv48, Sv39, etc.). For a virtual address to be valid, all bits in the unused portion of the address must be the same as the Most Significant Bit (MSB) of the used portion. For example, when page-based 48-bit virtual memory (Sv48) is used, load/store effective addresses, which are 64 bits, must have bits 63–48 all set to bit 47, or else a page-fault exception will occur. For physical addresses, validity means that bits XLEN-1 to PABITS are zero, where PABITS is the number of physical address bits supported by the processor.
+
+* **NVBITS:** The upper bits within a virtual address that have no effect on addressing memory and are only used for validity checks. These bits depend on the currently active address translation mode. For example, in Sv48, these are bits 63-48.
+
+* **VBITS:** The bits within a virtual address that affect which memory is addressed. These are the bits of an address which are used to index into page tables.
+
+[[sec-ignore-transform]]
+==== The “Ignore” Transformation
+
+The ignore transformation differs depending on whether it applies to a virtual or physical address. For virtual addresses, it replaces the upper PMLEN bits with the sign extension of the PMLEN+1st bit.
+
+[source]
+."Ignore" Transformation for virtual addresses, expressed in Verilog code.
+----
+transformed_effective_address =
+ {{PMLEN{effective_address[XLEN-PMLEN-1]}}, effective_address[XLEN-PMLEN-1:0]}
+----
+
+[NOTE]
+====
+If PMLEN is less than or equal to NVBITS for the largest supported address translation mode on a given architecture, this is equivalent to ignoring a subset of NVBITS. This enables cheap implementations that modify validity checks in the CPU instead of performing the sign extension.
+====
+
+When applied to a physical address, including guest-physical addresses (i.e., all cases except when the active satp register's MODE field != Bare), the ignore transformation replaces the upper PMLEN bits with 0. This includes both the case of running in M-mode and running in other privilege modes with Bare address translation mode.
+
+[source]
+."Ignore" Transformation for physical addresses, expressed in Verilog code.
+----
+transformed_effective_address =
+ {{PMLEN{0}}, effective_address[XLEN-PMLEN-1:0]}
+----
+
+[NOTE]
+====
+This definition is consistent with the way that RISC-V already handles physical and virtual addresses differently. While the unused upper bits of virtual addresses are the sign-extension of the used bits (see the definition of "address validity" in <<_definitions>>), the equivalent bits in physical addresses are zero-extended. This is necessary due to their interactions with other mechanisms such as Physical Memory Protection (PMP).
+====
+
+When pointer masking is enabled, the ignore transformation will be applied to every explicit memory access (e.g., loads/stores, atomics operations, and floating point loads/stores). The transformation *does not* apply to implicit accesses such as page-table walks or instruction fetches. The set of accesses that pointer masking applies to is described in <<_memory_accesses_subject_to_pointer_masking>>.
+
+[WARNING]
+====
+Pointer masking does not change the underlying address generation logic or permission checks. Under a fixed address translation mode, it is semantically equivalent to replacing a subset of instructions (e.g., loads and stores) with an instruction sequence that applies the ignore operation to the target address of this instruction and then applies the instruction to the transformed address. References to address translation and other implementation details in the text are primarily to explain design decisions and common implementation patterns.
+====
+
+Note that pointer masking is purely an arithmetic operation on the address that makes no assumption about the meaning of the addresses it is applied to. Pointer masking with the same value of PMLEN always has the same effect for the same type of address (virtual or physical). This ensures that code that relies on pointer masking does not need to be aware of the environment it runs in once pointer masking has been enabled, as long as the value of PMLEN is known, and whether or not addresses are virtual or physical. For example, the same application or library code can run in user mode, supervisor mode or M-mode (with different address translation modes) without modification.
+
+[NOTE]
+====
+A common scenario for such code is that addresses are generated by mmap system calls. This abstracts away the details of the underlying address translation mode from the application code. Software therefore needs to be aware of the value of PMLEN to ensure that its minimally required number of tag bits is supported. <<_determining_the_value_of_pmlen>> covers how this value is derived.
+====
+
+==== Example
+
+<<pm-example>> shows an example of the pointer masking transformation on a virtual address when PM is enabled for RV64 under Sv57 (PMLEN=7).
+
+[[pm-example]]
+
+[%header, cols="25%,75%", options="header"]
+.Example of PM address translation for RV64 under Sv57
+|===
+|Page-based profile|Sv57 on RV64
+|Effective Address |0xABFFFFFF12345678 +
+NVBITS[1010101] VBITS[11111111111111111111111110001...000]
+|PMLEN|7
+|Mask|0x01FFFFFFFFFFFFFF +
+NVBITS[0000000] VBITS[11111111111111111111111111111...111]
+|PMLEN+1st bit from the top (i.e., bit XLEN-PMLEN-1)|1
+|Transformed effective address |0xFFFFFFFF12345678 +
+NVBITS[1111111] VBITS[11111111111111111111111110001...000]
+
+|===
+
+If the address was a physical address rather than a virtual address with Sv57, the transformed address with PMLEN=7 would be 0x1FFFFFF12345678.
+
+==== Determining the Value of PMLEN
+
+From an implementation perspective, ignoring bits is deeply connected to the maximum virtual and physical address space supported by the processor (e.g., Bare, Sv48, Sv57). In particular, applying the above transformation is cheap if it covers only bits that are not used by **any** supported address translation mode (as it is equivalent to switching off validity checks). Masking NVBITS beyond those bits is more expensive as it requires ignoring them in the TLB tag, and even more expensive if the masked bits extend into the VBITS portion of the address (as it requires performing the actual sign extension). Similarly, when running in Bare or M mode, it is common for implementations to not use a particular number of bits at the top of the physical address range and fix them to zero. Applying the ignore transformation to those bits is cheap as well, since it will result in a valid physical address with all the upper bits fixed to 0.
+
+The current standard only supports PMLEN=XLEN-48 (i.e., PMLEN=16 in RV64) and PMLEN=XLEN-57 (i.e., PMLEN=7 in RV64). A setting has been reserved to potentially support other values of PMLEN in future standards. In such future standards, different supported values of PMLEN may be defined for each privilege mode (U/VU, S/HS, and M).
+
+[NOTE]
+====
+Future versions of the pointer masking extension may introduce the ability to freely configure the value of PMLEN. The current extension does not define the behavior if PMLEN was different from the values defined above. In particular, there is no guarantee that a future pointer masking extension would define the ignore operation in the same way for those values of PMLEN.
+====
+
+==== Pointer Masking and Privilege Modes
+
+Pointer masking is controlled separately for different privilege modes. The subset of supported privilege modes is determined by the set of supported pointer masking extensions. Different privilege modes may have different pointer masking settings active simultaneously and the hardware will automatically apply the pointer masking settings of the currently active privilege mode. A privilege mode's pointer masking setting is configured by bits in configuration registers of the next-higher privilege mode.
+
+Note that the pointer masking setting that is applied only depends on the active privilege mode, not on the address that is being masked. Some operating systems (e.g., Linux) may use certain bits in the address to disambiguate between different types of addresses (e.g., kernel and user-mode addresses). Pointer masking _does not_ take these semantics into account and is purely an arithmetic operation on the address it is given.
+
+[NOTE]
+====
+Linux places kernel addresses in the upper half of the address space and user addresses in the lower half of the address space. As such, the MSB is often used to identify the type of a particular address. With pointer masking enabled, this role is now played by bit XLEN-PMLEN-1 and code that checks whether a pointer is a kernel or a user address needs to inspect this bit instead. For backward compatibility, it may be desirable that the MSB still indicates whether an address is a user or a kernel address. An operating system's ABI may mandate this, but it does not affect the pointer masking mechanism itself. For example, the Linux ABI may choose to mandate that the MSB is not used for tagging and replicates bit XLEN-PMLEN-1 bit (note that for such a mechanism to be secure, the kernel needs to check the MSB of any user mode-supplied address and ensure that this invariant holds before using it; alternatively, it can apply the transformation from Listing 1 or 2 to ensure that the MSB is set to the correct value).
+====
+
+==== Memory Accesses Subject to Pointer Masking
+
+Pointer masking applies to all explicit memory accesses. Currently, in the Base and Privileged ISAs, these are:
+
+* **Base Instruction Set**: LB, LH, LW, LBU, LHU, LWU, LD, SB, SH, SW, SD.
+* **Atomics**: All instructions in RV32A and RV64A.
+* **Floating Point**: FLW, FLD, FLQ, FSW, FSD, FSQ.
+* **Compressed**: All instructions mapping to any of the above, and C.LWSP, C.LDSP, C.FLWSP, C.FLDSP, C.SWSP, C.SDSP, C.FSWSP, C.FSDSP.
+* **Hypervisor Extension**: HLV.\*, HSV.* (in some cases; see <<_ssnpm>>).
+* **Cache Management Operations**: All instructions in Zicbom, Zicbop and Zicboz.
+* **Vector Extension**: All vector load and store instructions in the ratified RVV 1.0 spec.
+* **Zicfiss Extension**: SSPUSH, C.SSPUSH, SSPOPCHK, C.SSPOPCHK, SSAMOSWAP.W/D.
+* **Assorted**: FENCE, FENCE.I (if the currently unused address fields become enabled in the future).
+
+[NOTE]
+====
+This list will grow over time as new extensions introduce new instructions that perform explicit memory accesses.
+====
+
+For other extensions, pointer masking applies to all explicit memory accesses by default. Future extensions may add specific language to indicate whether particular accesses are or are not included in pointer masking.
+
+[NOTE]
+====
+It is worth noting that pointer masking is not applied to `SFENCE.\*`, `HFENCE.*`, `SINVAL.\*`, or `HINVAL.*`. When such an operation is invoked, it is the responsibility of the software to provide the correct address.
+====
+
+MPRV and SPVP affect pointer masking as well, causing the pointer masking settings of the effective privilege mode to be applied. When MXR is in effect at the effective privilege mode where explicit memory access is performed, pointer masking does not apply.
+
+[NOTE]
+====
+Note that this includes cases where page-based virtual memory is not in effect; i.e., although MXR has no effect on permissions checks when page-based virtual memory is not in effect, it is still used in determining whether or not pointer masking should be applied.
+====
+
+[NOTE]
+====
+Cache Management Operations (CMOs) must respect and take into account pointer masking. Otherwise, a few serious security problems can appear, including:
+
+* CBO.ZERO may work as a STORE operation. If pointer masking is not respected, it would be possible to write to memory bypassing the mask enforcement.
+* If CMOs did not respect pointer masking, it would be possible to weaponize this in a side-channel attack. For example, U-mode would be able to flush a physical address (without masking) that it should not be permitted to.
+====
+
+Pointer masking only applies to accesses generated by instructions on the CPU (including CPU extensions such as an FPU). E.g., it does not apply to accesses generated by page-table walks, the IOMMU, or devices.
+
+[NOTE]
+====
+Pointer Masking does not apply to DMA controllers and other devices. It is therefore the responsibility of the software to manually untag these addresses.
+====
+
+Misaligned accesses are supported, subject to the same limitations as in the absence of pointer masking. The behavior is identical to applying the pointer masking transformation to every constituent aligned memory access. In other words, the accessed bytes should be identical to the bytes that would be accessed if the pointer masking transformation was individually applied to every byte of the access without pointer masking. This ensures that both hardware implementations and emulation of misaligned accesses in M-mode behave the same way, and that the M-mode implementation is identical whether or not pointer masking is enabled (e.g., such an implementation may leverage MPRV to apply the correct privilege mode's pointer masking setting).
+
+No pointer masking operations are applied when software reads/writes to CSRs, including those meant to hold addresses. If software stores tagged addresses into such CSRs, data load or data store operations based on those addresses are subject to pointer masking only if they are explicit (<<_memory_accesses_subject_to_pointer_masking>>) and pointer masking is enabled for the privilege mode that performs the access. The implemented WARL width of CSRs is unaffected by pointer masking (e.g., if a CSR supports 52 bits of valid addresses and pointer masking is supported with PMLEN=16, the necessary number of WARL bits remains 52 independently of whether pointer masking is enabled or disabled).
+
+In contrast to software writes, pointer masking **is applied** for hardware writes to a CSR (e.g., when the hardware writes the transformed address to `stval` when taking an exception). Pointer masking is also applied to the memory access address when matching address triggers in debug.
+
+For example, software is free to write a tagged or untagged address to `stvec`, but on trap delivery (e.g., due to an exception or interrupt), pointer masking **will not be applied** to the address of the trap handler. However, pointer masking **will be applied** by the hardware to any address written into `stval` when delivering an exception.
+
+[NOTE]
+====
+The rationale for this choice is that delivering the additional bits may add overheads in some hardware implementations. Further, pointer masking is configured per privilege mode, so all trap handlers in supervisor mode would need to be careful to configure pointer masking the same way as user mode or manually unmask (which is expensive).
+====
+
+==== Pointer Masking Extensions
+
+Pointer masking refers to a number of separate extensions, all of which are privileged. This approach is used to capture optionality of pointer masking features. Profiles and implementations may choose to support an arbitrary subset of these extensions and must define valid ranges for their corresponding values of PMLEN.
+
+**Extensions**:
+
+* **Ssnpm**: A supervisor-level extension that provides pointer masking for the next lower privilege mode (U-mode), and for VS- and VU-modes if the H extension is present.
+* **Smnpm**: A machine-level extension that provides pointer masking for the next lower privilege mode (S/HS if S-mode is implemented, or U-mode otherwise).
+* **Smmpm**: A machine-level extension that provides pointer masking for M-mode.
+
+See <<_isa_extensions>> for details on how each of these extensions is configured.
+
+In addition, the pointer masking standard defines two extensions that describe an execution environment but have no bearing on hardware implementations. These extensions are intended to be used in profile specifications where a User profile or a Supervisor profile can only reference User level or Supervisor level pointer masking functionality, and not the associated CSR controls that exist at a higher privilege level (i.e., in the execution environment).
+
+* **Sspm**: An extension that indicates that there is pointer-masking support available in supervisor mode, with some facility provided in the supervisor execution environment to control pointer masking.
+* **Supm**: An extension that indicates that there is pointer-masking support available in user mode, with some facility provided in the application execution environment to control pointer masking.
+
+The precise nature of these facilities is left to the respective execution environment.
+
+Pointer masking only applies to RV64. In RV32, trying to enable pointer masking will result in an illegal WARL write and not update the pointer masking configuration bits (see <<_isa_extensions>> for details). The same is the case on RV64 or larger systems when UXL/SXL/MXL is set to 1 for the corresponding privilege mode. Note that in RV32, the CSR bits introduced by pointer masking are still present, for compatibility between RV32 and larger systems with UXL/SXL/MXL set to 1. Setting UXL/SXL/MXL to 1 will clear the corresponding pointer masking configuration bits.
+
+[NOTE]
+====
+Note that setting UXL/SXL/MXL to 1 and back to 0 does not preserve the previous values of the PMM bits. This includes the case of entering an RV32 virtual machine from an RV64 hypervisor and returning.
+====
+
+=== ISA Extensions
+
+This section describes the pointer masking extensions `Smmpm`, `Smnpm` and `Ssnpm`. All of these extensions are privileged ISA extensions and do not add any new CSRs. For the definitions of `Sspm` and `Supm`, see <<_pointer_masking_extensions>>.
+
+[NOTE]
+====
+Future extensions may introduce additional CSRs to allow different privilege modes to modify their own pointer masking settings. This may be required for future use cases in managed runtime systems that are not currently addressed as part of this extension.
+====
+
+Each extension introduces a 2-bit WARL field (`PMM`) that may take on the following values to set the pointer masking settings for a particular privilege mode.
+
+[[pmm-values]]
+
+[%header, cols="25%,75%", options="header"]
+.Possible values of `PMM` WARL field.
+|===
+|Value|Description
+|00|Pointer masking is disabled (PMLEN=0)
+|01|Reserved
+|10|Pointer masking is enabled with PMLEN=XLEN-57 (PMLEN=7 on RV64)
+|11|Pointer masking is enabled with PMLEN=XLEN-48 (PMLEN=16 on RV64)
+|===
+
+All of these fields are read-only 0 on RV32 systems.
+
+==== Ssnpm
+
+`Ssnpm` adds a new 2-bit WARL field (`PMM`) to bits 33:32 of `senvcfg`. Setting `PMM` enables or disables pointer masking for the next lower privilege mode (U/VU mode), according to the values in <<pmm-values>>.
+
+In systems where the H Extension is present, `Ssnpm` also adds a new 2-bit WARL field (`PMM`) to bits 33:32 of `henvcfg`. Setting `PMM` enables or disables pointer masking for VS-mode, according to the values in <<pmm-values>>. Further, a 2-bit WARL field (`HUPMM`) is added to bits 49:48 of `hstatus`. Setting `hstatus.HUPMM` enables or disables pointer masking for `HLV.\*` and `HSV.*` instructions in U-mode, according to the values in <<pmm-values>>, when their explicit memory access is performed as though in VU-mode. In HS- and M-modes, pointer masking for these instructions is enabled or disabled by `senvcfg.PMM`, when their explicit memory access is performed as though in VU-mode. Setting `henvcfg.PMM` enables or disables pointer masking for `HLV.\*` and `HSV.*` when their explicit memory access is performed as though in VS-mode.
+
+[NOTE]
+====
+The hypervisor should copy the value written to `senvcfg.PMM` by the guest to the `hstatus.HUPMM` field prior to invoking `HLV.\*` or `HSV.*` instructions in U-mode.
+====
+
+The memory accesses performed by the `HLVX.*` instructions are not subject to pointer masking.
+
+[NOTE]
+====
+`HLVX.*` instructions, designed for emulating implicit access to fetch instructions from guest memory, perform memory accesses that are exempt from pointer masking to facilitate this emulation. For the same reason, pointer masking does not apply when MXR is set.
+====
+
+==== Smnpm
+
+`Smnpm` adds a new 2-bit WARL field (`PMM`) to bits 33:32 of `menvcfg`. Setting `PMM` enables or disables pointer masking for the next lower privilege mode (S-/HS-mode if S-mode is implemented, or U-mode otherwise), according to the values in <<pmm-values>>.
+
+[NOTE]
+====
+The type of address determines which type of pointer masking is applied. For example, when running with virtualization in VS/VU mode with `vsatp.MODE` = Bare, physical address pointer masking (zero extension) applies.
+====
+
+==== Smmpm
+
+`Smmpm` adds a new 2-bit WARL field (`PMM`) to bits 33:32 of `mseccfg`. The presence of `Smmpm` implies the presence of the `mseccfg` register, even if it would not otherwise be present. Setting `PMM` enables or disables pointer masking for M mode, according to the values in <<pmm-values>>.
+
+==== Interaction with SFENCE.VMA
+
+Since pointer masking applies to the effective address only and does not affect any memory-management data structures, no SFENCE.VMA is required after enabling/disabling pointer masking.
+
+==== Interaction with Two-Stage Address Translation
+
+Guest physical addresses (GPAs) are 2 bits wider than the corresponding virtual address translation modes, resulting in additional address translation schemes Sv32x4, Sv39x4, Sv48x4, and Sv57x4 for translating guest physical addresses to supervisor physical addresses. When running with virtualization in VS/VU mode with `vsatp.MODE` = Bare, this means that those two bits may be subject to pointer masking, depending on `hgatp.MODE` and `senvcfg.PMM`/`henvcfg.PMM` (for VU/VS mode). If `vsatp.MODE` != BARE, this issue does *not* apply.
+
+[NOTE]
+====
+An implementation could mask those two bits on the TLB access path, but this can have a significant timing impact. Alternatively, an implementation may choose to "waste" TLB capacity by having up to 4 duplicate entries for each page. In this case, the pointer masking operation can be applied on the TLB refill path, where it is unlikely to affect timing. To support this approach, some TLB entries need to be flushed when PMLEN changes in a way that may affect these duplicate entries.
+====
+
+To support implementations where (XLEN-PMLEN) can be less than the GPA width supported by `hgatp.MODE`, hypervisors should execute an `HFENCE.GVMA` with _rs1_=`x0` if the `henvcfg.PMM` is changed from or to a value where (XLEN-PMLEN) is less than GPA width supported by the `hgatp` translation mode of that guest. Specifically, these cases are:
+
+* `PMLEN=7` and `hgatp.MODE=sv57x4`
+* `PMLEN=16` and `hgatp.MODE=sv57x4`
+* `PMLEN=16` and `hgatp.MODE=sv48x4`
+
+[NOTE]
+====
+`Smmpm` implementations need to satisfy max(largest supported virtual address size, largest supported supervisor physical address size) <= (XLEN - PMLEN) bits to avoid any masking logic on the TLB access path.
+====
+
+Implementation of an address-specific `HFENCE.GVMA` should either ignore the address argument, or should ignore the top masked GPA bits of entries when comparing for an address match.
+
+==== Number of Masked Bits
+
+As described in <<_determining_the_value_of_pmlen>>, the supported values of PMLEN may depend on the effective privilege mode. The current standard only defines PMLEN=XLEN-48 and PMLEN=XLEN-57, but this assumption may be relaxed in future extensions and profiles. Trying to enable pointer masking in an unsupported scenario represents an illegal write to the corresponding pointer masking enable bit and follows WARL semantics. Future profiles may choose to define certain combinations of privilege modes and supported values of PMLEN as mandatory.
+
+[NOTE]
+====
+An option that was considered but discarded was to allow implementations to set PMLEN depending on the active addressing mode. For example, PMLEN could be set to 16 for Sv48 and to 25 for Sv39. However, having a single value of PMLEN (e.g., setting PMLEN to 16 for both Sv39 and Sv48 rather than 25) facilitates TLB implementations in designs that support Sv39 and Sv48 but not Sv57. 16 bits are sufficient for current pointer masking use cases but allow for a TLB implementation that matches against the same number of virtual tag bits independently of whether it is running with Sv39 or Sv48. However, if Sv57 is supported, tag matching may need to be conditional on the current address translation mode.
+====
diff --git a/src/ztso-st-ext.adoc b/src/ztso-st-ext.adoc
new file mode 100644
index 0000000..356d6ff
--- /dev/null
+++ b/src/ztso-st-ext.adoc
@@ -0,0 +1,47 @@
+[[ztso]]
+== "Ztso" Extension for Total Store Ordering, Version 1.0
+
+This chapter defines the "Ztso" extension for the RISC-V Total Store
+Ordering (RVTSO) memory consistency model. RVTSO is defined as a delta
+from RVWMO, which is defined in <<rvwmo>>.
+[NOTE]
+====
+_The Ztso extension is meant to facilitate the porting of code originally
+written for the x86 or SPARC architectures, both of which use TSO by
+default. It also supports implementations which inherently provide RVTSO
+behavior and want to expose that fact to software._
+====
+RVTSO makes the following adjustments to RVWMO:
+
+* All load operations behave as if they have an acquire-RCpc annotation
+* All store operations behave as if they have a release-RCpc annotation.
+* All AMOs behave as if they have both acquire-RCsc and release-RCsc
+annotations.
+
+[NOTE]
+====
+_These rules render all PPO rules except
+<<overlapping-ordering, 4-7>> redundant. They also make
+redundant any non-I/O fences that do not have both PW and SR set.
+Finally, they also imply that no memory operation will be reordered past
+an AMO in either direction._
+
+_In the context of RVTSO, as is the case for RVWMO, the storage ordering
+annotations are concisely and completely defined by PPO rules
+<<overlapping-ordering, 5-7>>. In both of these
+memory models, it is the <<ax-load>> that allows a hart to forward a value from its
+store buffer to a subsequent (in program order) load—that is to say that
+stores can be forwarded locally before they are visible to other harts._
+====
+
+Additionally, if the Ztso extension is implemented, then vector memory
+instructions in the V extension and Zve family of extensions follow RVTSO at
+the instruction level.
+The Ztso extension does not strengthen the ordering of intra-instruction
+element accesses.
+
+In spite of the fact that Ztso adds no new instructions to the ISA, code
+written assuming RVTSO will not run correctly on implementations not
+supporting Ztso. Binaries compiled to run only under Ztso should
+indicate as such via a flag in the binary, so that platforms which do
+not implement Ztso can simply refuse to run them.
diff --git a/src/ztso.tex b/src/ztso.tex
deleted file mode 100644
index 39683c4..0000000
--- a/src/ztso.tex
+++ /dev/null
@@ -1,29 +0,0 @@
-\chapter{``Ztso'' Standard Extension for Total Store Ordering, v0.1}
-\label{sec:ztso}
-
-This chapter defines the ``Ztso'' extension for the RISC-V Total Store Ordering (RVTSO) memory consistency model.
-RVTSO is defined as a delta from RVWMO, which is defined in Chapter~\ref{sec:rvwmo}.
-
-\begin{commentary}
- The Ztso extension is meant to facilitate the porting of code originally written for the x86 or SPARC architectures, both of which use TSO by default.
- It also supports implementations which inherently provide RVTSO behavior and want to expose that fact to software.
-\end{commentary}
-
-RVTSO makes the following adjustments to RVWMO:
-
-\begin{itemize}
- \item All load operations behave as if they have an acquire-RCpc annotation
- \item All store operations behave as if they have a release-RCpc annotation.
- \item All AMOs behave as if they have both acquire-RCsc and release-RCsc annotations.
-\end{itemize}
-
-\begin{commentary}
- These rules render all PPO rules except \ref{ppo:fence}--\ref{ppo:rcsc} redundant.
- They also make redundant any non-I/O fences that do not have both PW and SR set.
- Finally, they also imply that no memory operation will be reordered past an AMO in either direction.
-
- In the context of RVTSO, as is the case for RVWMO, the storage ordering annotations are concisely and completely defined by PPO rules \ref{ppo:acquire}--\ref{ppo:rcsc}. In both of these memory models, it is the \nameref{rvwmo:ax:load} that allows a hart to forward a value from its store buffer to a subsequent (in program order) load---that is to say that stores can be forwarded locally before they are visible to other harts.
-\end{commentary}
-
-In spite of the fact that Ztso adds no new instructions to the ISA, code written assuming RVTSO will not run correctly on implementations not supporting Ztso.
-Binaries compiled to run only under Ztso should indicate as such via a flag in the binary, so that platforms which do not implement Ztso can simply refuse to run them.
diff --git a/tagging_normative_rules.adoc b/tagging_normative_rules.adoc
new file mode 100644
index 0000000..d60093b
--- /dev/null
+++ b/tagging_normative_rules.adoc
@@ -0,0 +1,134 @@
+== How to Tag Normative Rules in the ISA Manuals
+
+The ISA manuals contain a mix of normative and informative (AKA non-normative) content.
+We use AsciiDoctor's anchor facility to tag normative text which is extracted by tools
+provided in the link:https://github.com/riscv/docs-resources[docs-resources GitHub repository]
+to create machine-readable and human-readable representations of normative rules.
+
+=== Tagging Normative Rules in RISC-V International Standards
+
+First, please read the link:https://github.com/riscv/docs-resources/blob/main/normative-rules.md[How to Tag Normative Rules in RISC-V International Standards] for information that applies to all RISC-V International standards. This document provides information such as:
+
+* What exactly is a "normative rule"?
+* How does one add normative rule tags to the AsciiDoc files using the AsciiDoc anchor facility?
+* Ins and outs and gotchas when using the AsciiDoc anchor facility.
+* How are the normative rules extracted from the AsciiDoc files?
+
+=== Tagging Normative Rules in ISA Manuals
+
+Now that you've read link:https://github.com/riscv/docs-resources/blob/normative-rules.md[How to Tag Normative Rules in RISC-V International Standards], here's some information specific to tagging normative rules
+in the ISA manuals.
+
+The ISA manual builds upon the anchor naming convention of a "norm:" prefix by following it with
+an enum identifying the ISA manual object type, another colon,
+one or more names describing the object(s) related to the tag,
+another colon and finally an ID that identifies the associated behavior.
+It looks like this (where `<>` delimit names, `[]` indicates optional, `*` means 0 or more, and
+`_` is used to separate multiple object names if needed):
+
+[source]
+norm:<object-type>:<object-name>[_<object-name>]*:<id>
+
+There are some cases (e.g., CSR field names) where there is a hierachy of object names and so there
+are additional colon-separated object-names.
+Here's what it looks like with 2 hiearchy levels with a parent/child relationship:
+
+[source]
+norm:<object-type>:<parent-object-name>[_<parent-object-name>]*:<child-object-name>[_child-<object-name>]*:<id>
+
+[NOTE]
+We aren't too worried about having long tag names since they are invisible unless viewing the
+raw AsciiDoc source so don't clutter the ISA manual output formats like PDFs. So, we've leaned
+in the direction of having longer names that provide information about what is being tagged.
+
+The justification for this naming convention is:
+
+* Encourages consistency and regularity in names
+* Helps ensure anchor names are unique across both ISA manuals (they are in one global namespace)
+* Provides some information about which ISA objects (e.g., instructions, extensions, CSRs) are related to the tagged text
+
+=== Naming Convention Details
+
+The following table shows the supported ISA object types, the naming convention for them,
+and examples for each.
+
+[%autowidth]
+|===
+| Format | Description
+
+| Format `norm:base:<base-name>:<id>` +
+Example `norm:base:rv32i:xregsz`
+| One base ISA (rv32i/rv32e/rv64i)
+
+| Format `norm:bases:<base-name>[_<base-name>]+:<id>` +
+Example `norm:bases:rv32i_rv64i:num-xregs`
+| List of bases
+
+| Format `norm:basegrp:<group-name>:<id>` +
+Example `norm:base:all:x0eq0`
+| Named group of bases (e.g., rv32, all)
+
+| Format `norm:ext:<ext-name>:<id>` +
+Example `norm:Zilsd_reg_pairs`
+| Single extension
+
+| Format `norm:exts:<ext-name>[_<ext-name>]:<id>` +
+Example `norm:exts:F_D:num-fregs`
+| List of extensions
+
+| Format `norm:extgrp:<group-name>:<id>` +
+Example `norm:extgrp:security:attacks`
+| Named group of extensions
+
+| Format `norm:enc:insttable:<inst-name>` +
+Example `norm:enc:insttable:add`
+| Table cell for instruction encoding
+
+| Format `norm:inst:<inst-name>:<id>` +
+Example `norm:add_op`
+| Single instruction
+
+| Format `norm:insts:<inst-name>[_<inst-name>]+:<id>` +
+Example `norm:add_sub_overflow`
+| List of instructions
+
+| Format `norm:instgrp:<group-name>:<id>` +
+Example `norm:instgrp:division:div_by_zero`
+| Named group of insts (e.g., branch, load)
+
+| Format `norm:csr:<csr-name>:<id>` +
+Example `norm:misa_sz`
+| Single CSR
+
+| Format `norm:csrs:<csr-name>[_<csr-name>]+:<id>` +
+Example `norm:csrs:mstatus_sstatus:sz`
+| List of CSRs
+
+| Format `norm:csrgrp:<group-name>:<id>` +
+Example `norm:csrgrp:status:sz`
+| Named group of CSRs
+
+| Format `norm:csrfld:<csr-name>:<field-name>:<id>` +
+Example `norm:misa_mxl_base_int_sz`
+| Single CSR field
+
+| Format `norm:csrflds:<csr-name>:<field-name>[_<field-name>]+:<id>` +
+Example `norm:csrflds:hip:vseip_vseie:ro`
+| List of fields in the same CSR
+
+| Format `norm:csrsfld:<csr-name>[_<csr-name>]+:<field-name>:<id>` +
+Example `norm:csrsfld:vsip_vsie:ssi:operation`
+| Same field in the listed CSRs
+
+| Format `norm:param:<param-name>:<id>` +
+Example `norm:endianness_little_or_big`
+| Single parameter
+
+| Format `norm:params:<param-name>[_<param-name>]+:<id>` +
+Example `norm:params:mutable-misa-a_mutable-misa-b:operation`
+| List of parameters
+
+| Format `norm:paramgrp:<group-name>:<id>` +
+Example `norm:paramgrp:mtval-va-report:operation`
+| Named group of parameters
+|===