From: Luke Kenneth Casson Leighton Date: Sun, 4 Nov 2018 02:34:53 +0000 (+0000) Subject: clarify parallelisation section X-Git-Tag: convert-csv-opcode-to-binary~4864 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=d6e868d7e9f81230e38e92419d601d08833f0f86;p=libreriscv.git clarify parallelisation section --- diff --git a/simple_v_extension/specification.mdwn b/simple_v_extension/specification.mdwn index a6a8eba48..02fbe5c37 100644 --- a/simple_v_extension/specification.mdwn +++ b/simple_v_extension/specification.mdwn @@ -805,16 +805,18 @@ With some exceptions, where it does not make sense or is simply too challenging, all RV-Base instructions are parallelised: * CSR instructions, whilst a case could be made for fast-polling of - a CSR into multiple registers, would require guarantees of strict - sequential ordering that SV does not provide. Therefore, CSRs are - not really suitable and are left out. + a CSR into multiple registers, or for being able to copy multiple + contiguously addressed CSRs into contiguous registers, and so on, + are the fundamental core basis of SV. If parallelised, extreme + care would need to be taken. Additionally, CSR reads are done + using x0, and it is *really* inadviseable to tag x0. * LUI, C.J, C.JR, WFI, AUIPC are not suitable for parallelising so are left as scalar. * LR/SC could hypothetically be parallelised however their purpose is single (complex) atomic memory operations where the LR must be followed up by a matching SC. A sequence of parallel LR instructions followed by a sequence of parallel SC instructions therefore is guaranteed to - not be useful. Not least: the guarantees of LR/SC + not be useful. Not least: the guarantees of a Multi-LR/SC would be impossible to provide if emulated in a trap. * EBREAK, NOP, FENCE and others do not use registers so are not inherently paralleliseable anyway.