git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Daniel Gurney <dgurney99@gmail.com>,
	git@vger.kernel.org, Sebastian Schuberth <sschuberth@gmail.com>
Subject: Re: [PATCH] compat/bswap.h: detect ARM64 when using MSVC
Date: Tue, 10 Nov 2020 23:38:50 +0000	[thread overview]
Message-ID: <20201110233850.GJ6252@camp.crustytoothpaste.net> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2011101418550.18437@tvgsbejvaqbjf.bet>

[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]

On 2020-11-10 at 13:58:21, Johannes Schindelin wrote:

> The biggest question now is: are we certain that `_M_ARM64` implies
> little-endian?

For Windows?  Yes.  I'm almost certain Windows has only supported
little-endian architectures, possibly with the exception of gaming
consoles.

> I remember that ARM (the 32-bit variety, that is) has support for
> switching endianness on the fly. Happily, MSVC talks specifically about
> _not_ supporting that:
> https://docs.microsoft.com/en-us/cpp/build/overview-of-arm-abi-conventions
> 
> Likewise, it says the same about ARM64 (mentioning that it would be much
> harder to switch endianness there to begin with):
> https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions
> 
> So does that make us confident that we can just add that `_M_ARM64` part?
> Yes. Does it make me confident that we can just drop all of the
> architecture-dependent conditions? No, it does not. There _were_ versions
> of MSVC that could compile code for PowerPC, for example, which _is_
> big-endian.

PowerPC can actually be either.  Most 64-bit PowerPC machines these days
are run as little endian, and Windows has always run it in little-endian
mode.  Macs ran it in big-endian mode.

> > As far as I know, Windows has always run on little-endian hardware.
> 
> I think that depends on your point of view... IIRC an early version of
> Windows NT (or was it still VMS Plus?) ran on DEC Alpha, which I seem to
> _vaguely_ remember was big-endian.

Alpha appears to have supported both, but as far as I know, both Windows
and Linux used it in little-endian mode.

> > [0] Wikipedia does not specify the endiannesses supported by the MIPS
> > edition.
> 
> I have another vague memory about MIPS (a wonderful SGI machine I had the
> pleasure of banging my head against, for lack of Python support and Git
> requiring Python back then) being big-endian, too.

Another architecture that supports both endiannesses.  Debian supports
both, but I believe Windows only supported the little-endian version.  I
have a small MIPS board that uses the little endian port for Debian.

> Short version: while I managed to convince myself that _currently_ there
> are no big-endian platforms that we can support via MSVC, I would like to
> stay within the boundaries of caution and _not_ drop those `defined(_M_*)`
> parts.

While I'm confident in my statements, you're the relevant subsystem
maintainer here, so I'm happy to defer to your judgment.  I think Junio
can just pick up the earlier patch version and we should be good to go,
since that patch seemed to meet everyone's needs.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

      parent reply	other threads:[~2020-11-10 23:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-07 22:19 [PATCH] compat/bswap.h: detect ARM64 when using MSVC Daniel Gurney
2020-11-07 22:47 ` brian m. carlson
2020-11-07 23:23   ` Daniel Gurney
2020-11-10 13:58   ` Johannes Schindelin
2020-11-10 16:44     ` Sebastian Schuberth
2020-11-10 23:38     ` brian m. carlson [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20201110233850.GJ6252@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=dgurney99@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sschuberth@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).