On 6/30/2015 1:42 PM, H.J. Lu wrote:
On Tue, Jun 30, 2015 at 10:44 AM, Joseph Myers <jos...@codesourcery.com> wrote:
On Tue, 30 Jun 2015, Zinovy Nis wrote:
It works properly but I noticed that code the size for many arithmetic
functions is much more larger than for soft-fp emulation provided by
LLVM's compiler_rt library.
Code size is discussed in the paper about soft-fp in the 2006 Summit
proceedings. In general, soft-fp is optimized for speed (having
completely separate "if" cases for addition and subtraction, both of which
appear in both __addsf3 and __subsf3, for example) and for generality
(it's used in the Linux kernel for floating-point emulation, where you
want to follow the same choice of NaN etc. as a particular processor even
where IEEE semantics don't specify a particular choice, and it has
optional support for floating-point exceptions and rounding modes - note
that __float128 support in libgcc uses the hardware exceptions and
rounding modes when available), not for size (and generality takes
precedence over speed where they conflict, hence being a bit slower than
ieeelib even after the 2006 optimization work).
soft-fp is expected to be used on 32-bit and 64-bit systems for which a
few kB code size is insignificant.
Size is very important for IA MCU. Would it be acceptable to update
soft-fp to optimize for size with
#ifdef __OPTIMIZE_SIZE__
#else
#endif
I don't dispute that optimizing for size would probably be wise
on any x86 CPU that needs soft-float. They are all relatively slow.
But posted measurements of size and speed impact of doing this
would be appreciated.
Unless I slept through it getting removed, the rtems targets
never dropped the lower end i386 to keep legacy hardware supported.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
