Re: Floating point emulation

["Kai Ruottu" <kai dot ruottu at luukku dot com>]

Yves Rutschle <y.rutschle@indigovision.com> wrote:

> On Fri, Nov 29, 2002 at 10:35:06AM +0100, Daniel Lidsten wrote:
> > In my application i can increase the performance if i use "double
> > precision" for my floating point calculation. However, i don't know what
> > is used today since there is no such option in the compiler. Currently i
> > specify the "-msoft-float" option - is this "single precision", double,
> > or any other?
> 
> "soft float" relates to *how* the operations are performed.
> Namely, in software (as opposed to "hard float" (ack I'm not
> actually sure what the proper term is :/ ) where the
> operations are performed by a floating point unit, ie it's
> done in hardware.) So that has nothing to do with the
> precision used.

 Some CPUs have only a single-precision FPU, like some MIPS-
models... With them even the 'double's may be processed using
single-precision if not using '-msoft-float'.

-------------------- a clip from GCC-manual -----------------
-msingle-float
-mdouble-float
	The -msingle-float switch tells gcc to assume that the
	floating point coprocessor only supports single precision
	operations, as on the r4650 chip. The -mdouble-float switch
	permits gcc to use double precision operations. This is the
	default.

-mmad
-mno-mad
	Permit use of the mad, madu and mul instructions, as on the
	r4650 chip.

-m4650
	Turns on -msingle-float, -mmad, and, at least for now,
	-mcpu=r4650.
---------------------- clip -----------------------------------

> IIRC, precision is chosen by the type:
> void main( void ) {
>   float x,y;
>   double z;
> }

 Some GCC-implementations for CPUs without FPUs may also calculate
all float operations in single-precision in their 'soft-float'
routines. The Hitachi H8/300 series and H8/500 series are such.
Probably most 8- and 16-bit CPU-targets don't have any 64-bit
floats because their 'long's are also 32-bit ('int's are 16-bit).
The 'gcc/config/fp-bit.c' is normally the single/double precision
package, controlled with '#define's in the associated 't-file',
for instance in 'gcc/config/h8300/t-h8300', into the needed role.
Normally it will be copied into two file, 'fp-bit.c' and 'dp-bit.c',
into the 'gcc' build-dir with controlling '#define's in their
beginnings, when one builds GCC. Some targets like m68k have their
own 'custom' soft-float routines, partly made in assembler...

 About 'performance' one can only say that it could be better in
these soft-float implementations. Maybe in 1999 a Swedish-company
gave their 'ieeelib.c' to GNU and promised it to give 5-times better
speed in the basic 'fadd/fsub/fmul/fdiv' etc. operations than the
'fp-bit.c'... Some guy from the Baltian-countries ported it to the
H8/300 (it needed some porting) and tests with it gave about 2-times
better speed... No comparisons in accuracy was done though.

 What could be hoped is that the people who work hard with GCC and
need soft-float, could implement the basic float operations in the
best possible algorithms for each CPU, in optimized assembly. In the
'assembly-age' in 70's and early 80's almost every "How to write
embedded apps"-book included these routines for the processors of
that age: '8080/85', 'z80', '8088/86',... But no implementations
for H8/300, AVR, MSP430, MN10200 etc. CPUs of this age can be seen.

 The 'commercial' compilers have optimized routines in their C-
libraries, in the H8/300-case the IAR-routines seemed to be still
5-times quicker than the 'ieeelib.c'-implementation. With the 32-
bit CPUs the 'fp-bit.c' may be quick enough...

 The 8- and 16-bit processors really are not aimed for 'number
crunching', but sometimes someone however wants to do this in
some device. My estimate to the work to write soft-float routines
in assembly for H8/300 for instance, could be one week, for a
person who knows that CPU and has programmed in assembly for it
a year or more... A total novice can spend half an year learning
the processor, assembly, soft-float algorithms and such while
writing the routines and reporting what was done. I remember one
student in early 80's doing soft-float routines for z80 as his
diploma-work (for a MSc-level examination) and the estimate for
these is half-an-year... The person really didn't know much about
these things when starting. Another earlier example was the Lawrence
Livermore Laboratory's Public Domain BASIC-interpreter (LLLBASIC) for
8080. It's soft-float implementation is one of the weirdest I have
seen. Ok, it was done in Moscow (Idaho), and when all the 8-bit GCC
implementations (AVR, MSP430,...) seem to have something to do with
the 'other' Moscow or StPetersburg, maybe this problem can get some
help from there ;-)

 Can we blame the university professors about this condition now?  
Why writing soft-float routines into the AVR, MSP430, H8/300 etc. 
wouldn't be good 'practice' nowadays for the students graduating
in computer architectures, embedded systems and such?

 In the H8/300 case it probably could help if every company which
thinks that it is a good idea to better the soft-float routines in
this architecture with GCC, would use $100 and give it to the Kpit
(www.kpit.com) in India... If even 100 companies could do this, the
$10.000 could enable them to put a guy or gal to think this thing
for a couple of months...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com