This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH, v3] ARM: Integrate Cortex-A15 optimized memcpy using NEON/VFP.

> -----Original Message-----
> From: []
> On Behalf Of Will Newton
> Sent: Thursday, April 11, 2013 10:14 PM
> To: Ramana Radhakrishnan
> Cc:
> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]