GOMIPS - new arch-specific environment variable

[vladimir....@imgtec.com]

Hi all,

I would like to add an environment variable, GOMIPS, for mips-specific options.
It would be used for the choice between hard-float and soft-float, and the instruction set: mips32(r1), mips32r2 and mips32r6. (mips32r6 isn't backward compatible with r1/r2.)

Any thoughts?

Thanks,
Vladimir

[Brad Fitzpatrick]

So what values do you propose for it? Are there 6 combinations? How do you combine the two axes?

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

[vladimir....@imgtec.com]

1. 'hard-float' (default), 'soft-float'
2. 'mips32' (default), 'mips32r2', 'mips32r6'.

The user could specify one or both choices, separated with comma in the latter case.


E.g.:
GOMIPS=soft-float
GOMIPS=soft-float,mips32r2
GOMIPS="soft-float, mips32r2"
GOMIPS=mips32r6

On Friday, March 10, 2017 at 6:57:24 PM UTC+1, Brad Fitzpatrick wrote:

So what values do you propose for it? Are there 6 combinations? How do you combine the two axes?

On Mar 10, 2017 9:26 AM, <vladimir....@imgtec.com> wrote:

Hi all,

I would like to add an environment variable, GOMIPS, for mips-specific options.
It would be used for the choice between hard-float and soft-float, and the instruction set: mips32(r1), mips32r2 and mips32r6. (mips32r6 isn't backward compatible with r1/r2.)

Any thoughts?

Thanks,
Vladimir

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

[Keith Randall]

So which instructions in particular do you want to use?  Does the compiler need to emit them, or do you just intend to use them in assembly?  Where (runtime, math, sync/atomic, ...)?

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

[vladimir....@imgtec.com]

Yes, there would be different code both emitted by the compiler and written in assembly. The current (R1) code works on R2 hardware, 'mips32r2' option would just mean we could emit the code optimized for R2 (e.g. ext, ins, seb, seh instructions), but R6 isn't compatible with R1, so to support it, different code has to be generated.

[Keith Randall]

SEB and SEH seem pretty useful for the compiler.  We currently issue <<24>>24 and <<16>>16 to sign extend.

EXT and INS could be useful for bit operations.  We just added bit test instructions for amd64 and I don't think we have any for other architectures.

I'm surprised R1 code doesn't run on an R6 chip.  That sounds like a really bad backwards-compatible breakage.  That almost argues for a different GOARCH.

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

[Petar Jovanovic]

It has been two months without new comments. Do we have agreement that new environment variable, GOMIPS, can be added?

[Brad Fitzpatrick]

The last I saw, Keith was asking whether this deserves a new GOARCH. It definitely doesn't sound like any plan was reached.

On Mon, May 8, 2017 at 4:40 AM, Petar Jovanovic <pet...@mips.com> wrote:

It has been two months without new comments. Do we have agreement that new environment variable, GOMIPS, can be added?

--

[vladimir....@imgtec.com]

So, to summarize, we would like to support a few variants of mips:
-mips32(r1);
-mips32r2;
-mips32r6;

mips32r2 is backward compatible with r1, without the option we just couldn't take advantage of the new instructions (the aforementioned ext, ins, seb, seh, and rotr, wsbh). Or we could emit them unconditionally, but that would mean we give up supporting r1.
r6 isn't backward compatible so it might be a new GOARCH, though majority of the code is the same as for GOARCH=mips, in compiler, assembler and runtime.
Btw, mips32r2 patch is quite ready, it could be submitted soon after we get past GOMIPS.

Also, the same GOMIPS variable might be used for the mips64 variants:
-mips3 (current mips64);
-mips64r2;
-mips64r6;

Besides, we would like to have a choice between hard-float and soft-float, although that might be a separate, non-arch-specific, variable.

On Monday, May 8, 2017 at 9:27:24 PM UTC+2, Brad Fitzpatrick wrote:

The last I saw, Keith was asking whether this deserves a new GOARCH. It definitely doesn't sound like any plan was reached.

On Mon, May 8, 2017 at 4:40 AM, Petar Jovanovic <pet...@mips.com> wrote:

It has been two months without new comments. Do we have agreement that new environment variable, GOMIPS, can be added?

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

[Keith Randall]

On Tue, May 9, 2017 at 1:06 PM, <vladimir....@imgtec.com> wrote:

So, to summarize, we would like to support a few variants of mips:
-mips32(r1);
-mips32r2;
-mips32r6;

mips32r2 is backward compatible with r1, without the option we just couldn't take advantage of the new instructions (the aforementioned ext, ins, seb, seh, and rotr, wsbh). Or we could emit them unconditionally, but that would mean we give up supporting r1.
r6 isn't backward compatible so it might be a new GOARCH, though majority of the code is the same as for GOARCH=mips, in compiler, assembler and runtime.
Btw, mips32r2 patch is quite ready, it could be submitted soon after we get past GOMIPS.

Sounds reasonable.  GOMIPS values of 1 (default), 2, 6.  It's new that the subarch values are mutually incompatible (unlike arm, where they are only unidirectionally incompatible), but that's life I guess.

What are the incompatibilities with mips32r6, exactly?

 

Also, the same GOMIPS variable might be used for the mips64 variants:
-mips3 (current mips64);
-mips64r2;
-mips64r6;

Besides, we would like to have a choice between hard-float and soft-float, although that might be a separate, non-arch-specific, variable.

ARM selects soft float for GOARM=5 but not for later versions.  Is that not the case here - you want a full cross product of the above and soft float?

 

On Monday, May 8, 2017 at 9:27:24 PM UTC+2, Brad Fitzpatrick wrote:

The last I saw, Keith was asking whether this deserves a new GOARCH. It definitely doesn't sound like any plan was reached.

On Mon, May 8, 2017 at 4:40 AM, Petar Jovanovic <pet...@mips.com> wrote:

It has been two months without new comments. Do we have agreement that new environment variable, GOMIPS, can be added?

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

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

[vladimir....@imgtec.com]

On Tuesday, May 9, 2017 at 10:17:26 PM UTC+2, Keith Randall wrote:

On Tue, May 9, 2017 at 1:06 PM, <vladimir....@imgtec.com> wrote:

So, to summarize, we would like to support a few variants of mips:
-mips32(r1);
-mips32r2;
-mips32r6;

mips32r2 is backward compatible with r1, without the option we just couldn't take advantage of the new instructions (the aforementioned ext, ins, seb, seh, and rotr, wsbh). Or we could emit them unconditionally, but that would mean we give up supporting r1.
r6 isn't backward compatible so it might be a new GOARCH, though majority of the code is the same as for GOARCH=mips, in compiler, assembler and runtime.
Btw, mips32r2 patch is quite ready, it could be submitted soon after we get past GOMIPS.

Sounds reasonable.  GOMIPS values of 1 (default), 2, 6.  It's new that the subarch values are mutually incompatible (unlike arm, where they are only unidirectionally incompatible), but that's life I guess.

What are the incompatibilities with mips32r6, exactly?

 

mips32r6 has new instructions, like branches with no delay slots and pc-relative loads, and has some others removed, like lwl/lwr/swl/swr for unaligned memory access (so we need to rewrite memmove), or mult/div which stored the result in hi and lo registers (gone too), replaced by mul/div which store the result in a GPR.
Also, some instructions are encoded differently.
 

 

Also, the same GOMIPS variable might be used for the mips64 variants:
-mips3 (current mips64);
-mips64r2;
-mips64r6;

Besides, we would like to have a choice between hard-float and soft-float, although that might be a separate, non-arch-specific, variable.

ARM selects soft float for GOARM=5 but not for later versions.  Is that not the case here - you want a full cross product of the above and soft float?

 Yes, we'd like the soft-float option to be available for all subarches.

[Petar Jovanovic]

---

From: Keith Randall [k...@google.com]
Sent: Tuesday, May 09, 2017 10:17 PM
To: Vladimir Stefanovic
Cc: golang-dev; Petar Jovanovic
Subject: Re: [golang-dev] GOMIPS - new arch-specific environment variable

Sounds reasonable.  GOMIPS values of 1 (default), 2, 6.  It's new that the subarch values are mutually incompatible (unlike arm, where they are only unidirectionally incompatible), but that's life I guess.

Great. So, we should use GOMIPS for MIPS-specific options only and use for instance GOFLOAT for soft vs. hard?

[Keith Randall]

Yes, that sounds good to me.  We can bikeshed on the GOFLOAT name.  Maybe just GOSOFTFLOAT=1, and make hard the default?

Other opinions?

[vladimir....@imgtec.com]

In case everyone agrees, I updated the soft-float patches submitted to gerrit to introduce and use GOSOFTFLOAT=1.

[Ian Lance Taylor]

On Mon, May 15, 2017 at 10:42 AM, 'Keith Randall' via golang-dev
<golan...@googlegroups.com> wrote:
> Yes, that sounds good to me. We can bikeshed on the GOFLOAT name. Maybe
> just GOSOFTFLOAT=1, and make hard the default?
> Other opinions?

I'm not fond of a generic name like GOSOFTFLOAT that only applies to MIPS.

In particular I note that we currently have GO386 that takes values
"387" or "sse". I don't see a problem with GOMIPS that takes one or
more strings that describe specific attributes.

Ian

> On Mon, May 15, 2017 at 10:37 AM, Petar Jovanovic
> <Petar.J...@imgtec.com> wrote:
>>
>>
>> ________________________________
>> From: Keith Randall [k...@google.com]
>> Sent: Tuesday, May 09, 2017 10:17 PM
>> To: Vladimir Stefanovic
>> Cc: golang-dev; Petar Jovanovic
>> Subject: Re: [golang-dev] GOMIPS - new arch-specific environment variable
>>
>>> Sounds reasonable. GOMIPS values of 1 (default), 2, 6. It's new that
>>> the subarch values are mutually incompatible (unlike arm, where they are
>>> only unidirectionally incompatible), but that's life I guess.
>>
>>
>> Great. So, we should use GOMIPS for MIPS-specific options only and use for
>> instance GOFLOAT for soft vs. hard?
>
>

[Petar Jovanovic]

________________________________________
From: Ian Lance Taylor [ia...@golang.org]
Sent: Tuesday, May 23, 2017 1:36 AM
To: Keith Randall
Cc: Petar Jovanovic; Vladimir Stefanovic; golang-dev

Subject: Re: [golang-dev] GOMIPS - new arch-specific environment variable

On Mon, May 15, 2017 at 10:42 AM, 'Keith Randall' via golang-dev

><golan...@googlegroups.com> wrote:
>> Yes, that sounds good to me. We can bikeshed on the GOFLOAT name. Maybe
>> just GOSOFTFLOAT=1, and make hard the default?
>> Other opinions?
> I'm not fond of a generic name like GOSOFTFLOAT that only applies to MIPS.
>
> In particular I note that we currently have GO386 that takes values
> "387" or "sse". I don't see a problem with GOMIPS that takes one or
> more strings that describe specific attributes.

ARMv5 may also want to use GOSOFTFLOAT, hence both MIPS and ARM would
use it. Speaking of which, I believe MIPS's approach to soft-float code
generation is better and ARMv5 could easily switch to that (with trivial
modification, this could be easily done and benchmarked).

Petar

[Ian Lance Taylor]

On Wed, May 24, 2017 at 10:38 AM, Petar Jovanovic
<Petar.J...@imgtec.com> wrote:
> ________________________________________
> From: Ian Lance Taylor [ia...@golang.org]
> Sent: Tuesday, May 23, 2017 1:36 AM
> To: Keith Randall
> Cc: Petar Jovanovic; Vladimir Stefanovic; golang-dev
> Subject: Re: [golang-dev] GOMIPS - new arch-specific environment variable
>
> On Mon, May 15, 2017 at 10:42 AM, 'Keith Randall' via golang-dev
>><golan...@googlegroups.com> wrote:
>>> Yes, that sounds good to me. We can bikeshed on the GOFLOAT name. Maybe
>>> just GOSOFTFLOAT=1, and make hard the default?
>>> Other opinions?
>> I'm not fond of a generic name like GOSOFTFLOAT that only applies to MIPS.
>>
>> In particular I note that we currently have GO386 that takes values
>> "387" or "sse". I don't see a problem with GOMIPS that takes one or
>> more strings that describe specific attributes.
>
> ARMv5 may also want to use GOSOFTFLOAT, hence both MIPS and ARM would
> use it.

I suppose, but no other processors would use it even though
GOSOFTFLOAT appears meaningful for all processors. Given that we
already have GO386 and GOARM, I don't see the advantage to introducing
a new kind of environment variable.

Ian

[vladimir....@imgtec.com]

Ok, so we're back at GOMIPS, holding two comma-separated choices - the instruction set and hard-float/soft-float?

[Brad Fitzpatrick]

Comma-separated would be new. And invites a question about whether GOMIPS=foo,bar is the same as GOMIPS=bar,foo, to which I imagine the answer is no (e.g. the build ID change from yesterday https://go-review.googlesource.com/c/43855/ wouldn't want to normalize GOMIPS). But I'd rather users not even consider that question.

I'd rather see a concrete set of possible values:

   GOMIPS=r1

   GOMIPS=r1soft

   GOMIPS=r2

   GOMIPS=r2soft

   GOMIPS=r6

   GOMIPS=r6soft

Or something like that.

I know nothing about MIPS.

--

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.

[vladimir....@imgtec.com]

For the build ID I suppose the processed value would be used, otherwise even "foo, bar" would be different than "foo,bar".

A few small remarks for the concrete set - a user couldn't set just e.g. soft-float and leave the instruction set at default, but would have to specify both choices.
And if at some point we want to add a third choice, the list of possible values would be multiplied.

Nevertheless, I'm OK with the concrete set.

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

[Brad Fitzpatrick]

Please propose a concrete set, then. Like I said, I don't know MIPS.

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

[vladimir....@imgtec.com]

For example:

   GOMIPS=r1
   GOMIPS=r1sf
   GOMIPS=r2
   GOMIPS=r2sf
   GOMIPS=r6
   GOMIPS=r6sf

[cherry]

On Thu, May 25, 2017 at 3:37 PM, <vladimir....@imgtec.com> wrote:

For the build ID I suppose the processed value would be used, otherwise even "foo, bar" would be different than "foo,bar".

A few small remarks for the concrete set - a user couldn't set just e.g. soft-float and leave the instruction set at default, but would have to specify both choices.

GOMIPS=soft could be accepted, as soft-float with default instruction set.

But I'm not sure whether we need it: if you cross compile, you would specify both, or use the default value for both; if you compile natively, it should do the right thing automatically.

[ra...@develer.com]

Is it possible to agree that the runtime should detect whether the binary is running on a supported architecture, and abort with a clear error message if it doesn't? I think it's very user-unfriendly to create a binary that can potentially crash after minutes or hours (e.g.: when a specific instruction unsupported instruction is hit). I'd rather make sure that the binary refuses to run altogether. I had this problem with GOARM before.

Giovanni

[cherry]

On Thu, May 25, 2017 at 5:25 PM, <ra...@develer.com> wrote:

Is it possible to agree that the runtime should detect whether the binary is running on a supported architecture, and abort with a clear error message if it doesn't? I think it's very user-unfriendly to create a binary that can potentially crash after minutes or hours (e.g.: when a specific instruction unsupported instruction is hit). I'd rather make sure that the binary refuses to run altogether. I had this problem with GOARM before.

I think we detect it for GOARM on Linux, but this is not implemented on BSD and Plan 9. I believe it should be possible for MIPS on Linux (but not sure).

 

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

[v239...@gmail.com]

In case of mips, running a hard-float binary on a machine without FPU raises illegal instruction during the initialization (in runtime.check(), as reported on https://github.com/golang/go/issues/18162).

[vladimir....@imgtec.com]

Yes, let me add GOMIPS=sf, which would mean soft-float and the default instruction set.

   GOMIPS=r1
   GOMIPS=r1sf
   GOMIPS=r2
   GOMIPS=r2sf
   GOMIPS=r6
   GOMIPS=r6sf

   GOMIPS=sf

[Taru Karttunen]

On 26.05 12:18, vladimir....@imgtec.com wrote:
> Yes, let me add GOMIPS=sf, which would mean soft-float and the default
> instruction set.
>
>
> GOMIPS=r1
> GOMIPS=r1sf
> GOMIPS=r2
> GOMIPS=r2sf
> GOMIPS=r6
> GOMIPS=r6sf
> GOMIPS=sf

For what realistic scenarios does it make sense to have GOMIPS=sf?
Also are binaries built with GOMIPS=sf identical (with regards to
checksums etc) to those built with e.g. GOMIPS=r2sf if r2 was the
default subarchitecture? I.e. does it require normalisation of the
GOMIPS values? Also is "sf" better than "soft" or "softfloat"?

- Taru Karttunen

[Giovanni Bajo]

Well, if it were possible to intercept that illegal instruction and change it into a readable message like “this binary requires a MIPS with hard-float”, it would be great.

--

Giovanni Bajo   ::  ra...@develer.com

Develer S.r.l.  ::  http://www.develer.com

Tel: +39-055-3984627 (ext: 206)

Mob: +39-392-9808692

My Blog: http://giovanni.bajo.it

[vladimir....@imgtec.com]

The illegal instruction happens a lot earlier than the signal handler is registered, but probably it can be done.

[vladimir....@imgtec.com]

To spare one having to think about their machine's supported instruction set.
I suppose people are usually aware that their router doesn't have an FPU, but are less familiar with the instruction set it supports.
The binaries built with GOMIPS=sf would be identical with binaries built with GOMIPS=r2sf (if r2 is the default), as 'sf' would be converted into 'r2sf' when validating the input value.
'sf' is just shorter, but 'soft' or 'softfloat' is clearer (and therefore easily better).

[HWJ]

I'd prefer "soft" or "softfloat" over "sf" because

* the variable has a large scope
* "sf" isn't a common abbreviation (afaik)

--

On Mon, May 29, 2017 at 01:14:31PM -0700, vladimir....@imgtec.com wrote:
>To spare one having to think about their machine's supported instruction
>set.
>I suppose people are usually aware that their router doesn't have an FPU,
>but are less familiar with the instruction set it supports.
>The binaries built with GOMIPS=sf would be identical with binaries built
>with GOMIPS=r2sf (if r2 is the default), as 'sf' would be converted into
>'r2sf' when validating the input value.
>'sf' is just shorter, but 'soft' or 'softfloat' is clearer (and therefore
>easily better).
>
>
>On Saturday, May 27, 2017 at 11:50:18 AM UTC+2, Taru Karttunen wrote:
>>

>> On 26.05 12:18, vladimir....@imgtec.com <javascript:> wrote:
>> > Yes, let me add GOMIPS=sf, which would mean soft-float and the default
>> > instruction set.
>> >
>> >
>> > GOMIPS=r1
>> > GOMIPS=r1sf
>> > GOMIPS=r2
>> > GOMIPS=r2sf
>> > GOMIPS=r6
>> > GOMIPS=r6sf
>> > GOMIPS=sf
>>
>> For what realistic scenarios does it make sense to have GOMIPS=sf?
>> Also are binaries built with GOMIPS=sf identical (with regards to
>> checksums etc) to those built with e.g. GOMIPS=r2sf if r2 was the
>> default subarchitecture? I.e. does it require normalisation of the
>> GOMIPS values? Also is "sf" better than "soft" or "softfloat"?
>>
>> - Taru Karttunen
>>
>

[vladimir....@imgtec.com]

I agree; the new list:

GOMIPS=r1
GOMIPS=r1softfloat
GOMIPS=r2
GOMIPS=r2softfloat
GOMIPS=r6
GOMIPS=r6softfloat

Optionally:
GOMIPS=softfloat

[milan.k...@rt-rk.com]

Hello all,

I would like to bring GOMIPS topic to discussion one more time. 

Currently the mips64 softloat patches are under review and they are based on mips implementation, so they reuse GOMIPS environment variable. The other soultion would be introduction of GOMIPS64. Current implementation is sufficient for current needs but there is a few problems that should be noted.

The purpose of GOMIPS is to enable users to choose between softfloat and hardfloat and to select mips release. Currently, only the softfloat/hardfloat options are available, but we are planning to do support for mips32r2. After that the GOMIPS variable should be comma separated (e.g. GOMIPS=r2,hardfloat) as mentioned. 

The problem could be setting of the different default options (when GOMIPS is not specified) for each of architectures because default GOMIPS value would be used for both of them (e.g. default for mips32 could be release 1 and for mips64 release 2).

Another problem could appear when we make support for mips32r2 because then GOMIPS=r2 will be valid value, but on mips64 we could only ignore it because r2 is not supported.

Any thoughts?

Thanks,

Milan

[Austin Clements]

I chatted about this with some of the other compiler folks and we'd lean toward introducing GOMIPS64. None of the other GO$GOARCH variables are overloaded at the moment, so it would be inconsistent to do so here. Given the differing defaults, it also seems less surprising to have two different variables. Also, combining them into a single variable makes it harder for users to set up a standard configuration that makes sense both for building mips and mips64 binaries. For example, if a user sets GOMIPS=softfloat in their environment for building mips binaries, but then they later build a mips64 binary, they probably didn't want to force that binary to use softfloat.

--

[Michael Jones]

perhaps MIPS32 and MIPS64

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.

--

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.

--

Michael T. Jones
michae...@gmail.com

[Keith Randall]

GOMIPS already exists, we probably don't want to rename it.

On Tue, Apr 24, 2018 at 1:44 PM Michael Jones <michae...@gmail.com> wrote:

perhaps MIPS32 and MIPS64

On Tue, Apr 24, 2018 at 1:41 PM, 'Austin Clements' via golang-dev <golan...@googlegroups.com> wrote:

I chatted about this with some of the other compiler folks and we'd lean toward introducing GOMIPS64. None of the other GO$GOARCH variables are overloaded at the moment, so it would be inconsistent to do so here. Given the differing defaults, it also seems less surprising to have two different variables. Also, combining them into a single variable makes it harder for users to set up a standard configuration that makes sense both for building mips and mips64 binaries. For example, if a user sets GOMIPS=softfloat in their environment for building mips binaries, but then they later build a mips64 binary, they probably didn't want to force that binary to use softfloat.

On Tue, Apr 24, 2018 at 12:44 PM <milan.k...@rt-rk.com> wrote:

Hello all,

I would like to bring GOMIPS topic to discussion one more time. 

Currently the mips64 softloat patches are under review and they are based on mips implementation, so they reuse GOMIPS environment variable. The other soultion would be introduction of GOMIPS64. Current implementation is sufficient for current needs but there is a few problems that should be noted.

The purpose of GOMIPS is to enable users to choose between softfloat and hardfloat and to select mips release. Currently, only the softfloat/hardfloat options are available, but we are planning to do support for mips32r2. After that the GOMIPS variable should be comma separated (e.g. GOMIPS=r2,hardfloat) as mentioned. 

The problem could be setting of the different default options (when GOMIPS is not specified) for each of architectures because default GOMIPS value would be used for both of them (e.g. default for mips32 could be release 1 and for mips64 release 2).

Another problem could appear when we make support for mips32r2 because then GOMIPS=r2 will be valid value, but on mips64 we could only ignore it because r2 is not supported.

Any thoughts?

Thanks,

Milan

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

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

--

Michael T. Jones
michae...@gmail.com

--

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.

[Michael Jones]

alas.

On Tue, Apr 24, 2018 at 1:46 PM, Keith Randall <k...@google.com> wrote:

GOMIPS already exists, we probably don't want to rename it.

On Tue, Apr 24, 2018 at 1:44 PM Michael Jones <michae...@gmail.com> wrote:

perhaps MIPS32 and MIPS64

On Tue, Apr 24, 2018 at 1:41 PM, 'Austin Clements' via golang-dev <golan...@googlegroups.com> wrote:

I chatted about this with some of the other compiler folks and we'd lean toward introducing GOMIPS64. None of the other GO$GOARCH variables are overloaded at the moment, so it would be inconsistent to do so here. Given the differing defaults, it also seems less surprising to have two different variables. Also, combining them into a single variable makes it harder for users to set up a standard configuration that makes sense both for building mips and mips64 binaries. For example, if a user sets GOMIPS=softfloat in their environment for building mips binaries, but then they later build a mips64 binary, they probably didn't want to force that binary to use softfloat.

On Tue, Apr 24, 2018 at 12:44 PM <milan.k...@rt-rk.com> wrote:

Hello all,

I would like to bring GOMIPS topic to discussion one more time. 

Currently the mips64 softloat patches are under review and they are based on mips implementation, so they reuse GOMIPS environment variable. The other soultion would be introduction of GOMIPS64. Current implementation is sufficient for current needs but there is a few problems that should be noted.

The purpose of GOMIPS is to enable users to choose between softfloat and hardfloat and to select mips release. Currently, only the softfloat/hardfloat options are available, but we are planning to do support for mips32r2. After that the GOMIPS variable should be comma separated (e.g. GOMIPS=r2,hardfloat) as mentioned. 

The problem could be setting of the different default options (when GOMIPS is not specified) for each of architectures because default GOMIPS value would be used for both of them (e.g. default for mips32 could be release 1 and for mips64 release 2).

Another problem could appear when we make support for mips32r2 because then GOMIPS=r2 will be valid value, but on mips64 we could only ignore it because r2 is not supported.

Any thoughts?

Thanks,

Milan

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

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

--

Michael T. Jones
michae...@gmail.com

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