From: Michael Felt <aixtools@felt.demon.nl>
To: Daniel Shumow <shumow@gmail.com>, Junio C Hamano <gitster@pobox.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
git@vger.kernel.org, "Jeff King" <peff@peff.net>
Subject: Re: Is detecting endianness at compile-time unworkable?
Date: Tue, 31 Jul 2018 12:06:11 +0200 [thread overview]
Message-ID: <599fc1eb-d295-fe63-4d86-168d569c876c@felt.demon.nl> (raw)
In-Reply-To: <CADMpRy7f_Zr7Ay7bU_5eBS+7yO-58EVsEGE0k9qxefS-TO+z8w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3396 bytes --]
I have just replied to
https://github.com/cr-marcstevens/sha1collisiondetection/pull/42
I checked a gcc compiler on AIX, and I have the defines for vac.
I do not have access yet to SLES or RHEL (or Ubuntu), just a "free
Debian" on my Power6.
* my conclusions|recommendations:
a) AIX is always Big Endian, the define _AIX can be used to determine if AIX
b) POWER7 and earlier are always Big Endian
c) assuming lscpu is always available on Linux systems a command (in
configure?) could be used:
root@x074:/usr/bin# lscpu | grep -i endian
Byte Order: Big Endian
d) some linux systems (in any case latest versions of RHEL and SLES
enterprise) should have a file named lparcfg in /proc
(/proc/{powerppc|ppc64|ppc64le|ppc64el}/lparcfg - and it might be in
that file. Need to get onto a (POWER8|POWER9) system to check.
Hope this helps:
details re: define of _AIX
root@x068:[/data/httpd/gcc]gcc -dM -E - < /dev/null | grep AIX | head -1
#define _AIX 1
michael@x071:[/home/michael]/usr/bin/grep -p DEFLT:
/etc/vac.cfg.[567][123] | grep options\
options =
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_IBMR2,-D_POWER
options =
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_IBMR2,-D_POWER
options =
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_AIX71,-D_IBMR2,-D_POWER
options =
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_AIX61,-D_AIX71,-D_AIX72,-D_IBMR2,-D_POWER
michael@x071:[/home/michael]ls /etc/vac.cfg.[567][123]
/etc/vac.cfg.53 /etc/vac.cfg.61 /etc/vac.cfg.71 /etc/vac.cfg.72
On 7/30/2018 8:39 PM, Daniel Shumow wrote:
> The change was definitely made for performance. Removing the if
> statements, conditioned upon endianess was an approx 10% improvement,
> which was very important to getting this library accepted into git.
>
> Thanks,
> Dan
>
>
> On Mon, Jul 30, 2018 at 11:32 AM, Junio C Hamano <gitster@pobox.com
> <mailto:gitster@pobox.com>> wrote:
>
> Junio C Hamano <gitster@pobox.com <mailto:gitster@pobox.com>> writes:
>
> > Ævar Arnfjörð Bjarmason <avarab@gmail.com
> <mailto:avarab@gmail.com>> writes:
> >
> >> And, as an aside, the reason we can't easily make it better
> ourselves is
> >> because the build process for git.git doesn't have a facility
> to run
> >> code to detect this type of stuff (the configure script is always
> >> optional). So we can't just run this test ourselves.
> >
> > It won't help those who cross-compile anyway. I thought we declared
> > "we make a reasonable effort to guess the target endianness from the
> > system header by inspecting usual macros, but will not aim to cover
> > every system on the planet---instead there is a knob to tweak it for
> > those on exotic platforms" last time we discussed this?
>
> Well, having said all that, I do not think I personally mind if
> ./configure learned to include a "compile small program and run it
> to determine byte order on the build machine" as part of "we make a
> reasonable effort" as long as it cleanly excludes cross building
> case (and the result is made overridable just in case we misdetect
> the "cross-ness" of the build).
>
>
[-- Attachment #2: Type: text/html, Size: 5514 bytes --]
next prev parent reply other threads:[~2018-07-31 10:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-29 16:44 git broken for AIX somewhere between 2.13.2 and 2.13.3 Michael
2018-07-29 18:10 ` brian m. carlson
2018-07-29 19:46 ` Michael
2018-07-29 20:05 ` Ævar Arnfjörð Bjarmason
2018-07-29 21:40 ` Andreas Schwab
2018-07-30 6:22 ` Michael
[not found] ` <2309fa7f-c2d8-ee57-aff5-b9e32d2da609@felt.demon.nl>
[not found] ` <20180729192753.GD945730@genre.crustytoothpaste.net>
2018-07-29 19:48 ` Michael
2018-07-29 20:06 ` brian m. carlson
2018-07-29 20:50 ` Michael
2018-07-30 9:39 ` Is detecting endianness at compile-time unworkable? Ævar Arnfjörð Bjarmason
2018-07-30 14:54 ` Junio C Hamano
2018-07-30 18:32 ` Junio C Hamano
2018-07-30 18:39 ` Daniel Shumow
2018-07-31 10:06 ` Michael Felt [this message]
2018-08-01 1:35 ` Eric Wong
2018-08-01 7:16 ` Ævar Arnfjörð Bjarmason
2018-07-31 10:39 ` Michael Felt
2018-08-01 7:31 ` Ævar Arnfjörð Bjarmason
2018-08-02 20:50 ` [PATCH] sha1dc: update from upstream Ævar Arnfjörð Bjarmason
2018-08-02 21:29 ` Michael Felt (aixtools)
2018-08-02 21:32 ` Stefan Beller
2018-07-31 12:32 ` Is detecting endianness at compile-time unworkable? Michael Felt
2018-07-31 14:01 ` Michael Felt
2018-07-31 14:25 ` Ævar Arnfjörð Bjarmason
2018-07-31 20:06 ` Michael
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=599fc1eb-d295-fe63-4d86-168d569c876c@felt.demon.nl \
--to=aixtools@felt.demon.nl \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
--cc=shumow@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).