On 3 December 2017 at 08:29, Richard Delorme via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 2 December 2017 at 23:44:39 UTC, Walter Bright wrote:
>>
>> On 12/2/2017 4:38 AM, Iain Buclaw wrote:
>>>
>>> But then you need to bloat your program with debug info in order to understand what, why, and how things went wrong.
>>
>>
>> Most of the time (for me) that isn't necessary, because the debugger still shows where it failed and that's enough.
>>
>> Besides, you can always rerun the test case with a debug build.
>
>
> +1
> To me, the current D assert is useless, and I prefer to use a C-like
> equivalent, that "crash" the program without unwinding the stack. Then I can
> inspect the cause of the crash on a debugger, with access to the current
> context (variable contents, etc.), is it from a (core file) or by running
> the program on the debugger. That way I do find the bug(s) much faster.
> More generally treating errors (ie bugs) as unrecoverable exceptions is a
> mistake in IMHO. I prefer a call to the C function abort() that leaves the
> context intact.
>

Core dumps are of no use if there's no debug info. ;-)

On 3 December 2017 at 00:56, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/2/2017 4:13 AM, Iain Buclaw wrote:
>>
>> On 29 November 2017 at 03:18, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 11/28/2017 9:27 AM, Jacob Carlborg wrote:
>>>>
>>>>
>>>> Why would druntime be a barrier for you for those projects?
>>>
>>>
>>>
>>> When the C version is 90K and the translated D version is 1200K, it is a barrier. It's a barrier for others, as well.
>>>
>>
>> Did you add an extra 0 here for the D version?
>
>
> No. I used the sizes for MicroEmacs in C vs MicroEmacs in D. (I translated the former into the latter.)
>
> With BetterC, I've been able to create virtually identical binaries for C and D.
>
>

Ah, you're referring to binary sizes.  Well you have two central components which do well to bolster that, core.thread and the GC.

I guess if your project is to port something from C to D.  You'd start out with `extern(C) int main() @nogc` and go from there.  That then leaves moduleinfo, to which there already exists the machinery in the compiler for determining whether it needs to be generated, dmd could start using it again instead of defaulting to always generating moduleinfo symbols that pull in druntime.  That would mean a switch that gives fine control over generation (-moduleinfo=[on|asneeded|off]), still better than a betterC feature gate.


>>> Another barrier for me has turned out to be the way assert() works in D.
>>> It
>>> just is not lightweight, and it visibly slows down dmd to have assert's
>>> turned on internally. The amount of machinery involved with it in
>>> druntime
>>> is way overblown. Hence, asserts in dmd are turned off, and that wound up
>>> causing me a lot of problems recently. There are even initiatives to add
>>> writefln like formatting to asserts. With betterC, asserts became
>>> lightweight and simple again.
>>
>> I find this assertion hard to believe (pun not intended).  Unless you
>> are omitting some extra check (invariant calls?), whether you are
>> using D's assert or C's assert, both have the same runtime cost.
>
>
> asserts are significantly larger in D. One reason is the filename string is passed as a D string, which is 2 pushes. A C string is one push.
>

D strings require one extra push, true.  But what's that, one extra clock cycle?  Not even the cost of half a crown.


> Consider that D asserts throw an exception. Where's the catch going to be, if you're linking the D code into a C program? And the D personality function, needed for D exception unwinding, is in druntime.
>

If there is no catch, what happens is that unwind raise exception returns end of stack, and you abort in the throw() function.


>
>>> BetterC is a door-opener for an awful lot of areas D has been excluded
>>> from,
>>> and requiring druntime is a barrier for that.
>>
>> It's not a door opener, and druntime is not a barrier.
>
>
> If you have a C program, and want to add a D function to it, you really don't want to add druntime as well. BetterC enables people to provide D addon libraries for people who have C main programs.
>
> There's a point to making incremental use of D as low cost as possible.
>

People have been making alternative druntime libraries for a while now, either as stubs inside their own project, or by using minilibd. There's nothing stopping you from simply swapping out druntime for another implementation.

On 12/3/2017 2:32 AM, Iain Buclaw wrote:
> People have been making alternative druntime libraries for a while
> now, either as stubs inside their own project, or by using minilibd.
> There's nothing stopping you from simply swapping out druntime for
> another implementation.

It may indeed work to use a special druntime. My expectation, however, is that it's a lot more work trying to develop and support another runtime library, and a lot more work for the user trying to get that library worked into his build system. This will drastically cut down on the number of users willing to give it a try.

(Consider the ENDLESS problems Win64 users have trying to link in the VC C runtime library, something that should be trivial. And these are experienced VC developers.)

Meanwhile, we've got -betterC today, and it's simple and it works.

On 3 December 2017 at 13:20, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/3/2017 2:32 AM, Iain Buclaw wrote:
>>
>> People have been making alternative druntime libraries for a while now, either as stubs inside their own project, or by using minilibd. There's nothing stopping you from simply swapping out druntime for another implementation.
>
>
> It may indeed work to use a special druntime. My expectation, however, is that it's a lot more work trying to develop and support another runtime library, and a lot more work for the user trying to get that library worked into his build system. This will drastically cut down on the number of users willing to give it a try.
>
> (Consider the ENDLESS problems Win64 users have trying to link in the VC C runtime library, something that should be trivial. And these are experienced VC developers.)
>
> Meanwhile, we've got -betterC today, and it's simple and it works.

I prefer the approach of, try compiling a simple "hello world" with an empty object.d file.  Then inspect what the compiler does.  Does it error and exit, or does it ICE?  What can be done to prevent that from happening?

