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:c0b::22a; helo=mail-it0-x22a.google.com; envelope-from=sigmaepsilon92@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 730752096DCDD for ; Sun, 13 May 2018 02:48:55 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id e185-v6so954077ita.0 for ; Sun, 13 May 2018 02:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FpnUdfYZp1ohRjVDh4wUMDjHfJve+5Ti6m5R50IoGA0=; b=bh31doFUoX7/0bjl2OxRuuWcYVl2TNt+zu41QLDNVGYFQA53J4yZkEPYZolKQXclm9 Mz+YZsadBv727XnPuTkDsntq2Wb1KSYaACQE1H854sE03lf58+DzXW9ji6rW0cQZDcRE lWn9oeUADMinS+FDvkITUX6/4hk0HkGmv2X3cdlJzqUKSkDsKepAYG26UF3mHgfsGZVV AHSWxb7wOEdfjjMYpUrHDwykN5i4HjHXVg2YWE7tiPKlmiWtiGymbPnb3+5O4DX76tny lUDF3i05iIruPc+oNTeOZSa7oIAW5wjf8+yEbm3QMRfwX18xdg3dbrhPjiF9xI+akBi8 ZXmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FpnUdfYZp1ohRjVDh4wUMDjHfJve+5Ti6m5R50IoGA0=; b=XctO1OXQIEKEidTxa9Q4aRkCpC/unup5itrYqJn/jz4Rk/BWBaR3XhdTeaqBA4Qpe/ O18W9NGqPdOfQ6rAzz64aBfsJY+txhrDiBK3on3LzEsl7TUleWqUt+9y+HIHzOx2OPPI 0Qsea9DKN1Q/i0xTGSuh8hERDoQkvrdpr2ud2rJ4HZUfRK0U9lu+tp3TYsU/oINg2yh7 +M6jd3jtcB1FeuCKsraA4E+bb+qxb8srCe4NK47g9/2PC64R8YHtGFN/rzUTTvvm6Lmh 5PMX6A9tdk5AKqSKhb6k0GHXryLps/Pkm08M4/KuXXoutmLQdEmaiuCIYBhKA1hQbUJj nTNA== X-Gm-Message-State: ALKqPwckp1Hn71rUjDucmvvf8g6lMTCVKScb9AcTZEs6vCiZzRu62Ck4 YdZ1l9c2PcorrqPw48VtrC7sbwCwgVfj5azUhbQ= X-Google-Smtp-Source: AB8JxZpEuBeXgcwtcKtk/Cj6ahehdczqRmxuq/RmYhctRrlyz23DjZd2QqQa0DM/WUZjxQvxmGYonT13+yNRoNqZB3U= X-Received: by 2002:a24:808c:: with SMTP id g134-v6mr4902953itd.130.1526204934293; Sun, 13 May 2018 02:48:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Zimmermann Date: Sun, 13 May 2018 11:48:43 +0200 Message-ID: To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , 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 09:48:55 -0000 Content-Type: text/plain; charset="UTF-8" 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 wrote: > 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.