On Thursday, 30 April 2015 at 00:14:18 UTC, Martin Nowak wrote:
Wonder if it makes more sense to start from zero and add as few
files as
possible.
Druntime doesn't do much useful stuff for a µC anyhow.
- GC and rt.lifetime (new, arrays)
- Moduleinfo
- EH unwind support
- AA implementation
- vectorized array ops
- core.time/sync/thread/demangle
What might be interesting is this.
- core.bitop
- maybe core.atomic
- some gcc simd module
- libc bindings for core.stdc.math and core.stdc.stdio for
printf
Starting from zero appeals to my way of thinking. I've made
several attempts at this both on the PC and for microcontrollers,
so please allow me to offer my thoughts on the idea:
If starting from zero, I recommend narrowing the scope to simply
runtime initialization. IMO, if one can get to main with a small
subset of the language ready for use, the rest is mostly icing on
the cake.
While this may seem simple to achieve, I think it will raise a
few questions that will need answering.
* Can ModuleInfo be leveraged, without introducing overhead, to
call module constructors and static constructors? They might be
useful for hardware initialization.
* Is dynamic memory allocation a requirement of D, or a library
feature?
* Does D need the C runtime, or can it init on its own?
* Should the C standard library bindings be part of the runtime,
or exist as an external Deimos library? Either way they can
still be used by the runtime, I'm just suggesting that they
should be encapsulated.
* What will be done about TypeInfo for now? It's causing me some
serious code-bloat problems. See
http://forum.dlang.org/post/[email protected]
* Is data and bss initialization part of the runtime, or
delegated to toolchain, silicon, and BSP vendors?
I think runtime initialization is a relatively simple task, but
would still present a few challenges, choices, and even a few
problems. However, due to the fact that it's narrow in scope, I
suspect it would be a likely success and could put some momentum
in the right direction.
Mike
