aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2019-07-18More hypervisor updates courtesy of @jhauser-usAndrew Waterman1-91/+282
2019-07-18Fix poor figure placementAndrew Waterman1-2/+3
2019-07-12Improve description of mtimecmp code sequenceAndrew Waterman1-1/+3
2019-07-12Clarify that mtime writes/ticks can also clear MTIPAndrew Waterman1-2/+3
2019-07-09Clarify that mtvec is WARL (#406)Alex Bradbury1-1/+1
Other WARL registers seem to be explicit (e.g. "The misa CSR is a WARL read-write register..."). This patch adds a similar indication for mtvec. This consistency is important, as otherwise the reader will spend time trying to determine if the behaviour is different. You can determine it's WARL by reading the field layout diagram, but I think a little redundancy in favour of easing readability makes sense. At least one simulator started off trapping on invalid field modifications <https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg04510.html>.
2019-06-26Clarify which hints are C.NOP hints and which are C.ADDI hintsAndrew Waterman1-4/+5
Closes #389
2019-06-25Touch up the mcycle textAndrew Waterman1-9/+10
2019-06-25Merge branch 'master' into counterinhibit-smtAndrew Waterman5-42/+26
2019-06-25ECALL and EBREAK don't retireAndrew Waterman1-0/+2
2019-06-25Don't mandate that multiple harts on a core share mcyclePalmer Dabbelt1-1/+1
The commentary indicates that sharing mcycle between harts is mandatory, but I don't think that's a good idea -- both because it's introducing a constraint that is very hard to formalize (ie, WTF is a core) and because I think some systems will desire different behavior. This patch softens the wording in the commentary to avoid the appearance that sharing mcycle between threads is mandatory. Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-25Indicate that mcycle can be shared between hartsPalmer Dabbelt1-2/+6
When reading through the manual for the QEMU patches to implement mcounterinhibit I found that the commentary allows mcycle to be shared between harts. I actually really don't like this behavior, but I can understand that it may make sense for some systems. Regardless, the normative text of the ISA manual should match the commentary. This patch introduces the concept that modifications of a CSR on one hart may cause the value on other harts to change. If I understand correctly that's not quite a WARL field, which can only change upon writes. I don't think it's worth giving this a name, though, as hopefull it'll only apply to mcycle. Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-24MPRV affects endiannessAndrew Waterman2-6/+7
2019-06-24Remove endianness dependence on PTE.UAndrew Waterman2-33/+9
2019-06-24Fix spellingAndrew Waterman1-2/+2
2019-06-24Update contributorsAndrew Waterman1-1/+1
cc @fintelia
2019-06-24Clarify that, if all PMPs are OFF, all S/U accesses failAndrew Waterman1-0/+5
Closes #399
2019-06-21Merge pull request #397 from riscv/endiannessAndrew Waterman5-15/+90
Changes to unprivileged spec for bi[g]-endian support
2019-06-21Clarify PC behavior when XLEN < max supported XLENAndrew Waterman1-0/+2
2019-06-21State endianness assumption of code exampleAndrew Waterman1-2/+3
2019-06-21Clarify sign of REM; add commentaryAndrew Waterman2-2/+10
Closes #375
2019-06-21Changes to unprivileged spec for bi[g]-endian supportAndrew Waterman4-13/+38
2019-06-21Bump version of unprivileged spec to 20190621-draftAndrew Waterman2-2/+52
2019-06-21Fix bad RV32I chapter formattingAndrew Waterman1-48/+48
2019-06-21Clarify SBE/SFENCE interactionAndrew Waterman1-1/+12
2019-06-21Update contributorsAndrew Waterman1-1/+2
2019-06-21Fix preface styleAndrew Waterman1-2/+2
2019-06-21Add mstatush to prefaceAndrew Waterman1-0/+2
2019-06-21Need SFENCE after change to SBEAndrew Waterman1-0/+3
2019-06-21SpellingAndrew Waterman2-2/+2
2019-06-21Bi-endian systems reset as little-endianAndrew Waterman1-0/+2
2019-06-21Add commentaryAndrew Waterman1-0/+9
2019-06-19Add endianness control proposal to priv specAndrew Waterman4-37/+198
Contributed by @jhauser-us
2019-06-16Bump priv spec to v1.12-draftAndrew Waterman2-6/+40
2019-06-16Hypervisor v0.4 draftAndrew Waterman3-314/+379
Courtesy @jhauser-us
2019-06-08Added text to indicate this is the ratified 1.11 version of the spec.Ratified-IMFDQC-and-Priv-v1.11Krste Asanovic2-6/+7
2019-06-08Updated preface to indicate this is now ratified spec.Krste Asanovic2-19/+19
2019-05-31Tiny editorial fixPhilipp Wagner1-1/+1
2019-05-21Adding FENCE to the table of RV64 HINT instructions (#387)Luís Marques1-1/+2
2019-05-15Correct iteration in LR/SC CAS example. (#384)David-Horner1-2/+3
Address argument was clobbered. Signed-off-by: David Horner <ds2horner@gmail.com>
2019-05-14zimm -> uimm in CSR instruction listingAndrew Waterman1-3/+3
This makes the table match the CSR chapter.
2019-05-09Clarify reserved/HINT encodings in C chapter text (#382)Andrew Waterman1-21/+54
This PR essentially copies the information from the encoding table at the end of the chapter into the mainline text. The intent is to remove any doubt about what happens when an instruction's operand constraints are not met.
2019-05-07Clarify the behaviour of LR.W/D and SC.W/DColumbus2401-7/+9
Concerning issue #376.
2019-05-06Add note about FLE vs. BGE inconsistencyAndrew Waterman1-0/+7
2019-05-04Typos (#379)Alexandre Joannou2-2/+2
* Fix typo ">" to "$>$" * typo of -> on
2019-04-23Update contributorsAndrew Waterman1-1/+1
cc @kdockser
2019-04-20Merge pull request #373 from riscv/hellwig-sbiKrste Asanovic2-33/+24
Don't reference the SBI in normative privileged spec sections
2019-04-20Express stvec alignment constraint more clearlyAndrew Waterman1-5/+4
2019-04-19Don't reference the SBI in normative privileged spec sectionsAndrew Waterman2-33/+24
Submitted on behalf of Christoph Hellwig For context, see https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/kL-2LhgUmcE/xxySlYT0CQAJ
2019-04-19Clarify hypervisor/PLIC sentimentAndrew Waterman1-4/+8
2019-04-19Remove outdated clause indicating incorrect exception prioritiesAndrew Waterman1-3/+4
The clause was superseded by Table 3.7, but we failed to delete it. Closes #372
generated by cgit v1.1 at 2024-11-18 10:45:22 +0000