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

[Mike Franklin]

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