Adding a MACHINE_ARCH note

[Konstantin Belousov]

On Wed, Jul 10, 2013 at 08:54:05AM +0200, Dimitry Andric wrote:
> On Jul 10, 2013, at 03:08, Peter Wemm <peter at wemm.org> wrote:
> > On Tue, Jul 9, 2013 at 5:56 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> >> ... boy I'd like to see this particular x86 hiccup fixed before this
> >> stuff is mainstream.
> > 
> > I'm not entirely sure how much support there is behind "x32".  I don't
> > know if its much more than an academic curiosity or if there's real
> > demand for it.
> 
> It seems to be driven by Intel and Google.  The idea is that for some
> applications (or maybe even most :), an ILP32 model will perform better.
> Quoting from one of the presentations:
> 
> On Core i7 2600K 3.40GHz:
> - Improved SPEC CPU 2K/2006 INT geomean by 7-10% over ia32 and 5-8% over
>   Intel64.
> - Improved SPEC CPU 2K/2006 FP geomean by 5-11% over ia32.
> - Very little changes in SPEC CPU 2K/2006 FP geomean, comparing against
>   Intel64.
> - Comparing against ia32 PIC, x32 PIC:
>   - Improved SPEC CPU 2K INT by another 10%.
>   - Improved SPEC CPU 2K FP by another 3%.
>   - Improved SPEC CPU 2006 INT by another 6%
>   - Improved SPEC CPU 2006 FP by another 2%.
> 
> As to how often it is actually used in practice, I am not sure.
> 
> 
> >  gcc-4.8 and clang have it, or have patches for it.
> 
> You also need a fairly recent binutils.  And kernel + libc support...
> It is probably not a trivial task. :-)

You definitely need a support from libc, libthr and rtld.
I am not convinced that the kernel modifications are needed,
except for the image activator to recognize new ELF ids. In
other words, I believe it is better to put shims into libc in
the long run.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130710/94aa1493/attachment.sig>