www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Trust about D programming.

reply "MMj" <mohsen1365b yahoo.com> writes:
Hello Folks.
How are you?
Excuse me, I need a trust about D programming and C, In your 
opinion D can be a replace for C?
Why a user should use D?
Please let me know your opinion.

Thank you.
Cheers.
Jan 22 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote:
 Hello Folks.
 How are you?
 Excuse me, I need a trust about D programming and C, In your 
 opinion D can be a replace for C?
 Why a user should use D?
 Please let me know your opinion.

 Thank you.
 Cheers.

It really depend on what you try to achieve. But in many case it is a viable alternative. In other, things need to be ironed out.
Jan 22 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 22.01.2013 17:19, schrieb Freddie Chopin:
 On Tuesday, 22 January 2013 at 15:42:04 UTC, Paulo Pinto wrote:
 It is possible to do C free development in embedded systems, using
 system programming languages with GC.

Instead of just ditching C or C++ for something related to Delphi, it would be nicer to use D, as it's multithreading options look quite nice (;

Sure, I was actually trying to point out the existence of strong type languages for (some type) of embedded development. It would be surely nice to use something like D.
 There are of course embedded systems, where the only way to program is
 either Assembly or a crippled down version of C due to hardware
 constraints.

Well, a typical ARM Cortex-M3 is not THAT crippled, it just does not have that much RAM to waste - rarely there's more than 64kB, usually less than 32kB...
 However, if the hardware is able to execute full ANSI C code, then
 there are other options becoming available.

Well, it's not about "full ANSI C", because you could do that on 8051 30 years ago... it just the matter of: a. RAM usage b. heap usage c. real-time constraints

I had PIC micro-controlers with memory in the order of bytes, when I wrote that. If I am not mistaken, many of the C compilers for such environments are limited on what is actually possible to use from ANSI C. There was an assembler from TI which looked like C control flow with intrinsics, but I am no longer able to find the information.
 For a typical ARM bare-metal microcontroller C++ exceptions are
 a-bit-too-much (taking ~60kB of flash code when almost not used, and
 60kB quite often would be 95% of available code memory, but in more
 common cases 25-50%), in D these are probably inevitable and I could
 live with that (; But I just cannot imagine a GC on a microcontroller
 that has so little RAM and which has to do something in real-time - you
 probably will just get annoyed if an app on PC freezes for a second, but
 if a 100-tonne crane controller freezes for that time it can end really
 bad (;

Agreed.
 Yes, GC and dynamic memory is really cool, but it costs just a lot of
 RAM... You can sometimes live with mallocs() (but modestly used), yet I
 cannot imaging GC in so small memory. It can be easily assumed that such
 applications don't do a lot of memory allocation at run-time (usually
 none), so the GC would just waste time and memory...

True, although in my naïve opinion, I would expect such systems to still be developed in Assembly.
 It is just a matter to get a more widespread acceptance.

I think it's just a matter of realistic expectations (; A LOT (and I really mean that) people think that ARM based microcontrollers are an overkill for most of the tasks, so you'll just not convince them to use an even more expensive chip, which has 4x the amount of RAM just to use "a fancy language".

Yes, I know the issues of a few cents per unit might imply.
 And do remember we're not talking about routers and smartphones that
 have 128MB of RAM, but rather about home automation systems, some
 industrial controllers (but not HMI with a fancy GUI, but the devices
 that really do the monitoring and control), maybe some electronics
 embedded in toys (RC models etc.).

 4\/3!!

Faire enough, I guess even C has issues on those systems right? Thanks for the comprehensive post, Paulo
Jan 22 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 22.01.2013 19:33, schrieb Freddie Chopin:
 On Tuesday, 22 January 2013 at 18:14:30 UTC, Paulo Pinto wrote:
 ... [cutted]
 Faire enough, I guess even C has issues on those systems right?

If we stick to ARM (like Cortex-M3) there are no issues other than memory limitations, and it generally concerns mostly RAM, as code memory is usually big enough (hundreds of kB usually, up to 512kB, sometimes 1MB). That's why you cannot get too fancy with your code, and - unfortunately - most of nice programming "tricks" are dynamic-memory-only... On the other hand, maybe I should ask what do you consider "an issue"? There's definitely nothing "non-standard" in the C/C++ that you use here - there's just no OS (but you can have an RTOS - scheduler), no POSIX (but there are POSIX-like RTOSes) and not-a-lot of RAM (there's no library for fixing that [; ). 4\/3!!

I don't really have much embedded experience besides assembly programming in the old days (Z80, M68000, x86, MIPS, self build processor for digital circuits class). My understanding is that the processors the micro-controler class, the ones with memory in the order of bytes or kilobytes, usually C compilers that only implement part of the ANSI standard, given the hardware constraints. Meaning just a very small subset of data types is supported, limited library support and lots of compiler extensions to make use of the processor and on die ports. I used to follow PIC articles for a while in the Elektor magazine, hence my fuzzy knowledge about this. -- Paulo
Jan 22 2013
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 23.01.2013 08:59, schrieb Mehrdad:
 On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote:
 But the trend is C is becoming more and more a high-level assembler.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html This blog post (the first in a series of three) tries to explain some of these issues so that you can better understand the tradeoffs and complexities involved, and perhaps learn a few more of the dark sides of C. It turns out that C is not a "high level assembler" like many experienced C programmers (particularly folks with a low-level focus) like to think, and that C++ and Objective-C have directly inherited plenty of issues from it.

Yes, I keep repeating that. Many developers have no idea that modern CPUs do lots of things that invalidate the concept of C as a "high level assembler". Most likely fuelled by the fact that many don't learn modern CPU architectures nowadays. -- Paulo
Jan 23 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/23/2013 9:10 PM, Era Scarecrow wrote:
   I remember doing things like that. If I was dividing something by 8 I would
 shift right instead by 3;

Compilers were doing that optimization 35 years ago, and probably decades longer than that. Generally, if you're thinking about doing an optimization, it pays to check the output of the compiler, as it has probably beaten you to it :-)
Jan 24 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 24.01.2013 11:20, schrieb Walter Bright:
 On 1/23/2013 9:10 PM, Era Scarecrow wrote:
   I remember doing things like that. If I was dividing something by 8
 I would
 shift right instead by 3;

Compilers were doing that optimization 35 years ago, and probably decades longer than that. Generally, if you're thinking about doing an optimization, it pays to check the output of the compiler, as it has probably beaten you to it :-)

It helps to have a broader experience in many languages. I think C only developers tend to suffer from premature optimization disease. :) -- Paulo
Jan 24 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/24/2013 8:43 AM, H. S. Teoh wrote:
 I remember being actually offended when I read about premature
 optimization. I felt insulted at the idea that my hand-written code
 could actually underperform what the compiler mechanically produces. Too
 bad it's actually true. :-P

 I later learned that my obsession with premature optimization distracted
 me from actually thinking about the algorithms, so that I was spending
 90% of my time optimizing the last CPU cycles out of an O(N^2) algorithm
 when even a poorly-written O(log N) algorithm would have easily
 outperformed my "optimized" code.

 Not to mention the humiliation of discovering, when I actually profiled
 my code, that the hotspots were nowhere near where I thought they were.
 I had spent 90% of my time "optimizing" for a <1% gain, when a simple
 algorithm fix at the real hotspot gained 20% instantly.

Don't feel bad. Everyone goes through that. Keep in mind that people who are attracted to the dirty job of writing compiler back ends tend to be people who are old time assembler hackers, and they know the tricks of the trade. Naturally, they wire that knowledge into the compiler. And they do learn new tricks all the time, and put those in, too. It's like thinking you can buy a $10 gimmick from the auto parts store and increase your gas mileage 10%. Ain't gonna happen, the car makers aren't stupid.
Jan 24 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 24, 2013 at 05:34:52PM +0100, Paulo Pinto wrote:
 Am 24.01.2013 11:20, schrieb Walter Bright:
On 1/23/2013 9:10 PM, Era Scarecrow wrote:
  I remember doing things like that. If I was dividing something by
  8 I would shift right instead by 3;

Compilers were doing that optimization 35 years ago, and probably decades longer than that. Generally, if you're thinking about doing an optimization, it pays to check the output of the compiler, as it has probably beaten you to it :-)

It helps to have a broader experience in many languages. I think C only developers tend to suffer from premature optimization disease. :)

I remember being actually offended when I read about premature optimization. I felt insulted at the idea that my hand-written code could actually underperform what the compiler mechanically produces. Too bad it's actually true. :-P I later learned that my obsession with premature optimization distracted me from actually thinking about the algorithms, so that I was spending 90% of my time optimizing the last CPU cycles out of an O(N^2) algorithm when even a poorly-written O(log N) algorithm would have easily outperformed my "optimized" code. Not to mention the humiliation of discovering, when I actually profiled my code, that the hotspots were nowhere near where I thought they were. I had spent 90% of my time "optimizing" for a <1% gain, when a simple algorithm fix at the real hotspot gained 20% instantly. T -- MSDOS = MicroSoft's Denial Of Service
Jan 24 2013
prev sibling next sibling parent "MMj" <mohsen1365b yahoo.com> writes:
On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote:
 On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote:
 Hello Folks.
 How are you?
 Excuse me, I need a trust about D programming and C, In your 
 opinion D can be a replace for C?
 Why a user should use D?
 Please let me know your opinion.

 Thank you.
 Cheers.

It really depend on what you try to achieve. But in many case it is a viable alternative. In other, things need to be ironed out.

I saw D wiki and understand some goals about but Can you tell me why you choose D and not C?
Jan 22 2013
prev sibling next sibling parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Tuesday, 22 January 2013 at 11:17:32 UTC, MMj wrote:
 On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote:
 On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote:
 Hello Folks.
 How are you?
 Excuse me, I need a trust about D programming and C, In your 
 opinion D can be a replace for C?
 Why a user should use D?
 Please let me know your opinion.

 Thank you.
 Cheers.

It really depend on what you try to achieve. But in many case it is a viable alternative. In other, things need to be ironed out.

I saw D wiki and understand some goals about but Can you tell me why you choose D and not C?

From my perspective, D cannot replace C in sense "you can throw C away". Well, maybe it could theoretically, but not practically. But the trend is C is becoming more and more a high-level assembler. Things like mapping to a register, no hidden costs, "you can basically see the assembler when programming in C". So programming OS kernels and stuff is very practical in C. I guess C++ could replace C in a sense "you can throw C away" in foreseeable future. Because, essentially C++ is a better C than C. It might go this way or not, but the potential is good enough. Things in D are kind of upside down. It places itself close to C++, but if C++ looks towards C from that position, D looks towards Java/C#. It makes it very appealing for "productive" (in Java sense) and "efficient" (in C sense) systems programming. E.g. right know, I think D is very compelling for writing a server (vibe.d would be a good example). But for embedded programming I don't think D is a good practical choice. C and C++ shines there and I don't think things are changing soon.
Jan 22 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
Well I could name slicing and meta programming (templates, traits,
mixins). But in reality it is more the feel of the language. It is easy
to read, (in D I even understand programs written by other people!), it
is powerful. Due to its meta programming techniques it has much of the
power typically only found in dynamically typed languages, but with the
safety and speed of compiled, statically typed language.

Typically when a language becomes powerful, it also becomes complex and
hard to learn, I think D did a really good job in being one of the most
powerful languages out there but still being "easy" to learn and
understand, in particular easy to read. The concepts are sound and well
thought of.

It is fun to use it. 

The down side is, that it is far less mature than C or C++. 

One of the things that convinced me, was slices and the way the GC is
put to good use. Things that make me stick to it, are the meta
programming capabilities, its power and its design.

Best regards,

Robert

On Tue, 2013-01-22 at 12:17 +0100, MMj wrote:
 On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote:
 On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote:
 Hello Folks.
 How are you?
 Excuse me, I need a trust about D programming and C, In your 
 opinion D can be a replace for C?
 Why a user should use D?
 Please let me know your opinion.

 Thank you.
 Cheers.

It really depend on what you try to achieve. But in many case it is a viable alternative. In other, things need to be ironed out.

I saw D wiki and understand some goals about but Can you tell me why you choose D and not C?

Jan 22 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--f46d0438912173c9b504d3dee722
Content-Type: text/plain; charset=ISO-8859-1

On 22 January 2013 11:17, MMj <mohsen1365b yahoo.com> wrote:

 On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote:

 On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote:

 Hello Folks.
 How are you?
 Excuse me, I need a trust about D programming and C, In your opinion D
 can be a replace for C?
 Why a user should use D?
 Please let me know your opinion.

 Thank you.
 Cheers.

It really depend on what you try to achieve. But in many case it is a viable alternative. In other, things need to be ironed out.

I saw D wiki and understand some goals about but Can you tell me why you choose D and not C?

I choose D for safety and speed. :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --f46d0438912173c9b504d3dee722 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 2 January 2013 11:17, MMj <span dir=3D"ltr">&lt;<a href=3D"mailto:mohsen136= 5b yahoo.com" target=3D"_blank">mohsen1365b yahoo.com</a>&gt;</span> wrote:= <br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef= t:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Tuesday, 22 January 2013 at 10:4= 5:27 UTC, deadalnix wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Hello Folks.<br> How are you?<br> Excuse me, I need a trust about D programming and C, In your opinion D can = be a replace for C?<br> Why a user should use D?<br> Please let me know your opinion.<br> <br> Thank you.<br> Cheers.<br> </blockquote> <br> It really depend on what you try to achieve. But in many case it is a viabl= e alternative. In other, things need to be ironed out.<br> </blockquote> <br></div></div> I saw D wiki and understand some goals about but Can you tell me why you ch= oose D and not C?<br> </blockquote></div><br></div><div class=3D"gmail_extra">I choose D for safe= ty and speed. :-)<br clear=3D"all"></div><div class=3D"gmail_extra"><br>-- = <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#3= 9;; </div></div> --f46d0438912173c9b504d3dee722--
Jan 22 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote:
 On Tuesday, 22 January 2013 at 11:17:32 UTC, MMj wrote:
 On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote:
 On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote:
 Hello Folks.
 How are you?
 Excuse me, I need a trust about D programming and C, In your 
 opinion D can be a replace for C?
 Why a user should use D?
 Please let me know your opinion.

 Thank you.
 Cheers.

It really depend on what you try to achieve. But in many case it is a viable alternative. In other, things need to be ironed out.

I saw D wiki and understand some goals about but Can you tell me why you choose D and not C?

From my perspective, D cannot replace C in sense "you can throw C away". Well, maybe it could theoretically, but not practically. But the trend is C is becoming more and more a high-level assembler. Things like mapping to a register, no hidden costs, "you can basically see the assembler when programming in C".

This is only true in very simple processor architectures. In modern optimizing C compilers targeting modern CPUs, C no longer maps to the hardware as much as many C coders still think it does. -- Paulo
Jan 22 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote:
 But for embedded programming I don't think D is a good 
 practical choice. C and C++ shines there and I don't think 
 things are changing soon.

