From 8a3c563272cf56bebec0fa3b4fc7546791511a1b Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Mon, 1 Aug 2022 21:31:41 +0100 Subject: [PATCH] cleanup, remove old pages --- x-list.mdwn | 462 ---------------------------------------------------- 1 file changed, 462 deletions(-) delete mode 100644 x-list.mdwn diff --git a/x-list.mdwn b/x-list.mdwn deleted file mode 100644 index d108485f0..000000000 --- a/x-list.mdwn +++ /dev/null @@ -1,462 +0,0 @@ -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. -- 2.30.2