Any one porting Go to big-endian ARM and Aarch64?

[Bryan Chan]

Is any one working on porting Go to big-endian ARM and Aarch64? I would like to contribute to an existing effort if there is one. If not, I would like to see whether it makes sense to take the existing arm and arm64 backends, and make them support big-endian targets. For 32-bit ARM, I am mainly interested in the BE8 mode, which uses little-endian instructions but big-endian data, but I think it should be possible to support the older BE32 mode as well (where both instructions and data are big-endian).

My guess is that the new targets could share most of compile and asm with the little-endian targets, but generate everything in big-endian, and link could then (optionally, if support for BE32 ARM is desired) perform byte swapping on instruction words. This is similar to the behaviour of the --be8 option in the ARM linker, if I understand correctly. I have only started studying the arm backend, so I am not sure whether this makes sense for arm64.

--

Bryan

[Dave Cheney]

I'm not aware of anyone working on a BE port. If you were going to do this you would also need to supply builders for the dashboard as the current ones are have a little endian only and I'm not aware of any commercial offerings that run in big endian mode.

--
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.
For more options, visit https://groups.google.com/d/optout.

[Bryan Chan]

Thanks Dave, I understand the need for public builders. That will be one of the tougher to-do's but I will try to figure it out as a priority. Do you foresee any problem with my approach? I would love to hear from the people involved what were some problems they ran into with the ppc64le port.

[Dave Cheney]

I think it should be pretty straight forward, the MIPS 32 big and little endian, and ppc64 be/let code was very similar and reusues the same respective backends. 

[minux]

On Fri, Dec 23, 2016 at 10:45 PM, Bryan Chan <brya...@gmail.com> wrote:

Is any one working on porting Go to big-endian ARM and Aarch64? I would like to contribute to an existing effort if there is one. If not, I would like to see whether it makes sense to take the existing arm and arm64 backends, and make them support big-endian targets. For 32-bit ARM, I am mainly interested in the BE8 mode, which uses little-endian instructions but big-endian data, but I think it should be possible to support the older BE32 mode as well (where both instructions and data are big-endian).

My guess is that the new targets could share most of compile and asm with the little-endian targets, but generate everything in big-endian, and link could then (optionally, if support for BE32 ARM is desired) perform byte swapping on instruction words. This is similar to the behaviour of the --be8 option in the ARM linker, if I understand correctly. I have only started studying the arm backend, so I am not sure whether this makes sense for arm64.

We have flushed out most little endian assumptions in the code base during the ppc64 port,

so I don't expect many problems for BE32 mode, but I do see some problems for BE8.

The Go toolchain/runtime assumes that the code and data are using the same endianness.

We do have armbe and arm64be GOARCH reserved. But I think armbe probably should

refer to BE32 mode? ARMv8 never supports BE32, so using GOARCH=arm64be for BE8

is probably ok.

Just curious, what's the motivation for BE8? It seems the world is moving towards LE

these days.

[Aram Hăvărneanu]

When I did the arm64 port, I did play with big-endian arm64, but
quickly lost interest in maintaining my own Linux distribution.

Adding BE support would be trivial.

--
Aram Hăvărneanu

[Bryan Chan]

On Saturday, 24 December 2016 00:54:14 UTC-5, minux wrote:

We have flushed out most little endian assumptions in the code base during the ppc64 port,

so I don't expect many problems for BE32 mode, but I do see some problems for BE8.

The Go toolchain/runtime assumes that the code and data are using the same endianness.

Which parts of the runtime make this assumption? Is there any runtime inspection or generation of code?

 

We do have armbe and arm64be GOARCH reserved. But I think armbe probably should

refer to BE32 mode? ARMv8 never supports BE32, so using GOARCH=arm64be for BE8

is probably ok.

That sounds reasonable. I could create "armbe8" as a variant of armbe.

Just curious, what's the motivation for BE8? It seems the world is moving towards LE

these days.

There are some BE8 programs written in C that my client would like to continue to use, but it would be nice to write new code in Go. For them, switching to LE is not an option at the moment. I agree with your understanding of the world, but I guess there is still interest in ARM BE given that the question comes up every once in a while.

Bryan

[Bryan Chan]

On Saturday, 24 December 2016 06:07:15 UTC-5, Aram Hăvărneanu wrote:

When I did the arm64 port, I did play with big-endian arm64, but
quickly lost interest in maintaining my own Linux distribution.
Adding BE support would be trivial.

That's excellent news! Do you still have the arm64 BE patches, or can you point me to what I'd need to change to get it going easily?

--

Bryan 

[Bryan Chan]

Hi Brian,

I ended up writing a bunch of patches to allow the compiler to generate 32-bit armbe and armbe8 binaries. I had access to an aarch64 box where I could get through most of run.bash in armbe8 mode. I didn't have hardware to test armbe programs, but helloworld worked in QEMU. Unfortunately I didn't find sufficient funding to put together a box for the builder.

I am setting up an aarch64 server now (alas only an internal one), and hopefully soon I'll be able to resume work on the port.

Would you be able to donate any builder hardware? :-)

--
Bryan

On Fri, Aug 4, 2017 at 3:17 PM, <brian....@broadcom.com> wrote:

Hi Aram:
I took a quick look at some of your commits related to arm64.  Very impressive work.  Seems like one would need a good understanding of the arm type processor in order to glean what is needed to port arm/arm64 for BE. 

My group would benefit greatly if we could use armbe for running GO tests on our arm devices as we want to test both LE and BE.

Regards,
-Brian

[brian....@broadcom.com]

Hi Aram:
I took a quick look at some of your commits related to arm64.  Very impressive work.  Seems like one would need a good understanding of the arm type processor in order to glean what is needed to port arm/arm64 for BE. 

My group would benefit greatly if we could use armbe for running GO tests on our arm devices as we want to test both LE and BE.

Regards,
-Brian

On Saturday, December 24, 2016 at 3:07:15 AM UTC-8, Aram Hăvărneanu wrote:

[Brian Kirsch]

Hi Bryan,

I wish I could, but I don’t think it will be possible. 

-Brian

[mijas...@gmail.com]

I can donate hardware for this.

On Friday, August 4, 2017 at 4:30:30 PM UTC-4, Bryan Chan wrote:

Hi Brian,

I ended up writing a bunch of patches to allow the compiler to generate 32-bit armbe and armbe8 binaries. I had access to an aarch64 box where I could get through most of run.bash in armbe8 mode. I didn't have hardware to test armbe programs, but helloworld worked in QEMU. Unfortunately I didn't find sufficient funding to put together a box for the builder.

I am setting up an aarch64 server now (alas only an internal one), and hopefully soon I'll be able to resume work on the port.

Would you be able to donate any builder hardware? :-)

--
Bryan