ARM Cortex-M Microcontroller startup files

Mike via Digitalmars-d digitalmars-d at puremagic.com
Thu Apr 30 04:30:31 PDT 2015


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/quemhwpgijwmqtpxukiv@forum.dlang.org
* 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


More information about the Digitalmars-d mailing list