On Sun, Sep 20, 2026, at 02:06, [email protected] wrote: > In the following document, http://www.collyer.net/who/geoff/9/9k-riscv.pdf > Mr. Collyer shares very clear opinions on RISC-V. I have thought about > these, and wanted to know more, for quite a while. It now occurs to me that > there may be three different things: > > 1) The RISC-V definition and extensions, > 2) The instruction sets that individual assembly-language programmers choose > to use, > 3) The instruction sets that board manufacturers decide to include in their > products. > > This opinion paper makes it very clear that in the opinion of at least one > person, "proposed and approved extensions beyond IMAFDC, and other additions" > should not be used. If one either happens to agree with this, or accepts the > conclusion for any other reason, obvious questions are the following: Are > any board manufacturers following this advice, and if not.. why? How big > would the community of people wanting such a board have to be to motivate the > creation of it, and how far short of being that big is that community now? > > I should add that I previously did a search on this general subject, and > found the following: > https://github.com/bintukappilgeorge/64-bit-RISC-V-processor-RV64IMAFD-SoC-Design
It seems that this discussion may benefit from defining the architectural decisions explicitly before deciding whether new hardware is needed. For example, the first decision could define the ISA target for the Plan 9 port. A reasonable starting point might be RV64IMAFDC, with additional extensions permitted in the processor but not required by the port. A second step could define the requirements for the hardware platform. These would include boot, privilege modes, MMU, interrupts, timers, memory, storage, networking, console, firmware, documentation, availability, and maintainability. Existing boards could then be evaluated against those requirements. The HiFive Unmatched and VisionFive 2, for example, provide RV64GC, which corresponds to the proposed RV64IMAFDC target. They could therefore serve as concrete candidates rather than discussing hypothetical hardware. Only after that evaluation would it make sense to consider a new board. If an existing board satisfies the requirements, there may be little reason to create another one. If existing candidates have a significant deficiency, that deficiency would provide a concrete reason to consider new hardware. This also separates the porting effort from the size of the community. A single person can create the port. The community can provide hardware, testing, feedback, documentation, and maintenance. In other words, rather than starting with "How large would the community have to be to motivate a board?", it may be more productive to establish the requirements first, record the significant decisions as ADRs, and then determine whether existing hardware satisfies them. That should give a much clearer answer to both the Plan 9 port question and the question of whether specialized hardware would provide any real benefit. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbf390d3a51f65cdf-M9c6003356ab16430588fd311 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
