Re: [boost] Default x86 instruction set

Subject: Re: [boost] Default x86 instruction set
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-05-07 12:17:27

Thank you for the reply.

On Tuesday 07 May 2013 17:24:06 Mathias Gaunard wrote:
> On 05/05/13 00:02, Andrey Semashev wrote:
> > Hi,
> > 
> > I noticed that by default x86 32 bit builds are targeted for i386 (at
> > least
> > gcc toolset and its derivatives explicitly specify -march=i386 in the
> > command line). Is there a reason to target for such an ancient
> > instruction set by default?
> 
> I take it you mean why is
> tools/build/v2/tools/gcc.jam
> adding -march=i386 when using GCC on 32-bit systems.

Yes.

> I also think it shouldn't do that. I suppose the reason is due to a
> limitation of Boost.Build that needs to know what the default is.
> Most GCC 32-bit binaries will build for i386 by default, even on modern
> linux distributions.

Not for Ubuntu 13.04, at least. 

gcc -m32 -dM -E - < /dev/null | grep __i686__
#define __i686__ 1

I also read that Fedora and Mandriva moved to i686 by default (probably, emulating 
cmov in kernel if running on i586) [1].

And Linux kernel dropped support for 80386 CPUs. [2] I actually read they dropped all 
CPUs without cpuid (which also includes some 80486) somewhere else, but I can't find it 
now. FreeBSD removed support for 80386 in 6.0 ([3], [4]). OpenBSD doesn't support 
both 80386 and some 80486 [5].

Noone uses pure 386 these days, so the default in gcc.jam looks inadequate.

> > Frankly, I'm not sure that the current Boost code would even run on a real
> > 80386, since there are at least quite a few places with atomic operations,
> > which I think were not present on that CPU.
> 
> Any code that relies on particular instructions should detect what the
> target is to only use what is supported by the target, with fallback to
> a portable implementation if possible.
> 
> It is also possible to not provide portable fallback, in which case the
> library needs to be ported to each architecture manually.

Technically, yes. But should one waste his time to support this architecture that noone 
uses anyway?

Actually, I was inaccurate in my previous statement; 80386 does support lock prefix, so 
atomic instructions are safe. That doesn't mean there's no reason to raise the default: 
my statement regarding cpuid is still in place, and enabling cmov might be benefical for 
performance.

> > But perhaps we could raise the default to Pentium Pro (i686)?
> 
> The best solution is to not add any flag, and use whatever the default is.

Agreed. But while that is not possible with the current Boost.Build, don't you think we 
should at least choose a more adequate default?

[1] http://boston-linux-unix-general-discussion-list.996279.n3.nabble.com/Linux-for-non-CMOV-processors-td2234.html
[2] http://www.phoronix.com/scan.php?page=news_item&px=MTI0OTg
[3] http://en.wikipedia.org/wiki/History_of_FreeBSD
[4] http://www.freebsd.org/releases/6.0R/hardware-i386.html
[5] http://www.openbsd.org/faq/faq12.html#FPU