utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries

Mike Franklin 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: 
> 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/clptjumxigcozfcyhzzx@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





More information about the Digitalmars-d-announce mailing list