utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
slavo5150 at yahoo.com
Fri May 10 17:16:24 UTC 2019
On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote:
> - Memcmp, memcpy, memmove and memset are named equal, copy,
> copyBackward and fill respectively. I just wanted to create
> native implementations that are bit safer than their C
> counterparts. So they do the same job, but accept void
> instead of pointers. There are also templated functions with
> the same names, that work with ranges.
> I‘m not very comfortable with GCC‘s inline asm and it doesn‘t
> support naked asm as DMD does, so I put asm in the .S files and
> compile them separately. But I‘m fine with inline asm too. A
> problem with the inline asm is that it should be written in
> several versions since DMD uses different calling conventions
> (unless we use extern(C)) and GDC and LDC use different asm
Yeah, that is indeed unfortunate, and something I'll have to
consider. I have had to write 3 different inline-asm
implementations for some of my exporations, and didn't find it to
be too bad. I very much prefer to read the D with the inline-asm
than a straight assembly file. I've studied the ARM
implementation of memcpy a little, and it's quite hard to follow.
I'd like for the D implementations to make such code easier to
understand and maintain.
> Tanya contains pretty much stuff now and I‘m just thinking to
> split it in a smaller parts (of a reasonable size), that are
> probably interesting for other people, who is ready to
> contribute, so I don‘t have to maintain everything myself. I
> don‘t know exactly what goes into this more „low-level“
> library, we can always talk about it.
Yes, I'm still working that out too. If you apply the rule that
it should not require anything from druntime, the C standard
library, or dynamic memory allocation, it does eliminate quite a
bit, and narrows the scope. What I'm trying to do now is just
focus on the obvious, and hopefully with that out of the way the
rest will begin to reveal themselves.
> - OS API
> Not sure if it belongs to the scope of utilD. Some time ago it
> became clear to me, that while C has functions for dynamic
> memory management, it uses them internally very seldom. Instead
> it lets the user to allocate the memory. So there functions
> char *if_indextoname(unsigned int ifindex, char *ifname);
> that take an output buffer as the last argument. The same can
> be done with output ranges in D, so these system functions can
> be rewritten in D with a better interface. Whereby I should say
> that tanya‘s range definitions differ from Phobos.
Yes, I like that. The buffer and memory management is then
delegated outside of the library. That, IMO, makes the library
more broadly useful. Fundamental algorithms (e.g. from
std.algorithm, std.range, etc.) that can operate on memory
buffers/ranges in this way would be good candidates for utiliD,
IMO. But I'd want them to meet the criteria of being fundamental
and broadly useful; not too specialized. Specialized algorithms
that are designed for specific problem domains should probably go
in a library designed for that problem domain.
> - meta
> Another thing probably interesting for utilD library is
> meta-programming. Tanya has „tanya.meta“ package which contains
> templates similar to to std.traits and std.meta + some nice
> extras like Union/Intersection/Difference working on sets of
> types, that are inspired by Boost Hana. This part is completely
> independent (from Phobos and the rest of tanya) and can even be
> a separate library.
I'm thinking metaprogramming modules and packages are good
candidates for utilitD as long as they are broadly useful. I see
them more as extensions of the language than a library. Though,
in a way, that's basically what libraries are too. I'll have to
think about this some more but at the moment I'm leaning towards
inclusion in utiliD.
More information about the Digitalmars-d-announce