www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Newbie questions. Which Compiler to start with? Real Time behaviour?

reply "John Carter" <john.carter taitradio.com> writes:
So I'm a reasonably experienced C/C++/Ruby/... programmer and D 
is looking very Good to me...

So, time to get serious and sit down and learn it.

Ultimately it won't pay me to learn it unless I can ultimately 
take my colleagues along.

Currently they are itching to move from C to C++, and I'm trying 
to convince them not to.

We work in the embedded linux real time area, so here are a few 
newbie questions that I couldn't spot the answer to...

1) Which D compiler should we start with? We use gcc/g++ for 
everything else, is gcd a good choice or should we stick with 
Digital mars one? (We would be cross compiling to sparc or arm)

2) The traditional argument against garbage collected languages 
in real time environments is that they sporadically lock up while 
collecting resulting in missed real time deadlines. Certainly the 
"state of the art" in GC has moved beyond this, and also there 
are workarounds for the problem. Is it possible to do real time 
programming in D?

3) A good starter project for me would be to take a well known 
cpu-intensive C++ template rich project and convert it to D and 
then present that side-by-side to my colleagues.

I like playing around with CImg, http://cimg.sourceforge.net/

CImg it is one huge template with chunks of macro magic to do 
image processing.

Before I start, has anyone converted CImg to DImg yet?

Thanks!
Sep 01 2013
next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
1) afaik you can't cross compile to arm with dmd. I know it's possible with
gdc.
2) There are people who successfully use d without gc. I think andrei
posted a stub gc that throws an exception every time the garbage collector
is tried to get used. You can't use whole phobos (yet) without gc.


2013/9/2 John Carter <john.carter taitradio.com>

 So I'm a reasonably experienced C/C++/Ruby/... programmer and D is looking
 very Good to me...

 So, time to get serious and sit down and learn it.

 Ultimately it won't pay me to learn it unless I can ultimately take my
 colleagues along.

 Currently they are itching to move from C to C++, and I'm trying to
 convince them not to.

 We work in the embedded linux real time area, so here are a few newbie
 questions that I couldn't spot the answer to...

 1) Which D compiler should we start with? We use gcc/g++ for everything
 else, is gcd a good choice or should we stick with Digital mars one? (We
 would be cross compiling to sparc or arm)

 2) The traditional argument against garbage collected languages in real
 time environments is that they sporadically lock up while collecting
 resulting in missed real time deadlines. Certainly the "state of the art"
 in GC has moved beyond this, and also there are workarounds for the
 problem. Is it possible to do real time programming in D?

 3) A good starter project for me would be to take a well known
 cpu-intensive C++ template rich project and convert it to D and then
 present that side-by-side to my colleagues.

 I like playing around with CImg, http://cimg.sourceforge.net/

 CImg it is one huge template with chunks of macro magic to do image
 processing.

 Before I start, has anyone converted CImg to DImg yet?

 Thanks!
Sep 01 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
John Carter:

 We work in the embedded linux real time area,
I think you could use D for embedded area, but I think of D more like a low level application language.
 1) Which D compiler should we start with?
dmd is more updated and it's the reference one, it compiles fast, but it produces less optimized binaries. All D compilers have some advantages and disadvantages. Also take in account the ldc2 compiler.
 (We would be cross compiling to sparc or arm)
I don't know about Sparc, but arm is being worked on gdc, but I don't expect the libraries to work well.
 2) The traditional argument against garbage collected languages 
 in real time environments is that they sporadically lock up 
 while collecting resulting in missed real time deadlines. 
 Certainly the "state of the art" in GC has moved beyond this, 
 and also there are workarounds for the problem. Is it possible 
 to do real time programming in D?
It's like real time programming in Java or C# (or in C++ game engines): you have to not allocate in the real-time parts of the code. Heap allocations in geeral, and GC allocations in particular are not yet designed for realtime work.
 3) A good starter project for me would be to take a well known 
 cpu-intensive C++ template rich project and convert it to D and 
 then present that side-by-side to my colleagues.
To do that you have to learn D first, learn the D idioms, and then write the translation. It will take some time. Do you already have an idea for what code to translate?
 I like playing around with CImg, http://cimg.sourceforge.net/
