+++ /dev/null
-Hi All,
-
-I think the time has come that someone constructs a list FAQ that we can
-put on the footer of posts. I’m not the best person to write it as like
-anyone I have unconscious biases that need to be moderated. It should be
-moderated and edited by several people. Nevertheless, I’ve had a go at
-a starting point. We need to put a stop to some of the recent behaviour
-on the list. Misinformation, speculation, gossip and negativity towards
-the current RISC-V standards track e.g. attacks on RISC-V suitability
-for use in X are not appropriate. We need to move the discussion back to
-purely technical issues, such as evolutionary and positive steps forward
-vs revolutionary rhetoric that attacks towards RISC-V. This requires
-some policy.
-
-This starting point for the list FAQ has a number of list misdemeanours
-including ones committed by me in the past, with lack of knowledge as a
-newcomer. Recent list traffic has crowded out the largest contributors
-to the specs and has made reading the list cringe material. The rhetoric
-on the list is occupying the mental bandwidth of many readers to the
-point where the list is becoming unreadable. This needs to stop. The
-traffic doesn’t represent the track of the many people who have
-contributed to the current base, which is the apex in which RISC-V
-will evolve from. RISC-V is not intended to be revolutionary rather it
-represents the next step in evolution from CISC, proprietary ISAs and
-the expiration of patents that allow for the construction of a royalty
-free open standard at the hardware level in a similar vain to what has
-happened with Linux at the software level. This is an industry standard
-group for an open standard.
-
-I’m not apologising for my long email. I’ve added bullets so one can
-skim through. I’m not apologising for my bias. I support the existing
-RISC-V standards track and open tools which represents the huge amount
-of work done by many contributors to date and I support the existing
-standards and its careful quantitative evolution.
-
-Work on a reference implementations for proposals and test them in RTL,
-Gem5, QEMU, spike or other. Ideas are not the time-consuming work. Testing
-them is…
-
-My response mirrors the discourse. It is not technical, or when it is,
-it is not consensus oriented. I find this difficult to digest. Particular
-because my recent focus has been on a faithful and accurate representation
-of the current specifications with a focus on backward and forward
-binary compatibility.
-
--
-https://www.sifive.com/blog/2018/04/25/risc-v-qemu-part-2-the-risc-v-qemu-port-is-upstream/
-
-A lot of the recent discourse is at odds with the current standards
-track and stated goals of the foundation, such as agnosticism towards
-proprietary or open implementations. I believe the choice for openness
-is out of pragmatism vs ideology. DRM is going to be one of those things
-that gets implemented on RISC-V whether we personally agree with it or
-not. We should refrain from attaching emotive language to implementation
-choices that are legal for which we disagree with.
-
-I tend towards consensus seeking behaviour. This list has become
-somewhat exhausting to read and I can’t contribute to the current
-style of discussions. It has occupied too much of my mental bandwidth
-which compelled me to write this email, instead of working on what I’m
-supposed to be working on. I do think we have a problem on this list
-which we need to resolve.\
-
-The founders of the ISA should be able to respond constructively and
-positively to proposals on the list. The fact that they are not is an
-indication that something is wrong.
-
-This email is not intended to start a discussion. It’s more one of
-despair. i.e. being nearly ready to hit “unsubscribe”.
-
-Sincerely, X-Michael.
-
-
-
-## X-RISC-V ISA Development Mailing List FAQ
-
-
-* Advocate for RISC-V on this mailing list
-
-Constructive criticism is essential for evolution of the RISC-V
-specifications, however opinions without quantitative assessment or that
-contain a general disillusionment towards RISC-V are not in the spirit
-of this list. Things can and will be improved as the specifications
-evolve. Quirks exist. They can be ironed out. To improve the ISA we
-need to maintain a generally positive attitude towards the evolution
-of the specifications, keeping in mind binary compatibility with the
-existing specifications. Editing the specifications is hard work. Gossip,
-speculation and inaccurate accounts of computer history are not on topic.
-
-
-* Read Computer Architecture, Sixth Edition: A Quantitative Approach
-
-As we all know, this book contains the foundation of the RISC-V
-quantitative design. Quoting Amazon: “Computer Architecture:
-A Quantitative Approach, Sixth Edition has been considered essential
-reading by instructors, students and practitioners of computer design for
-over 20 years. The sixth edition of this classic textbook from Hennessy
-and Patterson, winners of the 2017 ACM A.M. Turing Award recognizing
-contributions of lasting and major technical importance to the computing
-field, is fully revised with the latest developments in processor and
-system architecture. The text now features examples from the RISC-V
-(RISC Five) instruction set architecture, a modern RISC instruction set
-developed and designed to be a free and openly adoptable standard. It
-also includes a new chapter on domain-specific architectures and an
-updated chapter on warehouse-scale computing that features the first
-public information on Google’s newest WSC.”
-
-
-* RISC origins at Berkeley
-
-Rhetoric that compares RISC-V to a student project is defamatory and
-belies the fact that there is widespread support and adoption for RISC-V
-in the MCU space with companies committing to ship billions of RISC-V
-processors in deeply embedded applications. The RISC-V Foundation
-represents the apex of the academic-industrial complex and this is
-shown by the Foundation membership. Please respect that this list is for
-supporters of RISC-V and includes some of the most brilliant minds in the
-industry. argumentum ad hominem and conspiracy theories should be avoided.
-
-
-* The RISC-V Foundation has a large number of committed member companies.
-
-There are newcomers on the list who are not aware that they are
-broadcasting to a large Foundation of committed RISC-V member companies
-who support the RISC-V standards. General rules for constructive
-criticism and neutral discourse apply as indeed they would for any
-industry working group.
-
-
-* The privileged ISA is not a POSIX/Linux ISA
-
-The only thing in the privileged specification that supports a
-UNIX/POSIX-like OS is S-mode page based address translation and
-the Supervisor mode / User mode privilege separation. These are
-optional. These functions are not limited to POSIX. Windows NT with its
-roots in VMS could use these facilities with PE/COFF and UEFI to run
-ntoskrnl.exe on RISC-V. The System V ELF ABI and calling convention is
-documented in a separate processor supplement ABI document. The Linux
-ABI is not part of the ISA.
-
-
-* Binary compatibility is important for MCUs
-
-The machine mode registers should be consistent across
-implementations. Binary compatibility for micro controllers is just
-as important as OS level binary compatibility (which is distinct) as
-it allows RISC-V system level code to be shared across heterogenous
-implementations.
-
-
-* Modularity makes small implementations easier
-
-The modularity of the RISC-V specifications is very well thought
-through and is one of its strengths; credit to the ISA designers. RVI
-plus minimal M-mode is as easy to implement as one would expect for a
-simple MCU with in the order of a few hundred bits for processor state
-on top of the register file.
-
-
-* A minimal M-mode implementation is not onerous
-
-An M-mode only implementation requires approximately 11 CSRs (mcycle,
-minstret, mstatus, misa, mie, mtvec, mscratch, mepc, mcause, mtval, mip)
-out of a set of 18 CSRs. This is not onerous. Several only require 1
-bit of state in a minimal configuration.
-
-Below are the 18 CSRs with the minimal 11 identified which are necessary
-to implement a processor confirming to the M-mode subset of the Privileged
-ISA as distinct from the User-level ISA which only specifies the runtime
-aspects of the ISA, versus privilege modes (M-mode is mandatory, S and U
-are optional). An implementation with < 11 XLEN machine words is possible.
-
- /* machine counters */ mcycle - (useful to implement) minstret -
- (useful to implement)
-
- /* machine information */ mvendorid - (can wire to 0) marchid -
- (can wire to 0) mimplid - (can wire to 0) mhartid - (single core
- can wire to 0)
-
- /* machine trap setup */ mstatus - (requires MIE) 1-bit misa -
- (1 bit: ‘E’ or ‘I’) 1-bit mideleg - (can wire to 0)
- medeleg - (can wire to 0) mie - (require to enable external and
- timer interrupts MEIE, MTIE) 2-bits mtvec - (required for ISR
- entry, address, can be hardwired e.g to 0x10000) mcounteren -
- (can wire to 0)
-
- /* machine trap handling */ mscratch - (required register for
- ISR stack pointer) mepc - (required register for ISR return
- address) mcause - (required register for ISR cause: exception or
- interrupt) mtval - (required register for ISR exception info) mip
- - (required register for ISR to see which interrupts are pending)
-
-
-* RISC-V Control and status registers are accessed with an immediate
-
-Control and status registers are accessed via an instruction
-immediate. This means there is no register read required to decode the
-CSR. This makes pipelined and Out Of Order implementations easier to
-implement. Thus it doesn’t favour one implementation style over the
-other. CSRs could be present in an MMIO address space however the CSR
-instructions are the interface, not loads or stores. The spec doesn’t
-preclude the CSR instructions from fronting MMIO backed register space and
-I believe it was a design considerations and a plausible implementation
-choice. However, the specified instructions for accessing processor
-state use an immediate. This simplifies implementation. Indirection of
-access to CSRs via a register would remove the ability to rename and
-force serialisation as CSRs can change the state of instructions before
-and after them. This would be similar to loads and stores to IO space
-which need to be ordered. The current design supports tiny MCUs up to
-large multi-core OoO application processors.
-
-
-* Micro controllers have different memory maps
-
-The only thing limiting binary compatibility between bare metal apps are
-typically a linker script because the “memory map” differs between
-implementations and they require different device drivers. Bare metal apps
-need to have custom chip bringup code for the MCU which is part of a BSP
-(Board Support Package). Fortunately the privileged ISA is a constant
-across implementations. Moving privileged ISA function into a memory map
-won't improve this situation. It will worsen binary compatibility. Higher
-level OSes like Linux have user level ABIs and virtual memory to hide the
-physical memory map visible to the OS which makes binary portability
-easier at higher layers in the application stack. Bare metal code
-typically depends on a specific memory map but good design can factor
-out the differences between different processors from different vendors.
-
-Many RISC-V vendors are actively working on solutions to these
-problems. For medium size systems there is even the possibility of
-implementing arm’s EBBR standard which includes a cut down version of
-UEFI designed to work with device-tree instead of ACPI. The interface
-surface area is tractable for moderately sized embedded systems.
-
-For smaller MCUs, the memory map and devices are likely to be unique.
-Systems that have scratchpads that may be too small to hold device-tree
-parser (like SiFive’s HiFive1) will of course need custom linker scripts
-and custom BSPs. This is par for the course for the type of system that
-when scaled may cost several cents and can be used on a smart conference
-badge and in systems that are in the 1mm^2 range excluding packaging.
-
-
-* Standard privilege status and control registers allow for portable
-bare-metal code
-
-The standard machine mode registers minimise friction when adapting code
-to processors with different memory maps because developers can rely on
-a standard control mechanism for traps (interrupts and exceptions).
-
-
-* An ISA can’t disallow software, on the contrary it is designed to
-support it
-
-arm’s EBBR subset of UEFI is actually not that onerous and provides
-a relatively clean interface for binary compatible booting on medium
-size embedded devices. It is not appropriate for the smallest of
-implementations that just depend on the presence of the 11 CRSs mentioned
-above. But given RISC-V is an ISA, it can’t prevent someone from porting
-UEFI, PE/COFF, coreboot, u-boot, or any OS for that matter. The ISA can
-however enforce binary compatibility at the M-mode level.
-
-
-* Secure implementations that support digital right management are
-supported
-
-Mask ROM code that verifies EEPROM payload with signature checks
-using a public key in OTP are supported e.g. a Trusted Computing
-Base. RISC-V member companies are actively working on boot integrity
-across heterogenous RISC-V systems. Customers of chip vendors that have
-intellectual property to protect are not excluded. RISC-V is agnostic
-towards end-use and doesn’t have any restrictions on endeavours besides
-compliance with the technical requirements of the ISA, for reasons of
-binary compatibility.
-
-
-* RISC-V has several ISA variants
-
-At the moment MCUs and application processors with the same ISA share
-the same calling convention, but there are several ISA variants with
-different calling conventions in the RISC-V suite depending on the
-presence of F, D, E. The C extension also creates an ISA variant (GC
-code is not compatible with G), hence its presence in ‘misa’.
-
-
-* MCUs don’t need to save/restore all registers
-
-In the future, users of the open source tools will be able to do things
-for the MCU profile like hide the ISR setup and entry assembly behind
-C/C++ attributes, so programmers don’t need to worry about these
-low-level details. It is possible, today, with existing tools, to model
-an MCU ABI that has less register save restore overhead by compiling ISRs
-(bottom half) with a different set of registers to top half code. It
-is not necessary to make wholesale changes to the Privileged ISA to
-achieve this. Optimising trap/entry exit clearly requires some thought
-and using the standard C ABI may not be optimal. Luckily we can write
-bare functions and use inline asm, etc.
-
-Save/restore overhead can be reduced now with thoughtful use of compiler
-flags (-ffixed-reg) or hand coded assembly. Special compiler support will
-make this even easier in the future. Also, if code is purely interrupt
-driven, then ISRs can also avoid save/restore alttogether. They are
-many techniques to minimise interrupt overhead that don’t require ISA
-changes. Recursive interrupts are of course a distinct issue that requires
-thoughtful design… and I suspect will be addressed in a future version
-of the spec, in an evolutionary vs revolutionary manner.
-
-When a competitive RISC-V system can run at an order of magnitude faster
-clock speed in the same process and area, then claims of these overheads
-are “bunkem”
-
-
-* Is forking the RISC-V ISA a good idea
-
-Folk are free to fork the architecture , as it is CC licensed, and folk
-can even call it RISC-V if they comply with the specifications and if
-implementing a processor, an implementation need to implement the 11
-or so M-mode registers (and several more wired to 0). The User-Level
-ISA can only be used alone as part of an AEE. This is outlined in the
-current specs. Custom additions have to follow the conventions set out
-in the specification.
-
-
-* Should RISC-V trademark rules should be enforced
-
-Members could potentially be violating the RISC-V trademark usage
-guidelines and I believe they should be enforced:
-
-- https://riscv.org/risc-v-trademark-usage/
-
-Example: https://emb-riscv.github.io/
-
-Implementation proposal that does not comply with the minimal M mode
-requirements and may not be RISC-V compliant. The “Embedded RISC-V”
-initiative may very well comply with the Base ISA however as far as
-I am aware, a complete processor must implement M mode unless it only
-aims for AEE compliance. Use of the RISC-V logo in a way that suggests
-endorsement from the foundation without explicit permission should be
-questioned e.g. is “Embedded RISC-V” the official embedded working
-group and who is the chair? Using something like X-Embedded might be
-less risky assuming this may or may not be the Foundation’s official
-Embedded Working Group? It is hard to tell. It is suggestive.
-
-Uses X- prefix, extends the specifications, doesn’t modify the RISC-V
-logo. Clearly fair use.
-
-
-* Do we need an embedded working group.
-
-I’d like to know more about the embedded working group. I think it would
-be a disservice to the other foundation members if it was run by one
-member acting without consideration of the existing specifications and
-the needs of other members. I imagine minimising binary incompatibility
-would be a mandate for the group with an objective to create “minimal”
-differences or additions to the Privileged ISA versus a radical departure
-that throws out the most minimal portion of the Privileged ISA.
-
-
-* Folk should be free to experiment, within reasonable bounds
-
-Certainly there needs to be a balance of freedom to experiment with the
-RISC-V architecture i.e. academic or research use, versus commercial
-implementations that would be subject to compliance assessment. Look at
-how other commercial and individual members of the RISC-V Foundation
-use the RISC-V logo and represent their custom “extensions”. Very
-carefully. e.g. preceding specifications with X or noting said
-specifications are “unofficial proposals”. My advice would be to avoid
-wholesale replacement of portions of the specification and representing
-it as “Industrial RISC-V” and the “RISC-V Industrial Profile”
-versus “RISC-V X-Industrial Profile”. Someone could easily perceive
-these as a projects that are endorsed by the foundation.
-
-The mandatory portions for a minimal processor implementing M-mode and
-RVI are indeed by all accounts small, so if an additive X-custom micro
-controller profile is available, it may very well be accepted, assuming
-it is compatible.
-
-
-* RISC-V ISA is open but agnostic to free and open source versus
-proprietary implementations alike
-
-Regarding a Trusted Computing Base, RISC-V is available for use by
-proprietary and open source implementations alike. This is clearly
-stated on the foundation website. If implementations were restricted
-to the hardware equivalent of GPL, then adoption in industry would be
-very limited. The choice for on an open standard ISA is out of pragmatism
-(cost reduction, shared common interest, industry competitive ISA that is
-also a base for computer architecture research). It is not idealogical
-(anti-DRM, tit-for-tat licensing schemes, prevents proprietary usage
-or proprietary additions, or alternatively prevents open usage or open
-additions). Many RISC-V Foundation members have intellectual property they
-want to continue to protect and RISC-V is completely open to supporting
-these implementations.
-
-
-* RISC-V Base ISA requires 2-read ports 1-write port
-
-Newcomers to the list might propose things that are inappropriate based
-on design decisions that are already set in stone or frozen. We should
-maintain a list FAQ for things that have already been discussed on the
-list, such as instructions that require 3 read ports. FMA in F and D is
-an exception and why. The Vector ISA allows for predicated operations
-and the intent, as i’ve witnessed it, is to keep the implementation
-requirements for the Base ISA to 2-read ports 1-write port. This means
-two input operands. The Base ISA has no exceptions to this rule. F and
-D which are optional extensions have some instructions with 3 input
-operands and/or use implicit state. e.g. floating point instructions
-read ‘frm’ and write to ‘fflags’. We can then simply reply with
-a pointer to the FAQ.
-
-
-* Inflammatory language vs neutral tone
-
-Avoid inflammatory language and slang on the list. Words such as
-“bunkem” and “treacherous” are examples of words that are not
-appropriate for use on the list. “misinformation” is a more neutral
-and correct. Avoid sensationalising issues and/or grandstanding.
-
-
-* Long emails
-
-If you want to send long emails, keep their frequency very low. I’ve
-added bullets to this email so folk could skip ahead. i.e. “brevity
-is the sole of wit”. A long email every few weeks is better than
-occupying > 50% of the list bandwidth with distant goals when there are
-more immediate and practical issues to solve. This involves discussing
-and submitting edits to the “existing” specs versus occupying
-the list with a deluge of radical departures from the current ISA
-specifications. Post at a low frequency and gather feedback off list if
-you write very long proposals, link to them
-
-
-* Fragmentation, gossip, opinion and speculation
-
-Fragmentation, gossip, opinion and speculation on this list is harmful. We
-need to keep the discussions on this list technical and refrain from
-industry gossip, fear mongering and opinion. Let’s keep things technical
-and let’s focus this list on small incremental additions to the parts of
-the ISA that are not frozen. I thought discussing something like a SELECT
-instruction was quite controversial (3 operand form of conditional move
-that requires a third bit-line read port and a zero comparator on each
-physical register). Very uncontroversial in comparison to the recent
-rampant expletive filled sagas on this list.
-
-
-* Inclusivity and digesting
-
-The list should remain open, inclusive and friendly towards newcomers. If
-the discussion veers off topic, or becomes time consuming, point someone
-to a book, FAQ or other material. Newcomers however should not post
-material at a rate that a large number of members on the list can’t
-possibly digest. Care for other peoples consciousness and their ability
-to digest information. Its possible to overload people and occupy peoples
-consciousness to their detriment if they are regular readers of this list.
-
-
-* My own view. I’m not speaking on behalf of the foundation or my
-employer
-
-This should be implicit. This is a public list. I’m speaking in my
-personal capacity. I would not dare to represent anything as RISC-V
-without appropriate approval. Discussing the RISC-V ISA is on-topic on
-this list. Proposing additions to the official specs via established
-channels such as the working groups and this mailing list is on topic.
projects / libreriscv.git / blobdiff