On Tuesday, 20 June 2017 at 09:36:54 UTC, Mike wrote:
> On Tuesday, 20 June 2017 at 08:54:01 UTC, Dan Walmsley wrote:
>>
>> Regarding not being able to --gc-sections, perhaps this was fixed in LDC?
>> http://forum.dlang.org/post/cxjubpxxknlkqvdgyibj@forum.dlang.org
>
> My last test with LDC is here:  https://issues.dlang.org/show_bug.cgi?id=14758#c14
>
> Try to get that code to compile with LDC and let me know what `objdump -s -j .rodata test` gives you.
>
> Mike

No longer compiles:

"Error: Missing class declaration: ModuleInfo

       Please check that object.di is included and valid"

So I add
`
struct ModuleInfo
{

}
`

but then ldc crashes...

added an issue here:
https://github.com/ldc-developers/ldc/issues/2174

20.06.2017 12:33, Mike пишет:
> That being said, let me offer a counter-opinion that occurred to me some
> time ago.  Many embedded systems programmers are not software engineers;
> they are electrical engineers that write code.

I'm sure this is very important thing - many who writes code are not software engineers at all. I can't imagine my colleagues switch to Rust, it' impossible because Rust is too hardcore. But I can imagine they switch to D easily. And this is power of D.
I've read your posts early and I think you're right, at least at general. I guess dlang should make these changes that allow using D at embedded systems.

On Tuesday, 20 June 2017 at 09:46:13 UTC, Dan Walmsley wrote:

> No longer compiles:
>
> "Error: Missing class declaration: ModuleInfo

> but then ldc crashes...

I had to use code from my minimal runtime experiment here and merge it with some of the code in the TypeInfo bloat issue.  Here's code that compiles.

object.d
https://dpaste.dzfl.pl/f7496296301a

test.d
https://dpaste.dzfl.pl/6a97b6f7fccf

How to compile
-------------------------------
`ldc2 --version`
LDC - the LLVM D compiler (1.2.0):
  based on DMD v2.072.2 and LLVM 4.0.0
  built with DMD64 D Compiler v2.074.0
  Default target: x86_64-unknown-linux-gnu

`ldc2 -m64 -defaultlib= -debuglib= -conf= -betterC -release object.d test.d -oftest`

`objdump -s -j .rodata test`

test:     file format elf64-x86-64

Contents of section .rodata:
 4005fd 74657374 2e546573 74436c61 73733100  test.TestClass1.
 40060d 74657374 2e546573 74436c61 73733200  test.TestClass2.
 40061d 74657374 2e546573 74436c61 73733300  test.TestClass3.
 40062d 74657374 2e546573 74436c61 73733400  test.TestClass4.
 40063d 74657374 2e546573 74436c61 73733500  test.TestClass5.
 40064d 74657374 2e546573 74436c61 73733600  test.TestClass6.
 40065d 74657374 2e546573 74436c61 73733700  test.TestClass7.
 40066d 74657374 2e546573 74436c61 73733800  test.TestClass8.
 40067d 74657374 2e546573 74436c61 73733900  test.TestClass9.
 40068d 48656c6c 6f0a006f 626a6563 742e4f62  Hello..object.Ob
 40069d 6a656374 006f626a 6563742e 54797065  ject.object.Type
 4006ad 496e666f 00547970 65496e66 6f5f5374  Info.TypeInfo_St
 4006bd 72756374 00547970 65496e66 6f5f436c  ruct.TypeInfo_Cl
 4006cd 61737300 54797065 496e666f 5f456e75  ass.TypeInfo_Enu
 4006dd 6d005479 7065496e 666f5f43 6f6e7374  m.TypeInfo_Const
 4006ed 006f626a 6563742e 4572726f 7200      .object.Error.


RESULT
------
* The TypeInfo bloat problem still exists.
* The problem is even worse as you now have to add even more silly hacks and stubs to get a build.

This problem has been known for more than 3 years, and it's only getting worse.  Move on.  There are better alternatives.

Mike

On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote:

> I had to use code from my minimal runtime experiment here

Sorry, I forgot to add the link for my minimal runtime experiment:  https://github.com/JinShil/minimal_druntime_experiment

Mike

On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote:
> 3.  Many of the veterans in the D community support the current dependency the runtime has on C standard library bindings, stating that they are required (which is not true).  Furthermore, they want to make the problem worse by adding C++ standard library bindings as well.

The C++ bindings should be opt-in..

>  I submitted  pull request to begin moving these bindings to Deimos, and make the dependencies private for individual platforms' ports, but only encountered resistance and misunderstanding.
>
> 4.  The D gatekeepers have become very averse to anything that would cause too much disruption, making me believe that the fundamental changes that are needed to make microcontroller programming in D a reality will never be accepted.

