I think because of the very modular design of the Go compiler, adapting it to work better for any specific RISCV variant would basically be trivial compared to other complicated compiler designs.
[Joop Kiefte - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=ol23b) [ol23b] On September 13, 2020 at 8:49 GMT, josvazg <josv...@gmail.com> wrote: This is not a proposal, just a curiosity question to check if anyone in the Go ecosystem has already thought on this issue and have some solutions in mind. I might be late to this realization, but nowadays is pretty clear Intel monolithic ISA dominance is threatened. ARM is taking over Macs and Amazon is doubling their offer of ARM based Cloud instances. In the end, you can't ignore chips with comparable performance but lower power consumption and heat dissipation issues. This is not yet disruptive for Go. Go already produces ARM binaries, so I'd expect it might just mean more compilations to ARM will happen and be offered. Maybe also ARM optimizations might see higher demand. RISCV is a different story. If server/laptop grade RISCV SoCs achieve a similar performance/power consumption ratio to their ARM counterparts, as they have no licensing costs & are extensible, I expect they are going to spread very quickly. ARM already saw this recently and is opening up a few of their licenses. And RISCV is not like the others for Go. RISCV is a modular extensible ISA, including standard and custom extensions. The standard extensions may already require some compiler architecture rework. Go might chose not to do anything and just support a handful of the most common RISCV ISA combinations... or add ISA modularity support. Starting from the mandatory core ISA, prefer specific module instructions to generic ones when the module letters are present in the GOARCH=riscvxxx passed in. The custom extensions may be even more disruptive. Go could chose to ignore them altogether so that Go compiled programs are always generic and can never use the custom extensions. But if RISCV takes off, that would mean Go programs will be slower and not really suitable for custom workloads some companies may have preferred to run on Go on their chosen chipset. On way around could be to provide compiler plugins so that some Go end users can extend the go compiler to use the custom extensions where they make sense. So they can customize their Go binaries for their workloads as they see fit. I expect having a plugin like this that has a simple & usable API to be tricky, to say the least. But I am not an expert so I might be wrong. Another way could be to provide even more generic compilations, and leave the final custom compilation step to the targets. For instance, the Go way could advise to just compile to GOARCH=wasm and leave the optimizations to a custom WASM runtime available at the target. That runtime is extended from the generic RISCV WASM runtime to use that particular chipset custom ISA extensions when appropriate. But Go is not involved in any way on that runtime, it might be even written in Rust or something else or be a Go program not provided as part of the Go language or tooling. Or Go could chose to ship unfinished compilations for this, not unlike JVM bytecodes. It could still be WASM or maybe the intermediate SSA representation of the program, and then provide an extensible transpiler that Go developers using particular custom ISA extensions can extend and use to produce the final custom static binary. It might be even embedded into the go tool so that when you "go get" you already get the custom executable locally. That would be very cool, but probably as tricky as the compiler plugins mentioned above. In fact, this and the compiler plugins option might end up being the same. I'd expect Go will not evolve to provide an extensible VM runner or JIT compiler environment. It seems too far a departure from the go runtime model and also will bring many known nuisances that plague these systems like JVM (big runtime env needed in the target, higher memory consumption, etc) So just curiosity, has any one have a thought on this or can point to literature on this matter? Thanks, Jose -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit [https://groups.google.com/d/msgid/golang-nuts/3c6d4b5f-0b9c-41da-b34e-24c765ab36cbn%40googlegroups.com](https://groups.google.com/d/msgid/golang-nuts/3c6d4b5f-0b9c-41da-b34e-24c765ab36cbn%40googlegroups.com?utm_medium=email&utm_source=footer). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c-64693-kf187hqe-ia33g5%3Dd90nao%402.gethop.com.
