-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
09.07.2014 20:10, Manuel Rüger ?????:
> On 07/09/2014 01:40 PM, Anthony G. Basile wrote:
>> On 07/09/14 05:09, Joshua Kinard wrote:
>>> On 07/08/2014 21:48, Matthew Thode wrote:
>>>> arm has a historical problem with stabilization, while keywording
>>>> doesn't require access to all arm sub-arches the problem with the
>>>> stabilization slowness causes running a full ~arm to become hard. By
>>>> that I mean that if someone keywords something for arm because it works
>>>> on armv7 and I run ~arm because stabilization takes forever then my
>>>> system may break because of both non-stabilized packages and because I
>>>> could be running armv6.
>>>>
>>>> In any case I propose splitting out arm into armv4, armv5, armv6 and
>>>> armv7. armv8 seems to be here already as arm64.
>>> Couldn't this be better handled with some profile work? These sound
like
>>> versions of Instruction Set Architectures. In the MIPS world, you
>>> have your
>>> original ISAs, mips1 through mips4, then you have the newer variants of
>>> mips32r* (branches from mips2) and mips64r* (branches from mips4).
>>> Anything
>>> supporting mips4 could also support earlier ISAs. Throw in our three
>>> supported ABIs (o32, n32, n64), and machine-specific curiosities (SGI,
>>> Cobalt, Yeelong/Loongson, etc), and life can be quite fun. But we can
>>> cover
>>> all of this with just a single 'mips' keyword in the tree.
>>
>> Yes, this should be done via the profiles. Code requiring later ISAs
>> and/or with extensions like thumb and neon will probably break on lower
>> ISAs. These should be masked on the profiles.
>>
>>> Is that similar to how these ARM variants work? Can an armv7 run code
>>> for
>>> armv6 and earlier?
>>
>> Its a bit more complicated that MIPS. You can test for yourself. I did
>> this via a chromebook (cortex-a15) using my hardened stages
>> (march=armv7a) available at <mirror>/experimental/arm/hardened, so you
>> can test too:
>>
>> chrome ~ # echo "int main() { return 0; }" > test.c
>> chrome ~ # gcc -march=armv7-a -o test test.c
>> chrome ~ # gcc -march=armv6 -o test test.c
>> chrome ~ # gcc -march=armv5 -o test test.c
>> chrome ~ # gcc -march=armv4 -o test test.c
>> chrome ~ # gcc -march=armv3 -o test test.c
>> /tmp/ccZjsI2O.s: Assembler messages:
>> /tmp/ccZjsI2O.s:45: Error: selected processor does not support ARM mode
>> `bx lr'
>> chrome ~ # gcc -march=armv3m -o test test.c
>> /tmp/cc1o59kQ.s: Assembler messages:
>> /tmp/cc1o59kQ.s:45: Error: selected processor does not support ARM mode
>> `bx lr'
>> chrome ~ # gcc -march=armv2 -o test test.c
>> /tmp/ccmTNSyh.s: Assembler messages:
>> /tmp/ccmTNSyh.s:45: Error: selected processor does not support ARM mode
>> `bx lr'
>> chrome ~ # gcc -march=armv2a -o test test.c
>> /tmp/ccTIXZ46.s: Assembler messages:
>> /tmp/ccTIXZ46.s:45: Error: selected processor does not support ARM mode
>> `bx lr'
>> chrome ~ # gcc --version
>> gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There
is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
>>
>>
>> So it looks like gcc can emit compat code back to armv4. This doesn't
>> necessarily mean that armv2 code won't run on an armv7a, but that
>> gcc-4.7.3-r1 can't produce such code, which is sufficient for our
>> purposes of masking.
>>
>>
>>>
>>> Splitting 'arm' into four new keywords, on top of 'arm64' is just
>>> going to
>>> give you guys major headaches later. You might even consider
>>> dedicated USE
>>> flags for the arm subvariants and use those to control things in an
>>> ebuild
>>> where applicable.
>>
>> arm64 might as well be a totally different arch. There is no
>> compatibility between 32-bit and 64-bit arm variants --- at least not
>> that I know of, its a new arch that I'm just now getting familiar with.
>> On the other hand ppc and ppc64 should never have been split, but that's
>> another story.
>>
>> We do not want keywords for every subarch otherwise we'll go crazy
>> stabilizing. We could adopt a policy of stabilizing on armv7a and when
>> a package doesn't build on a lower ISA, just mask it in the profiles.
>>
>>>
>>>> I think this would be beneficial because of not all developers that
want
>>>> to help with arm have or what all the sub-arches necessary. It also
>>>> allows us to move faster on stabilization because most of us have
access
>>>> to armv7 a bit easier. This would take some pressure off of the people
>>>> doing stabilization for older sub-arches, but not much.
>>> What's the support status of Gentoo on the older variants, such as
>>> armv4 and
>>> armv5 stuff? How fast is the CPU clock on those? Do they include L2/L3
>>> cache? Lots of memory? Generally, anything that could be a
>>> bottleneck or
>>> severely increase the build time should be weighed against the potential
>>> number of users and possibly support dropped if there aren't enough
>>> developers or contributing users to maintain it.
>>>
>>> I.e., w/ MIPS, we don't support anything under the mips3 ISA, which
>>> includes
>>> DECStations (Debian does support those). Build times would just be
>>> tremendously slow and I haven't seen a lot of desire to support those.
>>>
>>
>> Regarding MIPS, this isn't totally true. I'm willing to support mips-I
>> for embedded systems, although right now I'm just doing mipsel3 and
>> mip32r2. I used to have mips-I big endian uclibc stages. Also, you
>> don't have to hit slow build times because you can build mips-I on any
>> mips system of the same endianness.
>>
>>
>
> I think arm64 is getting keyworded using qemu, because nobody owns any
> hardware yet. Can't we use qemu for armv5, too?
> You won't need any additional hardware to handle stabilization. Just
> test on armv7 hw and in your qemu instance.
>
>
> Cheers
>
> Manuel
>
no, it uses armv8-fast-mode, i am have emul image and make some
experiments with keywording for future keywording in the tree.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iJwEAQECAAYFAlO9cxoACgkQG9wOWsQutdZqdwQAnereSwnPoOf6/9OT/52VtCH6
unAiqToMkK97RJRS7gBVlGP7M3mK+HfEeNcGanEVQFiKhvuRuQ1EgTSAdhxnR0xp
c0F50IlIx1gVaKsWuRjR5Eka0LsLmMoSyMe26Ved4jJjzXgb+tJpMGt8Krr7kgOn
RhUbQh1+uiPW9bHnC4g=
=wWUs
-----END PGP SIGNATURE-----