It would be a shame if D would be PC-only... Maybe when GDC will be ready things will change - who knows... Apart from the garbage collector, which really is not embedded-friendly (I'm talking about kilobytes of RAM, not megabytes) everything sounds quite OK in the specs (; 4\/3!!
Jan 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 22 January 2013 at 13:36:15 UTC, Freddie Chopin wrote:
 On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote:
 But for embedded programming I don't think D is a good 
 practical choice. C and C++ shines there and I don't think 
 things are changing soon.

It would be a shame if D would be PC-only... Maybe when GDC will be ready things will change - who knows... Apart from the garbage collector, which really is not embedded-friendly (I'm talking about kilobytes of RAM, not megabytes) everything sounds quite OK in the specs (; 4\/3!!

What is the problem with gdc ? I used to use it for ages.
Jan 22 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 22 January 2013 at 13:37:38 UTC, deadalnix wrote:
 What is the problem with gdc ? I used to use it for ages.

Have you tried compiling it for something like bare-metal ARM (arm-none-eabi target)? Check the thread about embedded D in the GDC (D.GNU) forum to see what problems exist when you want to compile that for an OS-less target that doesn't provide hundreds of POSIX functions. Do note that embedded does not mean "smartphone with Android". When GDC will be part of GCC a proper support for other platforms will probably appear, not only for PC with Windows/Linux/MacOS. 4\/3!!
Jan 22 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--20cf307f397c1b841c04d3e0dd96
Content-Type: text/plain; charset=ISO-8859-1

On 22 January 2013 13:43, Freddie Chopin <freddie_chopin op.pl> wrote:

 On Tuesday, 22 January 2013 at 13:37:38 UTC, deadalnix wrote:

 What is the problem with gdc ? I used to use it for ages.

Have you tried compiling it for something like bare-metal ARM (arm-none-eabi target)? Check the thread about embedded D in the GDC (D.GNU) forum to see what problems exist when you want to compile that for an OS-less target that doesn't provide hundreds of POSIX functions. Do note that embedded does not mean "smartphone with Android". When GDC will be part of GCC a proper support for other platforms will probably appear, not only for PC with Windows/Linux/MacOS. 4\/3!!

That's a common misconception. Other platform support are already appearing (ARM, MIPS, PPC), it just requires users who have the hardware and knowledge to port the D runtime over. Regards, -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --20cf307f397c1b841c04d3e0dd96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 2 January 2013 13:43, Freddie Chopin <span dir=3D"ltr">&lt;<a href=3D"mailt= o:freddie_chopin op.pl" target=3D"_blank">freddie_chopin op.pl</a>&gt;</spa= n> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Tuesday, 22 January 201= 3 at 13:37:38 UTC, deadalnix wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What is the problem with gdc ? I used to use it for ages.<br> </blockquote> <br></div> Have you tried compiling it for something like bare-metal ARM (arm-none-eab= i target)? Check the thread about embedded D in the GDC (D.GNU) forum to se= e what problems exist when you want to compile that for an OS-less target t= hat doesn&#39;t provide hundreds of POSIX functions.<br> <br> Do note that embedded does not mean &quot;smartphone with Android&quot;.<br=

When GDC will be part of GCC a proper support for other platforms will prob= ably appear, not only for PC with Windows/Linux/MacOS.<br> <br> 4\/3!!<br> </blockquote></div><br></div><div class=3D"gmail_extra">That&#39;s a common= misconception.=A0 Other platform support are already appearing (ARM, MIPS,= PPC), it just requires users who have the hardware and knowledge to port t= he D runtime over.<br> <br><br></div><div class=3D"gmail_extra">Regards,<br>-- <br>Iain Buclaw<br>= <br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --20cf307f397c1b841c04d3e0dd96--
Jan 22 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 22 January 2013 at 13:50:51 UTC, Iain Buclaw wrote:
 That's a common misconception.  Other platform support are 
 already
 appearing (ARM, MIPS, PPC), it just requires users who have the 
 hardware
 and knowledge to port the D runtime over.

That's what I meant (; A small misunderstanding [; 4\/3!!
Jan 22 2013
prev sibling next sibling parent "mist" <none none.none> writes:
Well, "porting druntime" is not exactly the thing I can call 
"support from GDC", it is somewhat orthogonal from compiler.

On Tuesday, 22 January 2013 at 13:55:05 UTC, Freddie Chopin wrote:
 On Tuesday, 22 January 2013 at 13:50:51 UTC, Iain Buclaw wrote:
 That's a common misconception.  Other platform support are 
 already
 appearing (ARM, MIPS, PPC), it just requires users who have 
 the hardware
 and knowledge to port the D runtime over.

That's what I meant (; A small misunderstanding [; 4\/3!!

Jan 22 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--14dae9cfc85020967a04d3e16639
Content-Type: text/plain; charset=ISO-8859-1

On 22 January 2013 14:02, mist <none none.none> wrote:

 Well, "porting druntime" is not exactly the thing I can call "support from
 GDC", it is somewhat orthogonal from compiler.

are wrong... in May perhaps... :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --14dae9cfc85020967a04d3e16639 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 2 January 2013 14:02, mist <span dir=3D"ltr">&lt;<a href=3D"mailto:none non= e.none" target=3D"_blank">none none.none</a>&gt;</span> wrote:<br><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"> Well, &quot;porting druntime&quot; is not exactly the thing I can call &quo= t;support from GDC&quot;, it is somewhat orthogonal from compiler.<div clas= s=3D"HOEnZb"><div class=3D"h5"><br> <br></div></div></blockquote><div><br></div><div>I could argue the toss, bu= t I&#39;m instead going to have talk about why you are wrong... in May perh= aps... :o)<br></div><br></div><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p+= + : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --14dae9cfc85020967a04d3e16639--
Jan 22 2013
prev sibling next sibling parent "mist" <none none.none> writes:
Please do, looking forward to watching video about how I am wrong 
:)

On Tuesday, 22 January 2013 at 14:29:11 UTC, Iain Buclaw wrote:
 On 22 January 2013 14:02, mist <none none.none> wrote:

 Well, "porting druntime" is not exactly the thing I can call 
 "support from
 GDC", it is somewhat orthogonal from compiler.

about why you are wrong... in May perhaps... :o)

