Arne Jansen <a.jansen@biodata.de> wrote;

> - stdargs: when using egcs 1.1.1 the above described problem
>   do not occur. But there is a problem with added softfloat
>   support, because the header assumes hardware floating point.
>   I modified the header, but am not sure how to integrate the
>   modification into the tree, i.e. which macro to use
>   (SOFTFLOAT? _SOFT_FLOAT? __SOFT_FLOAT?).

Please treat the word SOFTFLOAT in care.  From programmers' point of
view, it's universal -msoft-float flag means no FP instruction inside
target applications.  FP math can be ran in different ways;

[1] by a processor itself
	processor is capable of munching FP insn.  This is a canonical form.
[2] by avoiding FP insns
	all of application are specifically built w/o any FP insn.
	this is done by compiler.
[3] kernel emulates FP insn thru trap/exception
	modern processor can trap any FP insn being processed.  Then
	kernel analyses the FP insn opcode and imitates FP hardware
	behaviour by kernel logic.  When completed, kernel resets
	processor trap condition and restarts the application as if
	the FP insn was executed by FP hardware.

Case [3] has such an advantage that application binaries can be shared
between processor models with or without FP hardware, with the downside
of severe performance penalty when FP math is being made.  Case [2]
runs FP math faster than [3] with possible code size penalty induced in
target applications.

The point is it'd not be appropriate to call case [3] SOFTFLOAT.
Rather suitable to use a term FPU_EMULATE or some.  Please put a clear
distinction between case [2] and [3].

Tohru Nishimura
Information Technology Centre
Nara Institute of Science and Technology