Thanks for the explanation! So, in summary, not a big deal.
For standard RISCV ISA variants, GORISCV flag values for each variant should be used, probably accepting combinations. Support for standard ISA modules could be community contributions mainly. For popular custom RISCV ISA extensions they could just follow the same upstream contribution path as standard modules, adding extra GORISCV flag variants. Maybe just named differently to the standard ones. And I guess if demand is high on custom ISAs extensions it might prompt for more documentation & tutorials around adding ISA variants to the compiler in the go codebase, before thinking about plugins or alike. Correct? Jose El domingo, 13 de septiembre de 2020 a las 21:14:10 UTC+2, Ian Lance Taylor escribió: > On Sun, Sep 13, 2020 at 1:50 AM josvazg <jos...@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? > > > The way we've historically approached this kind of thing is to use a > fixed GOARCH value and to use a separate environment variable, which > for RISCV would be GORISCV and, perhaps, GORISCV64. That separate > environment variable would be the set of specific architecture > variants that matter. For example, see the variables GOARM, GO386, > etc., at https://golang.org/cmd/go/#hdr-Environment_variables . > > Ian > -- 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/8d119e98-9fb5-4cad-8e58-ccba8a13ddcan%40googlegroups.com.
