| Message ID | bd6e8e2eaf13ecc5e45e360875cfff3494b86a8c.1504444617.git.yann.morin.1998@free.fr |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [1/9] arch/arm: re-order cores choice | expand |
Thomas, All, On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly: > armv8a has made VFPv4 and NEON mandatory, so there is no point in > allowing software floating point, even in 32-bit mode. In fact, even though I'm pretty sure that OK in 64-bit, we might still have a reason to do soft-float in 32-bit mode, if only for legacy binary-only applications that were built as soft-float way back in the (not so) good old days... In which case, we should instead depend on !BR2_ARCH_IS_64. Thoughts? Regards, Yann E. MORIN. > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > --- > arch/Config.in.arm | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/Config.in.arm b/arch/Config.in.arm > index d110d52e2d..0ae6a16a0a 100644 > --- a/arch/Config.in.arm > +++ b/arch/Config.in.arm > @@ -374,6 +374,7 @@ choice > config BR2_ARM_SOFT_FLOAT > bool "Soft float" > depends on BR2_ARM_EABI > + depends on !BR2_ARM_CPU_ARMV8A > select BR2_SOFT_FLOAT > help > This option allows to use software emulated floating > -- > 2.11.0 >
Hello, On Mon, 4 Sep 2017 19:21:37 +0200, Yann E. MORIN wrote: > Thomas, All, > > On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly: > > armv8a has made VFPv4 and NEON mandatory, so there is no point in > > allowing software floating point, even in 32-bit mode. > > In fact, even though I'm pretty sure that OK in 64-bit, we might still > have a reason to do soft-float in 32-bit mode, if only for legacy > binary-only applications that were built as soft-float way back in the > (not so) good old days... > > In which case, we should instead depend on !BR2_ARCH_IS_64. > > Thoughts? I'm hesitating on this one. I believe the use-case you mention makes sense, however I believe that it can still be supported with your proposed patch. Indeed, even if you want to run a binary-only soft-float application, it doesn't prevent the rest of your system from using VFP, as long as you use EABI (and not EABIhf). The whole reason why EABI passes floating-point arguments into integer registers is precisely to allow compatibility between soft-float code and hard-float code. Thanks to that, a soft-float function can call a hard-float function, and vice-versa. Therefore, even if you have a binary-only soft-float application, there is really no reason to build the entire system soft-float. So, I think your original patch is OK as-is. However, I still see one inconsistent thing: if we disallow soft-float because ARMv8-A mandates VFPv4, why would we allow soft-float for ARMv7-A cores that have a VFP ? To be consistent, we should also disallow soft-float. Another way to think about this is: is it possible to build an AArch64 soft-float system? do we want to allow the user to select what is *possible* or what makes sense? Best regards, Thomas
On 24-11-17 23:08, Thomas Petazzoni wrote: > Hello, > > On Mon, 4 Sep 2017 19:21:37 +0200, Yann E. MORIN wrote: >> Thomas, All, >> >> On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly: >>> armv8a has made VFPv4 and NEON mandatory, so there is no point in >>> allowing software floating point, even in 32-bit mode. >> >> In fact, even though I'm pretty sure that OK in 64-bit, we might still >> have a reason to do soft-float in 32-bit mode, if only for legacy >> binary-only applications that were built as soft-float way back in the >> (not so) good old days... >> >> In which case, we should instead depend on !BR2_ARCH_IS_64. >> >> Thoughts? > > I'm hesitating on this one. I believe the use-case you mention makes > sense, however I believe that it can still be supported with your > proposed patch. > > Indeed, even if you want to run a binary-only soft-float application, > it doesn't prevent the rest of your system from using VFP, as long as > you use EABI (and not EABIhf). > > The whole reason why EABI passes floating-point arguments into integer > registers is precisely to allow compatibility between soft-float code > and hard-float code. Thanks to that, a soft-float function can call a > hard-float function, and vice-versa. > > Therefore, even if you have a binary-only soft-float application, there > is really no reason to build the entire system soft-float. > > So, I think your original patch is OK as-is. However, I still see one > inconsistent thing: if we disallow soft-float because ARMv8-A mandates > VFPv4, why would we allow soft-float for ARMv7-A cores that have a > VFP ? To be consistent, we should also disallow soft-float. > > Another way to think about this is: is it possible to build an AArch64 > soft-float system? do we want to allow the user to select what is > *possible* or what makes sense? gcc aarch64 doesn't have a float-abi option, so no it's not possible to build with soft-float. So the depends on BR2_ARM_EABI is certainly needed. That said, I don't think it makes a lot of sense to add extra 'depends on' lines just to avoid that the user would select an option that probably doesn't make sense. We already make sure that the default is appropriate. Let's not make our life more difficult. So I'd say: reject this patch. Regards, Arnout
Arnout, All, On 2017-11-25 18:10 +0100, Arnout Vandecappelle spake thusly: > On 24-11-17 23:08, Thomas Petazzoni wrote: > > Hello, > > > > On Mon, 4 Sep 2017 19:21:37 +0200, Yann E. MORIN wrote: > >> Thomas, All, > >> > >> On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly: > >>> armv8a has made VFPv4 and NEON mandatory, so there is no point in > >>> allowing software floating point, even in 32-bit mode. > >> > >> In fact, even though I'm pretty sure that OK in 64-bit, we might still > >> have a reason to do soft-float in 32-bit mode, if only for legacy > >> binary-only applications that were built as soft-float way back in the > >> (not so) good old days... > >> > >> In which case, we should instead depend on !BR2_ARCH_IS_64. > >> > >> Thoughts? > > > > I'm hesitating on this one. I believe the use-case you mention makes > > sense, however I believe that it can still be supported with your > > proposed patch. > > > > Indeed, even if you want to run a binary-only soft-float application, > > it doesn't prevent the rest of your system from using VFP, as long as > > you use EABI (and not EABIhf). > > > > The whole reason why EABI passes floating-point arguments into integer > > registers is precisely to allow compatibility between soft-float code > > and hard-float code. Thanks to that, a soft-float function can call a > > hard-float function, and vice-versa. > > > > Therefore, even if you have a binary-only soft-float application, there > > is really no reason to build the entire system soft-float. > > > > So, I think your original patch is OK as-is. However, I still see one > > inconsistent thing: if we disallow soft-float because ARMv8-A mandates > > VFPv4, why would we allow soft-float for ARMv7-A cores that have a > > VFP ? To be consistent, we should also disallow soft-float. > > > > Another way to think about this is: is it possible to build an AArch64 > > soft-float system? do we want to allow the user to select what is > > *possible* or what makes sense? > > gcc aarch64 It's not about aarch64, it's about aarch32, i.e. an armv8a core running in 32-bit mode. > doesn't have a float-abi option, so no it's not possible to build > with soft-float. So the depends on BR2_ARM_EABI is certainly needed. > > That said, I don't think it makes a lot of sense to add extra 'depends on' > lines just to avoid that the user would select an option that probably doesn't > make sense. We already make sure that the default is appropriate. Let's not make > our life more difficult. It's not about making *our* lives more dificult or easier. It's about making the user's lives easier. If there is a prompt that offers an option, but that has no impact on the resulting output, then that prompt should not exist. Otherwise, it is very confusing. Regards, Yann E. MORIN. > So I'd say: reject this patch. > > Regards, > Arnout > > > -- > Arnout Vandecappelle arnout at mind be > Senior Embedded Software Architect +32-16-286500 > Essensium/Mind http://www.mind.be > G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven > LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle > GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
Arnout, Thomas, All, On 2017-11-26 12:12 +0100, Yann E. MORIN spake thusly: > On 2017-11-25 18:10 +0100, Arnout Vandecappelle spake thusly: > > On 24-11-17 23:08, Thomas Petazzoni wrote: > > > On Mon, 4 Sep 2017 19:21:37 +0200, Yann E. MORIN wrote: > > >> Thomas, All, > > >> > > >> On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly: > > >>> armv8a has made VFPv4 and NEON mandatory, so there is no point in > > >>> allowing software floating point, even in 32-bit mode. > > >> > > >> In fact, even though I'm pretty sure that OK in 64-bit, we might still > > >> have a reason to do soft-float in 32-bit mode, if only for legacy > > >> binary-only applications that were built as soft-float way back in the > > >> (not so) good old days... > > >> > > >> In which case, we should instead depend on !BR2_ARCH_IS_64. > > >> > > >> Thoughts? > > > > > > I'm hesitating on this one. I believe the use-case you mention makes > > > sense, however I believe that it can still be supported with your > > > proposed patch. > > > > > > Indeed, even if you want to run a binary-only soft-float application, > > > it doesn't prevent the rest of your system from using VFP, as long as > > > you use EABI (and not EABIhf). > > > > > > The whole reason why EABI passes floating-point arguments into integer > > > registers is precisely to allow compatibility between soft-float code > > > and hard-float code. Thanks to that, a soft-float function can call a > > > hard-float function, and vice-versa. > > > > > > Therefore, even if you have a binary-only soft-float application, there > > > is really no reason to build the entire system soft-float. > > > > > > So, I think your original patch is OK as-is. However, I still see one > > > inconsistent thing: if we disallow soft-float because ARMv8-A mandates > > > VFPv4, why would we allow soft-float for ARMv7-A cores that have a > > > VFP ? To be consistent, we should also disallow soft-float. > > > > > > Another way to think about this is: is it possible to build an AArch64 > > > soft-float system? do we want to allow the user to select what is > > > *possible* or what makes sense? > > > > gcc aarch64 > > It's not about aarch64, it's about aarch32, i.e. an armv8a core running > in 32-bit mode. > > > doesn't have a float-abi option, so no it's not possible to build > > with soft-float. So the depends on BR2_ARM_EABI is certainly needed. > > > > That said, I don't think it makes a lot of sense to add extra 'depends on' > > lines just to avoid that the user would select an option that probably doesn't > > make sense. We already make sure that the default is appropriate. Let's not make > > our life more difficult. > > It's not about making *our* lives more dificult or easier. It's about > making the user's lives easier. > > If there is a prompt that offers an option, but that has no impact on > the resulting output, then that prompt should not exist. Otherwise, it > is very confusing. Damned, I hadn't finished my mail... > > So I'd say: reject this patch. But seeing the argument from Thomas, yes it does not make sense to hide soft-float anyway. Regards, Yann E. MORIN.
diff --git a/arch/Config.in.arm b/arch/Config.in.arm index d110d52e2d..0ae6a16a0a 100644 --- a/arch/Config.in.arm +++ b/arch/Config.in.arm @@ -374,6 +374,7 @@ choice config BR2_ARM_SOFT_FLOAT bool "Soft float" depends on BR2_ARM_EABI + depends on !BR2_ARM_CPU_ARMV8A select BR2_SOFT_FLOAT help This option allows to use software emulated floating
armv8a has made VFPv4 and NEON mandatory, so there is no point in allowing software floating point, even in 32-bit mode. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- arch/Config.in.arm | 1 + 1 file changed, 1 insertion(+)