When you reach the point that there's no way but to declare a symbol or function, add that to object.d and then move onto the next error or ICE.  Repeat until you can compile and link your program.

Next, try something a little more complex, such as define a struct and use it.  Then again address all problems that you encounter with that.

What you end up with, should be a compiler that is less coupled to the existence of object.d and all its definitions than what it was before. Doing things this way in a bottom-up fashion has allowed people to use gdc to target STM micro controllers.

On Sunday, 3 December 2017 at 12:20:14 UTC, Walter Bright wrote:
> It may indeed work to use a special druntime. My expectation, however, is that it's a lot more work trying to develop and support another runtime library, and a lot more work for the user trying to get that library worked into his build system.

It's pretty easy, actually, and you can then selectively opt into features  by copying function implementations as you need them.

That said, I like the idea of betterC just working... as long as it doesn't break the opt-in option.

> Meanwhile, we've got -betterC today, and it's simple and it works.

It is a bit simpler than the old way, but not that much... like other people have copy/pasted my minimal object.d into new projects and gotten it to work pretty easily. Downloading a file and compiling isn't much different than compiling with -betterC. (And actually, my minimal one gives you classes and exceptions if you want them too via -version! And is bare-metal compatible as well, which -betterC still needs a few little stubs to work on right now.)


So it is one thing to say "this is a bit more convenient", but don't say "this enables something D couldn't do before". The latter is patently false in all contexts, and in some of those contexts, further spreads FUD about druntime.

On Sunday, 3 December 2017 at 12:20:14 UTC, Walter Bright wrote:
> It may indeed work to use a special druntime. My expectation, however, is that it's a lot more work trying to develop and support another runtime library, and a lot more work for the user trying to get that library worked into his build system. This will drastically cut down on the number of users willing to give it a try.

I don't think it's necessary for you or anyone else to create a special officially supported runtime.  What I need is a way to create a very minimal runtime that supports just the features of D that I'm opting in to, without having to write phony stubs and boiler plate that, in the end, is just going to be discarded by the linker.

Currently the compiler expects things to exist in the runtime that have no hope of ever being used, just to get a build.  In fact, one can compile against the stock object.d to satisfy the compiler, but then omit linking to druntime, and still get a proper binary.  I had to stop pursuing it because I couldn't suggest it professionally and expect to be taken seriously.

> Meanwhile, we've got -betterC today, and it's simple and it works.

IMO -betterC is papering over the problem rather than dealing with it.

Mike

On 12/3/2017 11:22 AM, Michael V. Franklin wrote:
> On Sunday, 3 December 2017 at 12:20:14 UTC, Walter Bright wrote:
>> Meanwhile, we've got -betterC today, and it's simple and it works.
> IMO -betterC is papering over the problem rather than dealing with it.

If -betterC motivates people to come up with better solutions, I'm all for it.

On Sunday, 3 December 2017 at 23:34:13 UTC, Walter Bright wrote:

> If -betterC motivates people to come up with better solutions, I'm all for it.

A better solution would be to do what Iain said:

> Try compiling a simple "hello world" with an empty object.d file.  Then inspect what the compiler does.  Does it error and exit, or does it ICE?  What can be done to prevent that from happening?

> When you reach the point that there's no way but to declare a symbol or function, add that to object.d and then move onto the next error or ICE.  Repeat until you can compile and link your program.

> Next, try something a little more complex, such as define a struct and use it.  Then again address all problems that you encounter with that.

It would be great for the compiler devs to run through this exercise themselves and make changes to the compiler/runtime interface to remove the irrelevant requirements the compiler is imposing.

Mike

On Monday, 4 December 2017 at 00:25:53 UTC, Michael V. Franklin wrote:

> A better solution would be to do what Iain said:
>
>> Try compiling a simple "hello world" with an empty object.d file.  Then inspect what the compiler does.  Does it error and exit, or does it ICE?  What can be done to prevent that from happening?
>
>> When you reach the point that there's no way but to declare a symbol or function, add that to object.d and then move onto the next error or ICE.  Repeat until you can compile and link your program.
>
>> Next, try something a little more complex, such as define a struct and use it.  Then again address all problems that you encounter with that.

Here's an illustration:

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

alias immutable(char)[] string;

struct ModuleInfo { }

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);
}

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

.$> dmd -defaultlib= -debuglib= -conf= main.d -of=main
/usr/bin/ld: main.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output

I didn't compile with -shared.  What's going on here?

.$> dmd -defaultlib= -debuglib= -conf= main.d -of=main -fPIC

main.o:(.text.d_dso_init[.data.d_dso_rec]+0x22): undefined reference to `_d_dso_registry'

Again, not sure why the compiler's generated code for that?

Would it help for me to file bugzilla issues for things like this?  The reason I haven't thus far, is that this is just a symptom of a larger issue.  It needs a development strategy to be solved holistically.

Mike

On Monday, 4 December 2017 at 01:01:47 UTC, Michael V. Franklin wrote:

> .$> dmd -defaultlib= -debuglib= -conf= main.d -of=main
> /usr/bin/ld: main.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
>
> I didn't compile with -shared.  What's going on here?

> .$> dmd -defaultlib= -debuglib= -conf= main.d -of=main -fPIC
>
> main.o:(.text.d_dso_init[.data.d_dso_rec]+0x22): undefined reference to `_d_dso_registry'
>
> Again, not sure why the compiler's generated code for that?

Ok, well perhaps that makes sense compiling with -fPIC, but the "relocation R_X86_64_32 against `.rodata.str1.1'" seems unnecessary.

Mike