-msoft-float for mipsel-linux?

Kai Ruottu karuottuATfreenet.hut.fi
Thu Sep 16 16:23:00 GMT 1999

kevin wrote:

> > the output of floating computing is zero:
> >
> > bash# df
> > Filesystem           1k-blocks      Used Available Use% Mounted on
> > /dev/root               5887        5887        0   0%  /
> > /dev/ram1               9866          16      970   0%  /var
> > bash# df -h
> > Filesystem            Size  Used Avail Use% Mounted on
> > /dev/root             0.0K  0.0K  0.0K  0%  /
> > /dev/ram1             0.0K  0.0K  0.0K  0%  /var

 Did you compile 'df' using '-static -msoft-float'?  Then it shouldn't
use the shared libs (with '-mhard-float' routines inside them)...

> dear all,
>            shall we add -msoft-float to CFLAGS=
>             before building glibc?

 You wrote that your CPU is idt3051... Does it have a 'FPU' ?  If it
doesn't, it could be nice to have the '-msoft-float' as the default
or as the only choice for this target...

 But remembering always to use the '-msoft-float' is just as right.
The next MIPS-CPU-target can be something else, so there should be
enough possibilities in a cross-toolset...

 Ok, back to the subject... The answer is 'yes', just use it always
and for everything if there aren't any FPU or FPU-emulator. It just
uses the generic registers instead of the fp-ones and generates a
call to a soft-float routine instead of a 'inline' FPU instruction.

 A little about 'what the soft-float means' theory here... (this isn't
perhaps very clear for everyone)

 I did a simple experiment with my 'mips-elf' compiler. The following
code :

	#include <stdio.h>

	  float a, b, c;

	  a = 3.14159;
	  b = 2.718;

	  c = a + b;
	  c = a - b;

generated the following without the '-msoft-float' :

	li.s	$f0,3.14159011840820312500e0
	s.s	$f0,16($fp)
	li.s	$f0,2.71799993515014648438e0
	s.s	$f0,20($fp)
	l.s	$f0,16($fp)
	l.s	$f2,20($fp)
	add.s	$f0,$f0,$f2
	s.s	$f0,24($fp)
	l.s	$f0,16($fp)
	l.s	$f2,20($fp)
	sub.s	$f0,$f0,$f2
	s.s	$f0,24($fp)

and the following with '-msoft-float' :

	li.s	$2,3.14159011840820312500e0
	sw	$2,16($fp)
	li.s	$2,2.71799993515014648438e0
	sw	$2,20($fp)
	lw	$4,16($fp)
	lw	$5,20($fp)
	jal	fpadd
	sw	$2,24($fp)
	lw	$4,16($fp)
	lw	$5,20($fp)
	jal	fpsub
	sw	$2,24($fp)

There was no optimization, so this storing the stuff into stack
and reading it next back into some other CPU registers looks a
little silly... But the idea is there -- it uses the register #f0
or #2 for the storing and reads the values into registers #f0/#f2
or #4/#5 and does addition / subtraction with 'add.s'/'sub.s', or
calling 'fpadd()'/'fpsub', and stores the result into the stack
(frame) ...

The interesting thing is what the CPU does with those 'l.s', 's.s',
'add.s', 'sub.s' etc. instructions when it hasn't floating point
registers and a FP-unit...  Perhaps then "the output of floating
computing is zero", just as you wrote...

The C-library has those float operations in 'printf()', etc., so
compiling it totally with '-msoft-float', and linking the kernel,
producing the run-time libs and all the utilities with it may be
a necessity...

Cheers, Kai

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

More information about the crossgcc mailing list