* status of armhf asm with VFP instructions @ 2015-10-15 22:33 Szabolcs Nagy 2015-10-15 22:44 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Szabolcs Nagy @ 2015-10-15 22:33 UTC (permalink / raw) To: musl it is not possible to write arm asm in a way that pleases all assemblers, here is a summary of the problems relevant to musl: some instructions can be written in several ways since UAL (= unified assembler language) was introduced to unify arm and thumb instruction mnemonics. in case of armhf VFP instructions musl uses the following ones in hand written asm: hex ual old eeb1XacX vsqrt.f32 fsqrts eeb1XbcX vsqrt.f64 fsqrtd eeb0XacX vabs.f64 fabss eeb0XbcX vabs.f64 fabsd eef1Xa10 vmrs fpscr mrc p10,7,.. eee1Xa10 vmsr fpscr mcr p10,7,.. the issues: (1) binutils gas rejects UAL VFP instructions unless either the -mfpu=<vfp variant> option is passed or the asm source has '.fpu <vfp variant>' directive, the old names work though (if the target is hard float). A gcc toolchain built --with-float=hard but without --with-fpu=<vfp variant> does not pass -mfpu to the assembler. (2) Most UAL mnemonics were added in binutils 2.18, older binutils only supports the old syntax. Some UAL mnemonics were added later, vmrs and vmsr only appear in binutils 2.21 (released in 2010). (3) The clang assembler does not support old mnemonics in general but includes a few exceptions (e.g. fabs and fsqrt are supported, but not the mrc or mcr coprocessor instructions). Using UAL asm is the clean solution, but then to fix (1) we should have .fpu directives in the asm files. However the conflict between (2) and (3) means that fenv code using vmrs and vmsr either drops support for old binutils gas or the clang assembler. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: status of armhf asm with VFP instructions 2015-10-15 22:33 status of armhf asm with VFP instructions Szabolcs Nagy @ 2015-10-15 22:44 ` Rich Felker 2015-10-15 23:16 ` Szabolcs Nagy 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2015-10-15 22:44 UTC (permalink / raw) To: musl On Fri, Oct 16, 2015 at 12:33:20AM +0200, Szabolcs Nagy wrote: > it is not possible to write arm asm in a way that pleases all > assemblers, here is a summary of the problems relevant to musl: > > some instructions can be written in several ways since UAL > (= unified assembler language) was introduced to unify arm > and thumb instruction mnemonics. > > in case of armhf VFP instructions musl uses the following ones > in hand written asm: > > hex ual old > > eeb1XacX vsqrt.f32 fsqrts > eeb1XbcX vsqrt.f64 fsqrtd > eeb0XacX vabs.f64 fabss > eeb0XbcX vabs.f64 fabsd > eef1Xa10 vmrs fpscr mrc p10,7,.. > eee1Xa10 vmsr fpscr mcr p10,7,.. > > the issues: > > (1) binutils gas rejects UAL VFP instructions unless either > the -mfpu=<vfp variant> option is passed or the asm source > has '.fpu <vfp variant>' directive, the old names work though > (if the target is hard float). A gcc toolchain built > --with-float=hard but without --with-fpu=<vfp variant> does not > pass -mfpu to the assembler. > > (2) Most UAL mnemonics were added in binutils 2.18, older > binutils only supports the old syntax. Some UAL mnemonics were > added later, vmrs and vmsr only appear in binutils 2.21 > (released in 2010). > > (3) The clang assembler does not support old mnemonics in general > but includes a few exceptions (e.g. fabs and fsqrt are supported, > but not the mrc or mcr coprocessor instructions). > > Using UAL asm is the clean solution, but then to fix (1) we > should have .fpu directives in the asm files. > > However the conflict between (2) and (3) means that fenv code > using vmrs and vmsr either drops support for old binutils gas > or the clang assembler. It seems we're already using the new forms vsqrt and vabs in src/math/armhf/*.s. So using vmrs/vmsr presumably will not break support for any toolchains that work now. I think the reason this went unnoticed for so long is that Aboriginal Linux (the only real user of the ancient binutils, due to GPL v2 vs v3 issues) does not use the armhf ABI at all; it only targets standard EABI for which musl does not use any math/fenv asm. So I'm ok with the fpu-related changes proposed, but I'm not sure what to do about UAL issues elsewhere. Right now we have a lot of files with instructions written as .word in them which is a mess and which precludes Cortex-M (thumb2-only) targets. These are files which need to be built even on non-hf, so changing them presumably will break support for old binutils. As a workaround, users needing old binutils could perhaps misuse the ASM_CMD var in the Makefile to run a sed script that replaces UAL with old-syntax asm. Or someone could patch the old binutils to accept UAL... Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: status of armhf asm with VFP instructions 2015-10-15 22:44 ` Rich Felker @ 2015-10-15 23:16 ` Szabolcs Nagy 2015-10-15 23:58 ` Szabolcs Nagy ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Szabolcs Nagy @ 2015-10-15 23:16 UTC (permalink / raw) To: musl * Rich Felker <dalias@libc.org> [2015-10-15 18:44:25 -0400]: > On Fri, Oct 16, 2015 at 12:33:20AM +0200, Szabolcs Nagy wrote: > > it is not possible to write arm asm in a way that pleases all > > assemblers, here is a summary of the problems relevant to musl: > > > > some instructions can be written in several ways since UAL > > (= unified assembler language) was introduced to unify arm > > and thumb instruction mnemonics. > > > > in case of armhf VFP instructions musl uses the following ones > > in hand written asm: > > > > hex ual old > > > > eeb1XacX vsqrt.f32 fsqrts > > eeb1XbcX vsqrt.f64 fsqrtd > > eeb0XacX vabs.f64 fabss > > eeb0XbcX vabs.f64 fabsd > > eef1Xa10 vmrs fpscr mrc p10,7,.. > > eee1Xa10 vmsr fpscr mcr p10,7,.. sorry, for reading/writing fpscr fmrx/fmxr can be used in the old syntax instead of vmrs/vmsr, but clang does not know those names. > > the issues: > > > > (1) binutils gas rejects UAL VFP instructions unless either > > the -mfpu=<vfp variant> option is passed or the asm source > > has '.fpu <vfp variant>' directive, the old names work though > > (if the target is hard float). A gcc toolchain built > > --with-float=hard but without --with-fpu=<vfp variant> does not > > pass -mfpu to the assembler. > > > > (2) Most UAL mnemonics were added in binutils 2.18, older > > binutils only supports the old syntax. Some UAL mnemonics were > > added later, vmrs and vmsr only appear in binutils 2.21 > > (released in 2010). > > > > (3) The clang assembler does not support old mnemonics in general > > but includes a few exceptions (e.g. fabs and fsqrt are supported, > > but not the mrc or mcr coprocessor instructions). > > > > Using UAL asm is the clean solution, but then to fix (1) we > > should have .fpu directives in the asm files. > > > > However the conflict between (2) and (3) means that fenv code > > using vmrs and vmsr either drops support for old binutils gas > > or the clang assembler. > > It seems we're already using the new forms vsqrt and vabs in > src/math/armhf/*.s. So using vmrs/vmsr presumably will not break > support for any toolchains that work now. > vmrs/vmsr can break on old binutils versions (2.18 - 2.20) and 2.20 is not that ancient.. is that ok? > I think the reason this went unnoticed for so long is that Aboriginal > Linux (the only real user of the ancient binutils, due to GPL v2 vs v3 > issues) does not use the armhf ABI at all; it only targets standard > EABI for which musl does not use any math/fenv asm. > > So I'm ok with the fpu-related changes proposed, but I'm not sure what > to do about UAL issues elsewhere. Right now we have a lot of files > with instructions written as .word in them which is a mess and which > precludes Cortex-M (thumb2-only) targets. These are files which need > to be built even on non-hf, so changing them presumably will break > support for old binutils. As a workaround, users needing old binutils > could perhaps misuse the ASM_CMD var in the Makefile to run a sed > script that replaces UAL with old-syntax asm. Or someone could patch > the old binutils to accept UAL... > most likely ual is the long term solution. maybe it is best to switch to ual and then write that script if ppl with old binutils run into issues. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: status of armhf asm with VFP instructions 2015-10-15 23:16 ` Szabolcs Nagy @ 2015-10-15 23:58 ` Szabolcs Nagy 2015-10-19 6:12 ` Rich Felker 2015-10-16 0:00 ` Rich Felker 2015-10-16 6:42 ` Khem Raj 2 siblings, 1 reply; 10+ messages in thread From: Szabolcs Nagy @ 2015-10-15 23:58 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 481 bytes --] * Szabolcs Nagy <nsz@port70.net> [2015-10-16 01:16:07 +0200]: > * Rich Felker <dalias@libc.org> [2015-10-15 18:44:25 -0400]: > > It seems we're already using the new forms vsqrt and vabs in > > src/math/armhf/*.s. So using vmrs/vmsr presumably will not break > > support for any toolchains that work now. > > > > vmrs/vmsr can break on old binutils versions (2.18 - 2.20) and > 2.20 is not that ancient.. is that ok? > attached the old armhf patch with updated commit message. [-- Attachment #2: 0001-fix-armhf-asm-to-use-.fpu-vfp-and-UAL-mnemonics.patch --] [-- Type: text/x-diff, Size: 3509 bytes --] From 542d4003a60320ac0446b156681c59cbc19dd6a1 Mon Sep 17 00:00:00 2001 From: Szabolcs Nagy <nsz@port70.net> Date: Tue, 21 Jul 2015 20:00:03 +0000 Subject: [PATCH] fix armhf asm to use .fpu vfp and UAL mnemonics (1) Some armhf gcc toolchains (built with --with-float=hard but without --with-fpu=vfp*) do not pass -mfpu=vfp to the assembler and then binutils rejects the UAL mnemonics for VFP unless there is an .fpu vfp directive in the asm source. (2) binutils <= 2.17 does not support UAL VFP syntax, and vmrs/vmsr insns are only recognised in binutils >= 2.21. (3) clang builtin assembler does not support the old mnemonics (except a few with warnings). Added .fpu vfp directive to all armhf asm which use VFP instructions to solve (1) (only backward compatible VFPv1 instructions are used), dropped support for binutils < 2.21 and replaced mcr/mrc with vmsr/vmrs. The generated code should not be changed by this commit. --- src/fenv/armhf/fenv.s | 22 ++++++++++++---------- src/math/armhf/fabs.s | 1 + src/math/armhf/fabsf.s | 1 + src/math/armhf/sqrt.s | 1 + src/math/armhf/sqrtf.s | 1 + 5 files changed, 16 insertions(+), 10 deletions(-) diff --git a/src/fenv/armhf/fenv.s b/src/fenv/armhf/fenv.s index 387234b..2621422 100644 --- a/src/fenv/armhf/fenv.s +++ b/src/fenv/armhf/fenv.s @@ -1,17 +1,19 @@ +.fpu vfp + .global fegetround .type fegetround,%function fegetround: - mrc p10, 7, r0, cr1, cr0, 0 + vmrs r0, fpscr and r0, r0, #0xc00000 bx lr .global __fesetround .type __fesetround,%function __fesetround: - mrc p10, 7, r3, cr1, cr0, 0 + vmrs r3, fpscr bic r3, r3, #0xc00000 orr r3, r3, r0 - mcr p10, 7, r3, cr1, cr0, 0 + vmsr fpscr, r3 mov r0, #0 bx lr @@ -19,7 +21,7 @@ __fesetround: .type fetestexcept,%function fetestexcept: and r0, r0, #0x1f - mrc p10, 7, r3, cr1, cr0, 0 + vmrs r3, fpscr and r0, r0, r3 bx lr @@ -27,9 +29,9 @@ fetestexcept: .type feclearexcept,%function feclearexcept: and r0, r0, #0x1f - mrc p10, 7, r3, cr1, cr0, 0 + vmrs r3, fpscr bic r3, r3, r0 - mcr p10, 7, r3, cr1, cr0, 0 + vmsr fpscr, r3 mov r0, #0 bx lr @@ -37,16 +39,16 @@ feclearexcept: .type feraiseexcept,%function feraiseexcept: and r0, r0, #0x1f - mrc p10, 7, r3, cr1, cr0, 0 + vmrs r3, fpscr orr r3, r3, r0 - mcr p10, 7, r3, cr1, cr0, 0 + vmsr fpscr, r3 mov r0, #0 bx lr .global fegetenv .type fegetenv,%function fegetenv: - mrc p10, 7, r3, cr1, cr0, 0 + vmrs r3, fpscr str r3, [r0] mov r0, #0 bx lr @@ -57,6 +59,6 @@ fesetenv: cmn r0, #1 moveq r3, #0 ldrne r3, [r0] - mcr p10, 7, r3, cr1, cr0, 0 + vmsr fpscr, r3 mov r0, #0 bx lr diff --git a/src/math/armhf/fabs.s b/src/math/armhf/fabs.s index 2bdebff..8a705e1 100644 --- a/src/math/armhf/fabs.s +++ b/src/math/armhf/fabs.s @@ -1,3 +1,4 @@ +.fpu vfp .text .global fabs .type fabs,%function diff --git a/src/math/armhf/fabsf.s b/src/math/armhf/fabsf.s index 35c720f..2c7beb6 100644 --- a/src/math/armhf/fabsf.s +++ b/src/math/armhf/fabsf.s @@ -1,3 +1,4 @@ +.fpu vfp .text .global fabsf .type fabsf,%function diff --git a/src/math/armhf/sqrt.s b/src/math/armhf/sqrt.s index 99fe64b..90f74a9 100644 --- a/src/math/armhf/sqrt.s +++ b/src/math/armhf/sqrt.s @@ -1,3 +1,4 @@ +.fpu vfp .text .global sqrt .type sqrt,%function diff --git a/src/math/armhf/sqrtf.s b/src/math/armhf/sqrtf.s index 9ea519f..91d8ad6 100644 --- a/src/math/armhf/sqrtf.s +++ b/src/math/armhf/sqrtf.s @@ -1,3 +1,4 @@ +.fpu vfp .text .global sqrtf .type sqrtf,%function -- 2.4.1 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: status of armhf asm with VFP instructions 2015-10-15 23:58 ` Szabolcs Nagy @ 2015-10-19 6:12 ` Rich Felker 0 siblings, 0 replies; 10+ messages in thread From: Rich Felker @ 2015-10-19 6:12 UTC (permalink / raw) To: musl On Fri, Oct 16, 2015 at 01:58:09AM +0200, Szabolcs Nagy wrote: > * Szabolcs Nagy <nsz@port70.net> [2015-10-16 01:16:07 +0200]: > > * Rich Felker <dalias@libc.org> [2015-10-15 18:44:25 -0400]: > > > It seems we're already using the new forms vsqrt and vabs in > > > src/math/armhf/*.s. So using vmrs/vmsr presumably will not break > > > support for any toolchains that work now. > > > > > > > vmrs/vmsr can break on old binutils versions (2.18 - 2.20) and > > 2.20 is not that ancient.. is that ok? > > > > attached the old armhf patch with updated commit message. > >From 542d4003a60320ac0446b156681c59cbc19dd6a1 Mon Sep 17 00:00:00 2001 > From: Szabolcs Nagy <nsz@port70.net> > Date: Tue, 21 Jul 2015 20:00:03 +0000 > Subject: [PATCH] fix armhf asm to use .fpu vfp and UAL mnemonics > > (1) Some armhf gcc toolchains (built with --with-float=hard but without > --with-fpu=vfp*) do not pass -mfpu=vfp to the assembler and then binutils > rejects the UAL mnemonics for VFP unless there is an .fpu vfp directive > in the asm source. I've committed just this part 1 since it's independent of the other changes and should yield nothing but an improvement in compatibility. I'd still like to go ahead with all the UAL changes after release. Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: status of armhf asm with VFP instructions 2015-10-15 23:16 ` Szabolcs Nagy 2015-10-15 23:58 ` Szabolcs Nagy @ 2015-10-16 0:00 ` Rich Felker 2015-10-16 0:33 ` Szabolcs Nagy 2015-10-16 6:42 ` Khem Raj 2 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2015-10-16 0:00 UTC (permalink / raw) To: musl On Fri, Oct 16, 2015 at 01:16:07AM +0200, Szabolcs Nagy wrote: > > > the issues: > > > > > > (1) binutils gas rejects UAL VFP instructions unless either > > > the -mfpu=<vfp variant> option is passed or the asm source > > > has '.fpu <vfp variant>' directive, the old names work though > > > (if the target is hard float). A gcc toolchain built > > > --with-float=hard but without --with-fpu=<vfp variant> does not > > > pass -mfpu to the assembler. > > > > > > (2) Most UAL mnemonics were added in binutils 2.18, older > > > binutils only supports the old syntax. Some UAL mnemonics were > > > added later, vmrs and vmsr only appear in binutils 2.21 > > > (released in 2010). > > > > > > (3) The clang assembler does not support old mnemonics in general > > > but includes a few exceptions (e.g. fabs and fsqrt are supported, > > > but not the mrc or mcr coprocessor instructions). > > > > > > Using UAL asm is the clean solution, but then to fix (1) we > > > should have .fpu directives in the asm files. > > > > > > However the conflict between (2) and (3) means that fenv code > > > using vmrs and vmsr either drops support for old binutils gas > > > or the clang assembler. > > > > It seems we're already using the new forms vsqrt and vabs in > > src/math/armhf/*.s. So using vmrs/vmsr presumably will not break > > support for any toolchains that work now. > > > > vmrs/vmsr can break on old binutils versions (2.18 - 2.20) and > 2.20 is not that ancient.. is that ok? 2.20 seems to be from 2009 and 2.21 from 2010, despite the fake 2011 timestamps on the GNU ftp site. See: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=20835820a172906a3b24b2551d5eeb03e3d8dc32 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f195a4076f78b60965b4b95561c76d743fe7e1c7 This is not ancient, but also not recent. Are there arm-based distros using it, or any particular reason we should care? 2.17 is interesting to some people as the last-gplv2 version, but newer-but-old stuff seems less interesting. > > I think the reason this went unnoticed for so long is that Aboriginal > > Linux (the only real user of the ancient binutils, due to GPL v2 vs v3 > > issues) does not use the armhf ABI at all; it only targets standard > > EABI for which musl does not use any math/fenv asm. > > > > So I'm ok with the fpu-related changes proposed, but I'm not sure what > > to do about UAL issues elsewhere. Right now we have a lot of files > > with instructions written as .word in them which is a mess and which > > precludes Cortex-M (thumb2-only) targets. These are files which need > > to be built even on non-hf, so changing them presumably will break > > support for old binutils. As a workaround, users needing old binutils > > could perhaps misuse the ASM_CMD var in the Makefile to run a sed > > script that replaces UAL with old-syntax asm. Or someone could patch > > the old binutils to accept UAL... > > > > most likely ual is the long term solution. > > maybe it is best to switch to ual and then write that script > if ppl with old binutils run into issues. That sounds like it might be the best option. I don't like dropping support for old stuff, but ARM really made a mess of this by making a new gratuitously incompatible asm syntax and encouraging tools not to support the old syntax (and particularly, not to support generating thumb2 from it, despite the fact that there's no fundamental reason it couldn't be done). BTW for other things I think we need some sort of syntax directive to tell the assembler we'll be using the unified syntax -- is this right? Do you know what the minimum gas version that supports this directive is? Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: status of armhf asm with VFP instructions 2015-10-16 0:00 ` Rich Felker @ 2015-10-16 0:33 ` Szabolcs Nagy 2015-10-16 1:03 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Szabolcs Nagy @ 2015-10-16 0:33 UTC (permalink / raw) To: musl * Rich Felker <dalias@libc.org> [2015-10-15 20:00:56 -0400]: > On Fri, Oct 16, 2015 at 01:16:07AM +0200, Szabolcs Nagy wrote: > > most likely ual is the long term solution. > > > > maybe it is best to switch to ual and then write that script > > if ppl with old binutils run into issues. > > That sounds like it might be the best option. I don't like dropping > support for old stuff, but ARM really made a mess of this by making a > new gratuitously incompatible asm syntax and encouraging tools not to > support the old syntax (and particularly, not to support generating > thumb2 from it, despite the fact that there's no fundamental reason it > couldn't be done). > > BTW for other things I think we need some sort of syntax directive to > tell the assembler we'll be using the unified syntax -- is this right? > Do you know what the minimum gas version that supports this directive > is? .syntax unified (binutils supports it since 2005). and the default is divided syntax (so inline asm has to use divided syntax or ".sytax unified" ... ".syntax divided") ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: status of armhf asm with VFP instructions 2015-10-16 0:33 ` Szabolcs Nagy @ 2015-10-16 1:03 ` Rich Felker 2015-10-16 3:23 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2015-10-16 1:03 UTC (permalink / raw) To: musl On Fri, Oct 16, 2015 at 02:33:13AM +0200, Szabolcs Nagy wrote: > * Rich Felker <dalias@libc.org> [2015-10-15 20:00:56 -0400]: > > On Fri, Oct 16, 2015 at 01:16:07AM +0200, Szabolcs Nagy wrote: > > > most likely ual is the long term solution. > > > > > > maybe it is best to switch to ual and then write that script > > > if ppl with old binutils run into issues. > > > > That sounds like it might be the best option. I don't like dropping > > support for old stuff, but ARM really made a mess of this by making a > > new gratuitously incompatible asm syntax and encouraging tools not to > > support the old syntax (and particularly, not to support generating > > thumb2 from it, despite the fact that there's no fundamental reason it > > couldn't be done). > > > > BTW for other things I think we need some sort of syntax directive to > > tell the assembler we'll be using the unified syntax -- is this right? > > Do you know what the minimum gas version that supports this directive > > is? > > ..syntax unified (binutils supports it since 2005). Hm? That would include 2.17. So is the new vfp syntax separate from UAL-vs-legacy? > and the default is divided syntax > (so inline asm has to use divided syntax or > ".sytax unified" > .... > ".syntax divided") Uhg, and it's the opposite for clang with integrated assembler, right? Thankfully most instructions you'd actually use look the same either way... Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: status of armhf asm with VFP instructions 2015-10-16 1:03 ` Rich Felker @ 2015-10-16 3:23 ` Rich Felker 0 siblings, 0 replies; 10+ messages in thread From: Rich Felker @ 2015-10-16 3:23 UTC (permalink / raw) To: musl On Thu, Oct 15, 2015 at 09:03:46PM -0400, Rich Felker wrote: > On Fri, Oct 16, 2015 at 02:33:13AM +0200, Szabolcs Nagy wrote: > > * Rich Felker <dalias@libc.org> [2015-10-15 20:00:56 -0400]: > > > On Fri, Oct 16, 2015 at 01:16:07AM +0200, Szabolcs Nagy wrote: > > > > most likely ual is the long term solution. > > > > > > > > maybe it is best to switch to ual and then write that script > > > > if ppl with old binutils run into issues. > > > > > > That sounds like it might be the best option. I don't like dropping > > > support for old stuff, but ARM really made a mess of this by making a > > > new gratuitously incompatible asm syntax and encouraging tools not to > > > support the old syntax (and particularly, not to support generating > > > thumb2 from it, despite the fact that there's no fundamental reason it > > > couldn't be done). > > > > > > BTW for other things I think we need some sort of syntax directive to > > > tell the assembler we'll be using the unified syntax -- is this right? > > > Do you know what the minimum gas version that supports this directive > > > is? > > > > ..syntax unified (binutils supports it since 2005). > > Hm? That would include 2.17. So is the new vfp syntax separate from > UAL-vs-legacy? I just tested and gas 2.17 accepts the new syntax for vabs and vsqrt if you use .syntax unified (they're errors without the directive). But the vmsr/vmrs are still rejected. :( However it seems like we can safely convert all the other existing asm to UAL and have it work with all relevant binutils versions at least as well as it's working now. In particular this should allow fixing the mess in memcpy, etc. The arm atomics file is still a mess of non-thumb-compatible code (it actually does arithmetic on pc that depends on arm opcode size) but I want to replace it anyway now that the new dynamic linker init sequence does not need atomics that work before the thread pointer is initialized. So I think we're in good shape for transitioning towards Cortex-M support. Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: status of armhf asm with VFP instructions 2015-10-15 23:16 ` Szabolcs Nagy 2015-10-15 23:58 ` Szabolcs Nagy 2015-10-16 0:00 ` Rich Felker @ 2015-10-16 6:42 ` Khem Raj 2 siblings, 0 replies; 10+ messages in thread From: Khem Raj @ 2015-10-16 6:42 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 3442 bytes --] > On Oct 15, 2015, at 4:16 PM, Szabolcs Nagy <nsz@port70.net> wrote: > > * Rich Felker <dalias@libc.org> [2015-10-15 18:44:25 -0400]: >> On Fri, Oct 16, 2015 at 12:33:20AM +0200, Szabolcs Nagy wrote: >>> it is not possible to write arm asm in a way that pleases all >>> assemblers, here is a summary of the problems relevant to musl: >>> >>> some instructions can be written in several ways since UAL >>> (= unified assembler language) was introduced to unify arm >>> and thumb instruction mnemonics. >>> >>> in case of armhf VFP instructions musl uses the following ones >>> in hand written asm: >>> >>> hex ual old >>> >>> eeb1XacX vsqrt.f32 fsqrts >>> eeb1XbcX vsqrt.f64 fsqrtd >>> eeb0XacX vabs.f64 fabss >>> eeb0XbcX vabs.f64 fabsd >>> eef1Xa10 vmrs fpscr mrc p10,7,.. >>> eee1Xa10 vmsr fpscr mcr p10,7,.. > > sorry, for reading/writing fpscr fmrx/fmxr can be used in the > old syntax instead of vmrs/vmsr, but clang does not know > those names. > >>> the issues: >>> >>> (1) binutils gas rejects UAL VFP instructions unless either >>> the -mfpu=<vfp variant> option is passed or the asm source >>> has '.fpu <vfp variant>' directive, the old names work though >>> (if the target is hard float). A gcc toolchain built >>> --with-float=hard but without --with-fpu=<vfp variant> does not >>> pass -mfpu to the assembler. >>> >>> (2) Most UAL mnemonics were added in binutils 2.18, older >>> binutils only supports the old syntax. Some UAL mnemonics were >>> added later, vmrs and vmsr only appear in binutils 2.21 >>> (released in 2010). >>> >>> (3) The clang assembler does not support old mnemonics in general >>> but includes a few exceptions (e.g. fabs and fsqrt are supported, >>> but not the mrc or mcr coprocessor instructions). >>> >>> Using UAL asm is the clean solution, but then to fix (1) we >>> should have .fpu directives in the asm files. >>> >>> However the conflict between (2) and (3) means that fenv code >>> using vmrs and vmsr either drops support for old binutils gas >>> or the clang assembler. >> >> It seems we're already using the new forms vsqrt and vabs in >> src/math/armhf/*.s. So using vmrs/vmsr presumably will not break >> support for any toolchains that work now. >> > > vmrs/vmsr can break on old binutils versions (2.18 - 2.20) and > 2.20 is not that ancient.. is that ok? > >> I think the reason this went unnoticed for so long is that Aboriginal >> Linux (the only real user of the ancient binutils, due to GPL v2 vs v3 >> issues) does not use the armhf ABI at all; it only targets standard >> EABI for which musl does not use any math/fenv asm. >> >> So I'm ok with the fpu-related changes proposed, but I'm not sure what >> to do about UAL issues elsewhere. Right now we have a lot of files >> with instructions written as .word in them which is a mess and which >> precludes Cortex-M (thumb2-only) targets. These are files which need >> to be built even on non-hf, so changing them presumably will break >> support for old binutils. As a workaround, users needing old binutils >> could perhaps misuse the ASM_CMD var in the Makefile to run a sed >> script that replaces UAL with old-syntax asm. Or someone could patch >> the old binutils to accept UAL... >> > > most likely ual is the long term solution. thats right. > > maybe it is best to switch to ual and then write that script > if ppl with old binutils run into issues. agree here. [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 204 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-10-19 6:12 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-15 22:33 status of armhf asm with VFP instructions Szabolcs Nagy 2015-10-15 22:44 ` Rich Felker 2015-10-15 23:16 ` Szabolcs Nagy 2015-10-15 23:58 ` Szabolcs Nagy 2015-10-19 6:12 ` Rich Felker 2015-10-16 0:00 ` Rich Felker 2015-10-16 0:33 ` Szabolcs Nagy 2015-10-16 1:03 ` Rich Felker 2015-10-16 3:23 ` Rich Felker 2015-10-16 6:42 ` Khem Raj
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).