On Tue, Jan 20, 2015 at 2:17 PM, Christopher Head wrote:
> On January 20, 2015 12:47:03 AM PST, Alexis Ballier
> wrote:
> >So, you're telling me that if you have a list of 90 cpu extensions, you
> >will from time to time open that list to see if there is a 91st one
> >added ? I think most people
On Tue, 20 Jan 2015 12:17:35 -0800 Christopher Head wrote:
> On January 20, 2015 12:47:03 AM PST, Alexis Ballier
> wrote:
> >So, you're telling me that if you have a list of 90 cpu extensions, you
> >will from time to time open that list to see if there is a 91st one
> >added ? I think most peopl
On January 20, 2015 12:47:03 AM PST, Alexis Ballier wrote:
>So, you're telling me that if you have a list of 90 cpu extensions, you
>will from time to time open that list to see if there is a 91st one
>added ? I think most people won't even notice, at best they'll look for
>the changelog.
No, act
On Tue, 20 Jan 2015 00:29:22 -0800
Christopher Head wrote:
> On Tue, 20 Jan 2015 09:21:54 +0100
> Alexis Ballier wrote:
>
> > you will not see it if no package use it.
>
> I guess you mean I wouldn’t see it in emerge output if no package uses
> it, even if it is USE-expanded? Yes, I’m aware of
On Tue, 20 Jan 2015 09:21:54 +0100
Alexis Ballier wrote:
> you will not see it if no package use it.
I guess you mean I wouldn’t see it in emerge output if no package uses
it, even if it is USE-expanded? Yes, I’m aware of that. But if all the
flags are listed together in one place (I forget what
On Mon, 19 Jan 2015 23:43:19 -0800
Christopher Head wrote:
> On Wed, 14 Jan 2015 11:01:16 -0800
> Zac Medico wrote:
>
> > Why should we have to foresee the future? We can easily add support
> > for new flags in CPU_FLAGS_* variables at any time.
>
> Ah, what I meant was that whoever maintains
On Wed, 14 Jan 2015 11:01:16 -0800
Zac Medico wrote:
> Why should we have to foresee the future? We can easily add support
> for new flags in CPU_FLAGS_* variables at any time.
Ah, what I meant was that whoever maintains this flag list only needs
to forsee the present—when AMD or Intel adds a ne
On Wed, 14 Jan 2015 21:59:37 +0100
"Andreas K. Huettel" wrote:
> That said, long time ago I was taught that "instruction set
> use-flags" should be avoided as much as possible. I don't remember
> the source for that anymore.
>
> Question to all, is that documented anywhere, and what are the
> s
On Wed, 14 Jan 2015 12:58:21 +0100
Michał Górny wrote:
> Solution: per-arch USE_EXPANDs for flags, e.g.:
>
> CPU_FLAGS_X86="3dnow 3dnowext avx ..."
> CPU_FLAGS_ARM="neon ..." # arm* flags?
> CPU_FLAGS_MIPS="..." # mips* flags?
>
> Any specific comments? I can handle x86 but I'd appreciate
Am Mittwoch, 14. Januar 2015, 12:58:21 schrieb Michał Górny:
>
> Solution: per-arch USE_EXPANDs for flags, e.g.:
>
> CPU_FLAGS_X86="3dnow 3dnowext avx ..."
> CPU_FLAGS_ARM="neon ..." # arm* flags?
> CPU_FLAGS_MIPS="..." # mips* flags?
>
I like it, because it standardizes and removes cause
On 01/14/2015 09:55 AM, Christopher Head wrote:
> On January 14, 2015 7:16:46 AM PST, Alexis Ballier
> wrote:
>> however, i disagree with your rationale: asm for specific cpu
>> extensions tend to be written and tested after given cpu is available,
>> thus if you have a brand new cpu, you want to
On 01/14/2015 10:28 AM, Anthony G. Basile wrote:
> Would this approach clean up some of the masking? Eg. I hate having to
> mask sse and friends in base/use.mask and then unmask them in
> arch/amd64/use.mask. I'm not sure if there's a technique to make a use
> expand flags relevant only for a par
On 01/14/15 10:16, Alexis Ballier wrote:
On Wed, 14 Jan 2015 12:58:21 +0100
Michał Górny wrote:
Any specific comments? I can handle x86 but I'd appreciate specific
arch teams replying about more exotic arches.
+1
i like the idea, but with a list of useflags that would get converted
this coul
On January 14, 2015 7:16:46 AM PST, Alexis Ballier wrote:
>however, i disagree with your rationale: asm for specific cpu
>extensions tend to be written and tested after given cpu is available,
>thus if you have a brand new cpu, you want to be notified if a package
>gains support for this new instr
On Wed, 14 Jan 2015 12:58:21 +0100
Michał Górny wrote:
> Any specific comments? I can handle x86 but I'd appreciate specific
> arch teams replying about more exotic arches.
+1
i like the idea, but with a list of useflags that would get converted
this could "reach" more people i think
profiles/
Hi,
I think this has been discussed already [1] but in the end never was
applied or even finished discussing. So I'd like to revive the topic
and apply the necessary changes in a few days if nobody objects
strongly.
Rationale: we have a growing number of CPU-corresponding flags that all
are fit a
16 matches
Mail list logo
