From 9aebfd90fb5526cd327d022c6d74e728917a65b3 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Thu, 3 May 2018 04:27:36 +0100 Subject: [PATCH] add x-list --- x-list.mdwn | 465 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 465 insertions(+) create mode 100644 x-list.mdwn diff --git a/x-list.mdwn b/x-list.mdwn new file mode 100644 index 000000000..174de2e68 --- /dev/null +++ b/x-list.mdwn @@ -0,0 +1,465 @@ +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 1: 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. + +Example 2: +https://github.com/cliffordwolf/xbitmanip/blob/master/xbitmanip-draft.pdf + +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. -- 2.30.2