mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Go in ptxdist
Date: Thu, 6 Oct 2016 11:17:40 +0200	[thread overview]
Message-ID: <20161006091740.ucqtuzagmi5benl7@pengutronix.de> (raw)
In-Reply-To: <20161005204241.GA3454@archie.localdomain>

Hi,

On Wed, Oct 05, 2016 at 10:42:41PM +0200, Clemens Gruber wrote:
> On Wed, Oct 05, 2016 at 06:31:17PM +0200, Michael Olbrich wrote:
> > This description is a bit vague. In general, whether armel or armhf is used
> > does not depend on the ARM architecture, so armel on ARMv7 (and using
> > floating point instructions!) is perfectly valid.
> > We need to investigate if armhf is just the default for ARMv6/7 or if that
> > can be configured.
> 
> Yes, I found more information on this topic:
> 
> $GOARM (for arm only; default is auto-detected if building on the target
> processor, 6 if not)
> This sets the ARM floating point co-processor architecture version the
> run-time should target. If you are compiling on the target system, its
> value will be auto-detected.
> - GOARM=5: use software floating point; when CPU doesn't have VFP
>   co-processor
> - GOARM=6: use VFPv1 only; default if cross compiling; usually ARM11 or
> better cores (VFPv2 or better is also supported)
> - GOARM=7: use VFPv3; usually Cortex-A cores
> 
> See: https://golang.org/doc/install/source#environment
> 
> So we have to use 5 for all softfloat architectures, no matter if they
> are ARMv5, v6 or v7 based.
> So only for ARMv6 and ARMv7 with hardfloat we would use a GOARM value of
> 6 and 7 respectively.
> 
> They also seem to use ARMv7 Data Memory Barrier instructions if GOARM==7
> https://github.com/golang/go/blob/master/src/runtime/asm_arm.s#L716

This is still not clear. 'use VFPv3' does not imply armhf ABI. You can mix
code that uses VFPv3 with code that only uses ARMv5 features, as long as
both use the same ABI (armel). But you cannot mix armel and armhf code.

None of these wiki pages make it really clear, what exactly is generated.
We need to take a closer look once we get there.

> Something else I forgot to mention:
> Since a few releases, Go is implemented in Go (and a little bit of asm)
> and no longer in C, which means, to build Go, you need to bootstrap it
> with a binary Go for your host architecture.
> They do release official Linux binaries for amd64, 386 and armv6l (with
> the l standing for little endian I assume)
> Do you think there are PTXdist users out there who are running it on
> non-amd64 hosts? What host platforms do we have to support?
> 
> Maybe we could also bootstrap it with gccgo (but then we would need a
> toolchain containing a GCC built with --enable-languages=c,c++,go).

I think we can rely on a host Go compiler to build 'our' Go compiler. We do
the same thing with the C compiler and similar things. I think we may want
to add it to 'ptxdist setup' or something like that, so that the user can
specify a defined version.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

  reply	other threads:[~2016-10-06  9:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04 15:23 Clemens Gruber
2016-10-05 13:13 ` Michael Olbrich
2016-10-05 15:55   ` Clemens Gruber
2016-10-05 16:31     ` Michael Olbrich
2016-10-05 20:42       ` Clemens Gruber
2016-10-06  9:17         ` Michael Olbrich [this message]
2016-10-07 16:47           ` Clemens Gruber
2016-10-07 18:37             ` Uwe Kleine-König
2016-10-11 16:18               ` Clemens Gruber
2016-10-12  0:07                 ` Clemens Gruber
2016-10-06  6:33     ` Uwe Kleine-König
2016-10-06 10:04       ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161006091740.ucqtuzagmi5benl7@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox