ARM Cortex-M Microcontroller startup files

[Mike via Digitalmars-d]

On Thursday, 30 April 2015 at 20:45:28 UTC, Martin Nowak wrote:

>> 
>> * Can ModuleInfo be leveraged, without introducing overhead, 
>> to call
>> module constructors and static constructors?  They might be 
>> useful for
>> hardware initialization.
>
> Currently D sorts modules by initialization order,which 
> requires every
> moduleinfo to contain an array of imported modules. Quite a lot 
> of RAM
> for a nice to have feature, so we should drop it or at least 
> provide a
> -fno-moduleinfo switch.

Agreed.  Luckily -fno-emit-moduleinfo is already implemented, but 
without a ModuleInfo implementation, this will be a required 
switch to get a successful build.

>> * Is dynamic memory allocation a requirement of D, or a 
>> library feature?
>
> Definitely a library feature, though many language features, 
> like array
> appending, won't work without it (delegate closures won't even 
> work
> without a GC).

Good!

>
>> * Does D need the C runtime, or can it init on its own?
>
> It shouldn't need a C runtime.

Good!

>
>> * 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.
>
> It doesn't cost you anything to include the bindings in a 
> release, they
> could be maintained in a separate project if that helps.

Yes, that helps.  There's already a project created in Deimos: 
https://github.com/D-Programming-Deimos/libc

>
>> * 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
>
> Implement a -fno-rtti switch for GDC.

What about https://issues.dlang.org/show_bug.cgi?id=12270?  
...perhaps in addition to -fno-rtti.

>
>> * Is data and bss initialization part of  the runtime, or 
>> delegated to
>> toolchain, silicon, and BSP vendors?
>
> We should provide appropriate linker scripts and do the 
> initialization.

The linker script can give the location of the data and bss 
segments.  My question is really about whether or not the 
druntime implementation should assume responsibility for loading 
the data segment from flash and zeroing bss.  I suppose that 
should be left to the vendor's BSP, not part of druntime itself.

I guess what I'm trying to articulate is that currently when you 
download an MCU toolchain, it contains a collection of things 
from many different vendors (GCC, binutils, newlib, startup 
files, linker scripts, multilibs, etc...), all in one package.  I 
recommend, not doing that with this druntime.  druntime should 
just be the implementation of D language features for 
microcontrollers.

Once a minimal druntime is created, some other effort can take 
that druntime and package it with a compiler, linker, startup 
files, linker scripts, c standard library, debugger, flash 
programmer, etc... and make a convenient downloadable/installable 
package for immediate use.

Assuming that is an appropriate strategy, what does the first 
druntime release look like.
* For example: What will `assert` do?  Is that just a stub to be 
implemented by the programmer?
* What are druntime's "syscalls" that need to be implemented by 
the silicon vendor, BSP, and/or programmer (I'm using a newlib 
port analogy here)?  What does druntime do, and what does it 
require its users to do?

My mind is currently seeing an object.d with some aliases and 
some TypeInfo stubs, __entrypoint.d, and a minimal rt/dmain2.d.  
That will give you a build and get you to main() for a trivial 
program, but you'll start getting linker errors, and potentially 
runtime errors, as you begin to employ more of D's features; even 
the simple ones like `assert`.

That is one of the things that's making it difficult for me to 
simply get a working language.  druntime has features that really 
seem to be more "standard library" features (e.g. `assert`), but 
they are mingled with the language implementation.  It, 
therefore, makes it a challenge to get a build, separate 
concerns, and delegate implementation to users.

Mike