Symmetry Autumn of Code
Zheng Luo (Vic)
vicluo96 at gmail.com
Mon Jul 23 09:52:54 UTC 2018
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.
More information about the Digitalmars-d-announce
mailing list