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
parent reply "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
next sibling parent reply "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 

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
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 reply "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
next sibling parent reply "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
parent reply "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
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Jan 22 2013
parent reply "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
parent reply "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
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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.


I could argue the toss, but I'm instead going to have talk about why you
are wrong... in May perhaps... :o)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Jan 22 2013
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.


 I could argue the toss, but I'm instead going to have talk 
 about why you
 are wrong... in May perhaps... :o)
Jan 22 2013
prev sibling parent reply "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
parent reply "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
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 reply "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
parent reply 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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
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
prev sibling parent reply "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
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 "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
next sibling parent reply "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
parent reply "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
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
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 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 reply "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
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 "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 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 parent Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Jan 22 2013
prev 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