Symmetry Autumn of Code

[Zheng Luo (Vic)]

On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote:
> So, IMO, if you need to link in a library or object file that 
> was not compiled from D code, then you're cheating.  This is 
> also one of the reasons why I suggested re-implementing 
> software building blocks such as `memcpy`, `memset`, `malloc`, 
> `free`, etc. in D as another potential project for the Autumn 
> of Code.
>
> So, to keep this software rasterizer project within scope, I 
> suggest creating naive implementations of those functions in D 
> for now to stay true to spirit of the project (no dependencies, 
> everything in D), and "make the point".  You can those software 
> building blocks in their own module, and let the user of the 
> software rasterizer library link it their own implementation if 
> they wish to deviate from the spirit of the proposal.


That's actually what I am doing now. Currently I wrote a short 
script to ensure the symbols in the main project within a subset 
(https://github.com/htfy96/rasterizer-d-embed/blob/master/check-no-und-symbols.sh). I also plan to create some basic dependency-free building blocks like memcpy/memset/memcmp (already implemented in https://github.com/htfy96/d-rlib) and malloc/free (maybe reusing some building blocks from std.experimental.allocator?) in separate projects. Regarding floating point operations, I plan to use dmd.builtins/ldc.builtins instead of linking with libm.

Above this well-defined set of primitives, the core rasterizer 
will be built, so that  users can plug in their own 
implementations or use the default implementation when libc/libm 
is linked.