Generic_64 or nehalem subarch for 64 bit atom?

[its1louder]

I've got an embedded machine with a 4 core atom CPU (C2758  @ 2.40GHz) that I've run reliably with silvermont subarch.  I've not been able to upgrade from 1.3 to 1.4 without significant dependency issues.  I want to convert an old laptop ( Core i5-3317U CPU @ 1.70GHz) to a development machine so I don't have significant downtime on the atom PC.  The idea is I'll keep this old hardware around just for being a compile machine for bleeding edge packages that I'll then distribute out as a stage 4 tarball to upgrade and then continue upkeep with qpkg.  I originally meant to just go with generic subarch and use this old laptop to serve out to the atom machine as well as some other machines that I don't want to be down for long. but as I went to get the generic_64 stage 3 I read on the webpage how the generic64 was discouraged and you should really use a nehalem stage 3 since it is good for all post 2009 intel CPUs and most recent AMD cpus.  Does this include atom processors?  I'm assuming generic_64 is truly generic for all x86_64, atom core or whatever.  I'm not sure this istrue for the nehalem stage despite what the subarch page implies.

PS I know my compile machine is slower than my target machine and this seems perverse.  But compile time is not a huge issue it's downtime on the target that is a problem.  Also due to Covid, I can't get in to touch my target machine right now, I have to just use what I've got on hand.

  target cpuino:

processor	: 7
vendor_id	: GenuineIntel
cpu family	: 6
model		: 77
model name	: Intel(R) Atom(TM) CPU  C2758  @ 2.40GHz
stepping	: 8
microcode	: 0x127
cpu MHz		: 1200.000
cache size	: 1024 KB
physical id	: 0
siblings	: 8
core id		: 7
cpu cores	: 8
apicid		: 14
initial apicid	: 14
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb kaiser tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm arat
bugs		: cpu_meltdown spectre_v1 spectre_v2
bogomips	: 4800.23
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

compiler cpuinfo:

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 58
model name	: Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz
stepping	: 9
microcode	: 0x15
cpu MHz		: 807.188
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 2
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips	: 3392.34
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

 

[cardinal]

 

Don't use a subarch that includes CPU_FLAGS that are not supported by the CPU of the target hardware(intel64-silvermont) or compiler(intel64-ivybridge).

Reference the Funtoo CPU Guide to find it's subarch, then go to the subarch download page to find it's CPU_FLAGS.

Reference intel64-nehalem subarch download page to find it's CPU_FLAGS.

The atom(silvermont) cpu and the i5(ivybridge) cpu support all the CPU_FLAGS in the intel64-nehalem subarch.

Yes, you could use the intel-nehalem subarch on the i5 to build software for the atom.

It would be a problem if you are building to run on an older CPU that doesn't support all the nehalem CPU_FLAGS.

If you are only building packages for the atom then use intel64-silvermont on the i5 . 

Don't use intel64-ivybridge subarch on the i5 to build packages for atom because the atom doesn't have avx.

generic_64 :                                              mmx mmxext sse sse2

intel64-nehalem :                                    mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

intel64-silvermont:     aes mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

intel64-ivybridge:  aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

 

Edited July 4, 2020 by cardinal

[its1louder]

Thank you Cardinal, You have confirmed what I guessed based on that notice on the generic page.  You are saying that the only difference between the different subarches is the cpuflags, I wasn't sure if that was true or if there was something else beyond that.  Like I thought atom was a more radically different CPU type from the pentium/core types.  I guess I'm not sure what is meant to convey by the atom brand. 

In the end, I went ahead with generic gnome, because what I'm really trying to do is make my own personal binary metadistribution (including my overlay for some obscure stuff I need) and I wanted to be as general as possible and support whatever non-arm hardware I may have.  But I understand now I should have chosen nehalem subarch (if I want to support a couple of old core2 minipcs I have in addition to the silvermont one).  I may try to change the subarch profile and emerge -e the system at some point, but not now.