This is another thing I see in hushed tones around here. So all in one place, the information goes.

Here's the short story for my plans for the runtime component of Smithy:

extern( C++ ) all the things.

Shipping Quantum Break showed me one thing: Certification processes will stop you dead in your tracks if any given platform holder's code analysis tools can't understand what your code is doing.

This slots neatly in with my DMD/LDC on mobile post. If I extern( C++ ) all the things, and avoid core and std, then I should be able to write code that doesn't even need a heavy druntime initialisation. Perhaps not even an init at all. I just want to write code at that point that doesn't use typeinfo, moduleinfo, etc. Binderoo won't be linked for example, I intend on making a library that for all intents and purposes looks like it was written in C++ to every compiler in use on the platforms I'll be targeting.

Making the compiler not link phobos should be easy. But the compiler expects to find druntime so it can include all its little hooks for arrays etc.

So. Is there a working minimal druntime out there? Or a process that can be applied for any given DMD release?

On Saturday, July 27, 2019 6:51:23 AM MDT Ethan via Digitalmars-d wrote:
> This is another thing I see in hushed tones around here. So all in one place, the information goes.
>
> Here's the short story for my plans for the runtime component of Smithy:
>
> extern( C++ ) all the things.
>
> Shipping Quantum Break showed me one thing: Certification processes will stop you dead in your tracks if any given platform holder's code analysis tools can't understand what your code is doing.
>
> This slots neatly in with my DMD/LDC on mobile post. If I extern( C++ ) all the things, and avoid core and std, then I should be able to write code that doesn't even need a heavy druntime initialisation. Perhaps not even an init at all. I just want to write code at that point that doesn't use typeinfo, moduleinfo, etc. Binderoo won't be linked for example, I intend on making a library that for all intents and purposes looks like it was written in C++ to every compiler in use on the platforms I'll be targeting.
>
> Making the compiler not link phobos should be easy. But the compiler expects to find druntime so it can include all its little hooks for arrays etc.
>
> So. Is there a working minimal druntime out there? Or a process that can be applied for any given DMD release?

It sounds to me like what you want is -betterC.

- Jonathan M Davis

On 28/07/2019 1:11 AM, Jonathan M Davis wrote:
> It sounds to me like what you want is -betterC.
> 
> - Jonathan M Davis


Indeed.

E.g.

extern(C) void main() {
    Foo foo = create!Foo;
    foo.func();
}

extern(C++) class Foo {
    int x;
    float y;

    this() {
    }

    this(int x) {
    	this.x = x;
    }

    void func() {
        import core.stdc.stdio : printf;

        printf("Hello!\n");
        printf("x = %d\n", x);
        printf("y = %f\n", y);
    }
}

T create(T, Args...)(Args args) {
    import core.stdc.stdlib : malloc;

    __gshared T Default = new T;
    enum Size = __traits(classInstanceSize, T);

    void* raw = cast(void*)Default;

    void* newRaw = malloc(Size);
    newRaw[0 .. Size] = raw[0 .. Size];

    T ret = cast(T)newRaw;

    static if (__traits(hasMember, T, "__ctor")) {
   	ret.__ctor(args);
    }

    return ret;
}

On Saturday, 27 July 2019 at 12:51:23 UTC, Ethan wrote:

> So. Is there a working minimal druntime out there? Or a process that can be applied for any given DMD release?

This is the most minimal runtime you can use:

object.d
```
module object;
```

That's right, an empty object.d file.  Unfortunately, the compiler still requires an object.d file to exist in order to get a build.  I've tried a few pull requests to change that, but they've all failed scrutiny.

Assuming you use the above minimal runtime, you can create the following minimal hello world program on Linux.

main.d
```
private extern(C) void __d_sys_exit(long arg1)
{
    asm
    {
        mov RAX, 60;
        mov RDI, arg1;
        syscall;
    }
}

private long __d_sys_write(long arg1, in void* arg2, long arg3)
{
    long result;

    asm
    {
        mov RAX, 1;
        mov RDI, arg1;
        mov RSI, arg2;
        mov RDX, arg3;
        syscall;
    }

    return result;
}

void write(immutable(char)[] text)
{
    __d_sys_write(2, text.ptr, text.length);
}

private extern(C) void _start()
{
    main();
    __d_sys_exit(0);
}

void main()
{
    write("Hello, World!\n");
}
```

See it in action at https://run.dlang.io/is/Ix22Eo

From there, the world's your oyster.  Start programming in D, and if the compiler or linker can't find something, either copy it from druntime, or implement your own.

I suspect that's not much use to you, but it is indeed the most "minimal runtime".  The motivation for using a minimal runtime is to incrementally port D to a new platform and implement only what is needed in a pay-as-you-go fashion.

Some of us are slowly improving the experience, but it still has a long way to go.  It's MUCH better than it was a few years ago, though.

Mike

On Saturday, 27 July 2019 at 13:11:23 UTC, Jonathan M Davis wrote:
> It sounds to me like what you want is -betterC.

It's kind of not though.

I don't want a subset of D, I want DMD to not inject things in to my library that I just plain won't use.

I'd already considered -betterC, and immediately decided it was going to be too much hassle after writing one line and finding out the compiler doesn't agree with my coding style. The code is going to compile with and without -betterC, which itself is a massive undertaking at this point.

I've got a related point about the Unity guys writing High Performance C#. If C# is so good, why do you need a subset of it? This exact argument is what I have about -betterC. If D is so good, why do I need a subset of it?

On Saturday, 27 July 2019 at 14:06:51 UTC, Mike Franklin wrote:
> This is the most minimal runtime you can use:
>
> object.d
> ```
> module object;
> ```
>
> That's right, an empty object.d file.  Unfortunately, the compiler still requires an object.d file to exist in order to get a build.  I've tried a few pull requests to change that, but they've all failed scrutiny.

