[GSoC] 'Independency of D from the C Standard Library' progress and update thread

[Stefanos Baziotis]

On Friday, 28 June 2019 at 12:11:10 UTC, Stefanos Baziotis wrote:
>
> An update regarding the project. There was a lot of turbulance 
> in this project, so I'm sorry I did not post earlier.
>

I'm now moving to weekly updates. Before the updates of what I 
did, let me update
you on the state of the project.
The focus of the project has changed in the following ways:
- No assembly
- Generic and portable code
- Focus on LDC and GDC
- PRs to core.experimental

This week
==========
- Because of the above, this week I started with the replacement 
of all the ASM
with SSE intrinsics and providing simple implementation for when 
SIMD is not available.
The goal was not only the replacement but also the optimization 
for LDC.
Eventually (either as part of this summer or of future work), the 
simple implementation
should not be so "simple" and be one that helps LDC and GDC 
optimize it without
the need to be explicitly in `version (D_SIMD)`.

- I moved the functions in a common repository: 
https://github.com/baziotis/Dmemutils

- I made a draft PR in the D runtime: 
https://github.com/dlang/druntime/pull/2662
(Thanks to lesderid and wilzbach for their help).


* A note on intel-intrinsics:
I first tried intel-intrinsics for the use of intrinsics.
That worked great in LDC (I think it's focused on LDC),
not so good in DMD and not at all in GDC.
Firstly, in DMD it didn't work meaning it generated "wrong" code. 
The problem is
that doing a load/store with intel-intrinsics and doing a 
load/store with load/storeUnaligned of core.simd does not 
generate the same code.
This is important for Dmemmove because it is very
sensitive to the order of instructions because of the overlap 
(e.g. here [1])

So, I made my own intrinsics that are different depending on if 
we use DMD or LDC.

Regarding GDC, I just couldn't get it compile.

My purpose is not to disparage intel-intrinsics, it's a great 
library. This was just
my experience, in which maybe I did something wrong. I tried also 
to contact
the creator, becase maybe he has some insight.

* A note on GDC intrinsics:
GDC now compiles to the naive version, because I don't know of 
load/storeUnaligned
respective functions for GDC.
Iain told me that I could use the i386 intrinsics
(which as far as I know is this [2]), but I could not use them in 
GDC.

Blockers
========

Only what I said above regarding GDC intrinsics.


[1] 
https://github.com/baziotis/Dmemutils/blob/master/Dmemmove/Dmemmove.d#L267
[2] 
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/X86-Built-in-Functions.html



Next week
==========
Sadly, I don't know. According to my schedule, the work on the 
allocator should have
started. But, there were a couple of problems in the project, 
which changed its focus and so there were things that had to be 
done that were not initially planned.
That means that the allocator, that should have started by now, 
hasn't.

Other than that, the plans for the allocator changed when the 
project started to things
that I'm not fully experienced with (changed from malloc(), 
free() etc. to using the std.experimental.allocator).

So, how the project will continue is currently an open discussion.

If std.experimental.allocator is interesting to the community, 
I'm happy to discuss it
and learn how to continue.

If we fall back to classic malloc(), free() implementations, this 
is something
that can't be fully done in the time available. To make a 
complete replacement
of malloc() et al, one has to make a serious attempt on 
multi-threading and optimization.

_HOWEVER_, one possible alternative is to provide minimalistic 
versions of those functions
for "baremetal" systems. That means either embedded systems or 
WASM. I think that this
is interesting, meaning, to not have a dependency on the libc 
there and have minimal
(regarding resources and code) implementations.