[ECOS] Re: Ecos Port to PPC509/PPC555

[Sergei Organov <osv at Javad dot RU>]

Bart Veer <bartv@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; have the context switch code and the interrupt
> handling code do the right thing; I believe this implementation can be
> done entirely inside the architectural HAL, without changing the
> kernel or HAL interfaces, because all context-related code and all
> hardware exception code is isolated there. However it is not
> necessarily the correct implementation, or at least not the only
> correct one.

Agreed. It seems I see how to do it at least for PowerPC. But it's
questionable that FP-enable bit found in PowerPC MSR or similar is
available on any FP architecture, and thus there could be no way to
get exception from code that just uses FP operations.

[...]
> 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.
> Furthermore the build system is undergoing heavy development at the
> moment (and no, I cannot reveal the details just yet), so any such
> kludge is likely to break for the next full release of eCos. There are
> plans to sort this out properly, but it is a hard problem and it is
> going to take time.

Thanks for warning. It'd be fine if you post details as soon as you
can. Don't know if you are going to implement it, but it seems to be a
good thing to be able to describe dependencies between packages.
Something like Debian does comes to mind (ability to put "requires"
and "conflicts" statements into package description).

>
> For the time being you would either have to build all of eCos with
> -msoft-float, accepting performance penalties for libm, or you would
> run the risk that things stop working in the next release.

No, I'd better build all eCos with -mhard-float. The only significant
trouble is 'printf' and friends where FP code isn't separated from
non-FP, and thus generated code contains FP registers save/restore in
prologue and epilogue. While I don't have time to fix 'printf', I'll
just don't use it in threads that have no FP context. And I'll use
FP-enable bit of MSR to get exceptions if non-FP task uses FP
operation. For me it seems to be more acceptable way until eCos
configuration system evolves to give clean ability to handle this.

>
>     Sergei> For PowerPC it is possible to disable FP in MSR and get
>     Sergei> exception if code executes FP instruction, then change
>     Sergei> code to don't use constructs that are translated to FP
>     Sergei> instructions (actually so far I soo only one place where
>     Sergei> gcc generates FP for PowerPC: structure move operations,
>     Sergei> and fixing this is very simple: just do per-member copy).
>
> According to the relevant gcc maintainer the compiler may also use
> floating point registers in other circumstances, mainly when it runs
> out of integer registers and needs to cache some data temporarily.
> This will only happen for code which has high register pressure. Of
> course as the compiler optimisations become more aggressive this can
> start happening more often.

True. It's very compiler dependent. However, still I see that gcc 
uses stack when there are not enough registers. Maybe I just didn't
run into such circumstances, though.

>
> It should be possible to add another compiler flag to gcc that
> instructs it to use the floating point registers only for floating
> point data, not for any other purposes. This would make life quite a
> lot easier, and get around the compiler flags problem in the build
> system as well. The best place for discussing such a change to the
> compiler would be the egcs mailing list, see http://egcs.cygnus.com/
> Although this should work for the PowerPC it might not be applicable
> to some other architectures.

Well, this idea came to my mind as well. The pair -m[soft/hard]-float
needs -mno-float to be complete. If it's not applicable to some
architecture, it apparently means that for given architecture FP
context just couldn't be separated, and thus there is no need for
special support for separate FP context in eCos for this architecture, 
I think.

I'm aware of egcs mailing lists, but I'm afraid there was not enough
demand so far for such an option to be implemented. Maybe further eCos 
development will produce such demand.

[...]

Regards,
Sergei.