On Friday, 10 May 2019 at 17:55:53 UTC, Johan Engelen wrote:
Why would you use inline assembly ? (generalizing but: extremely bad portability, bad performance, bad readability)
The only reason to use inline assembly is to achieve something that can't be achieved directly with D. For example, prior to the introduction of `volatileLoad` and `volatileStore` inline assembly was required to achieve `volatile` semantics.
For memcpy and memcmp, one would first attempt to write a good implementation in straight D, but if the compiler doesn't generate good code for it, it would be appropriate to take control and provide an implementation in inline assembly.
I don't know how a proper assembly implementation would not be performant. Perhaps you could elaborate.
Recent discussion on LLVM mailinglist about the problem of the optimizer recognizing memcmp implementation and substituting it with a call to memcmp: https://lists.llvm.org/pipermail/llvm-dev/2019-April/131973.html
Yes, that bit me a while back when I was doing some bare-metal ARM Cortex-m development https://forum.dlang.org/post/clptjumxigcozfcyh...@forum.dlang.org
For compilers that already provide an optimized intrinsic implementation for memcpy none of this is necessary; one could simply add a naive implementation, the compiler would recognize it, and replace it with their optimized version. DMD, to my understanding, is not one of those compilers.
One of the goals is to no longer require a C toolchain to build D programs. If the compiler already provides intrinsics without needed a C standard library, Great!
The other goal is to explore what D could improve upon with its design-by-introspection features and compiler guarantees (e.g. `pure` and `@safe`). My initial exploration into that can be found at https://github.com/JinShil/memcpyD I find it much easier to read D code like that than something like this: https://github.com/opalmirror/glibc/blob/c38d0272b7c621078d84593c191e5ee656dbf27c/sysdeps/arm/memcpy.S
Mike
