os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add Warner Losh <imp@FreeBSD.org>'s soft float to hard float report.

Browse source
This commit is contained in:
Warren Block 2015-07-20 18:14:54 +00:00
parent fecc07d2c5
commit 06855d0a7e
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=47024
1 changed files with 84 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

84
en_US.ISO8859-1/htdocs/news/status/report-2015-04-2015-06.xml
View file

@ -2760,4 +2760,88 @@
</task> </task>
</help> </help>
</project> </project>
<project cat='kern'>
<title>Warner's ARMv6 Hard Float Experiment</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/armv6tohardfloat">Moving
armv6 from Soft Float to Hard Float</url>
</links>
<body>
<p>The plan for the transition to hard float on ARMv6 involved
having a new <tt>MACHINE_ARCH</tt>. That seemed expedient,
but inelegant to me. The kernel can easily run both soft and
hard floating point binaries, assuming that the proper
libraries are available.</p>
<p>As an experiment, I have been investigating how hard it would
be to just start generating hard float binaries starting with
&os; 11.0 and what issues this causes. I am most interested
in the source, the effects on ports, and any binary/package
upgrade issues from &os; 10.X to 11.</p>
<p>If successful, this will allow the project to move more
quickly away from a soft-floating point default. Users
upgrading from &os; 10 will automatically be upgraded to hard
float. All supported ARMv6 and ARMv7 processors have hardware
floating point, so this will not be a problem for the vast
majority of users. In addition, many of the build scripts
know about all values of <tt>MACHINE_ARCH</tt>, and not
changing the <tt>MACHINE_ARCH</tt> will allow those scripts to
continue to function without additional changes.</p>
<p>I am about three fourths of the way through investigating
this possibility and coding up solutions to the problems
encountered so far.</p>
<p>The risks from this experiment are that it will encounter
unforseen dependencies. This could force us to go with the
original plan for migration to hard floating point.</p>
<p>The hope for this experiment is to pave the way for using the
superior hard floating point in &os; 11 with minimal impact to
our users and their current build scripts and processes.
Backwards compatibility will be ensured with the libsoft tasks
if users need to run &os; 10.X ARMv6 softfloat binaries on
&os; 11.0 with its new hardfloat libraries. Packages should
automatically update once the new hardfloat packages are put
into place.</p>
</body>
<help>
<task>
<p>Building seat belts into <tt>ld.so</tt> to not cross-thread
libraries of differing floating point implementations.</p>
</task>
<task>
<p>Clang should properly mark hard versus soft floating point
<tt>.o</tt>s. This is a minor issue, since <tt>ld</tt>
handles things correctly.</p>
</task>
<task>
<p><tt>libsoft</tt>, the analog of <tt>lib32</tt>, needs to be
completed.</p>
</task>
<task>
<p>Patches to flip the switch from soft to hard for builds for
<tt>armv6</tt>. Some additional code needed to build soft
float may be needed for the prior task.</p>
</task>
</help>
</project>
</report> </report>