Hmm, I would definitely recommend to submit a DIP about the proposed changes. "Unfortunately" D is so big now that changes need to be carefully evaluated. Providing such an analysis in a DIP, will vastly help your cause!

> 5.  Too many pull requests sit in "purgatory" for way too long without any progress.  I believe that trying to move my changes forward would be an uphill battle, and ultimately not worth the frustration.

That's a problem about missing reviewers. However, usually reviewing other work will help a lot to speed up your PRs and also you shouldn't be afraid to ping your PRs from time to time!

On Tuesday, 20 June 2017 at 10:41:10 UTC, Mike wrote:
> On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote:
>
>> I had to use code from my minimal runtime experiment here
>
> Sorry, I forgot to add the link for my minimal runtime experiment:  https://github.com/JinShil/minimal_druntime_experiment
>
> Mike

Mike,

I think good news:

I built a slightly different example, because I don't have access to the linker you have, I just had the arm-none-eabi one and I used ldc 1.3.0-beta2.

I compiled using these flags:
-march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi  -g -defaultlib= -conf= -oftest -better

and I got 0 rodata no rtti (I did do -gc-sections) if I don't gc-sections it complains about loads of missing runtime stuff.

I tried then to instantiate a class, but it just crashes in hardfault:

final abstract class TestClass1 { }
final abstract class TestClass2 { }
final abstract class TestClass3 { }
final abstract class TestClass4 { }
final abstract class TestClass5 { }
final abstract class TestClass6 { }
final abstract class TestClass7 { }
final abstract class TestClass8 { }
final abstract class TestClass9 { }

extern (C) void _d_callfinalizer (void *p)
{
}

class Point
{
    this (int x, int y)
    {
        X = x;
        Y = y;
    }

    int X;
    int Y;
}

void Main()
{
    scope p = new Point(2,2);

    p.X = 1;
    p.Y = 1;

    int x = 0;

    x++;
}

Perhaps D needs to be aware of my stack? I will take a look at your linker script. But at least there is 0 type info data after -gc-sections has run.

On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote:
> On Tuesday, 20 June 2017 at 10:41:10 UTC, Mike wrote:
>> On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote:
>>
>>> I had to use code from my minimal runtime experiment here
>>
>> Sorry, I forgot to add the link for my minimal runtime experiment:  https://github.com/JinShil/minimal_druntime_experiment
>>
>> Mike
>
> Mike,
>
> I think good news:
>
> I built a slightly different example, because I don't have access to the linker you have, I just had the arm-none-eabi one and I used ldc 1.3.0-beta2.
>
> I compiled using these flags:
> -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi  -g -defaultlib= -conf= -oftest -better
>
> and I got 0 rodata no rtti (I did do -gc-sections) if I don't gc-sections it complains about loads of missing runtime stuff.
>
> I tried then to instantiate a class, but it just crashes in hardfault:
>
> final abstract class TestClass1 { }
> final abstract class TestClass2 { }
> final abstract class TestClass3 { }
> final abstract class TestClass4 { }
> final abstract class TestClass5 { }
> final abstract class TestClass6 { }
> final abstract class TestClass7 { }
> final abstract class TestClass8 { }
> final abstract class TestClass9 { }
>
> extern (C) void _d_callfinalizer (void *p)
> {
> }
>
> class Point
> {
>     this (int x, int y)
>     {
>         X = x;
>         Y = y;
>     }
>
>     int X;
>     int Y;
> }
>
> void Main()
> {
>     scope p = new Point(2,2);
>
>     p.X = 1;
>     p.Y = 1;
>
>     int x = 0;
>
>     x++;
> }
>
> Perhaps D needs to be aware of my stack? I will take a look at your linker script. But at least there is 0 type info data after -gc-sections has run.

Actually about the stack was a red herring the code did actually work!

my only issue is now when I add a method I get:

C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi':
C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv'
C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg'
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv':
C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind'

Whats the invariant object thing?

On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote:

> C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi':
> C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv'
> C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg'
> C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv':
> C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind'
>
> Whats the invariant object thing?

Please publish your source code and your linker script.

On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote:
> On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote:
>
>> C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi':
>> C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv'
>> C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg'
>> C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv':
>> C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind'
>>
>> Whats the invariant object thing?
>
> Please publish your source code and your linker script.

I'm going to shove it in a GitHub repo give me 10 mins.

On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote:
> On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote:
>
>> C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi':
>> C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv'
>> C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg'
>> C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv':
>> C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind'
>>
>> Whats the invariant object thing?
>
> Please publish your source code and your linker script.

https://github.com/vitalElement/STM32DBlinky