GOARCH=mips32

[vladimir....@imgtec.com]

Hi all,

we are working on adding golang mips32 port (on behalf of imgtec).
The reserved GOARCH name in go/build/syslist.go is 'mips'.
On the other hand, the directory 'cmd/internal/obj/mips' belongs to mips64 (though the other one is 'cmd/compile/internal/mips64'). So we propose changing GOARCH from 'mips' to 'mips32'.
Alternatively (preferably?), 'cmd/internal/obj/mips' could be renamed to 'cmd/internal/obj/mips64', and we would keep the old GOARCH name for mips32 (ie. mips).

Regards,
Vladimir

[David Chase]

I happily cast my vote for mips32, reduced ambiguity is good.

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

[Brad Fitzpatrick]

Please keep GOARCH as "mips" and rename the directory to "mips64".

The reason we reserved all those GOARCH values in the first place was so old versions of Go would not be confused by unknown GOOS/GOARCH identifiers in filenames later.

That is, if you don't use "mips" and just make up a new "mips32", then older versions of Go will be confused by:

    sha1_mips32.go

And we'll need to use "// +build mips32" in those files.

Also, bare "mips" came first and parallels "arm".

[cherry]

On the other hand, the directory 'cmd/internal/obj/mips' belongs to mips64 (though the other one is 'cmd/compile/internal/mips64'). So we propose changing GOARCH from 'mips' to 'mips32'.

The thought behind this is that cmd/internal/obj/mips could be used for both 32-bit and 64-bit, just like cmd/internal/obj/x86 is used for both 386 and AMD64. I think the modification of the current cmd/internal/obj/mips to support 32-bit should be small.

The compiler, on the other hand, is sufficiently different so it is worth two implementations, just like 386 and AMD64 as well.

[minux]

On Wed, Aug 31, 2016 at 4:07 PM, <vladimir....@imgtec.com> wrote:

Please don't rename the directory cmd/internal/obj/mips and instead add necessary

32-bit mode to internal/obj/mips.

We chose the names for cmd/internal/obj/mips and cmd/{compile,link}/internal/mips64

for a reason: we expect both 32-bit and 64-bit mips to share the implementation of

cmd/internal/obj/mips, which should be much easier than 32-bit/64-bit x86 sharing

the same cmd/internal/obj/x86.

In fact, we even thought that risc-v could share the cmd/internal/obj as well, but

that might be a far-stretch as risc-v has larger differences to mips.

Also please do not change the reserved GOARCH names as that will negate all the