I have used CImg in past, and it's a cute huge header. I like it for its lack of dependences. Importing a header is (or was) enough.
 CImg it is one huge template with chunks of macro magic to do 
 image processing.
I didn't know it uses significant macros. Could you show some of such code pieces?
 Before I start, has anyone converted CImg to DImg yet?
I think no one has converted CImg to D. There is a graphics project for D, perhaps named simplegraphics, that contains about 0.01% of CImg. I don't know but perhaps the conversion CImg to D could take a year or two of work for a person that knows D :-) Bye, bearophile
Sep 01 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 2 September 2013 at 00:32:52 UTC, bearophile wrote:
 I think no one has converted CImg to D. There is a graphics 
 project for D, perhaps named simplegraphics, that contains 
 about 0.01% of CImg.
If you mean my little libs, I'm not really aiming for complex drawing. simpledisplay.d has the basic functions that all operating systems have (lines, rectangles, etc.) and as of recently, some OpenGL support for drawing on screen, but not much beyond that. I am working on a generic drawing library that works entirely in memory without OS assistance, but again my plan is to keep it simple and just do the basics so it won't be anywhere near what cimg does. Some of this code is now in color.d on my github, and more is in a file called image_basicdrawing that I haven't posted online yet. But I use words like "simple" and "basic" in the filenames hopefully to keep people from getting their hopes too high so they aren't disappointed when it doesn't do what they want :)
Sep 01 2013
prev sibling parent reply "John Carter" <john.carter taitradio.com> writes:
Thanks for your reply!

On Monday, 2 September 2013 at 00:32:52 UTC, bearophile wrote:

 I didn't know it uses significant macros. Could you show some 
 of such code pieces?
Here is the documentation... http://cimg.sourceforge.net/reference/group__cimg__loops.html // Macros to perform various image loops. // // These macros are simpler to use than loops with C++ iterators. #define cimg_for(img,ptrs,T_ptrs) for (T_ptrs *ptrs = (img)._data, *_max##ptrs = (img)._data + (img).size(); ptrs<_max##ptrs; ++ptrs) Probably more interesting are the neighbourhood ops like... #define cimg_for2(bound,i) \ for (int i = 0, _n1##i = 1>=(bound)?(int)(bound)-1:1; \ _n1##i<(int)(bound) || i==--_n1##i; \ ++i, ++_n1##i) #define cimg_for2x2(img,x,y,z,c,I,T) \ cimg_for2((img)._height,y) for (int x = 0, \ _n1##x = (int)( \ (I[0] = (T)(img)(0,y,z,c)), \ (I[2] = (T)(img)(0,_n1##y,z,c)), \ 1>=(img)._width?(img).width()-1:1); \ (_n1##x<(img).width() && ( \ (I[1] = (T)(img)(_n1##x,y,z,c)), \ (I[3] = (T)(img)(_n1##x,_n1##y,z,c)),1)) || \ x==--_n1##x; \ I[0] = I[1], \ I[2] = I[3], \ ++x, ++_n1##x)
 I don't know but perhaps the conversion CImg to D could take a 
 year or two of work for a person that knows D :-)
I guess one of the interesting questions it would answer is "How easy is it to convert both C++ programs and C++ programmers to D?"
Sep 01 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
John Carter:

 "How easy is it to convert both C++ programs and C++ 
 programmers to D?"
Porting C code to D is not hard, it's mostly mechanical work, you just have to keep an eye on few things (like passing fixed-sized arrays to functions by reference, global floating point data not initialized to zero, etc). I think that for a C++ programmer it's not too much hard to learn D. But converting C++ code to D could be very hard (and a slow work) if the code uses lot of small things that are specific of C++ and missing or different in D. If the C++ code is more plain, then it's probably not hard, despite the missing multiple inheritance and struct inheritance. Converting CImg to D seems a multi-years work. Bye, bearophile
Sep 01 2013
parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Monday, 2 September 2013 at 02:38:35 UTC, bearophile wrote:
 John Carter:

 "How easy is it to convert both C++ programs and C++ 
 programmers to D?"
