From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-patches@ecos.sourceware.org
Subject: [Bug 1001607] Cortex-M4F architectural Floating Point Support
Date: Wed, 08 Aug 2012 17:14:00 -0000 [thread overview]
Message-ID: <20120808171417.91BA42F78005@mail.ecoscentric.com> (raw)
In-Reply-To: <bug-1001607-104@http.bugs.ecos.sourceware.org/>
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001607
--- Comment #19 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-08 18:14:13 BST ---
(In reply to comment #17)
> More comments....
>
> 7) There's a few more things from cortexm_stub.h which you put in fpv4_sp_d16.h
> which I don't think need to be: HAL_STUB_REGISTERS_SIZE, PS_N/Z/C/V, the
> definition of target_register_t and TARGET_HAS_LARGE_REGISTERS. These
> definitions will be the same everywhere in Cortex-M so can just live once in
> cortexm_stub.h.
OK.
>
> 8) In fpv4_sp_d16.h, hal_cortexm_fpu_enable/disable are still extern inline,
> which as I mentioned in comment #9 can be problematic. You are slightly at risk
> of link errors depending on the compiler optimisations. So these should be
> HAL_CORTEXM_FPU_ENABLE/DISABLE preprocessor macros instead.
I haven't experienced problems so far, but I haven't tried other optimization
than default. But we can trade them for macros, though I am reluctant.
>
> 9) CYGARC_CORTEXM_FPU_EXC_AUTOSAVE defaults to off.
>
> 10) A bit like my previous comment about lining up things in CDL, lining up
> some things here can be clearer too. For example:
> # define HAL_SAVEDREG_MAN_EXCEPTION_FPU_N 16
> # define HAL_SAVEDREG_AUTO_EXCEPTION_FPU_N 16
> # define HAL_SAVEDREG_AUTO_FRAME_SIZE (8*4 + 16*4 + 4 + 4)
>
> // HAL_SavedRegisters entries for floating point registers
> // see hal_arch.h for HAL_SavedRegisters definition.
>
> # define HAL_SAVEDREG_AUTO_FPU_EXCEPTION_S \
> cyg_uint32 s_auto[HAL_SAVEDREG_AUTO_EXCEPTION_FPU_N]; \
> cyg_uint32 fpscr; \
> cyg_uint32 align;
>
> is a little better as:
>
> # define HAL_SAVEDREG_MAN_EXCEPTION_FPU_N 16
> # define HAL_SAVEDREG_AUTO_EXCEPTION_FPU_N 16
> # define HAL_SAVEDREG_AUTO_FRAME_SIZE (8*4 + 16*4 + 4 + 4)
>
> // HAL_SavedRegisters entries for floating point registers
> // see hal_arch.h for HAL_SavedRegisters definition.
>
> # define HAL_SAVEDREG_AUTO_FPU_EXCEPTION_S \
> cyg_uint32 s_auto[HAL_SAVEDREG_AUTO_EXCEPTION_FPU_N]; \
> cyg_uint32 fpscr; \
> cyg_uint32 align;
>
> Well, personally I find it easier to read anyway.
>
> 11) hal_arch.inc: The line indentation isn't very consistent through this,
> including of comments. It may also be helpful to put a comment separator
> between the two halves (i.e. //=========================== etc.).
I'll try to improve.
>
> 12) hal_fpu_unenable surely ought to be named just hal_fpu_disable ? Ditto all
> the other mentions of unenable. Just wondering if you're using it specifically
> or just temporarily forgot the word :-). Bear in mind I don't know a single
> word of Macedonian so I'm grateful your English is so good!.
>
My English is less than perfect but here it is not a lost memory. The meaning
is (intended to be), as stated in the comment just below the line
_undo_last_enable_. It is not equivalent to disable because the FPU might have
been enabled already.
> 13) In fpv4_sp_d16.h the uses of __regs_p in HAL_THREAD_INIT_FPU_REGS and
> _CONTEXT still need brackets for safety :).
>
One reason why I prefer functions to macros.
> 14) In hal_arch.h, CYGNUM_HAL_STACK_CONTEXT_SIZE still needs abstracting so
> that different FPUs can have different sizes (as per comment #9)
>
OK. Then it (or override) shall be defined in fpv4_sp_d16.h
> 15) In hal_arch.inc, hal_fpu_enable and _disable should use
> CYGARC_REG_FPU_CPACR_ENABLE to be consistent
OK. There are some other places as well.
>
> 16) The banner at the top of hal_arch.inc isn't right (it says vectors.S) and
> the description of cortexm_fpu.c could be better - I think that was just taken
> from vectors.S as well.
Yes, it is.
>
> 17) As mentioned in comment #9, I think all the usage fault processing in
> vectors.S and hal_misc.c should only be present if lazy FPU context switching
> is enabled. Otherwise let it default to the hal_default_exception_vsr. That's
> the only time we need it.
OK.
>
> 18) Before, I had mentioned about saving FP context with interrupts and
> exceptions. I was making two observations there, one was about interrupts
> (thanks for sorting that out with LSPEN/ASPEN) but the other is that, unless
> the user explicitly requests it, we should only save the FP state for
> exceptions if we're a ROM monitor or have GDB stubs. At the moment they're
> always saved, which I think is unnecessary for most people's production
> applications. So I think we need an option just to cover the
> hal_fpu_exc_push/pop calls in hal_default_exception_vsr.
It is only possible when automatic FPU context saving is disabled. With enabled
automatic FPU context saving we have no choice.
>
> 19) reg_offset() in cortexm_stub.c still has a diag_printf. It also would be
> improved with some abstraction. I _think_ the following untested code would do
> it and then we wouldn't need two different versions at all:
> static int
> reg_offset(regnames_t reg)
> {
> int i, offset;
> for (i=0,offset=0; i<NUMREGS; i++)
> {
> if ( i == reg )
> break;
> offset += REGSIZE(i);
> }
> if ( NUMREGS == i || REGSIZE(i) == 0 )
> return -1;
> return offset;
> }
> since this is only used by the stub, a tiny amount of runtime inefficiency is
> fine.
>
I need some time to check this.
>
> 21) It looks like we still may not agree about whether usage faults should have
> their own exception vsr or not. As I said they are only used with lazy FPU
> handling and at most once per thread, so this is not performance critical code.
> Code size might be critical though. But the biggest problem is that, as you
> say, at present the hal_usagefault_exception_vsr has a different
> prologue/epilogue to hal_default_exception_vsr. That means the user can't debug
> any usage faults such as illegal instructions or unaligned accesses because the
> stub won't be entered. Whether with a separate vsr or not, I think it is
> important we have a solution that still allows users to debug usage faults. I
> guess that if we did do this through hal_default_exception_vsr then it would
> mean having to test whether the FPU was enabled or not before attempting to
> save the context. On the other hand, exceptions are of course rare and usually
> not something programs rely on for normal operation (only fatal errors
> usually), so performance probably isn't critical either. Can you think of any
> other way to allow usage faults to be debuggable when using the usage fault
> exception and lazy FPU context switching?
>
It is possible to change hal_deliver_usagefault_exception to return a value
that will be !0 if there are still exceptions to process. Then
hal_usagefault_exception_vsr can be tweaked to jump into
hal_default_exception_vsr. I am testing this and am going to post a patch
later, here is a snippet:
=== Code snippet =================
hal_usagefault_exception_vsr:
mrs r0,psp // Get process stack
sub r1,r0,#(12*4) // Make space for saved state
msr psp,r1 // Ensure PSP is up to date
mrs r3,basepri // R3 = basepri
stmfd r0!,{r2-r11,lr} // save registers
sub r0,#4
mov r4,r0 // R4 = saved state pointer
bl hal_deliver_usagefault_exception
mov r1,r0 // return code
mov r0,r4 // R0 = state saved across call
add r0,#4
ldmfd r0!,{r2-r11,lr} // Restore registers
msr psp,r0 // Restore PSP
msr basepri,r3 // Restore basepri
cmp r1,#0 // Exc. other than FPU?
bne hal_default_exception_vsr // Yes - process it
bx lr // Not: Return
====== Snippet end ====================
>
> I'm prepared to make many of these changes as it is unfair of me to ask you to
> do them all when you have already done so much, but given how much time has
> passed since this patch, I'm not sure if you have made other changes in the
> meantime, so let me know if you want me to make changes, so we can avoid
> clashes and having to merge.
If you have time that would be helpful, especially with CDL, but before we jump
to coding let's discuss it. I haven't changed anything since I posted the last
patch as I expected your comments. Now I'm testing the usagefault tweak and I
plan to post a small incremental patch later today or tomorrow.
>
> Благодарам !
So you do some Macedonian after all :-)
Cheers
Ilija
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
next prev parent reply other threads:[~2012-08-08 17:14 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-03 12:57 [Bug 1001607] New: " bugzilla-daemon
2012-06-03 12:58 ` [Bug 1001607] " bugzilla-daemon
2012-06-03 12:59 ` bugzilla-daemon
2012-06-03 13:04 ` bugzilla-daemon
2012-06-03 13:05 ` bugzilla-daemon
2012-06-03 13:06 ` bugzilla-daemon
2012-06-03 14:22 ` bugzilla-daemon
2012-06-03 16:22 ` bugzilla-daemon
2012-06-06 6:33 ` bugzilla-daemon
2012-06-10 20:56 ` bugzilla-daemon
2012-06-22 4:56 ` bugzilla-daemon
2012-06-24 15:01 ` bugzilla-daemon
2012-06-28 7:41 ` bugzilla-daemon
2012-07-01 4:23 ` bugzilla-daemon
2012-07-08 16:51 ` bugzilla-daemon
2012-07-08 16:52 ` bugzilla-daemon
2012-07-08 16:53 ` bugzilla-daemon
2012-08-07 5:56 ` bugzilla-daemon
2012-08-07 5:57 ` bugzilla-daemon
2012-08-08 16:49 ` bugzilla-daemon
2012-08-08 17:14 ` bugzilla-daemon [this message]
2012-08-08 18:01 ` bugzilla-daemon
2012-08-08 19:28 ` bugzilla-daemon
2012-08-09 4:03 ` bugzilla-daemon
2012-08-09 10:12 ` bugzilla-daemon
2012-08-10 18:09 ` bugzilla-daemon
2012-08-10 18:14 ` bugzilla-daemon
2012-08-12 11:05 ` bugzilla-daemon
2012-08-29 19:34 ` bugzilla-daemon
2012-08-29 19:36 ` bugzilla-daemon
2012-08-29 19:37 ` bugzilla-daemon
2012-08-31 18:40 ` bugzilla-daemon
2012-08-31 18:42 ` bugzilla-daemon
2012-10-09 19:33 ` bugzilla-daemon
2012-11-06 20:54 ` bugzilla-daemon
2012-11-06 20:56 ` bugzilla-daemon
2012-11-06 20:57 ` bugzilla-daemon
2012-12-02 20:15 ` bugzilla-daemon
2012-12-02 20:18 ` bugzilla-daemon
2012-12-02 20:20 ` bugzilla-daemon
2012-12-02 20:21 ` bugzilla-daemon
2012-12-13 5:37 ` bugzilla-daemon
2012-12-16 15:51 ` bugzilla-daemon
2012-12-17 4:02 ` bugzilla-daemon
2012-12-17 14:05 ` bugzilla-daemon
2012-12-17 15:30 ` bugzilla-daemon
2012-12-21 13:42 ` bugzilla-daemon
2012-12-21 13:53 ` bugzilla-daemon
2013-02-06 21:29 ` bugzilla-daemon
2013-02-06 23:02 ` bugzilla-daemon
2013-02-06 23:08 ` bugzilla-daemon
2013-02-07 9:47 ` bugzilla-daemon
2013-02-07 21:52 ` bugzilla-daemon
2013-02-07 21:57 ` bugzilla-daemon
2013-02-07 21:59 ` bugzilla-daemon
2013-02-07 22:00 ` bugzilla-daemon
2013-02-09 2:08 ` bugzilla-daemon
2013-02-10 12:33 ` bugzilla-daemon
2013-02-10 17:30 ` bugzilla-daemon
2013-02-10 17:34 ` bugzilla-daemon
2013-02-16 14:34 ` bugzilla-daemon
2013-02-20 3:21 ` bugzilla-daemon
2013-03-07 0:16 ` bugzilla-daemon
2013-03-07 0:17 ` bugzilla-daemon
2013-03-07 0:18 ` bugzilla-daemon
2013-03-07 0:19 ` bugzilla-daemon
2013-03-07 1:46 ` bugzilla-daemon
2013-03-08 15:09 ` bugzilla-daemon
2013-03-09 22:49 ` bugzilla-daemon
2013-03-12 22:42 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120808171417.91BA42F78005@mail.ecoscentric.com \
--to=bugzilla-daemon@bugs.ecos.sourceware.org \
--cc=ecos-patches@ecos.sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).