Hello,

Johan Engelen suggested I bring further attention to this issue here in the D forums.

We need a version identifier for 16-bit code (e.g. to conditionally define size_t correctly). This is not theoretical, it's an actual need, since LDC essentially works for MSP430, even though it isn't officially supported. I'm assuming that adding a predefined version identifier isn't problematic, so the only issue is how it should be named. Here's what I wrote on GitHub:

"I defined a version identifier for 16-bit code called D_P16, by analogy with D_LP64. Now, D_LP64 was an awful name because it means 64-bit in general and not C's LP64 in particular. I chose D_P16 to mean pointers are 16-bit, but now I'm thinking if we should just call it D_16. In theory we could have a Harvard architecture where the native integer size is different from the native pointer size. That's one argument in favor of D_P16. Another argument would be consistency with D_LP64." -> but maybe that's overcomplicating and D_16 suffices?

Bikeshed all the things! \o

- Luís

On 7/10/2017 12:46 PM, Luís Marques wrote:
> since LDC essentially works for MSP430, even though it isn't officially supported.

I'm curious how that implementation addresses the issues I brought up:

http://www.digitalmars.com/d/archives/digitalmars/D/size_t.sizeof_2_LINE_.sizeof_4_304013.html#N304054

Curiously, there's the MSP430X with 20 bit registers!

https://en.wikipedia.org/wiki/TI_MSP430#MSP430X_20-bit_extension

On Monday, 10 July 2017 at 20:19:46 UTC, Walter Bright wrote:
> On 7/10/2017 12:46 PM, Luís Marques wrote:
> I'm curious how that implementation addresses the issues I brought up:

I'm not really sure how to respond, you mostly just made statements about your worldview. For instance:

"C++ on a 64K machine is like using a tank to get to the grocery store". If you mean using all of C++ features, sure, that's inappropriate. If you mean that there are no C++ features that you could use in a microcontroller, there are non-trivial amounts of people the disagree with you.

"D for 16 bits wouldn't really be D, it would be a D variant with different
semantics and capabilities. (Like C++ for 16 bits.)" -> so far LDC with mtriple=msp430 has worked for me, for my needs. I don't really know what you mean by D for 16 bits...

On 7/10/2017 1:52 PM, Luís Marques wrote:
> On Monday, 10 July 2017 at 20:19:46 UTC, Walter Bright wrote:
>> On 7/10/2017 12:46 PM, Luís Marques wrote:
>> I'm curious how that implementation addresses the issues I brought up:
> 
> I'm not really sure how to respond, you mostly just made statements about your worldview. For instance:
> 
> "C++ on a 64K machine is like using a tank to get to the grocery store". If you mean using all of C++ features, sure, that's inappropriate. If you mean that there are no C++ features that you could use in a microcontroller, there are non-trivial amounts of people the disagree with you.

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.


> "D for 16 bits wouldn't really be D, it would be a D variant with different
> semantics and capabilities. (Like C++ for 16 bits.)" -> so far LDC with mtriple=msp430 has worked for me, for my needs. I don't really know what you mean by D for 16 bits...

For example, ints in C are 16 bits. In D they are 32. This means that integer operations are expensive.

But hey, if it works for your application, I can't argue with that!

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.

Sure, people don't use exceptions and RTTI and other expensive things on microcontrollers. But, as you say, they use it for less expensive or zero cost things like member functions, operator overloading, templates (not very common, but I've seen some interesting 0-cost wrappers that increased the safety of setting registers), etc. But I'm not here to advocate C++, I've only used it incidentally for microcontrollers (AVR, the Arduino libraries are C++, urg).

> For example, ints in C are 16 bits. In D they are 32. This means that integer operations are expensive.

I don't understand this point of view. You are literally saying that writing "int x" is more expensive in D than in 16-bit C because they mean something different. Uhh, so just write "short x" in D? That's the equivalent code. Why would you write code that's character-by-character the same but means a different machine type?

If that's because short is more inconvenient in D than in C, I can understand that! But C also has a lot of annoying limitations, I feel that overall it's still a win.

If you give me more concrete examples I can try to address them. Just keep in mind that it's still fairly low level D code. I'm not throwing new Exceptions! But you can use modules, static ifs, templates... Modules alone sometimes feel like enough benefit...

