On Monday, 21 September 2020 at 16:23:33 UTC, Imperatorn wrote:
> On Monday, 14 September 2020 at 07:59:08 UTC, Severin Teona wrote:
>> [...]
>
> How does your work relate to:
>
> https://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler
>
> https://github.com/denizzzka/D_minimal_Cortex-M3
>
> https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

https://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22

On Monday, 14 September 2020 at 07:59:08 UTC, Severin Teona wrote:
>
> Milestone 2:  Try to have a small object.d implementation
> - Continue removing any functionality a small class doesn’t need.
> - Try to test the new ‘object.d’ on the microcontroller after a successful build of the file.
>

If you are going to port the garbage collector, then what is the point of changing object.d. Yes, each class comes with extra typeinfo which takes up space but if that's a big problem then you are in a microcontroller size class that is not suitable for D. Then betterC and C is a better choice. I'm thinking about something like systems with 512KB RAM/Flash and more, then is the extra type information that big of a problem? D is great as it allows dynamic RTTI (C++ term) by default and by removing typeinfo you will remove such functionality.

Systems that has 32KB of RAM and such, forget about D all together and use C (not even C++). BetterC might work though.

I haven't done any size comparison what you really save by removing the extra meta data. Do anyone really know how much it really is?

On Monday, 21 September 2020 at 14:56:57 UTC, Severin Teona wrote:
> Hi Denis!
>
> On Monday, 14 September 2020 at 17:34:22 UTC, Denis Feklushkin wrote:
>> On Monday, 14 September 2020 at 15:00:31 UTC, Severin Teona wrote:
>>
>> Faced with this too. At this stage I choosed Meson build system and moved druntime build to it:
>>
>> https://github.com/denizzzka/druntime/blob/non_posix/meson.build
>
> I followed your advice and started to take a look at Meson build system. But I can't seem to succeed in building the druntime. Is there something not so straightforward that I'm missing in order to make it work?

How you trying to build it?
Example of usage of this branch of druntime is here:
https://github.com/denizzzka/d_c_arm_test/blob/master/d/meson.build#L65

(Also you can ask me in "Issues" section on the Github because I not very frequent look into this forum.)

On Monday, 21 September 2020 at 16:48:28 UTC, IGotD- wrote:
> On Monday, 14 September 2020 at 07:59:08 UTC, Severin Teona

> Systems that has 32KB of RAM and such, forget about D all together and use C (not even C++). BetterC might work though.

At first steps for non-mass market devices it is possible and convenient to solder-in external ROM to fit D binary into MCU.

On Monday, 21 September 2020 at 16:39:58 UTC, Imperatorn wrote:
> On Monday, 21 September 2020 at 16:23:33 UTC, Imperatorn wrote:
>> On Monday, 14 September 2020 at 07:59:08 UTC, Severin Teona wrote:
>>> [...]
>>
>> How does your work relate to:
>>
>> https://wiki.dlang.org/Bare_Metal_ARM_Cortex-M_GDC_Cross_Compiler
>>
>> https://github.com/denizzzka/D_minimal_Cortex-M3
>>
>> https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices
>
> https://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22

https://bitbucket.org/timosi/minlibd/src/master/

On Monday, 21 September 2020 at 16:58:15 UTC, Denis Feklushkin wrote:
>
> At first steps for non-mass market devices it is possible and convenient to solder-in external ROM to fit D binary into MCU.

Most SoC has everything integrated today so the memory, flash and everything is on the die. Long are the days gone when at least I can solder things on circuit boards. Today I can't even see many of the components. A few times I needed something changed at work on a modern circuit board and I had give it away to experts who had microscopes and special equipment.

Today, you size the system from the beginning otherwise you have change the SoC completely which means new PCB design which is expensive.

On Monday, 21 September 2020 at 14:56:57 UTC, Severin Teona wrote:

>>
>> https://github.com/denizzzka/druntime/blob/non_posix/meson.build
>
> I followed your advice and started to take a look at Meson build system. But I can't seem to succeed in building the druntime. Is there something not so straightforward that I'm missing in order to make it work?

I upgraded https://github.com/denizzzka/d_c_arm_test ~master and checked build process - it is sucessfully builds with current ~non_posix branch of druntime.

Can you try to build d_c_arm_test as described in its README file?

On Monday, 21 September 2020 at 17:06:38 UTC, IGotD- wrote:
> On Monday, 21 September 2020 at 16:58:15 UTC, Denis Feklushkin wrote:
>>
>> At first steps for non-mass market devices it is possible and convenient to solder-in external ROM to fit D binary into MCU.
>
> Most SoC has everything integrated today so the memory, flash and everything is on the die. Long are the days gone when at least I can solder things on circuit boards. Today I can't even see many of the components. A few times I needed something changed at work on a modern circuit board and I had give it away to experts who had microscopes and special equipment.
>
> Today, you size the system from the beginning otherwise you have change the SoC completely which means new PCB design which is expensive.

It can be less expensive than rewrite code from D to betterC or substitute MCU.
Probably, if several hundred or thousands of devices are expected, then it is more profitable to make a PCB with additional memory then use more expensive MCU.

On Monday, 14 September 2020 at 09:11:07 UTC, Denis Feklushkin wrote:

> Link Time Optimization (LTO) is available in LLVM-based ldc2 and can dramatically (2-3 times!) decrease .text size.

Hi again Denis. I have a quick question about this. Is there a special way in which I should compile the runtime? For me personally it didn't do much - from 2.8MB to 2.5MB.

> QEMU have -m option to add slightly more memory into emulated Cortex M3 devices - can be useful to fit all druntime tests.

Also, could you give more details about this? I have only found a few Cortex-M devices that could be emulated, but none of them had the resources I needed. The biggest was with 64KB of RAM and 256KB of flash.

Thank you!

On Wednesday, 30 September 2020 at 16:51:46 UTC, Severin Teona wrote:
> On Monday, 14 September 2020 at 09:11:07 UTC, Denis Feklushkin wrote:
>
>> Link Time Optimization (LTO) is available in LLVM-based ldc2 and can dramatically (2-3 times!) decrease .text size.
>
> Hi again Denis. I have a quick question about this. Is there a special way in which I should compile the runtime? For me personally it didn't do much - from 2.8MB to 2.5MB.
>
>> QEMU have -m option to add slightly more memory into emulated Cortex M3 devices - can be useful to fit all druntime tests.
>
> Also, could you give more details about this? I have only found a few Cortex-M devices that could be emulated, but none of them had the resources I needed. The biggest was with 64KB of RAM and 256KB of flash.
>
> Thank you!

Yes, this is a problem. For each module you import and just use one function in it you get a lot of extra code that you don't use. Usually you use --function-sections (LDC2) in order make it possible for the linker to remove unused functions. However this doesn't do much difference at all which is strange. Same flag in C++ does a difference indeed.

To be honest, I think that 64KB RAM, 256KB flash is betterC territory, unfortunately. However, regardless of that we should be able to clean up the binary so that no unnecessary code is ending up in the binary.

This is a question to the LDC maintainers, if --function-sections really does what it is supposed to do.