libosmocore and SSE

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Sat Aug 12 07:29:14 UTC 2017


Hi Neels,

On Sat, Aug 12, 2017 at 04:36:48AM +0200, Neels Hofmeyr wrote:

> a) debian packages should be usable on the largest set of CPUs, we should not
> build with CPU instructions we can't guarantee to be supported. So I guess we
> need a --without-sse configure option in libosmocore. Makes sense?

No, sorry.  We are *compiling* code for various CPU instruction sets, and deciding
at runtime, just like ffpmeg and many other projects with (optional) optimization,
too.

> b) I'm puzzled that the same host that built conv_gsm0503_test fails to run it.
> Is our SSE check in libosmocore's configure.ac broken? How to verify?

I'm not sure why you imply the assumption that the compiler capability to generate
instructions for a certain CPU feature set should be related to the actual
capability of the CPU to execute them.

You can always generate code that you cannot execute, this is quite normal.

> c) would be nice to find out what kind of host cumulus3 is; so far we know only
> that it is an x86_64. https://build.opensuse.org/monitor

Can we somehow "cat /proc/cpuinfo" during the build and get the output of that? We
could put this in the packaging rules or even in the makefile?  Or even compile it
into the binary with something like "-DCOMPILEHOST_CPUFLAGS=`cat /proc/cpuinfo`"

I've right now tested to build + make check libosmocore.git master
on a very old x86_64 machine, one of the first processors ever to support the
instructions set.  Worked fine:

=== AMD Opteron 250
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow rep_good nopl extd_apicid

It could of course be that the packaging rules or the environment of OBS do
something odd to the compiler optimization flags that would make an
obs-built-binary behave different from a manually built one...

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list