Subject: re: MPC860 port, various questions
To: None <firstname.lastname@example.org>
From: Toru Nishimura <email@example.com>
Date: 05/08/2001 16:45:09
Arne Jansen <firstname.lastname@example.org> 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;
 by a processor itself
processor is capable of munching FP insn. This is a canonical form.
 by avoiding FP insns
all of application are specifically built w/o any FP insn.
this is done by compiler.
 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  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 
runs FP math faster than  with possible code size penalty induced in
The point is it'd not be appropriate to call case  SOFTFLOAT.
Rather suitable to use a term FPU_EMULATE or some. Please put a clear
distinction between case  and .
Information Technology Centre
Nara Institute of Science and Technology