On Wednesday, 22 January 2014 at 02:18:43 UTC, Vladimir Panteleev
wrote:
Hi,
What's the current situation of using D without Phobos/Druntime?
I created a minimal, no runtime, "hello world" program [1], and I
think Iain Buclaw answered your question when he commented on my
example as follows:
"that's not D! That's some D, a bit of some extended inline
assembly, and a custom linker script."
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.
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.
Sometimes, it's quite useful to be able to use D to create tiny
EXEs/DLLs. For example, create simple DLL plugins that will be
loaded into non-D programs, or even not have a 50-line program
take half a meg. Additionally, some tasks require injecting a
DLL systemwide (into every running process), so it is critical
to minimize the impact by being as unintrusive as possible and
having a minimal overhead.
I've started a "framework" for this purpose a while ago[1], but
I heard of people starting similar projects since then and I
think they've gotten further than me. Would there be any
interest in collaborating and turning this into a community
project?
Didn't know about SlimD (catchy name by the way). I'll
definitely be taking a look as this aligns with my goals.
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.
I think some goals would be:
- A "runtime" (object.d) which provides either stubs for the
current compiler hooks, or implementations with minimal
dependencies
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'd also like to have the D runtime
"reorganzied" to make hardware/OS/C-library abstraction more
obvious. I submitted an enhancement to facilitate this [4]:
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.
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". Let's not track C's doo-doo into D's house, if it can
be avoided.
- A "standard library" which does not require runtime support,
but can also be used when using Druntime (as a GC-free
alternative to Phobos)
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.
- Options to enable/disable various runtime features? For
example, a project may want to use exceptions (which requires
ClassInfo) but not the GC.
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'd prefer some way
where I can pass a user-defined variable to my compiler flags in
concert with the version() feature. And if something is needed,
but not implemented, the compiler/linker will throw an error
saying so.
- Support for the Unilink linker? I think it is better at
generating smaller binaries that OPTLINK.
Does D have to support Unilink, or does Unilink have to support D?
There is also some ongoing work on the -betterC switch[2],
which I'm quite excited about, but it seems to be currently
blocked on waiting for the next DMD release as the changes[3]
might break a lot of code.
[1]: https://github.com/CyberShadow/SlimD
[2]: https://d.puremagic.com/issues/show_bug.cgi?id=11881
[3]: https://github.com/D-Programming-Language/dmd/pull/2561
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.
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.
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.
Mike
[1]
http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22
[2] https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study
[3]
https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/structs/source/object.d
[4] https://d.puremagic.com/issues/show_bug.cgi?id=11666
[5]
http://forum.dlang.org/post/[email protected]
[6] http://wiki.dlang.org/LDC-specific_language_changes
