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

[Vladimir Panteleev]

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.