Current state of "D as a better C" (Windows)?

Mike none at none.com
Tue Jan 21 20:13:39 PST 2014


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/jynxfglpulguvqbivrms@forum.dlang.org
[6] http://wiki.dlang.org/LDC-specific_language_changes


More information about the Digitalmars-d mailing list