Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001607
--- Comment #62 from Ilija Kocho <[email protected]> ---
Hi Jifl
(In reply to comment #57)
[snip]
I applied CYGTST_KERNEL_SKIP_MULTI_THREAD_FP_TEST and performed fixes to the
tests. In addition I renamed thread_switch_fpu.cxx to fpint_thread_switch.cxx -
sounds better to me and now all tests have same prefix.
> > > (In reply to comment #50)
[snip]
> > Provided that that LAZY uses FPU enabled/disbled state in order to
> > distinguish between _FP_ and _INT_ threads, suppose that _INT_ thread is
> > interrupted by _FP_ ISR. Then Usage Fault VSR will enable FPU and FPU will
> > remain enabled after ISR returns [in thread context], effectively converting
> > the tread to _FP_. Gradually, this ISR "_FP_ missioner" ISR may convert all
> > threads to _FP_ so we're not lazy any more.
>
> Yes you're right of course. But I can't help feel it wouldn't be difficult
> to fix this in the exception and interrupt vsrs - e.g. set
> HAL_SAVEDREGISTERS_WITH_FPU as the saved register type if the FPU enabled
> bit is set in FPU_CPACR on entry to the exception or interrupt VSR, and then
> ensure the FPU is enabled/disabled accordingly before exit. I just get the
> feeling this should be able to be solved with little overhead.
I think that for interrupts it would be a waste.
However this led me to idea to add check ASPEN bit of FPCCR to the
GDB_STUB_SAVEDREG_FPU_EXCEPTION_SET() so now RedBoot can determine if autosave
is enabled or disabled in runtime. Single RedBoot image to debug LAZY, ALL and
NONE. Implemented.
[snip]
>
> Yes! In fact I have no problems with the FP patch 130210 and as far as I'm
> concerned that patch can be committed. However I do have an issue with your
> changes for the code build flag which you added in comment #56, which is
> that this will also prevent use of the DSP instructions by GCC I believe?
There's no problem with using DSP instructions. CDL will allow you to set
-mcpu=cortex-m4 either manually or provide as default setting by platform (we
can do it when we adopt new compiler). As a side effect you can set cortex-m4
alone by sequence of enable/disable FPU.
>
> Also of course as mentioned above, we still need to work out the last few
> niggles with those kernel tests.
I hope the tests are clean now. Some of the "features" were inherited from
original files. My next window for check-in is the upcoming weekend.
Ilija
--
You are receiving this mail because:
You are on the CC list for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.