This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: [PATCH, v3] ARM: Integrate Cortex-A15 optimized memcpy using NEON/VFP.
- From: "Schwarz, Konrad" <konrad dot schwarz at siemens dot com>
- To: Will Newton <will dot newton at linaro dot org>, Ramana Radhakrishnan <ramrad01 at arm dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Fri, 12 Apr 2013 07:42:21 +0000
- Subject: RE: [PATCH, v3] ARM: Integrate Cortex-A15 optimized memcpy using NEON/VFP.
- References: <515C5C47 dot 4090601 at linaro dot org> <5166F1AD dot 7010703 at arm dot com> <CANu=Dmhs_YKDj+6aJPO3tp_4Qk0NwhtYWUWibgy1tC3wWkd04g at mail dot gmail dot com>
> -----Original Message-----
> From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
> On Behalf Of Will Newton
> Sent: Thursday, April 11, 2013 10:14 PM
> To: Ramana Radhakrishnan
> Cc: newlib@sourceware.org
> Subject: Re: [PATCH, v3] ARM: Integrate Cortex-A15 optimized memcpy
> using NEON/VFP.
My apologies if this has all been answered before, but the floating-point
units I am familiar with usually allow lazy context switching.
A common operating system optimization is give threads a floating point
context only after they actually start executing floating point operations.
(The initial floating point instruction causes a trap; the OS can
initializes the thread's floating point context before restarting
the instruction.)
Threads start off as integer (register) context only.
Won't an implementation of a nominally non-floating point function
such as memcpy break this optimization, and perhaps be harmful from
a system standpoint?
In bare-metal systems, the OS/Executive/whatever may not even have
have floating point support and would be in for a rude surprise
when they call memcpy().
Konrad Schwarz