On Monday, 10 July 2017 at 21:30:44 UTC, Walter Bright wrote:
> For example, ints in C are 16 bits. In D they are 32. This means that integer operations are expensive.

I just realized something interesting. The same situation happens on AVR with C. AVR is 8 bit (but often competes with 16-bit microcontrollers), which means that (int8_t x = int8_t a + int8_t b) at the C level is computed as (int8_t x = int16_t a + int16_t b).

This means that a lot of people (AVR is very popular, in part because of Arduino) have been relying on the optimizer. I haven't seen complaints or comments about this issue, so as far as I can tell this hasn't been a problem in the world at large, at least that people have noticed.

BTW, do notice that the addition with carry is optimized away even at the -O0 level.

On D side the issue that remains is the ergonomics of having to type cast(short) more frequently. I suppose that if this proves too inconvenient we can just create a library type that avoids this issue, right?

On Thursday, 13 July 2017 at 16:46:12 UTC, Luís Marques wrote:
> [ ... ]
>
> On D side the issue that remains is the ergonomics of having to type cast(short) more frequently. I suppose that if this proves too inconvenient we can just create a library type that avoids this issue, right?

Yes. we could even make this type be recognized by the compiler such that it will perform the optimizations ;)

On Monday, 10 July 2017 at 21:30:44 UTC, Walter Bright wrote:

> You can't use RTTI or Exceptions, for example. Those generate bloat even if they are not used - a compiler switch is typical to disable them. It's not true that C++ is "pay only for what you use".
>
> If the C++ usage is "C with member functions", then yes, it'll work and be useful.

I use C++ for microcontrollers all the time and I prefer to use exceptions and RTTI for most of my applications. There is a small amount of bloat when using RTTI and exceptions, but the linker is able to strip a large amount of it out, so the cost is minimal and opt-in.  I don't see why D couldn't do the same; it just needs to generate code in a way that allows the linker to identify dead code.

The only binary size problems I've encountered using C++ is using iostream and formatted IO.  Those seem to generate the most bloat.  But if you avoid iostream and use a C library designed for microcontrollers (e.g. newlib) it's not a problem.  It appear the bloat mostly comes from the standard library, not the language.

A recent pull request to GDC (https://github.com/D-Programming-GDC/GDC/pull/505#event-1141470083) removed much of the TypeInfo bloat that was generated when using classes, which has reignited some interest in using D for microcontrollers.  Perhaps there's something in that pull request for other compiler developers to learn from.

Mike