On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote:

> https://github.com/vitalElement/STM32DBlinky

I don't see the linker script

On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote:
> 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

commands to build were:
Compile:
ldc2  -c -O0 -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi  -g  -debuglib= -conf= -oftest -betterC -release  main.d -ofmain.o
ldc2  -c -O0 -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi  -g  -debuglib= -conf= -oftest -betterC -release stm32f4xx_startup.d -ofstm32f4xx_startup.o

Link:
arm-none-eabi-gcc -mcpu=cortex-m4 -Wl,-Map,output.map -nostdlib  -mfpu=fpv4-sp-d16 -mfloat-abi=hard -nostartfiles -Wl,--gc-sections  -O0 -Wl,-T"link.ld"  -oBlinky.elf attribute.o object.o main.o stm32f4xx_startup.o   -Wl,--start-group   -Wl,--end-group

If you need windows binaries for arm-none-eabi I can give you some.

On Tuesday, 20 June 2017 at 12:00:28 UTC, Mike wrote:
> On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote:
>
>> https://github.com/vitalElement/STM32DBlinky
>
> I don't see the linker script

sorry, committed linker script now :)

On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote:

>
> I think good news:
>

The bloat is still there, but for some reason it's in the .text section.

`objdump -s -j .text test`

...

 80004a8 9efe80bd 80b5fff7 9afe80bd 80b5fff7  ................
 80004b8 96fe80bd 80b5fff7 92fe80bd 80b5fff7  ................
 80004c8 8efe80bd 80b5fff7 71feffe7 00200028  ........q.... .(
 80004d8 02d1ffe7 ffe7f9e7 80bd6d61 696e2e54  ..........main.T
 80004e8 65737443 6c617373 31006d61 696e2e54  estClass1.main.T
 80004f8 65737443 6c617373 32006d61 696e2e54  estClass2.main.T
 8000508 65737443 6c617373 33006d61 696e2e54  estClass3.main.T
 8000518 65737443 6c617373 34006d61 696e2e54  estClass4.main.T
 8000528 65737443 6c617373 35006d61 696e2e54  estClass5.main.T
 8000538 65737443 6c617373 36006d61 696e2e54  estClass6.main.T
 8000548 65737443 6c617373 37006d61 696e2e54  estClass7.main.T
 8000558 65737443 6c617373 38006d61 696e2e54  estClass8.main.T
 8000568 65737443 6c617373 39006865 6c6c6f0d  estClass9.hello.
 8000578 0a000000

On Tuesday, 20 June 2017 at 12:22:42 UTC, Mike wrote:
> On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote:
>
>>[...]
>
> The bloat is still there, but for some reason it's in the .text section.
>
> [...]

damn!

If we push to have this fixed after that we are pretty close to having something usable are we not?

On Tuesday, 20 June 2017 at 11:11:20 UTC, Seb wrote:
> On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote:
>> [...]
>
> The C++ bindings should be opt-in..
>
>> [...]
>
> 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!
>
>> [...]
>
> 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!

I am going to try and get a minimal example working so I can fully evaluated what is needed, and then I will try and submit a DIP.

On Tuesday, 20 June 2017 at 12:35:38 UTC, Dan Walmsley wrote:
> On Tuesday, 20 June 2017 at 11:11:20 UTC, Seb wrote:
>> On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote:
>>> [...]
>>
>> The C++ bindings should be opt-in..
>>
>>> [...]
>>
>> 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!
>>
>>> [...]
>>
>> 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!
>
> I am going to try and get a minimal example working so I can fully evaluated what is needed, and then I will try and submit a DIP.

Ignoring the bloat issue before, any ideas why I might be getting hard fault when trying to create object on the stack?

On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote:

> If we push to have this fixed after that we are pretty close to having something usable are we not?

Depends on your definition of "usable".  Fixing the bloat issue would remove a current road block, and at least allow progress to continue.

IMO, to make D a pleasant experience on the ARM Cortex-M platform, we'll need to implement the entire druntime including threading, GC, exceptions, dynamic arrays, etc... even if those features are not used.  This is because D just hasn't been designed and implemented in a modular fashion to allow one to pay-as-they-go, and as you experienced in one of your other posts today, you just get too many undefined references and other odd errors that have nothing to do with your code.  The only way to make those errors go away is to ensure everything in druntime is there.

If the bloat problem were solved, we could at least continue working towards that end.  But it's not immediately apparent to me how much overhead a complete runtime implementation will add to as simple microcontroller application, and how well the compiler and linker can optimize and remove that overhead.  We may encounter other roadblocks like I did with the TypeInfo bloat, and have to fight a major battle to get something done about it.

But I don't want to have to implement the entire druntime in order to start making progress.  It shouldn't have to be that way.

Mike

On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:
> On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote:
>
>> If we push to have this fixed after that we are pretty close to having something usable are we not?
>
> Depends on your definition of "usable".  Fixing the bloat issue would remove a current road block, and at least allow progress to continue.
>
> IMO, to make D a pleasant experience on the ARM Cortex-M platform, we'll need to implement the entire druntime including threading, GC, exceptions, dynamic arrays, etc... even if those features are not used.  This is because D just hasn't been designed and implemented in a modular fashion to allow one to pay-as-they-go, and as you experienced in one of your other posts today, you just get too many undefined references and other odd errors that have nothing to do with your code.  The only way to make those errors go away is to ensure everything in druntime is there.
>
> If the bloat problem were solved, we could at least continue working towards that end.  But it's not immediately apparent to me how much overhead a complete runtime implementation will add to as simple microcontroller application, and how well the compiler and linker can optimize and remove that overhead.  We may encounter other roadblocks like I did with the TypeInfo bloat, and have to fight a major battle to get something done about it.
>
> But I don't want to have to implement the entire druntime in order to start making progress.  It shouldn't have to be that way.
>
> Mike

I completely agree with you here, its a real shame! Id be happy to put some effort into this, I don't know if you can help me put pressure on the right people to get the bloat thing fixed. It seems like its probably fixed in dmd compiler, but none of the others. I think ldc2 is the compiler that has the most potential because it can easily be compiled unlike the gdc one and then dmd one doesn't seem to support arm out the box unless things changed recently.

I'm happy to have a GC on a system like stm32, as I read it only collects on calls to new, and most sensible embedded designs would just allocate at initialization and not during runtime.

Threading I think we could easily use freertos or something underneath.

Which just leaves dynamic arrays and exceptions which I know next to nothing about right now :)

Firstly who do we need to talk to about the bloat in LDC?

On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote:
> On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote:
>
>> [...]
>
> Depends on your definition of "usable".  Fixing the bloat issue would remove a current road block, and at least allow progress to continue.
>
> [...]

Mike, I was thinking if you had used memory mapped structs instead of classes you probably wouldn't have come up across the rtti bloat so hard and it although be annoying wouldn't have been a show stopper, was there a particular reason to use classes to represent the registers?

Dan