August 25, 2017
On Friday, 25 August 2017 at 23:13:53 UTC, Mengu wrote:
> On Friday, 25 August 2017 at 00:24:14 UTC, Michael V. Franklin wrote:
>> On Thursday, 24 August 2017 at 19:21:31 UTC, Walter Bright wrote:
>>> [...]
>>
>> Great! I look forward to seeing improvements and hope to help.
>>
>> [...]
>
> i believe that should be an opt-out. what about newcomers? will they have to learn how to link std lib?

No, because the dmd.conf that is delivered with the toolchain is already ready to go with reasonable defaults; and not hard-coded into the compiler.  Advanced users can update dmd.conf or point the compiler to a different dmd.conf as they choose.

Mike
August 28, 2017
On Friday, 25 August 2017 at 18:08:06 UTC, Parke wrote:
> Is there any documentation on how to access and use the minimal runtime?

Runtime implements language features like boundschecking, it's not used explicitly in the code.
August 28, 2017
> On Friday, 25 August 2017 at 18:08:06 UTC, Parke wrote:
>> Is there any documentation on how to access and use the minimal runtime?

On Mon, Aug 28, 2017 at 5:22 AM, Kagamin via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> Runtime implements language features like boundschecking, it's not used explicitly in the code.

I understand that.

On Wed, Aug 23, 2017 at 10:17 AM, Kagamin via Digitalmars-d-announce
> 7.5kb totext.exe (encodes stdin to base64 and writes to stdout) - wrote it
> to put images in xml for opensearch descriptions.
> 12.5kb retab.exe (retabifies source code with various features)
> 5.5kb keepower.exe (manages screen saver and power settings because of
> obnoxious domain policy)
> 14.5kb fsum.exe (computes various hash sums of a file)

Is the source code available for totext.exe, retab.exe keepower.exe, and fsum.exe?

If the source code were available, I could try compiling them and see if I could reproduce the nice, small executable sizes you list above.

When I write "hello world" in C, the executable is 8,519 bytes.  When I write "hello world" in D, the executable is 100 times larger: 865,179 bytes.

Interestingly, "hello world" in C, compiled statically, yields 908,608 bytes.  And "hello world" in assembly yields 368 bytes.

Thanks,

Parke
August 29, 2017
On Monday, 28 August 2017 at 22:45:01 UTC, Parke wrote:
> When I write "hello world" in C, the executable is 8,519 bytes.
>  When I write "hello world" in D, the executable is 100 times larger: 865,179 bytes.

You mean the examples from the blog post https://dlang.org/blog/2017/08/23/d-as-a-better-c/ give you 800kb executables?
August 29, 2017
> On Monday, 28 August 2017 at 22:45:01 UTC, Parke wrote:
>> When I write "hello world" in C, the executable is 8,519 bytes.
>>  When I write "hello world" in D, the executable is 100 times larger:
>> 865,179 bytes.


On Tue, Aug 29, 2017 at 8:26 AM, Kagamin via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> You mean the examples from the blog post https://dlang.org/blog/2017/08/23/d-as-a-better-c/ give you 800kb executables?


No, I was talking about the below version of "hello world" that I compiled several weeks prior to reading the blog post.

import std.stdio;
void main() { writeln("Hello, world!"); }

The above D code yields 865,179 bytes.


Below is the version from the blog post:

import core.stdc.stdio;
extern (C) int main( int argc, char** argv ) {
    printf ( "hello world\n" );
    return 0;
}

The above D code yields 445,244 bytes when compiled with -release.
The above D code yields 445,187 bytes when compiled with -release -betterC.
DMD64 D Compiler 2.075.0-b2 on Linux on x86-64.

Still 50 times larger than C.  Perhaps it would be smaller with a newer version of DMD.

But my original question was about what you (Kagamin) called
"intermediate D".  I was trying to understand what "intermediate D"
is, and whether or not I could use "intermediate D" (whatever it is)
to produce small(er) executables.

-Parke
August 30, 2017
On Wednesday, 30 August 2017 at 00:29:19 UTC, Parke wrote:
> The above D code yields 445,187 bytes when compiled with -release -betterC.
> DMD64 D Compiler 2.075.0-b2 on Linux on x86-64.

-betterC does virtually nothing on that version of dmd...

> But my original question was about what you (Kagamin) called
> "intermediate D".  I was trying to understand what "intermediate D"
> is, and whether or not I could use "intermediate D" (whatever it is)
> to produce small(er) executables.

Regular D with a custom runtime library. You can get as small as 3 KB on Linux (though that is a super bare bones hello world).

But note that if you are distributing several executables you might also just use the shared phobos lib too with -defaultlib=libphobos2.so on Linux.
August 30, 2017
On Wednesday, 30 August 2017 at 00:29:19 UTC, Parke wrote:

