www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - version=D_16

reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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
Jul 10 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Jul 10 2017
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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...
Jul 10 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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!
Jul 10 2017
next sibling parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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...
Jul 10 2017
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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.
Jul 10 2017
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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.
Jul 10 2017
parent reply Martin Tschierschke <mt smartdolphin.de> writes:
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-- :-).
Jul 12 2017
parent Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:
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.
Jul 12 2017
prev sibling next sibling parent Adrian Matoga <dlang.spam matoga.info> writes:
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.
Jul 12 2017
prev sibling next sibling parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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?
Jul 13 2017
parent Stefan Koch <uplink.coder googlemail.com> writes:
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 ;)
Jul 13 2017
prev sibling parent Mike <none none.com> writes:
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
Jul 13 2017