On Monday, 10 July 2017 at 21:53:16 UTC, Luís Marques wrote:
> 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.
>
> Sure, people don't use exceptions and RTTI and other expensive things on microcontrollers. But, as you say, they use it for less expensive or zero cost things like member functions, operator overloading, templates (not very common, but I've seen some interesting 0-cost wrappers that increased the safety of setting registers), etc. But I'm not here to advocate C++, I've only used it incidentally for microcontrollers (AVR, the Arduino libraries are C++, urg).
>
>> For example, ints in C are 16 bits. In D they are 32. This means that integer operations are expensive.
>
> I don't understand this point of view. You are literally saying that writing "int x" is more expensive in D than in 16-bit C because they mean something different. Uhh, so just write "short x" in D? That's the equivalent code. Why would you write code that's character-by-character the same but means a different machine type?
>
> If that's because short is more inconvenient in D than in C, I can understand that! But C also has a lot of annoying limitations, I feel that overall it's still a win.
>
> If you give me more concrete examples I can try to address them. Just keep in mind that it's still fairly low level D code. I'm not throwing new Exceptions! But you can use modules, static ifs, templates... Modules alone sometimes feel like enough benefit...

The problem Walter pointed to is that due to integer promotion, arithmetic operands of types smaller than int are converted to int, hence even if you use bytes and shorts you would end up using ints, which are expensive on CPUs with no native 32-bit registers. In theory, you could write your code so that it's easy for the optimizer to prove that you're only using 8 or 16 bits and variables would fit in single registers, so you would be able to get away without a performance penalty for using a language where ints are 32-bit.

On Monday, 10 July 2017 at 22:39:22 UTC, Petar Kirov [ZombineDev] wrote:
> The problem Walter pointed to is that due to integer promotion, arithmetic operands of types smaller than int are converted to int, hence even if you use bytes and shorts you would end up using ints, which are expensive on CPUs with no native 32-bit registers. In theory, you could write your code so that it's easy for the optimizer to prove that you're only using 8 or 16 bits and variables would fit in single registers, so you would be able to get away without a performance penalty for using a language where ints are 32-bit.

Ah, that makes sense. Thanks for clarifying. For me it hasn't proved a problem, but I could see it being if you do a lot of arithmetic with 16-bit integers.

On Monday, 10 July 2017 at 23:01:50 UTC, Luís Marques wrote:
> On Monday, 10 July 2017 at 22:39:22 UTC, Petar Kirov [ZombineDev] wrote:
>> The problem Walter pointed to is that due to integer promotion, arithmetic operands of types smaller than int are converted to int, hence even if you use bytes and shorts you would end up using ints, which are expensive on CPUs with no native 32-bit registers. In theory, you could write your code so that it's easy for the optimizer to prove that you're only using 8 or 16 bits and variables would fit in single registers, so you would be able to get away without a performance penalty for using a language where ints are 32-bit.
>
> Ah, that makes sense. Thanks for clarifying. For me it hasn't proved a problem, but I could see it being if you do a lot of arithmetic with 16-bit integers.

I just want to point out, that my impression is that the maker scene
using all this 16 bit Arm Arduino and what ever micro controllers,
would be happy to have D as an alternative for coding in C.
So BetterC and D_16 might attract a way bigger community than many
other might think. Even if this reduced language might need to be named D-- :-).

On Wednesday, 12 July 2017 at 09:38:13 UTC, Martin Tschierschke wrote:
> On Monday, 10 July 2017 at 23:01:50 UTC, Luís Marques wrote:
>> On Monday, 10 July 2017 at 22:39:22 UTC, Petar Kirov [ZombineDev] wrote:
>>> The problem Walter pointed to is that due to integer
>> Ah, that makes sense. Thanks for clarifying. For me it hasn't proved a problem, but I could see it being if you do a lot of arithmetic with 16-bit integers.
>
> I just want to point out, that my impression is that the maker scene
> using all this 16 bit Arm Arduino and what ever micro controllers,
> would be happy to have D as an alternative for coding in C.
> So BetterC and D_16 might attract a way bigger community than many
> other might think. Even if this reduced language might need to be named D-- :-).
I would like to have a D that throw away all that integer promotion garbage anyway. We have CommonType!(), which is all we need and any promotion to a larger type than the common type of two operands does us no good in any place I can think of.

On Monday, 10 July 2017 at 21:30:44 UTC, Walter Bright wrote:
> On 7/10/2017 1:52 PM, Luís Marques wrote:
>> On Monday, 10 July 2017 at 20:19:46 UTC, Walter Bright wrote:
>>> On 7/10/2017 12:46 PM, Luís Marques wrote:
>>> I'm curious how that implementation addresses the issues I brought up:
>> 
>> I'm not really sure how to respond, you mostly just made statements about your worldview. For instance:
>> 
>> "C++ on a 64K machine is like using a tank to get to the grocery store". If you mean using all of C++ features, sure, that's inappropriate. If you mean that there are no C++ features that you could use in a microcontroller, there are non-trivial amounts of people the disagree with you.
>
> 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.

There's more to that. Since these chips have limited computational capabilities, you really want to move as much computation as possible into compile time. And this is what makes C++ a better choice than C, and D a better choice than C++. It's also the safer and more expressive type system that saves you the time you would spent on debugging every kind of bug resulting from casting everything to void* and back.