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/[email protected]
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
