On Wednesday, 30 September 2020 at 17:36:27 UTC, IGotD- wrote:
>
> 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.

Stupid me, I forgot to compile the druntime with --function-sections as well, forget what I said for the moment.

On Wednesday, 30 September 2020 at 17:40:45 UTC, IGotD- wrote:
>
> Stupid me, I forgot to compile the druntime with --function-sections as well, forget what I said for the moment.

Ok, back from stupidity. With --function-sections and --data-sections now with the phobos and runtime properly compiled with those options, I was able to reduce the size. One binary from about 700KB to 400KB, another binary from about 500KB to about 320Kb.

Still not microcontroller size but a slight improvement.

On Wednesday, 30 September 2020 at 17:55:48 UTC, IGotD- wrote:
>
> Ok, back from stupidity. With --function-sections and --data-sections now with the phobos and runtime properly compiled with those options, I was able to reduce the size. One binary from about 700KB to 400KB, another binary from about 500KB to about 320Kb.
>
> Still not microcontroller size but a slight improvement.

Also, when linking the flag --gc-sections (GNU linker) must be used otherwise nothing will happen.

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.

Use --flto=full or --flto=thin AND call linker with this option too.

Also do not forgot to use -Oz option with ldc2, it also reduces binary size.

>
>> 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.

As I said above, middle-class MCU typically have ability to support external memory ICs (both ROM and RAM). This memory will be transparently mapped into MCU address space.

For QEMU you only need to set -m option and also change linker script to support these amount of memory. For example, I use Cortex M3 "netduino2" device with script like:

[...]
MEMORY
{
 ram (rwx) : ORIGIN = 0x20000000, LENGTH = 10M /* <----- look here! */
 rom (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
}
[...]

On Wednesday, 30 September 2020 at 17:55:48 UTC, IGotD- wrote:
> On Wednesday, 30 September 2020 at 17:40:45 UTC, IGotD- wrote:
>>
>> Stupid me, I forgot to compile the druntime with --function-sections as well, forget what I said for the moment.
>
> Ok, back from stupidity. With --function-sections and --data-sections now with the phobos and runtime properly compiled with those options, I was able to reduce the size. One binary from about 700KB to 400KB, another binary from about 500KB to about 320Kb.
>
> Still not microcontroller size but a slight improvement.

Also it is necessary to determine what do we mean "size of the binary".

Not make sense size of resulting ELF file, matters only sections what will be actually uploaded into MCU and used RAM.

$ ls -l firmware.elf
-rwxr-xr-x 1 denizzz denizzz 3180060 Oct  2 10:51 firmware.elf
$ size firmware.elf
   text	   data	    bss	    dec	    hex	filename
 924140	  45764	   4796	 974700	  edf6c	firmware.elf

On Wednesday, 30 September 2020 at 18:03:55 UTC, IGotD- wrote:
> On Wednesday, 30 September 2020 at 17:55:48 UTC, IGotD- wrote:
>>
>> Ok, back from stupidity. With --function-sections and --data-sections now with the phobos and runtime properly compiled with those options, I was able to reduce the size. One binary from about 700KB to 400KB, another binary from about 500KB to about 320Kb.
>>
>> Still not microcontroller size but a slight improvement.
>
> Also, when linking the flag --gc-sections (GNU linker) must be used otherwise nothing will happen.

Hello, thanks a lot for the tips. I have tried compiling the runtime with both flags (--function-sections and --data-sections in --dFlags) and also with --gc-sections (as an argument for the linker), but I must be probably doing something wrong because the size of the output is the same.

The binary you are talking about is the one after you link the druntime with the application you want to write on the microcontroller? Or just the static runtime and phobos?

Thank you again.

On Tuesday, 6 October 2020 at 15:58:04 UTC, Severin Teona wrote:
>
> Hello, thanks a lot for the tips. I have tried compiling the runtime with both flags (--function-sections and --data-sections in --dFlags) and also with --gc-sections (as an argument for the linker), but I must be probably doing something wrong because the size of the output is the same.
>

It should work. I use the GNU linker "ld". The LLVM linker "llvm-ld" should also accept the argument but I haven't tested it. I use the GNU linker because the LLVM linker is a bit immature for my purpose.

> The binary you are talking about is the one after you link the druntime with the application you want to write on the microcontroller? Or just the static runtime and phobos?
>

That is the size of the .elf files for the executable in my custom system, so application + druntime/phobos. All the debugging information was stripped. It is not an exact match of code+data but close enough to give you a rough idea of the size.

Hi again. This is my third update for the first milestone for #SAoC2020.

Last week my plan ([1]) was to try to emulate some devices and applications in qemu with the druntime that I managed to compile, but as I was expecting, I encountered some problems. I am still not able to run TockOS in qemu (this is the work so far [2]), but maybe I will have a chance with xPack [3] to find a board that TockOS supports and can also be emulated by qemu (and can be added some more memory to fit the size of the druntime).

My plan for the next week remains the same:
- to emulate a device with qemu
- to run some applications to test the compiled druntime

If I won't be able to complete these tasks, I will skip testing and just start stubbing the druntime in order to decrease its size.

Thank you!

[1]: https://forum.dlang.org/thread/xhgqynaiwsujuojxfyhw@forum.dlang.org
[2]: https://github.com/tock/tock/issues/1827
[3]: https://xpack.github.io/qemu-arm/