Thanks for all the comments.
I was just trying to get a general understanding of how this was done now,
if a new instruction set is to be used, and of course I was thinking of the
way it gets done in gcc and binutils. But as a result of the comments
here, I understand there would be no need to add the full instruction set,
but only those that are worthwhile for use by gc in golang, and that is a
different type of implementation. That can be investigated when we are
ready to add them, which is not yet.
As far as the questions about options and switches, I understand your goal
of reducing code complexity and improving maintainability, but for some
features that might be the only way to do the implementation by adding an
option or switch? I'm trying to understand what you mean when you say you
"don't like knobs", if that is the best way to implement a new feature, all
things considered, does that mean you don't implement the feature?
On Tuesday, September 22, 2015 at 6:55:00 PM UTC-5, minux wrote:
On Tue, Sep 22, 2015 at 11:18 AM, Ian Lance Taylor <ia...@golang.org
user can provide the compiler with information that will help it to generate
the best code possible at compile time I think that is a good thing. I
don't understand the downside of having knobs if they are reasonably
implemented and well designed and documented and meaningful defaults are
chosen so that those who don't care if the knobs even exist don't need to
know about them.
The downside is increased testing requirements, code complexity, and
maintenance costs. These costs are bearable, but there needs to be a
Yeah, the current GO386/GOARM (esp the latter) are already causing us
a lot of troubles.
It's highly unlikely that Power 9 introduces an instruction that will be
the compiler enough that the toolchain needs to use the new instruction.
Even the bound checking instructions extension (MPX) which is appealing
at first is probably not worth the trouble to use in the compiler for bound
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 email@example.com.
For more options, visit https://groups.google.com/d/optout.