Re: reasoning beehind prohibiting VFP/NEON on AArch32

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

So basically using them should be safe as long as you're in
EfiGetCurrentTpl() < TPL_HIGH_LEVEL, right?
Also, it'd probably be trivial to add  VFP/NEON regs to
EFI_SYSTEM_CONTEXT_ARM though that wouldn't help when writing apps for
existing uefi platforms.
On Sun, May 13, 2018 at 9:32 AM Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:

> On 12 May 2018 at 23:11, Michael Zimmermann <sigmaepsilon92@gmail.com>
wrote:
> > For AArch32 the spec says in 2.3.5.3:
> >> Floating point, SIMD, vector operations and other instruction set
> > extensions must not
> > be used.
> >
> > For AArch64 the spec says in 2.3.6.4:
> >> Floating point and SIMD instructions may be used.
> >
> > So is there a reason why AArch32 is not allowed to use Floating point
> > operations?
> > I'd understand if this restriction was limited to runtime services only
but
> > I don't see how it makes sense for boot services.
> >
> > I've written a patch which adds NEON support to FrameBufferBltLib to
> > increase the rendering performance(by a lot actually) for 24bit displays
> > and thought about sending it to the mailing list - that's why the
question
> > came up.
> >

> The reason for the difference between AArch64 and the other EFI
> architectures is that AArch64 does not have a softfloat ABI, so it is
> impossible to compile floating point code [portably] without enabling
> VFP/NEON. This is why AArch64 is the exception here.

> Currently, the AArch32 CPU context structure [EFI_SYSTEM_CONTEXT_ARM]
> does not cover VFP/NEON registers, and so they are not
> preserved/restored when an interrupt is taken. This means you cannot
> use VFP/NEON registers in an event handler or you will corrupt the
> VFP/NEON state of the interrupted context.