Porting C code to D is not hard, it's mostly mechanical work, you just have to keep an eye on few things (like passing fixed-sized arrays to functions by reference, global floating point data not initialized to zero, etc). I think that for a C++ programmer it's not too much hard to learn D. But converting C++ code to D could be very hard (and a slow work) if the code uses lot of small things that are specific of C++ and missing or different in D. If the C++ code is more plain, then it's probably not hard, despite the missing multiple inheritance and struct inheritance. Converting CImg to D seems a multi-years work. Bye, bearophile
While I just had a brief look at CImg and am thus far from an expert I wonder if developing a similar project in D would be quite that bad. There seems like a lot of the code isn't core functionality for an image processing library. The whole header file is 40+K lines of code. The system seems to include its own cross-platform image/graphics rendering system. There are 1100+ loc are just static arrays storing fonts. Furthermore, while it does seem to include a tonne of image processing functions, I am sure a basic library could initially omit many of these. For example there is a math formula parser that accounts for a huge chunk of the library. Certainly something you would want to have in the long run, but might be omitted initially. Finally, the use of templates seems fairly straightforward - at least by my brief perusal, and the code is more C like that C++ like. It doesn't appear to have a complex object hierarchy at all. So, I think this might be doable if: 1. You skipped the image display system (that shouldn't be part of a library in my opinion anyway). 2. You identified what your priority functionality would be and (initially at least) dropped the others [eg. the math formula parser]. Craig
Sep 04 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 1 September 2013 at 23:35:16 UTC, John Carter wrote:
 We work in the embedded linux real time area, so here are a few 
 newbie questions that I couldn't spot the answer to...

 1) Which D compiler should we start with? We use gcc/g++ for 
 everything else, is gcd a good choice or should we stick with 
 Digital mars one? (We would be cross compiling to sparc or arm)
dmd is usually used only as development compiler because it is a reference one and because if fast compilation times. ldc and gdc code gen is much better and cross-compilation to arm is a serious indication that gdc is a best option.
 2) The traditional argument against garbage collected languages 
 in real time environments is that they sporadically lock up 
 while collecting resulting in missed real time deadlines. 
 Certainly the "state of the art" in GC has moved beyond this, 
 and also there are workarounds for the problem. Is it possible 
 to do real time programming in D?
I have answered this some time ago on SO: http://stackoverflow.com/questions/16668821/using-d-for-a-realtime-application/16687816#16687816 It is possible but not convenient. And requires good knowledge of D internals.
Sep 02 2013
prev sibling parent "Ramon" <spam thanks.no> writes:
Maybe I'm somewhat disturbed but I'd rather go the other way
round, i.e. (ab)use D as a comfortable and less error prone way
to create C Code. But oh well that's wet dreaming anyway for
quite some time.

To your questions:

Considering that you are new to D (like myself), come from gnu
compiler world and are doing embedded, you will most likely be
used to and want debugging. Therefore -> GDC.
It's simply the only option that allows for painless debugging.
Furthermore, support by the developer(s) is excellent and
friendly.

DMD is the ref. and is, besides some quirks, nicely working and
uncannily fast.
LDC (haven't had a closer look at it myself) is interesting for
llvm alone.

Right now, though, GDC is what you might want to have good look
at.

Ad "GC": As some pros already indicated, it's possible; well,
many things are possible - but it wise?

I think it depends a whole lot on factors like CPU, RAM, RT'ness.
For something highly RT critical on a 16bit, 20K RAM MCU GC is a
no-go and so quite probably is D.
For a "fat" Cortex M4 or a SPARC (what a beauty!) with RAM in the
MB range and real-time needs/criticality being not so high or
even sporadic D could quite well be the way to go, if only phobos
were completely ported.
Even a certain level of RT-crit. must not necessarily be a reason
to stay away from D, if e.g. one could split the job in a low
layer C and the major part in D with all its strengths and
comfort.

In summary though, it - unfortunately - seems somewhat early to
switch to D for embedded on Arm and Sparc.

Should you learn D or at least have an extended look at it,
anyway? Definitely yes. And if it was only to see what's
possible, how C-like programming can and should be done, and to
better and more deeply understand paradigms and concepts related
to reliability.

A+ -R
Sep 05 2013