ARM64 and RISCV ports

[ron minnich]

Hi, I'm trying to track down some info on "time and effort" for the
arm64 and riscv ports.

In the HPC world, we're seeing that work to port libraries to riscv64
is much less time than earlier work to port to aarch64. The reason is
that the effort expended in the move from x86_64 to arm resolved a lot
of the same problems that would need to be resolved on riscv, such
that problems resolved for arm were also resolved for riscv.

I put it to one of the HPC developers that the effort to move from
aarch64 to riscv64 was roughly the square root in time for
x86->aarch64 work, and they said that was actually a pretty decent
estimate. In other words, once you remove all the x86 assumptions from
your code, as HPC had to do, the next port is easier. Further, if you
squint at aarch64 and ARM (and MIPS and Alpha and Power) they don't
look all that different at user level. Port to one RISC-y thing and
you cover most of the important parts of all of them (but then of
course comes performance tuning!).

I'd like to see if that applied to Go. I've been walking the git logs
but am not sure I've found the right points to mark as start and end
of effort. Further, it's not obvious that the estimate applies in this
case, due to the unique (in the good sense!) structure of the Go
toolchain, and the several earlier ports to risc-y architectures like
power and mips.

If anyone has some numbers they think could apply, I'd be happy to hear them.

Thanks

[Michael Pratt]

I think the time effort is pretty hard to estimate, if only due to the strange way this port developed. Several folks (full list on https://go.dev/cl/193677) very slowly worked on a port at https://github.com/riscvarchive/riscv-go from ~2015-2017 before the effort petered out. Most of us were not familiar with the Go toolchain, so we spent a lot longer figuring everything out than an expert would. Plus we had roadblocks like having to rebase over the SSA backend rewrite. In 2019, Joel Sing then did the hard work of rebasing, completing, and upstreaming the port.

In terms of effort on architecture-independent code, I think that, to your point, because we have so many ports there are usually not too many issues in architecture-independent code that are uncovered only on a new port. e.g., https://go.dev/cl/204632 did not make any changes to architecture-independent code. At a quick glance at the issue tracker I don't see any architecture-independent bugs fixes that came out of RISC-V-only failures, but I wouldn't be surprised if I missed something.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAP6exYJWhd7xSP6DG0yChBr_TqYhBaWTtg5xB8wtEnfVnyBd-Q%40mail.gmail.com.

[Russ Cox]

No comment on the ARM64 vs RISCV ports, but my rule of thumb for ports back in the Plan 9 days was that if something ran on both Linux and Windows, then I could get it working on Plan 9 in reasonable time. Not because Linux and Windows are anything like Plan 9, but because they were different enough from each other that it meant that the developers had given proper thought to separating out OS-specific code. The second port is always the hard one. After that the only difficulties are system-specific.

When I started on Go, we had only amd64. I added 386 about six months later, with help from Ken to get the register optimizer hooked up. Given that we had already planned for separating architecture-specific code, it was relatively straightforward, but even so there was still quite a bit of refactoring, mainly to reduce copies of code that could be moved inside the portable boundary. We did arm a few months later, again not a big deal. Those were the ones Go shipped in the open source release. At that point I think things were very solid from a portability standpoint.

The most difficult port was probably power64, both because it has a very unusual calling convention and because it is big-endian. There turned out to be code in the runtime that accessed the garbage collection bitmaps as both an array of uint32 and as an array of uint8. That's fine on little-endian but not on big-endian. At this point I think it would be reasonable to just drop big-endian systems entirely. The endian wars are over, little endian won, and it allows that kind of punning.

Best,

Russ

[peterGo]

On Wednesday, November 15, 2023 at 4:26:13 PM UTC-5 Russ Cox wrote:

At this point I think it would be reasonable to just drop big-endian systems entirely. The endian wars are over, little endian won, and it allows that kind of punning.

Russ

 

IBM: Endianness Guidance for Open-Source Projects   

https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/javier-perez1/2021/01/19/endianness-guidance-for-open-source-projects   

Data can have the following byte order formats:

• Big-endian: A format in which the most significant byte is stored first. The other bytes follow in decreasing order of significance. The big-endian format is used by s390x (IBM Z & LinuxONE),.

Peter