www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [SAoC] "Druntime for Microcontrollers" project thread

reply Severin Teona <teona.severin9 gmail.com> writes:
Hi all,

I am Teona Severin and I am a first year Masters’ Degree student 
at University Politehnica of Bucharest. During my bachelor’ 
years, I was most interested in fields such as Operating Systems, 
Programming Languages and Paradigms and Embedded Systems, with a 
focus on the Internet of Things.
Learning new programming languages and understanding the way a 
compiler interacts with the operating system were the most 
fascinating things I have learned in my last 4 years of study. 
After studying different programming languages like Prolog, 
Haskell or Java, in the summer of 2019 I was introduced to the 
D-Language by Eduard Stăniloiu and Răzvan Nițu during a workshop 
at the summer-school I was volunteering for, “Ideas and Projects 
Workshop”.
Being an Internet of Things enthusiast, I began wondering whether 
it was possible or not to use D with different types of embedded 
and resource constrained devices. This is why I chose as my 
bachelor project “D-Language for IoT systems”. This project 
consisted in writing a few libraries for high-performance 
embedded systems (such as Raspberry Pi or BeagleBone Black), 
through which one can access different pins exported by the 
device (I2C[1], GPIO[2] or ADC[3] pins). Also, I have ported 
TockOS’ [4] C userland to D[5], in order to run D code on 
microcontrollers based on ARM Cortex-M CPUs (TockOS’ target 
systems).
A big problem I encountered while porting the userland was the 
fact that the Druntime was not built for the target architecture 
and even if it would have been, it would not have fit the memory 
on the device. As a conclusion, I had to use ‘betterC’, a very 
useful concept for devices with little memory, but lots of 
functionalities such as classes, GC or exceptions could not be 
used.

Starting from this point, I have decided to participate this year 
at Symmetry Autumn of Code and create a micro-runtime for the D 
language, to be used with microcontrollers and memory constrained 
devices. Up until now, I have managed to compile and run D code 
on microcontrollers with “betterC” but only without the standard 
D library and runtime and of course, without key concepts of D 
Languages.
This project combines perfectly all the fields I have an interest 
in: programming languages, understanding the way the compiler 
works (with or without an operating system) and embedded systems.

During SAoC, I have planned the next steps:

Milestone 1: Build a runtime (doesn’t matter the size yet) for 
the specified architecture:
- Try to build the runtime for the Cortex-M CPU architecture:
  * either by using the ‘ldc-build-runtime’ toolchain (which 
currently fails because of a ‘CMake’ error)
  * or by building and compiling manually the source code
- If the build succeeds, I won’t be able to test it because the 
size of the druntime doesn’t fit in the microcontroller’s 
constrained resources.
- Begin removing unnecessary functionalities (that a code running 
on a microcontroller does not need) from the ‘object.d’ file 
(most probably by stubbing the code)

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.

Milestone 3: Attempt a port of the current Garbage Collector
- Try to port the current GC for the target architecture
- If that fails in the first 2 weeks, try to implement a 
small-sized GC from scratch (this could exceed the deadline of 
this milestone)

Milestone 4: Stress test and further implementations
- If the GC is ported, begin to stress-test the runtime
- Write a few drivers that actively use classes and communicate 
with different devices (an LCD screen, a temperature sensor, etc).
- If everything goes well, begin research for porting other 
concepts like Exceptions or Errors.
- If the GC is not ported at the beginning of this milestone, 
finish the GC and stress-test in the remaining time.

I will keep you posted weekly with everything I manage to do (or 
I don’t manage to do).

Thank a lot,
Teona.

[1]: https://github.com/DLang-IoT/i2c
[2]: https://github.com/DLang-IoT/gpio
[3]: https://github.com/DLang-IoT/adc
[4]: https://www.tockos.org
[5]: https://github.com/DLang-IoT/libtock-d
Sep 14 2020
next sibling parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
Hi! I am also very interested in this.

This is my unfinished work about porting D to ARM Cortex-M MCU:
https://github.com/denizzzka/d_c_arm_test

Below in the comments I briefly write some thoughts that I came 
by doing this work. Maybe it will be helpful.

On Monday, 14 September 2020 at 07:59:08 UTC, Severin Teona wrote:


 A big problem I encountered while porting the userland was the 
 fact that the Druntime was not built for the target 
 architecture and even if it would have been, it would not have 
 fit the memory on the device.


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


 Starting from this point, I have decided to participate this 
 year at Symmetry Autumn of Code and create a micro-runtime for 
 the D language, to be used with microcontrollers and memory 
 constrained devices.


Thought about this while working on my project and came to 
conclusion that it makes no sense to write a new druntime. There 
is nothing superfluous in the existing "regular" druntime, any 
part of it is needed for key concepts of D.


 During SAoC, I have planned the next steps:

 Milestone 1: Build a runtime (doesn’t matter the size yet) for 
 the specified architecture:
 - Try to build the runtime for the Cortex-M CPU architecture:
  * either by using the ‘ldc-build-runtime’ toolchain (which 
 currently fails because of a ‘CMake’ error)
  * or by building and compiling manually the source code
 - If the build succeeds, I won’t be able to test it because the 
 size of the druntime doesn’t fit in the microcontroller’s 
 constrained resources.


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


 - Begin removing unnecessary functionalities (that a code 
 running on a microcontroller does not need) from the ‘object.d’ 
 file (most probably by stubbing the code)

 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.

 Milestone 3: Attempt a port of the current Garbage Collector
 - Try to port the current GC for the target architecture
 - If that fails in the first 2 weeks, try to implement a 
 small-sized GC from scratch (this could exceed the deadline of 
 this milestone)


