On Monday 21 October 2013 14:48:11 Stephan Kulow wrote:

On 21.10.2013 14:44, Sascha Peilicke wrote:

...

Hi guys,

without checking any mail archives, our forums or wikis for prior art, I would like to know if we have any general hardware support statements. I'm currently staring at a maintenance update that disables SSE2 support on certain software because the CPU doesn't support it. The manufacturing of that CPU stopped in 2004, so I'm not really sure what to think of it. Any thoughts?

Our documentation says - I bet it was updated last time 2004 ;)

1.2. System Requirements¶ Pentium* III 500 MHz or higher processor (Pentium 4 2.4 GHz or higheror any AMD64 or Intel* EM64T processor recommended)

Well, it's an AMD K7 [0] and actually matches these requirements :-) [0] http://www.cpu-world.com/CPUs/K7/AMD-Duron%201800%20-%20DHD1800DLV1C.html -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

On Tuesday 2013-10-22 16:24, Jan Engelhardt wrote:

Where I see problems:

1. software that inserts -march=native into the command line after our CFLAGS 2. software that inserts -mmmx, -msse/2/3, -mavx unconditionally 3. openSUSE prjconf lacks specifying -mno-mmx, -mno-sse etc. (but so far we have not needed that) 4. software that runs SSE assembler lines without checking CPUID [...] In case #4, which occurs at times, such as in /games/zdbsp[...] we just disable MMX/SSE/etc. for i586.

Everybody note that this is not a problem specific to i586. x86_64 only specifies the set of {MMX,SSE,SSE2}. Once software pops up that unconditionally includes or runs AVX, FM3/FM4, you will eventually have to write %configure \ %ifarch x86_64 %ix86 --disable-avx %endif It is not even limited to x86ish. Think %configure \ %ifarch sparc64 --disable-vis3 # T4 and up %endif %configure \ %ifarch ppc ppc64 --disable-vsx # POWER7 and up %endif (or make a cpuid-testing patch). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2013-10-22 17:14, Joerg Schilling wrote:

Is there nothing like isainfo in Linux?

isainfo -v 64-bit amd64 applications xsave sse4.1 ssse3 cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu 32-bit i386 applications xsave sse4.1 ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu

We have /proc/cpuinfo. But how does that relate to the compilation of programs? 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 eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2013-10-22 18:06, Joerg Schilling wrote:

Jan Engelhardt wrote:

...

On Tuesday 2013-10-22 17:14, Joerg Schilling wrote:

...

Is there nothing like isainfo in Linux?

We have /proc/cpuinfo. But how does that relate to the compilation of programs?

Well, when you comppile, you could use:

-xarch=generic to go back to a minimum set -xarch=native to use everything the current CPU supports - something special handrafted.

We must always compile with the minimum set because we do not know what the target machine will be like. gcc -march=i586 does that (for openSUSE's definition of "minimum"). But as portrayed in previous mails, compiler switches don't help if you have a __asm__("pmovsomething %xmmwhatever..."); or equivalent.

libc is mounted to the best fit libc compile variant for performance reasons. BTW: this appeared in 1997, when 64 bit support was added to Solaris.

In glibc, all the accelerated codes live within (the one) libc.so, and ld.so resolves symbols like strchr to __strchr_sse2 / __strchr_sse42 at program startup through a mechanism that is known as ifunc. That means we do not have to provide the computationally boring parts of libc — such as stdio, which provides one of the largest functions according to readelf — more than once like it would be the case for multiple libc.so files. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

<sarcasm> so where i can download this awesome operating system solaris for free, oh i can not? Shame on me i wanna use free (libre) opensource software. I assume windows is also better... oh no source either aaah... Windows and Solaris FTW in actual lingua... </sarcasm> I understand you have direct monetary benefit from Oracle or who ever but if you do not wanna help people/ do not wanna really provide constructive conversations please don't bother answering this email either. Saying Solaris is better than minix / linux / *BSD and we should use it IS NOT CONSTRUCTIVE... I do not mind you write CDDL code for external software (which i do not mind you do and it is good software mki... cdre... and so on) *BUT* Try to be constructive and write or bugfix code even if it is god forbid written with/in GPL. Rants about linux vs solaris way .... really you are older than that Or just enjoy life it is free (for most parts) -- Boris On Wed, Oct 23, 2013 at 12:23 PM, Joerg Schilling wrote:

Jan Engelhardt wrote:

...

We must always compile with the minimum set because we do not know what the target machine will be like. gcc -march=i586 does that (for openSUSE's definition of "minimum").

Correct. A useful minimum default would be a pentium with no fdiv bug.

...

But as portrayed in previous mails, compiler switches don't help if you have a __asm__("pmovsomething %xmmwhatever..."); or equivalent.

This is a general problem with the quality of OSS.

The opcode is not the only problem here, another problem is the assumtion that some vendor-specific non-standard C enhancements may be used with the systems compiler.

...

...

libc is mounted to the best fit libc compile variant for performance reasons. BTW: this appeared in 1997, when 64 bit support was added to Solaris.

In glibc, all the accelerated codes live within (the one) libc.so, and ld.so resolves symbols like strchr to __strchr_sse2 / __strchr_sse42 at program startup through a mechanism that is known as ifunc. That means we do not have to provide the computationally boring parts of libc ??? such as stdio, which provides one of the largest functions according to readelf ??? more than once like it would be the case for multiple libc.so files.

Well if you believe that disk space is rare, you are right. If you believe that avoiding to fill RAM with unneeded code is more important, the Solarie method is better.

Jörg

-- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 24 October 2013 12:25:01 Joerg Schilling wrote:

Boris Manojlovic wrote:

...

<sarcasm> so where i can download this awesome operating system solaris for free, oh i can not? Shame on me i wanna use free (libre) opensource software. I assume windows is also better... oh no source either aaah... Windows and Solaris FTW in actual lingua... </sarcasm>

For the uninformed people like you:

http://hg.berlios.de/repos/schillix-on

Jörg

... and I feel this part of the thread has outlived its useful-ness, could we refrain from sarcastic and condescending emails please? Hugs, Jos

El 22/10/13 12:14, Joerg Schilling escribió:

Is there nothing like isainfo in Linux?

Yes plus compiler/linker infrastructure to make code execute only when certain hardware capabilities exist in the target machine. Unfortunately it was only used by glibc and libstdc++ last time I checked. -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org