> But my original question was about what you (Kagamin) called
> "intermediate D".  I was trying to understand what "intermediate D"
> is, and whether or not I could use "intermediate D" (whatever it is)
> to produce small(er) executables.

"Intermediate D" probably refers to not use the -betterC switch, not linking in the official druntime, and instead implementing the features of D required by your program yourself.

For example, the following is the most minimal "Hello World" I can make with D that does not require the -betterC switch, and does not use the official D runtime.  Instead the runtime features required by this program are implemented in object.d.

object.d
--------
module object;

alias immutable(char)[] string;

struct ModuleInfo { }

class Object { }

class TypeInfo
{
    bool equals(in void* p1, in void* p2) const
    {
        return p1 == p2;
    }

    int compare(in void* p1, in void* p2) const
    {
        return _xopCmp(p1, p2);
    }
}

class TypeInfo_Class : TypeInfo
{
    ubyte[136] ignore;
}

alias TypeInfo_Class ClassInfo;

class TypeInfo_Struct : TypeInfo
{
    ubyte[120] ignore;
}

extern (C) Object _d_newclass(const ClassInfo ci)
{
    return null;
}

extern(C) void _d_throwc(Object h) { }

class Throwable { }

class Error : Throwable
{
    this(string x)
    { }
}

extern(C) void _d_throwdwarf(Throwable o) { }

extern(C) void _d_dso_registry(void* data) { }


// The following code basically replaces the C runtime
//----------------------------------------------------
extern extern(C) int main(int argc, char** argv);

extern(C) void sys_exit(long arg1)
{
    asm
    {
        mov RAX, 60;
        mov RDI, arg1;
        syscall;
    }
}

extern(C) void _start()
{
    auto ret = main(0, null);
    sys_exit(ret);
}

private alias extern(C) int function(char[][] args) MainFunc;

extern (C) int _d_run_main(int argc, char **argv, MainFunc mainFunc)
{
    // ignore args for now
    return mainFunc(null);
}

main.d
------
module main;

long 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(in string text)
{
    sys_write(2, text.ptr, text.length);
}

void main()
{
    write("Hello\n");
}

Building and executing
----------------------
On Linux 64-bit compile with:
$ dmd -c -fPIC -release object.d main.d -of=main.o

Link with:
$ ld main.o -o main

Report size:
$ size main
   text    data     bss     dec     hex filename
   1070    1872       8    2950     b86 main

Text execution:
$ ./main
Hello

If you link with:
$ ld main.o -o main --gc-sections

You end up with:
$ size main
   text    data     bss     dec     hex filename
    950    1688       0    2638     a4e main


This illustration does not require -betterC, but instead requires you to implement a "minimal D runtime" specific to your program, and the features of D that it employs.  In this illustration that "minimal D runtime" is object.d.

As you can see it is not a polished experience and gets much worse when you start employing more features of D.  This could be improved, and in fact, with GDC you need even less useless boilerplate in object.d and may end up with an even smaller executable. (Maybe I'll follow up later with GDC illustration.  Right now I don't have a computer with the latest GDC installed).  If you try this experiment with LDC, you may end up with a multi-gigabyte file and crash your PC due to https://github.com/ldc-developers/ldc/issues/781

Hopefully we can improve the compiler/runtime implementation so doing this kind of programming won't require so many useless stubs, and users can implement just the features of D that they need for their program without having to rely on the on the blunt and heavy hand of -betterC.

Mike

August 29, 2017
On Tue, Aug 29, 2017 at 7:19 PM, Michael V. Franklin via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> For example, the following is the most minimal "Hello World" I can make with D that does not require the -betterC switch, and does not use the official D runtime.  Instead the runtime features required by this program are implemented in object.d.

Thank you for the very helpful example and explanation.

-Parke
August 30, 2017
On Wednesday, 30 August 2017 at 00:29:19 UTC, Parke wrote:
> But my original question was about what you (Kagamin) called
> "intermediate D".  I was trying to understand what "intermediate D"
> is, and whether or not I could use "intermediate D" (whatever it is)
> to produce small(er) executables.

I rely on llvm tooling to remove unused stuff, build process is a bit lengthy, I didn't write a step by step guide for it. Also linux might need different approach depending what code compiler generates.
August 30, 2017
On Wednesday, 30 August 2017 at 02:19:21 UTC, Michael V. Franklin wrote:
> As you can see it is not a polished experience and gets much worse when you start employing more features of D.  This could be improved, and in fact, with GDC you need even less useless boilerplate in object.d and may end up with an even smaller executable. (Maybe I'll follow up later with GDC illustration.  Right now I don't have a computer with the latest GDC installed).
>  If you try this experiment with LDC, you may end up with a multi-gigabyte file and crash your PC due to https://github.com/ldc-developers/ldc/issues/781

I use stock object.d, just don't link it.