Cheers. That's still a good start.

I also like the way the compiler is going, by templatising all this stuff. Which should mean that when the job is done it's just a matter of providing your own templates and customising the code gen that way. That'll be a massive help for getting ARC at a compiler level instead of a library solution (assuming it's being done the way I imagine).

I use this: http://dpaste.com/13HWHT0
This is posix version for ldc 1.4, no -betterC, not sure if it compiles with -betterC. Runtime was compiler specific until recently, not sure if it was fixed.

On Saturday, July 27, 2019 8:20:52 AM MDT Ethan via Digitalmars-d wrote:
> On Saturday, 27 July 2019 at 13:11:23 UTC, Jonathan M Davis wrote:
> > It sounds to me like what you want is -betterC.
>
> It's kind of not though.
>
> I don't want a subset of D, I want DMD to not inject things in to my library that I just plain won't use.
>
> I'd already considered -betterC, and immediately decided it was going to be too much hassle after writing one line and finding out the compiler doesn't agree with my coding style. The code is going to compile with and without -betterC, which itself is a massive undertaking at this point.
>
> I've got a related point about the Unity guys writing High Performance C#. If C# is so good, why do you need a subset of it? This exact argument is what I have about -betterC. If D is so good, why do I need a subset of it?

Personally, I'd pretty much only use -betterC to help port a C/C++ library or program to D. I sure wouldn't want to use a stripped down version of D normally. But if you want to avoid stuff like TypeInfo, or you want your library to just look like it's basically C/C++, then that's the direction you're going. To fully use D's features, you need druntime with everything that it does. In theory, druntime could be improved to be more pay-as-you-go than it is, and work is slowly being done in that area, but what druntime does really does provide language functionality, and trying to avoid parts of it basically means avoiding language functionality. It's not like D's features all come for free.

I actually think that -betterC is mostly a waste of time, because I don't see enough benefit in using a stripped down version of D over just using C++ to bother, but it definitely can have benefits when porting code, and some people seem to think that it's the way to go, much as I really don't understand that.

However, D _is_ a general purpose programming language, and different people have different constraints that they operate under. For the vast majority of programs, what druntime does isn't a big deal at all. Complaints over stuff like D using a GC are mostly unreasonable. But there are domains where it's more problematic than is normally the case (games being one of those, because they typically can't afford the delays from the stop-the-world GC), and when you're in that kind of environment, you do potentially need to avoid aspects of D (and would presumably have to do something similar with C# for similar reasons) - or at least program in a way that tries to work around some of the downsides rather than just using the language like most people would (e.g. having a separate thread that the GC has no control over to deal with real-time stuff or specifically disabling the GC in certain sections of code). And in general, when having multiple languages interact, things can get a bit entertaining and potentially require avoiding aspects of D.

- Jonathan M Davis

On Saturday, 27 July 2019 at 17:57:07 UTC, Jonathan M Davis wrote:
> On Saturday, July 27, 2019 8:20:52 AM MDT Ethan via Digitalmars-d wrote:
>> On Saturday, 27 July 2019 at 13:11:23 UTC, Jonathan M Davis wrote:
>> > It sounds to me like what you want is -betterC.
>
> Personally, I'd pretty much only use -betterC to help port a C/C++ library or program to D. I sure wouldn't want to use a stripped down version of D normally. But if you want to avoid stuff like TypeInfo, or you want your library to just look like it's basically C/C++, then that's the direction you're going. To fully use D's features, you need druntime with everything that it does. In theory, druntime could be improved to be more pay-as-you-go than it is, and work is slowly being done in that area, but what druntime does really does provide language functionality, and trying to avoid parts of it basically means avoiding language functionality. It's not like D's features all come for free.
>
> I actually think that -betterC is mostly a waste of time, because I don't see enough benefit in using a stripped down version of D over just using C++ to bother, but it definitely can have benefits when porting code, and some people seem to think that it's the way to go, much as I really don't understand that.
>
> - Jonathan M Davis

I agree, why limit the D language. Always viewed -betterC as an intermediate step until the "pay for what you use" implementation is in place. For most embedded systems type/module info and so on isn't really much of a problem other those really memory limited targets. I regard the type/module info a great help actually even for bare metal targets.

What is the problem is the dependency to an operating system and how to make this more flexible. Hopefully in the future we can decouple the runtime language features (like classes) which doesn't really need OS support from things in the runtime that needs OS support.

On Saturday, 27 July 2019 at 14:20:52 UTC, Ethan wrote:
> On Saturday, 27 July 2019 at 13:11:23 UTC, Jonathan M Davis wrote:
>> It sounds to me like what you want is -betterC.
>
> It's kind of not though.
>
> I don't want a subset of D, I want DMD to not inject things in to my library that I just plain won't use.
>
> I'd already considered -betterC, and immediately decided it was going to be too much hassle after writing one line and finding out the compiler doesn't agree with my coding style. The code is going to compile with and without -betterC, which itself is a massive undertaking at this point.
>
> I've got a related point about the Unity guys writing High Performance C#. If C# is so good, why do you need a subset of it? This exact argument is what I have about -betterC. If D is so good, why do I need a subset of it?

For the same reason that C++ needs a C like subset when you want to extract the ultimate performance out of it.

Magical compiler optimizers able to generate the perfect Assembly and cache usage no matter what comes to the mind of the lazy developer are still a dream pipe.

Any programming language that cares about performance needs a performance oriented subset, for the use cases when the high level constructors don't deliver the desired performance and the optimizer just throws its hands up in the air.