As I remember, current default Garbage Collector just works - it 
is not need any porting.
Sep 14 2020
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 14/09/2020 9:11 PM, Denis Feklushkin wrote:

 As I remember, current default Garbage Collector just works - it is not 
 need any porting.


Not true, there are some OS bits that need dealing with[0].

[0] https://github.com/dlang/druntime/blob/master/src/gc/os.d
Sep 14 2020
parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Monday, 14 September 2020 at 13:00:23 UTC, rikki cattermole 
wrote:

 On 14/09/2020 9:11 PM, Denis Feklushkin wrote:

 As I remember, current default Garbage Collector just works - 
 it is not need any porting.


 Not true, there are some OS bits that need dealing with[0].

 [0] https://github.com/dlang/druntime/blob/master/src/gc/os.d


This is only sort of "tuning"
Sep 14 2020
prev sibling next sibling parent reply Severin Teona <teona.severin9 gmail.com> writes:
Hi Denis, thank you for your answer.

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

 This is my unfinished work about porting D to ARM Cortex-M MCU:
 https://github.com/denizzzka/d_c_arm_test


Thank you for sharing this with me, I will take a look at what 
you have done there.


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


Hmm, I will try this as soon as I manage to compile the runtime 
for the Cortex-M, because right now that the big issue for me. 
The 'ldc-build-runtime' tool fails for Cortex-M and I cannot find 
another way to build it. I have also tried to manually compile 
everything, but I could not get anywhere.

I have posted a question regarding the error I get when I try to 
compile the runtime on the Learn thread: 
https://forum.dlang.org/thread/btiahosjluxddsjjnleq forum.dlang.org.

I would appreciate if you could help me find a way to solve this.


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


Thank you, I will try to do that too.
Sep 14 2020
parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Monday, 14 September 2020 at 15:00:31 UTC, Severin Teona wrote:


 Hmm, I will try this as soon as I manage to compile the runtime 
 for the Cortex-M, because right now that the big issue for me. 
 The 'ldc-build-runtime' tool fails for Cortex-M and I cannot 
 find another way to build it. I have also tried to manually 
 compile everything, but I could not get anywhere.


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

Meson supports fine-tuning of build process with all these tons 
cross-compiling options.

I remembered one more "hint" to avoid confusion of options, etc: 
don't use "bare metal" term. Just assume that you are implement 
druntime support for a new unusual operating system.
Sep 14 2020
parent reply Severin Teona <teona.severin9 gmail.com> writes:
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?


 Meson supports fine-tuning of build process with all these tons 
 cross-compiling options.

 I remembered one more "hint" to avoid confusion of options, 
 etc: don't use "bare metal" term. Just assume that you are 
 implement druntime support for a new unusual operating system.
Sep 21 2020
next sibling parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
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.)
Sep 21 2020
prev sibling parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
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?
Sep 21 2020
prev sibling parent reply Severin Teona <teona.severin9 gmail.com> writes:
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!
Sep 30 2020
next sibling parent reply IGotD- <nise nise.com> writes:
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.
Sep 30 2020
parent reply IGotD- <nise nise.com> writes:
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.
Sep 30 2020
parent reply IGotD- <nise nise.com> writes:
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.
Sep 30 2020
next sibling parent reply IGotD- <nise nise.com> writes:
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.
Sep 30 2020
parent reply Severin Teona <teona.severin9 gmail.com> writes:
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.
Oct 06 2020
parent IGotD- <nise nise.com> writes:
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.
Oct 06 2020
prev sibling parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
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
Oct 01 2020
prev sibling parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
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
}
[...]
Oct 01 2020
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 14/09/2020 7:59 PM, Severin Teona wrote:

 Milestone 3: Attempt a port of the current Garbage Collector
 - Try to port the current GC for the target architecture
 - If that fails in the first 2 weeks, try to implement a small-sized GC 
 from scratch (this could exceed the deadline of this milestone)


If you fail the first 2 milestones, you won't have access to classes and 
hence won't have access to anything GC related.

Classes and TLS are the two biggies that make porting to micro 
controllers hard. Good luck!
Sep 14 2020
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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
Sep 21 2020
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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
Sep 21 2020
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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/
Sep 21 2020
prev sibling next sibling parent WebFreak001 <d.forum webfreak.org> writes:
On Monday, 14 September 2020 at 07:59:08 UTC, Severin Teona wrote:

 [...]


cool thanks for this project! I have before also used D on AVR 
devices (8 bit microcontrollers) where I ported libc-avr to D 
here: https://github.com/WebFreak001/avrd

Maybe that will help you get the idea of how to get D running on 
a completely different hardware with betterC first. For porting 
object.d and the druntime check out Adam D. Ruppe's WebAssembly 
object.d, which is a very minimal good starting point where you 
just add features incrementally as you need them.

Don't forget to make a post when you get a basic D application 
with the most minimal runtime (just object.d without phobos and a 
lot of druntime) running with TockOS, I would love to try it out 
running it on my PineTime which I wanted to program for a while 
now!
Sep 21 2020
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
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?
Sep 21 2020
parent reply Denis Feklushkin <feklushkin.denis gmail.com> writes:
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.
Sep 21 2020
parent reply IGotD- <nise nise.com> writes:
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.
Sep 21 2020
parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
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.
Sep 21 2020
prev sibling parent Severin Teona <teona.severin9 gmail.com> writes:
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/
Oct 09 2020