Re: version=D_16
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
Re: version=D_16
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 ;)
Re: version=D_16
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?
Re: version=D_16
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.
Re: version=D_16
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.
Re: version=D_16
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-- :-).
Re: version=D_16
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.
Re: version=D_16
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.
Re: version=D_16
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...
Re: version=D_16
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!
Re: version=D_16
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...
Re: version=D_16
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
version=D_16
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