benefit of reserving GOARCH names ahead of time. (Whenever we add a new GOOS

or a new GOARCH, a new set files will be excluded from build, and this might affect

users' existing code: one prime example is when we introduced GOOS=android and

suddenly all files with the name *_android.go doesn't get build on Linux.) Additionally,

the reserved GOARChes are chosen to match gccgo as well.

[v239...@gmail.com]

Ok, thanks everyone for the prompt inputs; let's keep 'mips' goarch.
Will try to add 32bit part to cmd/internal/obj/mips.

[Taru Karttunen]

Hello,

Which variants of MIPS32 are you planning to support? Only MIPS32r6?
Or also things used in lower end stuff like MIPS32r2?

- Taru Karttunen

[vladimir....@imgtec.com]

In fact, the first on the list is MIPS32r1/r2, little and big endian. We'll be adding r6 some time later, likely after cgo and SSA.

[Nate Haggard]

Also in syslist.go goarchList has mips64p32 mips64p32le.  What are they for?

[Aram Hăvărneanu]

Mips64 with 32 bit pointers, and little-endian mips64 with 32-bit pointers.

--
Aram Hăvărneanu

[Keith Randall]

They are for 64-bit processors using a 32-bit address space.  See amd64p32 for an example, under NaCl (Native Client) the chip looks like it only has 32-bit pointers.

I don't know if MIPS has a NaCl port or a 32-bit pointer mode or anything, but the reservation is probably there just in case.

--

[minux]

On Fri, Sep 2, 2016 at 3:02 PM, Nate Haggard <nate...@gmail.com> wrote:

Also in syslist.go goarchList has mips64p32 mips64p32le.  What are they for?

MIPS is one of the first architecture to introduce 64-bit mode (circa 1992 with

MIPS III), at that time, memory is not as abundant as it's now, so SGI introduced

an ABI (only an ABI implemented by the kernel, not a processor mode) called

N32 that uses the full 64-bit registers, but limit the address space to the first 4GB

so that pointers are still 32-bit.

N32 is very popular for MIPS architecture. In fact, most (if not all) 64-bit MIPS

systems are using N32 user space in order to save memory, and MIPS64 gcc

will produce N32 binaries by default. Other 64-bit architectures are recently

trying to introduce their 32-bit pointer variants as well (x32 for x86_64, and I've

heard work has started for arm64 and ppc64 too.)

[Petar Jovanovic]

On Fri, Sep 2, 2016 at 10:06 PM, 'Keith Randall' via golang-dev
<golan...@googlegroups.com> wrote:
> They are for 64-bit processors using a 32-bit address space. See amd64p32
> for an example, under NaCl (Native Client) the chip looks like it only has
> 32-bit pointers.
> I don't know if MIPS has a NaCl port or a 32-bit pointer mode or anything,
> but the reservation is probably there just in case.
>

NaCl supports MIPS32.

[Keith Randall]

All the current ports now have SSA backend support and we're going to delete the legacy compiler from tip really soon now (starting tomorrow?).  I'd like to apologize in advance if that throws a wrench into your mips32 plans.  Please let me know if you need any help getting SSA working for mips32.

[Aram Hăvărneanu]

Well that certainly is a setback fro the sparc64 port.

--
Aram Hăvărneanu

[Brad Fitzpatrick]

This isn't really news, though... https://github.com/golang/go/issues/16357

[vladimir....@imgtec.com]

Long time no see.
Hi, I pushed the new version of mips port, with GOARCH=mips, SSA codegen and cmd/internal/obj shared with mips64.
I'll abandon the old mips32 commits now.

On Tuesday, September 13, 2016 at 11:38:46 PM UTC+2, Brad Fitzpatrick wrote:

This isn't really news, though... https://github.com/golang/go/issues/16357

On Sep 13, 2016 2:17 PM, "Aram Hăvărneanu" <ara...@mgk.ro> wrote:

Well that certainly is a setback fro the sparc64 port.

--
Aram Hăvărneanu

--
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.

[cherry]

Thank you for doing this. Could you set up the builders, so that we know it works?

Thank you.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.

[Brad Fitzpatrick]

Vladimir,

I can help set up the builders if I can have access to some hardware (or a VM).

My ssh keys are https://github.com/bradfitz.keys

The machine would not need any ports open to the outside world, except a way to ssh in, and outbound network access.

On Thu, Oct 20, 2016 at 4:08 AM, cherry <luna...@gmail.com> wrote:

Thank you for doing this. Could you set up the builders, so that we know it works?

Thank you.

[Petar Jovanovic]

I will send a separate email about our plan for the builders shorty.

Regards,
Petar

On Thu, Oct 20, 2016 at 10:35 AM, Brad Fitzpatrick <brad...@golang.org> wrote:
> Vladimir,
>
> I can help set up the builders if I can have access to some hardware (or a
> VM).
>
> My ssh keys are https://github.com/bradfitz.keys
>
> The machine would not need any ports open to the outside world, except a way
> to ssh in, and outbound network access.
>
>
>
>
> On Thu, Oct 20, 2016 at 4:08 AM, cherry <luna...@gmail.com> wrote:
>>
>> Thank you for doing this. Could you set up the builders, so that we know
>> it works?
>> Thank you.
>>

[firebo...@gmail.com]

Is the port complete now? Should we expect it in the next release?

[cherry]

On Thu, Nov 10, 2016 at 10:12 PM, <firebo...@gmail.com> wrote:
> Is the port complete now? Should we expect it in the next release?

Yes, it should be in for the next release. Most of the CLs are already
landed on tip. There is only one CL that still needs very small work.

[firebo...@gmail.com]

But when I browse https://build.golang.org/, I see that for MIPS target all builds are failed.

I tried to take a look at the logs and I see "GOHOSTARCH=mips". Does the buildbot run

on the mips host?!

[Brad Fitzpatrick]

The mips patches aren't all in yet.

The build system is a number of parts. There is a centralized coordinator part, a data storage part, and then an agent that runs on every machine being tested (the "buildlet").

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.