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
syntax.
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
like:
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.
Mike
