Re: [gentoo-dev] Profile-enforced big-endian USE flag

[Joshua Kinard]

On 06/28/2017 18:29, James Le Cuirot wrote:
> On Wed, 28 Jun 2017 17:52:26 -0400
> Mike Gilbert  wrote:
> 
>> On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot  wrote:
>>> I am therefore proposing a new global big-endian flag. This could be
>>> masked by default and unmasked + forced in the relevant profiles under
>>> arch. I will apply this according to the mapping defined in tc-endian of
>>> toolchain-funcs.eclass.  
> 
> I've just been putting the patch together. I made it slightly simpler
> by masking *and* forcing it by default so that it only needs to be
> unmasked were necessary.
> 
>> A possible alternative would be to create a new USE_EXPAND variable
>> for this. That would allow for easier expansion in case we ever
>> support something other than big/little endian machines.
> 
> That way madness lies? Wikipedia talks about middle-endian as being the
> catch all for other random orderings that have appeared over the years
> but I don't think any of them were used on a system-wide basis. I can't
> imagine Linux ever supporting such a thing. Unless you're talking about
> dealing with soft vs hard float here too?

As far as I know, Linux only supports big-endian and little-endian systems,
along with supporting a fairly-wide variety of platforms and architectures,
beaten really only by NetBSD.  If NetBSD lacks anything for middle-endian, then
it's probably safe to ignore it.

That said, Wikipedia doesn't offer much on the nature of middle-endian (which
is called "PDP-endian"), except to state that "The ARM architecture can also
produce this format when writing a 32-bit word to an address 2 bytes from a
32-bit word alignment."
https://en.wikipedia.org/wiki/Endianness#Middle

And this resource:
http://unixpapa.com/incnote/byteorder.html

Recommends to ignore middle-endian, as it believes no processor was ever
implemented that stored integers in middle-endian format.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Profile-enforced big-endian USE flag

[Mike Gilbert]

On Wed, Jun 28, 2017 at 6:29 PM, James Le Cuirot  wrote:
> On Wed, 28 Jun 2017 17:52:26 -0400
> Mike Gilbert  wrote:
>
>> On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot  wrote:
>> > I am therefore proposing a new global big-endian flag. This could be
>> > masked by default and unmasked + forced in the relevant profiles under
>> > arch. I will apply this according to the mapping defined in tc-endian of
>> > toolchain-funcs.eclass.
>
> I've just been putting the patch together. I made it slightly simpler
> by masking *and* forcing it by default so that it only needs to be
> unmasked were necessary.
>
>> A possible alternative would be to create a new USE_EXPAND variable
>> for this. That would allow for easier expansion in case we ever
>> support something other than big/little endian machines.
>
> That way madness lies? Wikipedia talks about middle-endian as being the
> catch all for other random orderings that have appeared over the years
> but I don't think any of them were used on a system-wide basis. I can't
> imagine Linux ever supporting such a thing. Unless you're talking about
> dealing with soft vs hard float here too?

No, I'm not referring to anything specifically. Just wanted to point
out the possibility of having a multi-value variable instead of a
boolean.

If that seems very un-useful, please disregard.

Re: [gentoo-dev] Profile-enforced big-endian USE flag

[Gordon Pettey]

On Wed, Jun 28, 2017 at 5:29 PM, James Le Cuirot  wrote:

> On Wed, 28 Jun 2017 17:52:26 -0400
> Mike Gilbert  wrote:
>
> > On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot 
> wrote:
> > > I am therefore proposing a new global big-endian flag. This could be
> > > masked by default and unmasked + forced in the relevant profiles under
> > > arch. I will apply this according to the mapping defined in tc-endian
> of
> > > toolchain-funcs.eclass.
>
> I've just been putting the patch together. I made it slightly simpler
> by masking *and* forcing it by default so that it only needs to be
> unmasked were necessary.
>
> > A possible alternative would be to create a new USE_EXPAND variable
> > for this. That would allow for easier expansion in case we ever
> > support something other than big/little endian machines.
>
> That way madness lies? Wikipedia talks about middle-endian as being the
> catch all for other random orderings that have appeared over the years
> but I don't think any of them were used on a system-wide basis. I can't
> imagine Linux ever supporting such a thing. Unless you're talking about
> dealing with soft vs hard float here too?

So I can't ever expect support for littler-endian, giant-endian,
shrinking-endian, and chaos-endian?

Re: [gentoo-dev] Profile-enforced big-endian USE flag

[James Le Cuirot]

On Wed, 28 Jun 2017 17:52:26 -0400
Mike Gilbert  wrote:

> On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot  wrote:
> > I am therefore proposing a new global big-endian flag. This could be
> > masked by default and unmasked + forced in the relevant profiles under
> > arch. I will apply this according to the mapping defined in tc-endian of
> > toolchain-funcs.eclass.  

I've just been putting the patch together. I made it slightly simpler
by masking *and* forcing it by default so that it only needs to be
unmasked were necessary.

> A possible alternative would be to create a new USE_EXPAND variable
> for this. That would allow for easier expansion in case we ever
> support something other than big/little endian machines.

That way madness lies? Wikipedia talks about middle-endian as being the
catch all for other random orderings that have appeared over the years
but I don't think any of them were used on a system-wide basis. I can't
imagine Linux ever supporting such a thing. Unless you're talking about
dealing with soft vs hard float here too?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpPckculHDJL.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Profile-enforced big-endian USE flag

[Mike Gilbert]

On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot  wrote:
> I am therefore proposing a new global big-endian flag. This could be
> masked by default and unmasked + forced in the relevant profiles under
> arch. I will apply this according to the mapping defined in tc-endian of
> toolchain-funcs.eclass.

A possible alternative would be to create a new USE_EXPAND variable
for this. That would allow for easier expansion in case we ever
support something other than big/little endian machines.

[gentoo-dev] Profile-enforced big-endian USE flag

[James Le Cuirot]

Hello devs,

I'm currently adding ppc64le to the list of platforms supported by
icedtea-bin before we lose gcj to save me fudging around later. This
addition presents a small problem.

I currently use the ARCH (e.g. amd64) and ABI (e.g. abi_x86_32) USE
flags to fetch the relevant tarballs. The trouble is that there is no
flag that decides the endianness. Both ppc64 and ppc64le share the
"ppc64" ARCH and ABI. The only differing element between the two
profiles is CHOST, which starts with powerpc64- and powerpc64le-
respectively.

This is sufficient when dealing with multilib-enabled source ebuilds.
As far as I know, there is no such as thing as a mixed endian system on
any architecture. They require different kernels. If a package doesn't
work on one endian type, it can simply be masked in that profile.

However, when dealing with binary ebuilds, you ideally want to split
the different platforms into separate tarballs to reduce the download
size. The platform-specific tarballs for icedtea-bin:8 currently weigh
around 55MB each. It would be polite not to double this for ppc64. You
can't use CHOST in SRC_URI so a new USE flag is the only way.

I am therefore proposing a new global big-endian flag. This could be
masked by default and unmasked + forced in the relevant profiles under
arch. I will apply this according to the mapping defined in tc-endian of
toolchain-funcs.eclass.

There is just one package already this flag, dev-haskell/skein. I don't
believe it would need to change though it might want to hard enable the
force-endianness option or at least enable it by default. On the other
hand, using tc-endian may be a better option here.

If we're broadly agreed then I will submit a patch for review.

On a side note, this problem also applies to soft vs hard float except
that these can be mixed under the same kernel. We don't have profiles
for these though and soft float seems to be a relic now anyway, at
least on ARM.

Cheers,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpd5ujrDlhPv.pgp
Description: OpenPGP digital signature