* Cortex-M support @ 2018-09-13 0:39 Pierluigi Passaro 2018-09-13 0:41 ` Christopher Friedt 0 siblings, 1 reply; 6+ messages in thread From: Pierluigi Passaro @ 2018-09-13 0:39 UTC (permalink / raw) To: musl Hi, I was wondering if musl already supports Cortex-M or not. Thanks Regards Pier ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cortex-M support 2018-09-13 0:39 Cortex-M support Pierluigi Passaro @ 2018-09-13 0:41 ` Christopher Friedt 2018-09-13 0:52 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: Christopher Friedt @ 2018-09-13 0:41 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 302 bytes --] It does :) Although only through thumbv2, so there would be some assembly rework required for cortex-m0. On Wed., Sep. 12, 2018, 8:39 p.m. Pierluigi Passaro, < pierluigi.passaro@phoenixsoftware.it> wrote: > Hi, > I was wondering if musl already supports Cortex-M or not. > Thanks > Regards > Pier > [-- Attachment #2: Type: text/html, Size: 574 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cortex-M support 2018-09-13 0:41 ` Christopher Friedt @ 2018-09-13 0:52 ` Rich Felker 2018-09-13 1:06 ` Pierluigi Passaro 0 siblings, 1 reply; 6+ messages in thread From: Rich Felker @ 2018-09-13 0:52 UTC (permalink / raw) To: musl On Wed, Sep 12, 2018 at 08:41:15PM -0400, Christopher Friedt wrote: > It does :) Although only through thumbv2, so there would be some assembly > rework required for cortex-m0. There's also no fdpic ABI support yet, so it's only going to be nonshared text. For bare-metal/pseudo-kernel or a single-program userspace on Linux it probably doesn't matter, but if you're trying to run a real userspace it's very inefficient. I'd like to add fdpic soon. Also, I think it won't work unless the kernel traps and emulates the cp15 thread-pointer access, since we don't support the get_tls syscall. (We can add it if needed, but the whole idea of the syscall is silly since it's no more efficient than trapping on the kernel side, but support for switching to it makes userspace slower/heavier. Rich > On Wed., Sep. 12, 2018, 8:39 p.m. Pierluigi Passaro, < > pierluigi.passaro@phoenixsoftware.it> wrote: > > > Hi, > > I was wondering if musl already supports Cortex-M or not. > > Thanks > > Regards > > Pier > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cortex-M support 2018-09-13 0:52 ` Rich Felker @ 2018-09-13 1:06 ` Pierluigi Passaro 2018-09-13 1:24 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: Pierluigi Passaro @ 2018-09-13 1:06 UTC (permalink / raw) To: musl This looks a good starting point: I'm targeting Cortex-M4 / M7 and maybe Cortex-R. I'm inspecting the code and trying to get a build. I have a few questions: 1) NOMMU support looks disabled I'm wondering if in the file arch/arm/reloc.h, some code should be added (or not). Somthing like #if (__ARM_ARCH_PROFILE == 'M') || (__ARM_ARCH_PROFILE == 'R') #define DL_NOMMU_SUPPORT 1 #endif 2) trying to enable hardfp support, the build fails - fabs try calling vabs.f64 assembly instruction - sqrt try calling vsqrt.f64 assembly instruction As far as I understood, vXXX.f64 instructions are only available with single/double precision FPU, not with half precision. I'm wondering if the assembly optimization should be wrapped by something like #if ... && (__ARM_FP > 7) I'm still trying to setup a reasonable build/test environment, but I suppose I need some suggestions on how to proceed. Any hints? Thanks Regards Pier On 13/09/2018 02:52, Rich Felker wrote: > On Wed, Sep 12, 2018 at 08:41:15PM -0400, Christopher Friedt wrote: >> It does :) Although only through thumbv2, so there would be some assembly >> rework required for cortex-m0. > There's also no fdpic ABI support yet, so it's only going to be > nonshared text. For bare-metal/pseudo-kernel or a single-program > userspace on Linux it probably doesn't matter, but if you're trying to > run a real userspace it's very inefficient. I'd like to add fdpic > soon. > > Also, I think it won't work unless the kernel traps and emulates the > cp15 thread-pointer access, since we don't support the get_tls > syscall. (We can add it if needed, but the whole idea of the syscall > is silly since it's no more efficient than trapping on the kernel > side, but support for switching to it makes userspace slower/heavier. > > Rich > > >> On Wed., Sep. 12, 2018, 8:39 p.m. Pierluigi Passaro, < >> pierluigi.passaro@phoenixsoftware.it> wrote: >> >>> Hi, >>> I was wondering if musl already supports Cortex-M or not. >>> Thanks >>> Regards >>> Pier >>> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cortex-M support 2018-09-13 1:06 ` Pierluigi Passaro @ 2018-09-13 1:24 ` Rich Felker 2018-09-13 9:43 ` Szabolcs Nagy 0 siblings, 1 reply; 6+ messages in thread From: Rich Felker @ 2018-09-13 1:24 UTC (permalink / raw) To: musl On Thu, Sep 13, 2018 at 03:06:52AM +0200, Pierluigi Passaro wrote: > This looks a good starting point: I'm targeting Cortex-M4 / M7 and > maybe Cortex-R. > I'm inspecting the code and trying to get a build. > I have a few questions: > > 1) NOMMU support looks disabled > I'm wondering if in the file arch/arm/reloc.h, some code should be > added (or not). > Somthing like > #if (__ARM_ARCH_PROFILE == 'M') || (__ARM_ARCH_PROFILE == 'R') > #define DL_NOMMU_SUPPORT 1 > #endif This is only going to matter if you want to do dynamic linking, which is *really* bad without fdpic/shared-text. You'll have a whole copy of each shared lib for each process. Once fdpic support is added and dynamic linking makes sense, it should probably be fixed, but I'd like to rethink some of this and make it so the dynamic linker doesn't need to be aware of whether it's nommu-compatible. > 2) trying to enable hardfp support, the build fails > - fabs try calling vabs.f64 assembly instruction > - sqrt try calling vsqrt.f64 assembly instruction > As far as I understood, vXXX.f64 instructions are only available > with single/double precision FPU, not with half precision. > I'm wondering if the assembly optimization should be wrapped by > something like > #if ... && (__ARM_FP > 7) > > I'm still trying to setup a reasonable build/test environment, but I > suppose I need some suggestions on how to proceed. > Any hints? Configurations where float and double are anything other than IEEE single and double with IEEE-conforming semantics, or where long double does not have IEEE-conforming semantics, are not supported/supportable by musl, by intent. I would assume there's some way to configure the compiler to offer a separate half-precision hardfloat type on an otherwise soft-float EABI target with conforming float/double, but if not this is a compiler deficiency that makes it impossible to use at this time. There were some SH4 models that also had this limitation (only single-precision FPU) and since GCC's only profile for them redefines double as single, rather than doing hard-single and soft-double, we just don't support hardfloat at all on them. In principle you could build musl as soft-float (with a softfloat toolchain) but use a separate toolchain with half-precision hardfloat for your applications. There would be no way to call stdlib interfaces that take floating point arguments without a glue layer though. Use of setjmp/longjmp might also be problematic (failure to restore float regs) but this could possibly be mitigated. Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Cortex-M support 2018-09-13 1:24 ` Rich Felker @ 2018-09-13 9:43 ` Szabolcs Nagy 0 siblings, 0 replies; 6+ messages in thread From: Szabolcs Nagy @ 2018-09-13 9:43 UTC (permalink / raw) To: musl * Rich Felker <dalias@libc.org> [2018-09-12 21:24:10 -0400]: > On Thu, Sep 13, 2018 at 03:06:52AM +0200, Pierluigi Passaro wrote: > > 2) trying to enable hardfp support, the build fails > > - fabs try calling vabs.f64 assembly instruction > > - sqrt try calling vsqrt.f64 assembly instruction > > As far as I understood, vXXX.f64 instructions are only available > > with single/double precision FPU, not with half precision. i think half precision is used incorrectly here: single is 32bit half is 16bit (arm has half precision instructions so mixing these can be confusing) > > I'm wondering if the assembly optimization should be wrapped by > > something like > > #if ... && (__ARM_FP > 7) > > > > I'm still trying to setup a reasonable build/test environment, but I > > suppose I need some suggestions on how to proceed. > > Any hints? > > Configurations where float and double are anything other than IEEE > single and double with IEEE-conforming semantics, or where long double > does not have IEEE-conforming semantics, are not supported/supportable > by musl, by intent. I would assume there's some way to configure the > compiler to offer a separate half-precision hardfloat type on an > otherwise soft-float EABI target with conforming float/double, but if > not this is a compiler deficiency that makes it impossible to use at > this time. > > There were some SH4 models that also had this limitation (only > single-precision FPU) and since GCC's only profile for them redefines > double as single, rather than doing hard-single and soft-double, we > just don't support hardfloat at all on them. > > In principle you could build musl as soft-float (with a softfloat > toolchain) but use a separate toolchain with half-precision hardfloat > for your applications. There would be no way to call stdlib interfaces > that take floating point arguments without a glue layer though. Use of > setjmp/longjmp might also be problematic (failure to restore float > regs) but this could possibly be mitigated. note that a large part of the float code in libc is in the math library which expects efficient double arithmetics, i plan to rewrite the most important single precision math functions using double arithmetics, this gives significant benefits on all systems except ones with single precision only hw. (for soft float systems using int arithmetics is the best, for single prec only systems using single prec arithmetics is, there are also many places where musl could be better size optimized, but musl does not have such implementation variations for maintainability reasons.) ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-09-13 9:43 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-13 0:39 Cortex-M support Pierluigi Passaro 2018-09-13 0:41 ` Christopher Friedt 2018-09-13 0:52 ` Rich Felker 2018-09-13 1:06 ` Pierluigi Passaro 2018-09-13 1:24 ` Rich Felker 2018-09-13 9:43 ` Szabolcs Nagy
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).