Re: [gentoo-dev] CPU_FLAGS_X86 gentoo repository migration complete
On Sun, Feb 1, 2015 at 3:28 PM, Zac Medico wrote: > On 02/01/2015 02:39 PM, Matt Turner wrote: >> On Sun, Feb 1, 2015 at 2:17 PM, Michał Górny wrote: >>> 2. app-emulation/bochs got local USE=3dnow and USE=avx since the flag >>> control support of emulating the two instruction sets rather than using >>> host CPU instruction sets. >> >> Wouldn't it be simpler to use CPU_FLAGS_X86 for these and simply >> disable the emulation code if they're set? That seems better to me. > > CPU_FLAGS is intended to control which machine code instructions are > allowed to be used in the compiled executables. If we use it for > anything else that does not fit this precise definition, then it will be > inconsistent and lead to confusion. I'd interpreted Michał's statement to mean that bochs would support 3DNow/AVX regardless and that the flag simply determined whether it used the CPU's native support or built emulation code. Looking at the code, I don't believe that is the case. It appears that the flag simply determines whether bochs can execute those instructions at all.
Re: [gentoo-dev] CPU_FLAGS_X86 gentoo repository migration complete
On 01.02.2015 23:17, Michał Górny wrote: > Hi, developers. > > Just a quick note: the CPU_FLAGS_X86 conversion of the Gentoo > repository is complete now. Cool! Thanks for fixing the freeverb3 ebuild, too. Best, Sebastian
Re: [gentoo-dev] CPU_FLAGS_X86 gentoo repository migration complete
On 02/01/2015 02:39 PM, Matt Turner wrote: > On Sun, Feb 1, 2015 at 2:17 PM, Michał Górny wrote: >> 2. app-emulation/bochs got local USE=3dnow and USE=avx since the flag >> control support of emulating the two instruction sets rather than using >> host CPU instruction sets. > > Wouldn't it be simpler to use CPU_FLAGS_X86 for these and simply > disable the emulation code if they're set? That seems better to me. CPU_FLAGS is intended to control which machine code instructions are allowed to be used in the compiled executables. If we use it for anything else that does not fit this precise definition, then it will be inconsistent and lead to confusion. -- Thanks, Zac
Re: [gentoo-dev] CPU_FLAGS_X86 gentoo repository migration complete
Dnia 2015-02-01, o godz. 14:39:30 Matt Turner napisał(a): > On Sun, Feb 1, 2015 at 2:17 PM, Michał Górny wrote: > > 2. app-emulation/bochs got local USE=3dnow and USE=avx since the flag > > control support of emulating the two instruction sets rather than using > > host CPU instruction sets. > > Wouldn't it be simpler to use CPU_FLAGS_X86 for these and simply > disable the emulation code if they're set? That seems better to me. To be honest, I don't know how this works exactly, but I'd suspect that disabling the options will cause the emulated CPU not to have those instructions at all. -- Best regards, Michał Górny pgpTQQrEal1P4.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] CPU_FLAGS_X86 gentoo repository migration complete
On Sun, Feb 1, 2015 at 2:17 PM, Michał Górny wrote: > 2. app-emulation/bochs got local USE=3dnow and USE=avx since the flag > control support of emulating the two instruction sets rather than using > host CPU instruction sets. Wouldn't it be simpler to use CPU_FLAGS_X86 for these and simply disable the emulation code if they're set? That seems better to me.
[gentoo-dev] CPU_FLAGS_X86 gentoo repository migration complete
Hi, developers. Just a quick note: the CPU_FLAGS_X86 conversion of the Gentoo repository is complete now. More specifically: 1. all packages (except app-emulation/bochs) use new CPU_FLAGS_X86 flags. Whenever appropriate, the used flags were fixed to match common naming. 2. app-emulation/bochs got local USE=3dnow and USE=avx since the flag control support of emulating the two instruction sets rather than using host CPU instruction sets. 3. Global definitions of old USE flags were removed to make sure repoman will complain when someone mistakenly tries to use them. This hopefully will help getting overlays in shape. If someone wants a bit of a challenge, I've assembled list of packages potentially using old flags in overlays [1], grouped by layman overlay name. I will probably start mailing the overlay owners or filing bugs myself in a few days, after my initial overlay QA runs are done. At this point, I think we can also start discussing introducing CPU_FLAGS_* for other architectures. [1]:http://dev.gentoo.org/~mgorny/tmp/cpuflags-in-overlays.txt -- Best regards, Michał Górny pgpaRjd9J9vr9.pgp Description: OpenPGP digital signature