This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
[Bug 1001607] Cortex-M4F architectural Floating Point Support
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Thu, 9 Aug 2012 11:12:03 +0100
- Subject: [Bug 1001607] Cortex-M4F architectural Floating Point Support
- Auto-submitted: auto-generated
- References: <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
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #1881|0 |1
is obsolete| |
--- Comment #23 from Ilija Kocho <ilijak@siva.com.mk> 2012-08-09 11:11:57 BST ---
Created an attachment (id=1882)
--> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1882)
Enter default VSR from Usagefault VSR if not FPU exception. 120809
(In reply to comment #22)
> (In reply to comment #19)
> > (In reply to comment #17)
>
> Looking at the patch you posted in comment #21, do you need to save r2/r3 at
> all? In fact since hal_deliver_usagefault_exception doesn't use its 'regs'
> argument, should we drop that and only be saving, I guess, r12 and lr?
Although
> we have to stash r0 into r4 as before, so that too. All the other registers
> should be unaffected by hal_deliver_usagefault_exception, since unlike other
> user exception handling by default_exception_vsr, we know what this handler
> does. And basepri should also be unaffected I would have thought.
You are right, now that exception's job is predetermined, it can be optimized.
We don't have to save all registers, indeed, and r12 can be omitted (auto-saved
by exception), also maybe lr - but we need to keep stack aligned to 8 bytes
anyway.
[snip]
> I think with this route then hal_usagefault_exception_vsr and
> hal_deliver_usagefault_exception should be renamed to
> hal_fpu_usagefault_exception_vsr and hal_deliver_fpu_usagefault_exception
> instead.
>
I renamed hal_deliver_usagefault..., but technically
hal_usagefault_exception_vsr still handles all usagefault exceptions, though
some of them with help of hal_default_exception_vsr
I am going to implement other changes for which which I think that are clear,
and for others I will reply in another post.
ÐÐÐÐÑÐÐ
ÐÐÐÑÐ
--
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.