Hi Mike, thanks for the extensive reply.
On Wednesday, 22 January 2014 at 04:13:41 UTC, Mike wrote:
To paraphrase, if you really want the best of what D has to
offer, you'll need to implement a good part of the runtime.
But I argue, not all of it.
Well, even C with D's metaprogramming would be a big win. But
picking-and-choosing runtime-supported features would be even
better.
I'm working on a bare-metal ARM Cortex-M _very minimal_ port of
the D runtime with an emphasis on "minimal". I just created my
repository and started documenting my progress [2]. It's in
the very early stages, and I am quite new to D, so I have quite
a ways to go, but my goals align with your stated intent.
I'm able to do structs with just a few line of stubbed TypeInfo
stuff in my object.d. I've reduced it to 21 lines [3].
I've also implemented a simple malloc/free and am able to do
classes, but I haven't tested any D feature thoroughly yet.
As the Cortex-M microcontrollers have very little FLASH memory,
it is also important for me to reduce the executable size, and
I'm focusing on that in my project. I've been able to get my
"Hello, World!" program down to 68 bytes, with 15 of those
bytes being the "Hello, World!\r\n" string constant.
This is quite cool.
I noticed you're using GNU make. On Windows, D uses Digital Mars
make, which is quite minimalistic. I've considered writing a
custom build tool for SlimD, but now that I think about it, I
think GNU make will suffice.
I would really like to see a more modular D runtime in which
features of the D language can be selectively chosen. This is
one of my goals.
I thin, a modular, well-organized, well-abstracted, D runtime
will facilitate both your stated intention and my goals to
bring D to the microcontroller world, and will also facilitate
bringing D to a variety of other platforms as well. But, I
really think the D runtime needs some refactoring to achieve
this.
So, you think it would be better to make the standard D runtime
more customizable in this regard, instead of putting together a
new one?
I believe the biggest factor for why someone would want to use a
lighter runtime is the garbage collector. I think a lot of the
code in Druntime still assumes that a GC is present... and then
I'm not sure the D maintainers would want to maintain support for
such rarely-needed features such as a custom entry point. (Case
in point: pragma(entrypoint, symbol) has been broken since DMD
2.061.)
In my project, I'm also trying to do everything in D ("Look,
Walter!, No C!"). I'd like to see all the references to C's
baggage left separate from the rest of the D runtime, included
"size_t".
What's wrong with size_t?
On Windows, it is quite necessary if you want to target both
32-bit and 64-bit (and if you want to do system-wide DLL
injection, that's an absolute requirement).
Phobos will not be useful to me unless I can find some way to
make it lighter and GC-Free. I'll probably just end up taking
pieces of it. I would _really_ like to have the whole concept
of a GC decoupled from D. There are many suitable memory
models to use with D, and the memory model seems like it should
be a platform feature, not a language feature. But, I don't
know how one could accomplish that without some changes to the
language itself, and it seems the core language folks have
their hands full.
There have been discussions of a compiler switch or @attribute to
make implicit allocations (such as array literals, or heap
closures) generate compiler errors.
Yes, this definitely aligns with my goals, see my comment above
about a modular D runtime. But I wouldn't necessarily be in
favor of adding switches to the compiler, as I don't like to be
at the mercy of the compiler implementers.
I agree that hacking or forking the compiler should be avoided
and left as a last resort. By "switches" I meant per-project
(e.g. makefile) options.
Does D have to support Unilink, or does Unilink have to support
D?
Well, neither. The "framework" would need to support linking your
project with Unilink if you indicate that preference in your
project's build configuration.
There was an interesting discussion, recently, that might
relevant to this. I encourage you to check it out and maybe
post your thoughts [5]. It's more about the required TypeInfo
stuff, but nevertheless related to the -betterC idea.
Well, as long as the linker throws away all compiler-emitted
TypeInfo objects if your code doesn't use them, there doesn't
seem to be any practical problem with them, is there?
LCD has some pragmas that seem to align with the general idea
of what you're looking for [6], and GDC has the
-fno-emit-moduleinfo which is essential for what I'm doing.
ModuleInfo IS a problem, though. It is like a parasite of
interdependence: it points towards all class information (for
Object.factory), which itself pulls in all virtual methods of all
classes in your program (through the Vtable). That means that
anything that any virtual method in your program uses, regardless
if you use that class or not, WILL end up in the executable. Ugh!
I'd love to contribute to something like this in anyway I can,
but I'd probably be asking more questions than providing help.
At the moment, my contribution is in the form of my repository
[2]. I hope it will have some influence in the long run, and
maybe when I come up to speed on the language I'll be able to
contribute more.
Maybe we could join efforts, even though our goals target
different platforms :)
What do you say to this repository structure (inspired by the
Windows DDK):
Users start a new SlimD (or whatever name) project by adding a
Makefile to their project directory. The makefile configures the
project's requirements (target platform, used D features, linker
of choice) and source files (*.d by default), and includes the
main SlimD makefile, which does all the work based on the given
configuration.
