From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::22e; helo=mail-io0-x22e.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5B60F207E6373 for ; Sun, 13 May 2018 00:32:28 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id g14-v6so11683609ioc.7 for ; Sun, 13 May 2018 00:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C76g4Q1bohSgCOs3DABfwQDdhoX/+t9tbXAlxM60Mqk=; b=h7GWrcA3LNi2oYW4b/Y/IYsqy2hAyNYoP0lqEIlL97h5/GFhmOa0g1bND/NGn2UE9n jFG08ZMd5sqA1a/YacvuEK4soHWiJh+dsf/KdaJe0Acz7mQsZ2m6I2nXX+dvfTqXous9 hjQcE1rYsg8DUyBFtZSkd0oPFWwFKNOfGEJnI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C76g4Q1bohSgCOs3DABfwQDdhoX/+t9tbXAlxM60Mqk=; b=Ss1acEiOKWbLmF2XtJ3coYI/3zxKp3mbbPH5onPPKgugzBLTamOKF71dpBJ/J9aDBW GlWq7ba4+jWCIgLuqZXqt9sBSsOSEnQeZdH5TZDYyFIu7PLUsZ0ixV/GRwGufVuL5TMt 9JLGRSLdXRfJOHyIr9uDWq6EigRnxebVWuWLSV2ZZoGXknuJP1btBoFfSsuTraP3XNHL +gnxpUEQyNy6lcnFSOdxShTmeN6u3W6yP5J7zwGmuuNaTbQtIh+pCmAKXlRA5/fc80Gz wcqQQHCwEYc1t/FFfnUK3uAMcgegtZgKFKelxYSUcpaurgUELBwLXOaf3RdA2NzDituU tBYA== X-Gm-Message-State: ALKqPwdRN/ipwDCzomXOYvRbkgR2W6buxUJbKFpqsatMxBAh9Q0t85UP /wetYUzgQMJMT5CIxaS3gqWfBnasav0WubxdnqWvRw== X-Google-Smtp-Source: AB8JxZpcbvpnZ1SlB0xr4ctIh2MhMzIeSF5qBf1HRzeFyeM7ki0rdJH/aeIAf2TZl5cUBhUwhXqnPBItNAmKFTempzc= X-Received: by 2002:a6b:a9d1:: with SMTP id f78-v6mr5294567ioj.277.1526196746887; Sun, 13 May 2018 00:32:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.187.134 with HTTP; Sun, 13 May 2018 00:32:26 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Sun, 13 May 2018 09:32:26 +0200 Message-ID: To: Michael Zimmermann Cc: edk2-devel-01 , Leif Lindholm Subject: Re: reasoning beehind prohibiting VFP/NEON on AArch32 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2018 07:32:28 -0000 Content-Type: text/plain; charset="UTF-8" On 12 May 2018 at 23:11, Michael Zimmermann 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.