Jan 22 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 22 January 2013 at 13:36:15 UTC, Freddie Chopin wrote:
 On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote:
 But for embedded programming I don't think D is a good 
 practical choice. C and C++ shines there and I don't think 
 things are changing soon.

It would be a shame if D would be PC-only... Maybe when GDC will be ready things will change - who knows... Apart from the garbage collector, which really is not embedded-friendly (I'm talking about kilobytes of RAM, not megabytes) everything sounds quite OK in the specs (; 4\/3!!

Ah, you mean something like Astrobe, an Oberon compiler for the ARM Cortex-M3 and NXP LPC2000 micro-controlers? http://www.astrobe.com/default.htm Presentation from the 2011 Oberon days, http://www.oberonday2011.ethz.ch/talks/armembedded.pdf It is possible to do C free development in embedded systems, using system programming languages with GC. There are of course embedded systems, where the only way to program is either Assembly or a crippled down version of C due to hardware constraints. However, if the hardware is able to execute full ANSI C code, then there are other options becoming available. It is just a matter to get a more widespread acceptance. -- Paulo
Jan 22 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 22 January 2013 at 15:42:04 UTC, Paulo Pinto wrote:
 It is possible to do C free development in embedded systems, 
 using system programming languages with GC.

Instead of just ditching C or C++ for something related to Delphi, it would be nicer to use D, as it's multithreading options look quite nice (;
 There are of course embedded systems, where the only way to 
 program is either Assembly or a crippled down version of C due 
 to hardware constraints.

Well, a typical ARM Cortex-M3 is not THAT crippled, it just does not have that much RAM to waste - rarely there's more than 64kB, usually less than 32kB...
 However, if the hardware is able to execute full ANSI C code, 
 then there are other options becoming available.

Well, it's not about "full ANSI C", because you could do that on 8051 30 years ago... it just the matter of: a. RAM usage b. heap usage c. real-time constraints For a typical ARM bare-metal microcontroller C++ exceptions are a-bit-too-much (taking ~60kB of flash code when almost not used, and 60kB quite often would be 95% of available code memory, but in more common cases 25-50%), in D these are probably inevitable and I could live with that (; But I just cannot imagine a GC on a microcontroller that has so little RAM and which has to do something in real-time - you probably will just get annoyed if an app on PC freezes for a second, but if a 100-tonne crane controller freezes for that time it can end really bad (; Yes, GC and dynamic memory is really cool, but it costs just a lot of RAM... You can sometimes live with mallocs() (but modestly used), yet I cannot imaging GC in so small memory. It can be easily assumed that such applications don't do a lot of memory allocation at run-time (usually none), so the GC would just waste time and memory...
 It is just a matter to get a more widespread acceptance.

I think it's just a matter of realistic expectations (; A LOT (and I really mean that) people think that ARM based microcontrollers are an overkill for most of the tasks, so you'll just not convince them to use an even more expensive chip, which has 4x the amount of RAM just to use "a fancy language". And do remember we're not talking about routers and smartphones that have 128MB of RAM, but rather about home automation systems, some industrial controllers (but not HMI with a fancy GUI, but the devices that really do the monitoring and control), maybe some electronics embedded in toys (RC models etc.). 4\/3!!
Jan 22 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 22 January 2013 at 18:14:30 UTC, Paulo Pinto wrote:
 If I am not mistaken, many of the C compilers for such 
 environments are limited on what is actually possible to use 
 from ANSI C.

From what I've heard D is 32- and 64-bits only, so that actually leaves things like ARM, MIPS, AVR32 and such cores, these usually have really good GCC support, so I guess there are no "special" limits... It also depends on what you mean by "ANSI C" - for example for ARM, GCC and newlib's libc you basically have everything [; Things that are "OS-dependent" - like malloc(), stdio functions (printf(), ...) and stuff like that require you to provide "re-targeting syscalls" (like sbrk(), write(), read(), ...) but that's not a big issue [; You basically have whole libstdc++ too (from GCC), with all the templates, containers, iterators and stuff, plus typical C++ stuff - exceptions, RTTI, new, delete etc. - some of these things depend on the syscalls I mentioned above, some of these features take just too much memory [; So I guess that 32-bit microcontrollers are really standards-compliant! (;
 True, although in my naïve opinion, I would expect such systems 
 to still be developed in Assembly.

Do you mean controllers for 100-tonne crane of maybe just "general embedded microcontroller"? I guess that no one would go so low for things that can be done in C with a cheap chip like Cortex-M0 [;
 Faire enough, I guess even C has issues on those systems right?

If we stick to ARM (like Cortex-M3) there are no issues other than memory limitations, and it generally concerns mostly RAM, as code memory is usually big enough (hundreds of kB usually, up to 512kB, sometimes 1MB). That's why you cannot get too fancy with your code, and - unfortunately - most of nice programming "tricks" are dynamic-memory-only... On the other hand, maybe I should ask what do you consider "an issue"? There's definitely nothing "non-standard" in the C/C++ that you use here - there's just no OS (but you can have an RTOS - scheduler), no POSIX (but there are POSIX-like RTOSes) and not-a-lot of RAM (there's no library for fixing that [; ). 4\/3!!
Jan 22 2013
prev sibling next sibling parent "angel" <andrey.gelman gmail.com> writes:
C requirements are extremely low. With only a couple of standard 
library functions (I think memcpy() and memcmp()) gcc starts to 
generate viable code. You can code on bare metal out of the box.
D 'flyes' much higher - it uses a whole runtime, and requires OS 
services. Of course there are ways to adapt D to bare metal, but 
C was born adapted.
But, for coding on top of fully fledged OS, looks like D is a 
good choice.
Jan 22 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 22 January 2013 at 21:02:32 UTC, Paulo Pinto wrote:
 I don't really have much embedded experience besides assembly 
 programming in the old days (Z80, M68000, x86, MIPS, self build 
 processor for digital circuits class).

 My understanding is that the processors the micro-controler 
 class, the ones with memory in the order of bytes or kilobytes, 
 usually C compilers that only implement part of the ANSI 
 standard, given the hardware constraints.

 Meaning just a very small subset of data types is supported, 
 limited library support and lots of compiler extensions to make 
 use of the processor and on die ports.

Nothing like this here - you have all types, you have complete libm, libc and stdlibc++ with everything you need. There are no compiler extensions other than a typical GCC __attribute__ used to declare interrupts, which is not really necessary on most Cortex-M3 chips. These are really powerful chips with 1.25DMIPS/MHz and clocks around 70MHz (ranging from 24MHz to 204MHz)... There's even a dual-core chip - LPC43xx which has Cortex-M4F (with single precision hardware FPU and some SIMD instructions) and a Cortex-M0, both running at 204MHz <: So these are not very much like 8-bit microcontrollers (AVR, PIC, ...) That's why I think D would fit such chips quite nice (; Sans the GC of course... Maybe without exceptions too, but I don't think that would be possible (it's pretty hard in C++)... 4\/3!!
Jan 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote:
 But the trend is C is becoming more and more a high-level 
 assembler.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html This blog post (the first in a series of three) tries to explain some of these issues so that you can better understand the tradeoffs and complexities involved, and perhaps learn a few more of the dark sides of C. It turns out that C is not a "high level assembler" like many experienced C programmers (particularly folks with a low-level focus) like to think, and that C++ and Objective-C have directly inherited plenty of issues from it.
Jan 22 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 22 January 2013 at 21:14:21 UTC, Freddie Chopin wrote:
 On Tuesday, 22 January 2013 at 21:02:32 UTC, Paulo Pinto wrote:
 I don't really have much embedded experience besides assembly 
 programming in the old days (Z80, M68000, x86, MIPS, self 
 build processor for digital circuits class).

 My understanding is that the processors the micro-controler 
 class, the ones with memory in the order of bytes or 
 kilobytes, usually C compilers that only implement part of the 
 ANSI standard, given the hardware constraints.

 Meaning just a very small subset of data types is supported, 
 limited library support and lots of compiler extensions to 
 make use of the processor and on die ports.

Nothing like this here - you have all types, you have complete libm, libc and stdlibc++ with everything you need. There are no compiler extensions other than a typical GCC __attribute__ used to declare interrupts, which is not really necessary on most Cortex-M3 chips. These are really powerful chips with 1.25DMIPS/MHz and clocks around 70MHz (ranging from 24MHz to 204MHz)... There's even a dual-core chip - LPC43xx which has Cortex-M4F (with single precision hardware FPU and some SIMD instructions) and a Cortex-M0, both running at 204MHz <: So these are not very much like 8-bit microcontrollers (AVR, PIC, ...) That's why I think D would fit such chips quite nice (; Sans the GC of course... Maybe without exceptions too, but I don't think that would be possible (it's pretty hard in C++)... 4\/3!!

Thanks for the valuable explanation.
Jan 23 2013
prev sibling next sibling parent "Oleg Kuporosov" <Oleg.Kuporosov gmail.com> writes:
On Wednesday, 23 January 2013 at 21:14:26 UTC, Paulo Pinto wrote:

 Many developers have no idea that modern CPUs do lots of things 
 that invalidate the concept of C as a "high level assembler".

Paolo, the most important features of C makes it "high-level assembler" it are pointer and its arithmetics. What hell "modern CPUs" doing wrong with it? Thanks, Oleg.
Jan 23 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 24, 2013 at 04:59:15AM +0100, Oleg Kuporosov wrote:
 On Wednesday, 23 January 2013 at 21:14:26 UTC, Paulo Pinto wrote:
 
Many developers have no idea that modern CPUs do lots of things
that invalidate the concept of C as a "high level assembler".

Paolo, the most important features of C makes it "high-level assembler" it are pointer and its arithmetics. What hell "modern CPUs" doing wrong with it?

For one thing, modern CPUs have pipelines and caches. Modern optimizing C compilers often rearrange instructions in order to maximize performance by reducing (or eliminating) pipeline hazards and cache misses. The resulting assembly code often look nothing like the source code. (In fact, some CPUs do this internally as well, and optimizing compilers often rearrange the code in order to take maximum advantage of what the CPU is doing.) The result of this is that many of the so-called "optimizations" that C programmers like to do by hand (and I am among them) actually have no real benefits, and in fact, sometimes has worse performance because it obscures your intent to the compiler, so the compiler is unable to produce the best code for it. T -- Ignorance is bliss... but only until you suffer the consequences!
Jan 23 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 24 January 2013 at 04:31:24 UTC, H. S. Teoh wrote:
 For one thing, modern CPUs have pipelines and caches. Modern 
 optimizing C compilers often rearrange instructions in order to 
 maximize performance by reducing (or eliminating) pipeline 
 hazards and cache misses. The resulting assembly code often 
 look nothing like the source code. (In fact, some CPUs do this 
 internally as well, and optimizing compilers often rearrange 
 the code in order to take maximum advantage of what the CPU is 
 doing.)

 The result of this is that many of the so-called 
 "optimizations" that C programmers like to do by hand (and I am 
 among them) actually have no real benefits, and in fact, 
 sometimes has worse performance because it obscures your intent 
 to the compiler, so the compiler is unable to produce the best 
 code for it.

I remember doing things like that. If I was dividing something by 8 I would shift right instead by 3; Although it does the same job it hides my intent from readers (and even myself) and might not allow the compiler to make better optimizations because of it. I ended up coming to the conclusion after reading a lot on compilers that the compilers do a decent job of finding cases where it replace them with better choices and condensing code. Rather than doing math for a fixed set of calculations, it pre-calculates them and sets it into variables that are used, drops whole sections that don't do anything, etc. In today's CPU's the C compiler is somewhat obsolete. Half the time to make use of special hardware (say the MPU's in video cards) you need to do assembly code anyways for access to them. The compiler might make use of MMX or other instruction sets but that seems a bit more unlikely on it's own without some hints or certain code patterns that suggest heavy use where it would benefit heavily from (and the hardware flags know the target can handle said instructions).
Jan 23 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 24 January 2013 at 10:21:06 UTC, Walter Bright wrote:
 On 1/23/2013 9:10 PM, Era Scarecrow wrote:
  I remember doing things like that. If I was dividing 
 something by 8 I would
 shift right instead by 3;

Compilers were doing that optimization 35 years ago, and probably decades longer than that. Generally, if you're thinking about doing an optimization, it pays to check the output of the compiler, as it has probably beaten you to it :-)

Well, some micro optimization pay off, but any straightforward one is already done by the compiler. Even some tricky one in fact. One that is not done to the best of my knowledge is the dual loop : uint countChar(char* cstr, char c) { uint count; while(*cstr) { while(*cstr && *cstr != c) cstr++; if(*cstr == c) { count++; cstr++; } } } Which is faster as the straightforward way of doing things.
Jan 24 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 24 January 2013 at 03:59:17 UTC, Oleg Kuporosov 
wrote:
 On Wednesday, 23 January 2013 at 21:14:26 UTC, Paulo Pinto 
 wrote:

 Many developers have no idea that modern CPUs do lots of 
 things that invalidate the concept of C as a "high level 
 assembler".

Paolo, the most important features of C makes it "high-level assembler" it are pointer and its arithmetics. What hell "modern CPUs" doing wrong with it? Thanks, Oleg.

Almost every language that compiles to native code as its default implementation, has some way of doing pointer manipulation, that is not what makes C a "high level assembler". What used to give C such status as the almost one-to-one correspondence between what developers write and the corresponding Assembly instructions. As many already answered before me, this one-to-one correspondence does not exist any longer. -- Paulo
Jan 24 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Wednesday, 23 January 2013 at 08:54:46 UTC, Paulo Pinto wrote:
 Nothing like this here - you have all types, you have complete 
 libm, libc and stdlibc++ with everything you need. There are 
 no compiler extensions other than a typical GCC __attribute__ 
 used to declare interrupts, which is not really necessary on 
 most Cortex-M3 chips. These are really powerful chips with 
 1.25DMIPS/MHz and clocks around 70MHz (ranging from 24MHz to 
 204MHz)... There's even a dual-core chip - LPC43xx which has 
 Cortex-M4F (with single precision hardware FPU and some SIMD 
 instructions) and a Cortex-M0, both running at 204MHz <:

 So these are not very much like 8-bit microcontrollers (AVR, 
 PIC, ...)

 That's why I think D would fit such chips quite nice (; Sans 
 the GC of course... Maybe without exceptions too, but I don't 
 think that would be possible (it's pretty hard in C++)...

 4\/3!!

Thanks for the valuable explanation.

The Cortex M4F based STM32F4 is an awesome ucontroller. It has 192kb of RAM, up to 2Mb of Flash, a FPU, I2S, I2C, USART, ethernet, etc. And it costs a few $ only. http://en.wikipedia.org/wiki/STM32#STM32_F4 You can play with one for about 20$ using the ST STM32F4 Discovery board. Python (running on bare metal, no OS) has been ported to it. If you really are serious with this ucontroller, you want to spend a few hundreds dollars and go with the Keil or Atollic toolchains, which bring IDE, debugger, desassembly, network analyzer, etc.
Jan 26 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Sunday, 27 January 2013 at 07:36:50 UTC, SomeDude wrote:
 If you really are serious with this ucontroller, you want to 
 spend a few hundreds dollars and go with the Keil or Atollic 
 toolchains, which bring IDE, debugger, desassembly, network 
 analyzer, etc.

1. Atollic is just Eclipse + GCC + GDB + some proprietary plugins. 2. Keil does not cost "a few" hundred dollars, unless by "a few" you mean "30" or something like that. 3. All the features you list are also present in open-source and free solutions. 4\/3!!
Jan 27 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 27 January 2013 at 08:52:08 UTC, Freddie Chopin wrote:
 On Sunday, 27 January 2013 at 07:36:50 UTC, SomeDude wrote:
 If you really are serious with this ucontroller, you want to 
 spend a few hundreds dollars and go with the Keil or Atollic 
 toolchains, which bring IDE, debugger, desassembly, network 
 analyzer, etc.

1. Atollic is just Eclipse + GCC + GDB + some proprietary plugins. 2. Keil does not cost "a few" hundred dollars, unless by "a few" you mean "30" or something like that. 3. All the features you list are also present in open-source and free solutions. 4\/3!!

1. it's a bit more than that. 2. a friend of mine bought the Keil development board. It's awesome, and it includes the toolchain. That one costs around 300 euros.
Jan 27 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Sunday, 27 January 2013 at 15:01:51 UTC, SomeDude wrote:
 On Sunday, 27 January 2013 at 08:52:08 UTC, Freddie Chopin 
 wrote:
 On Sunday, 27 January 2013 at 07:36:50 UTC, SomeDude wrote:
 If you really are serious with this ucontroller, you want to 
 spend a few hundreds dollars and go with the Keil or Atollic 
 toolchains, which bring IDE, debugger, desassembly, network 
 analyzer, etc.

1. Atollic is just Eclipse + GCC + GDB + some proprietary plugins. 2. Keil does not cost "a few" hundred dollars, unless by "a few" you mean "30" or something like that. 3. All the features you list are also present in open-source and free solutions. 4\/3!!

1. it's a bit more than that.

Whatever suits your needs - for me it's not much more than what I listed (; Most of that I can get for free.
 2. a friend of mine bought the Keil development board. It's 
 awesome, and it includes the toolchain. That one costs around 
 300 euros.

Ask him what the restrictions are, as I just don't see a 3000€ toolchain being included with a 300€ board... And - believe me - Keil DOES cost 3000€ (~4000$) - per year... In case it's just the regular demo version, you can download it from network. http://pl.mouser.com/Search/Refine.aspx?Keyword=keil&Ns=Pricing%7c1&FS=True standard one year license - http://pl.mouser.com/ProductDetail/Keil-Tools/MDK-PRO-T/?qs=sGAEpiMZZMvjj1qeIvr2hhBSab3Xr1Fj 4\/3!!
Jan 27 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 27 January 2013 at 20:49:47 UTC, Freddie Chopin wrote:
 Ask him what the restrictions are, as I just don't see a 3000€ 
 toolchain being included with a 300€ board... And - believe me 
 - Keil DOES cost 3000€ (~4000$) - per year... In case it's just 
 the regular demo version, you can download it from network.

 4\/3!!

It's a "MDK-Lite" version, whatever that means. http://www.keil.com/mcbstm32F400/
Jan 27 2013
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 27 January 2013 at 22:35:21 UTC, SomeDude wrote:
 On Sunday, 27 January 2013 at 20:49:47 UTC, Freddie Chopin 
 wrote:
 Ask him what the restrictions are, as I just don't see a 3000€ 
 toolchain being included with a 300€ board... And - believe me 
 - Keil DOES cost 3000€ (~4000$) - per year... In case it's 
 just the regular demo version, you can download it from 
 network.

 4\/3!!

It's a "MDK-Lite" version, whatever that means. http://www.keil.com/mcbstm32F400/

It does have some serious limitations: http://www.keil.com/support/man/docs/mcbstm32f200/mcbstm32f200_pr_mdk.htm
Jan 27 2013