On Thursday, 30 April 2015 at 23:03:48 UTC, Mike wrote:
On Thursday, 30 April 2015 at 20:45:28 UTC, Martin Nowak wrote:
* 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.
How about providing functions for copying data and zeroing bss ?
-In my startup file, I use functions for that, because they're
optimized pretty well.
The code is very similar to my optimized #define in C.
Most Cortex-M microcontrollers allow you to set the clock
frequency.
It's a good idea to do this before you start copying a large
block of data, because that means the startup time is quicker.
The drawback is that ... CMSIS wants to write in the BSS (the
CoreClockFrequency variable, for instance), and that's just
erased when BSS is cleared - I wish they had just reserved a
hardware register for these 4 variables.
Anyway, personally, I like the startup file to contain the
data/bss init, because I might want to customize it. My startup
files allow you to override Reset_Handler and each exception,
which means you don't even have to modify the startup file. That
means one less template-file to copy to every project.
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.
Agree.
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.
Agree.
Linker-scripts can usually be written so they work well with
multiple devices from the same vendor. I'm not talking about
specific RAM and Flash settings, but the main body of the linker
script. Small 3 .. 8 line scripts can then include the body,
which provides all the standard stuff. So here I'm talking about
a body linker-script could be provided for each vendor (not each
device family or each device). If each device family or device
requires different attention, then I suggest something like
Vendor:DeviceFamily:DeviceSpecific.
Thus it would not be overwhelming writing one linker script per
vendor and it would be fairly straight-forward for the casual
user to add a new device or even a device family if needed.
I'd also prefer having the linker-script in a location, outside
each project (because I have many projects and I hate duplicates
and updating each duplicate each time I find something that needs
to be changed).
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?
Most asserts on microcontrollers I've seen are just implemented
as while(1){}
-But one could probably also trigger the debugger (BKPT),
HardFault or RESET if necessary.
Perhaps the default could be while(1){} and then
version(ASSERT_BKPT) could be used to add a breakpoint before
that while(1){}. Thus --version=ASSERT_BKPT could be specified on
the command-line.
Would it be possible to 'extend' an existing assert; eg. the user
might want to be notified via the U(S)ART ?
