utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
slavo5150 at yahoo.com
Sat May 11 00:09:08 UTC 2019
On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote:
> I'm not 100% sure it's a good idea to implement memcpy in D
> just to prove that it can be done / just to say that we're
> independent of libc. Libc implementations of fundamental
> operations, esp. memcpy, are usually optimized to next week and
> back for the target architecture, taking advantage of the
> target arch's quirks to maximize performance. Not to mention
> that advanced compiler backends recognize calls to memcpy and
> can optimize it in ways they can't optimize a generic D
> function they fail to recognize as being equivalent to memcpy.
> I highly doubt a generic D implementation could hope to beat
> that, and it's a little unrealistic, given our current manpower
> situation, for us to be able to optimize it for each target
> arch ourselves.
I understand that point of view. Indeed we have to demonstrate
benefit. One benefit is to not have to obtain a C toolchain when
building D programs. That is actually quite an inconvenient
barrier to entry when cross-compiling (e.g. for developing
microcontroller firmware on a PC).
I'm also hoping that a D implementation would be easier to
comprehend than something like this:
https://github.com/opalmirror/glibc/blob/c38d0272b7c621078d84593c191e5ee656dbf27c/sysdeps/arm/memcpy.S The D implementation still has to handle all of those corner cases, but I'd rather read D code with inline assembly sprinkled here and there than read the entire thing in assembly. The goal with the D implementation would be to minimize the assembly.
For compilers that already do something special with memcpy and
don't require a C standard library, there's no reason to do
anything. My initial exploration into this has shown that DMD is
not one of those compilers.
>> On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote:
>> > Whereby I should say that tanya‘s range definitions differ
>> > from Phobos.
> I'm a bit uncomfortable with having multiple, incompatible
> range definitions. While the Phobos definition can be argued
> whether it's the best, shouldn't we instead be focusing on
> improving the *standard* definition of ranges, rather than
> balkanizing the situation by introducing multiple, incompatible
> definitions just because? It's one thing for Andrei to propose
> a std.v2 that, ostensibly, might have a new, hopefully
> improved, range API, deprecating the current definition; it's
> another thing to have multiple alternative, competing
> definitions in libraries that user code can choose from. That
> would be essentially inviting the Lisp Curse.
Agreed. We should decide on one consistent definition. I don't
know what that looks like right now. I'm more focused on
low-level details right now. I do, however, like the idea of
delegating the memory management (allocation/deallocation)
outside of the library. If that's not feasible for some reason,
then I would suggest it not be included in utiliD. I don't want
dynamic memory allocation in utiliD; that should go into a
higher-level library that may import utiliD.
More information about the Digitalmars-d-announce