Quoting Kaz Kojima <kkoj...@rr.iij4u.or.jp>:
but in general the maintenance of hand crafted assembly codes will be hard.
If you have a fixed feature set and pipeline, and have made sure the code is correct, no further maintenance should be required - which is more than can be said of the target port code generator, which tends to fall back in generated code performance if you have a finely tuned port and don't keep up with changes in the optimizers. AFAIK the pipeline variations in the SH still don't come close to the difference between compiler generated code and assembly code that is properly hand-optimized for the SH4-[123]00 pipelines.
If soft-fp is yet too inefficient for you, you can free to propose a complete and regtested patch for SH assembly soft fp against trunk.
IIRC I never finished working on some corner cases of division rounding in the SH floating-point emulation because I had no testcase (and it was not high on my agenda because there seemed to be little practical relevance). In order to test the ARCompact floating point emulations, I made a new test to check rounding of subnormal numbers during division: http://gcc.gnu.org/viewcvs/branches/arc-4_4-20090909-branch/gcc/testsuite/gcc.c-torture/execute/ieee/denorm-rand.c?limit_changes=0&view=markup&pathrev=151545 To give the code a good workout, you can up the iteration count, e.g. 1000 -> 1000000 . However, you probably don't want to do this with fp-bit at -O0. Also note that fp-bit.c in SVN gets the rounding wrong, you can use this patch to have a sane comparison: http://gcc.gnu.org/viewcvs/branches/arc-4_4-20090909-branch/gcc/config/fp-bit.c?limit_changes=0&r1=151545&r2=151544&pathrev=151545 FWIW, these are the associated ChangeLog entries: gcc/testsuite: 2008-04-04 J"orn Rennecke <joern.renne...@arc.com> * gcc.c-torture/execute/ieee/denorm-rand.c: New file. * gcc.dg/torture/fp-int-convert.h: Avoid undefined behaviour. gcc: 2008-04-04 J"orn Rennecke <joern.renne...@arc.com> * config/fp-bit.c (_fpdiv_parts): Avoid double rounding.
