From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bart Veer <bartv@cygnus.co.uk>
To: jlarmour@cygnus.co.uk
Cc: ecos-discuss@sourceware.cygnus.com
Subject: [ECOS] Re: Ecos Port to PPC509/PPC555
Date: Tue, 28 Sep 1999 08:00:00 -0000
Message-id: <199909281459.PAA09627@sheesh.cygnus.co.uk>
References: <37E80554.7D56118D@danlawinc.com> <199909231448.PAA13861@sheesh.cygnus.co.uk> <87puz8v8sh.fsf@osv.javad.ru> <199909271854.TAA26830@sheesh.cygnus.co.uk> <37F00D1F.FDEC9E27@cygnus.co.uk>
X-SW-Source: 1999-09/msg00048.html

>>>>> "Jifl" == Jonathan Larmour <jlarmour@cygnus.co.uk> writes:

    >> Mostly correct, although one possible implementation requires
    >> no changes to existing interfaces: add a boolean field to the
    >> context structure to indicate whether or not the current thread
    >> has performed any floating point; trap FP exceptions and set
    >> this boolean for the current thread; [snip]

    Jifl> But you can't rely on FP exceptions being generated - they
    Jifl> don't for normal code, so I don't believe this is a viable
    Jifl> option unless I've misunderstood you.

On some architectures including the PPC (if I remember correctly), it
is possible to disable the floating point unit. The first operation
that attempts to access the floating point unit, even if it is just to
access a floating point register, will cause a hardware exception.
This is separate from normal floating point exceptions such as
overflow. 

    >> <snip>
    Sergei> You was right so far, but I can't agree with the last
    Sergei> statement. I'd prefer to don't save/restore FP context on
    Sergei> interrupts and all context switches. First, it is possible
    Sergei> to compile code that should never use FP with -msoft-float
    Sergei> to prevent compiler from generating FP instructions.
    >> 
    >> This is the first complication. Even if you compile most of eCos with
    >> -msoft-float, there are some bits such as libm which you will probably
    >> want to compile with -mhard-float. Furthermore these flags are only
    >> applicable to the PowerPC architecture, other architectures may need
    >> something different. In the current eCos build system there is no easy
    >> way to support this, although an ugly kludge would be possible.

    Jifl> Actually yes we do - the existing Configuration Tool allows
    Jifl> the overriding of flags on a per-package basis (although no
    Jifl> finer granularity than that). Its under Build->Options...

In the current build system there is some support to do this on a
per-package basis, but not automatically. It is necessary to create
some additional files, either manually or via the configuration tool.
This is not really acceptable for what is proposed here, and anyway
package-based granularity may not be good enough. Also I am not sure
we have ever documented how this part of the build system worked, and
it will change for the next release.

Bart Veer // eCos net maintainer