utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
slavo5150 at yahoo.com
Fri May 10 23:58:37 UTC 2019
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:
Yes, that bit me a while back when I was doing some bare-metal
ARM Cortex-m development
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:
More information about the Digitalmars-d-announce