www.digitalmars.com         C & C++   DMDScript  

D.gnu - D for embedded system

reply "Timo Sintonen" <t.sintonen luukku.com> writes:
I have written programs with C for Arm Cortex controller boards. 
I think that D might be an interesting nut simple enough oo 
language. So far I have a working gdc for my target, but I can 
not compile the runtime library because of too many os related 
assertions.
With my own makefile I can compile part of the library, so I know 
tha compiler is working. Is there a way to make a minimum 
library? Embedded systems do not have file systems or streams or 
many other things that operating systems have. There would be no 
need for the whole libaray, but the compiler needs at least the 
Object class.
So is it possible to configure a minimum library or should I just 
look at every file and remove everything that is not needed?
Oct 18 2012
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 October 2012 12:36, Timo Sintonen <t.sintonen luukku.com> wrote:
 I have written programs with C for Arm Cortex controller boards. I think
 that D might be an interesting nut simple enough oo language. So far I have
 a working gdc for my target, but I can not compile the runtime library
 because of too many os related assertions.
 With my own makefile I can compile part of the library, so I know tha
 compiler is working. Is there a way to make a minimum library? Embedded
 systems do not have file systems or streams or many other things that
 operating systems have. There would be no need for the whole libaray, but
 the compiler needs at least the Object class.
 So is it possible to configure a minimum library or should I just look at
 every file and remove everything that is not needed?

What OS are you working on? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 18 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-19 20:08, Johannes Pfau wrote:

 Druntime might not need file access/etc as long as version(Posix) isn't
 defined for your target.

 Nobody has used GDC/D/druntime on a system without OS afaik. So you
 have to pioneer ;-) I see two solutions:

There are developers who have used D1 to create an operating system, or kernel. http://wiki.xomb.org/index.php?title=Main_Page https://github.com/xomboverlord/xomb Last update, 4 months ago, I thought it was completely dead.
 * Create your own, simple runtime library. There's no real
    documentation on the minimum interface a runtime must implement (the
    compiler calls back into the runtime), so this would be a little
    tricky.

 * Adjust druntime. You can probably throw out 90% of the druntime code
    (core.sys.*). Make sure the basic code work with ansi C. Forget
    about things like threading (core.thread, core.sync), those require
    system specific code and can be implemented later on. Your biggest
    problem is probably the GC and TLS. If your target libc supports
    TLS, things should work just fine. If not, there's some additional
    work waiting. You need to reimplement some functions for the GC (get
    stack top/bottom...) which shouldn't be too difficult, but getting
    the TLS range might be tricky, depending on your system.
    You could also try to remove the GC completely, but the language
    currently assumes that a GC is available (things like dynamic array
    appending, ...). A proper -nogc switch which disables GC features
    like array appending would be a solution, but nothing like this is
    implemented yet, IIRC. (But I think there was some kind of --betterc
    switch which could be a start?)

There are a lot of other features in D that depend on the runtime, which one needs to be aware of. -- /Jacob Carlborg
Oct 20 2012
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
 What OS are you working on?

Linux
Oct 18 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 October 2012 16:12, Timo Sintonen <t.sintonen luukku.com> wrote:
 What OS are you working on?

Linux

I shouldn't have thought there would be any asserts when compiling the library (at least I don't get any). Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 18 2012
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
 I shouldn't have thought there would be any asserts when 
 compiling the
 library (at least I don't get any).

 Regards

Yes, but I need the library for the cross compiled target, arm-eabi. This target doen not define any os. There are several places where is a test for mac/win/linux and if none of them, the last choice is "unsupported target". If it pass, some symbols are not defined at all causing trouble somewhere else. So we need a version define like "embedded" or "no_os" that leaves totally out all os related stuff like file access or provides dummy functions.
Oct 18 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 18 Oct 2012 17:51:46 +0200
schrieb "Timo Sintonen" <t.sintonen luukku.com>:

 I shouldn't have thought there would be any asserts when 
 compiling the
 library (at least I don't get any).

 Regards

Yes, but I need the library for the cross compiled target, arm-eabi. This target doen not define any os. There are several places where is a test for mac/win/linux and if none of them, the last choice is "unsupported target". If it pass, some symbols are not defined at all causing trouble somewhere else. So we need a version define like "embedded" or "no_os" that leaves totally out all os related stuff like file access or provides dummy functions.

Druntime might not need file access/etc as long as version(Posix) isn't defined for your target. Nobody has used GDC/D/druntime on a system without OS afaik. So you have to pioneer ;-) I see two solutions: * Create your own, simple runtime library. There's no real documentation on the minimum interface a runtime must implement (the compiler calls back into the runtime), so this would be a little tricky. * Adjust druntime. You can probably throw out 90% of the druntime code (core.sys.*). Make sure the basic code work with ansi C. Forget about things like threading (core.thread, core.sync), those require system specific code and can be implemented later on. Your biggest problem is probably the GC and TLS. If your target libc supports TLS, things should work just fine. If not, there's some additional work waiting. You need to reimplement some functions for the GC (get stack top/bottom...) which shouldn't be too difficult, but getting the TLS range might be tricky, depending on your system. You could also try to remove the GC completely, but the language currently assumes that a GC is available (things like dynamic array appending, ...). A proper -nogc switch which disables GC features like array appending would be a solution, but nothing like this is implemented yet, IIRC. (But I think there was some kind of --betterc switch which could be a start?)
Oct 19 2012
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
 Nobody has used GDC/D/druntime on a system without OS afaik. So 
 you
 have to pioneer ;-)

So I have to try it on my own...
 * Create your own, simple runtime library. There's no real
   documentation on the minimum interface a runtime must 
 implement (the
   compiler calls back into the runtime), so this would be a 
 little
   tricky.

I have already made some tests: I compiled a simple class without any library. The missing symbols tell me what is the minimum that is expected to be in Object class. I tried to compile an empty Object class. There is some problems because Object seems to be a reserved word in gdc. The biggest problem is that gdc gets an internal error every time I try to compile my own Object. If this is an unknown bug in gdc, I may look it again. (an internal compiler error is always a bug, isn't it?)
 * Adjust druntime. You can probably throw out 90% of the 
 druntime code

I compiled object.d without imports and commented out everything that failed the compilation. There is still some missing symbols but I think this version would not work anyway. I have a working glibc, newlib and my own minimum libc. So I would follow the linux version as far as possible. Because Linux is a reserved word I changed with sed all the linux version checks to another word and got nearly all compiled. First time I got over 400 lines of missisng symbols but I could see what functions are expected from the c library.
 Your biggest
   problem is probably the GC and TLS.

To be more general, the library should have a minimum version with no threads and gc and be configurable to have them. In controller world resources are limited. We talk about kilobytes when pc people talk about gigabytes. The advantage is that everything is usually fixed and known at design time. Memory is usually allocated once and kept as long as the device is operating. The same is for threads. Threads are initiated at startup and have only one instance. They keep running as long as the device is operating. In the threading system I use now the main loop of each thread is run once and at the end of the loop control is returned to the scheduler which jumps to the next thread. So the application can run without gc and tls. On the other hand, the amount of threads is known. It is even possible to hardcode tls address for every thread if needed. Memory pool and stack are also in fixed addresses and all pointers are available. So the low level stuff would be quite simple. The biggest job is to get it work with the higher level code.
Oct 20 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 20 October 2012 09:23, Timo Sintonen <t.sintonen luukku.com> wrote:
 Nobody has used GDC/D/druntime on a system without OS afaik. So you
 have to pioneer ;-)

So I have to try it on my own...
 * Create your own, simple runtime library. There's no real
   documentation on the minimum interface a runtime must implement (the
   compiler calls back into the runtime), so this would be a little
   tricky.

I have already made some tests: I compiled a simple class without any library. The missing symbols tell me what is the minimum that is expected to be in Object class. I tried to compile an empty Object class. There is some problems because Object seems to be a reserved word in gdc. The biggest problem is that gdc gets an internal error every time I try to compile my own Object. If this is an unknown bug in gdc, I may look it again. (an internal compiler error is always a bug, isn't it?)
 * Adjust druntime. You can probably throw out 90% of the druntime code

I compiled object.d without imports and commented out everything that failed the compilation. There is still some missing symbols but I think this version would not work anyway. I have a working glibc, newlib and my own minimum libc. So I would follow the linux version as far as possible. Because Linux is a reserved word I changed with sed all the linux version checks to another word and got nearly all compiled. First time I got over 400 lines of missisng symbols but I could see what functions are expected from the c library.
 Your biggest
   problem is probably the GC and TLS.

To be more general, the library should have a minimum version with no threads and gc and be configurable to have them. In controller world resources are limited. We talk about kilobytes when pc people talk about gigabytes. The advantage is that everything is usually fixed and known at design time. Memory is usually allocated once and kept as long as the device is operating. The same is for threads. Threads are initiated at startup and have only one instance. They keep running as long as the device is operating. In the threading system I use now the main loop of each thread is run once and at the end of the loop control is returned to the scheduler which jumps to the next thread. So the application can run without gc and tls. On the other hand, the amount of threads is known. It is even possible to hardcode tls address for every thread if needed. Memory pool and stack are also in fixed addresses and all pointers are available. So the low level stuff would be quite simple. The biggest job is to get it work with the higher level code.

Quick question, what is defined in your phobos-vers-syms file? (This will be located in the libphobos / libdruntime build directory). Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 20 2012
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Saturday, 20 October 2012 at 09:40:28 UTC, Iain Buclaw wrote:

 Quick question,  what is defined in your phobos-vers-syms file?
  (This
 will be located in the libphobos / libdruntime build directory).

 Regards

NoSystem DCFG_NEARBYINT DCFG_TGAMMA DCFG_NAN GNU_Need_exp2 GNU_Need_log2 DCFG_EXECVPE DCFG_SPAWNVP GNU_CBridge_Stdio GNU_ARM_EABI_Unwinder
Oct 20 2012
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Thu, 18 Oct 2012 13:36:45 +0200, Timo Sintonen <t.sintonen luukku.com>  
wrote:

 I have written programs with C for Arm Cortex controller boards. I think  
 that D might be an interesting nut simple enough oo language. So far I  
 have a working gdc for my target, but I can not compile the runtime  
 library because of too many os related assertions.
 With my own makefile I can compile part of the library, so I know tha  
 compiler is working. Is there a way to make a minimum library? Embedded  
 systems do not have file systems or streams or many other things that  
 operating systems have. There would be no need for the whole libaray,  
 but the compiler needs at least the Object class.
 So is it possible to configure a minimum library or should I just look  
 at every file and remove everything that is not needed?

I recently did a project on the STM32F0-Discovery board. After having used a nice arm-none-eabi-*/openocd toolchain I wonder what is needed to build a cross-gdc. As these devices are really short on Flash and RAM I would've only translated the peripheral headers without using any runtime. Not sure though if you can get classes without full typeinfos support. martin
Oct 20 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-18 00:07, maarten van damme wrote:

 Why wasn't opted for making opIndex overloadable with other objects so
 AA's could be moved out of druntime and in phobos?

One reason for why AA's are in druntime is for the syntax sugar: int[string] aa; If the AA's where only in Phobos, this would be the syntax: AssociativeArray!(string, int) aa; Originally there were much more code in the compiler for handling associative arrays. Then, not that long a go, there was a rewrite that tried to move as much as possible to druntime instead. -- /Jacob Carlborg
Nov 18 2012
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Saturday, 20 October 2012 at 14:35:44 UTC, Martin Nowak wrote:
 I recently did a project on the STM32F0-Discovery board.
 After having used a nice arm-none-eabi-*/openocd toolchain I 
 wonder what is needed to build a cross-gdc.
 As these devices are really short on Flash and RAM I would've 
 only translated the peripheral headers
 without using any runtime.
 Not sure though if you can get classes without full typeinfos 
 support.

without it. One test I made shows that object and typeinfo would take 16-20 kb flash. In addition we need some libc code and application code. STM32F0 may be too small. My target is STM32F4
Oct 20 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Sat, 20 Oct 2012 17:27:33 +0200
schrieb "Timo Sintonen" <t.sintonen luukku.com>:

 On Saturday, 20 October 2012 at 14:35:44 UTC, Martin Nowak wrote:
 I recently did a project on the STM32F0-Discovery board.
 After having used a nice arm-none-eabi-*/openocd toolchain I 
 wonder what is needed to build a cross-gdc.
 As these devices are really short on Flash and RAM I would've 
 only translated the peripheral headers
 without using any runtime.
 Not sure though if you can get classes without full typeinfos 
 support.

without it. One test I made shows that object and typeinfo would take 16-20 kb flash. In addition we need some libc code and application code. STM32F0 may be too small. My target is STM32F4

It's sad that we don't have a documentation about features which require runtime support. If you manage to get this working please make some notes about what features need the runtime (You can use the gdc wiki, gdcproject.org/wiki or the d wiki: http://prowiki.org/wiki4d/wiki.cgi?FrontPage ) BTW: Here's the dmd commit which introduced betterc: https://github.com/D-Programming-Language/dmd/commit/707949edc30f245a68145bef619f6f02b85e39ab but right now it only disables moduleinfo generation, afaics. You probably already noticed that you can compile stuff without druntime support just fine (compile with -nophoboslib), as long as you only use c functions: ----------------------------- import core.stdc.stdio; extern(C) in main(int argc, const char* argv[]) { printf("Hello World!\n".ptr); return 0; } ----------------------------- As soon as a feature requires runtime support you'll get linker errors.
Oct 20 2012
prev sibling next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
It's also sad that druntime is so difficult to port to other platforms
because of the version(platformdependent) all over the place. Would
there be a way to cleanly seperate platform-dependent stuff with
platform-independent stuff (so a no-os or android version would be
easier to make).
Oct 20 2012
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Saturday, 20 October 2012 at 18:40:51 UTC, Johannes Pfau wrote:

 BTW: Here's the dmd commit which introduced betterc:
 https://github.com/D-Programming-Language/dmd/commit/707949edc30f245a68145bef619f6f02b85e39ab
 but right now it only disables moduleinfo generation, afaics.

This is only in dmd. Gdc does not have this. (d-glue.cc line 2827, I think)
 You probably already noticed that you can compile stuff without 
 druntime
 support just fine (compile with -nophoboslib), as long as you 
 only use c functions:

It seems that cross compilers does not use standard includes and libraries by default. I have my own linker script anyway, because I have fixed addresses and my own program to load the code to the controller. When I get that far, I have to check the extra sections the compiler generates, whether they are needed or not. I naturally want to use classes. A test of a simple class: class mytest { int atest(int m) { return m; } } This makes 6 calls to Object and 5-6 calls to other druntime classes or to functions druntime wants from os.
Oct 21 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 20 October 2012 19:40, Johannes Pfau <nospam example.com> wrote:
 Am Sat, 20 Oct 2012 17:27:33 +0200
 schrieb "Timo Sintonen" <t.sintonen luukku.com>:

 On Saturday, 20 October 2012 at 14:35:44 UTC, Martin Nowak wrote:
 I recently did a project on the STM32F0-Discovery board.
 After having used a nice arm-none-eabi-*/openocd toolchain I
 wonder what is needed to build a cross-gdc.
 As these devices are really short on Flash and RAM I would've
 only translated the peripheral headers
 without using any runtime.
 Not sure though if you can get classes without full typeinfos
 support.

without it. One test I made shows that object and typeinfo would take 16-20 kb flash. In addition we need some libc code and application code. STM32F0 may be too small. My target is STM32F4

It's sad that we don't have a documentation about features which require runtime support. If you manage to get this working please make some notes about what features need the runtime (You can use the gdc wiki, gdcproject.org/wiki or the d wiki: http://prowiki.org/wiki4d/wiki.cgi?FrontPage ) BTW: Here's the dmd commit which introduced betterc: https://github.com/D-Programming-Language/dmd/commit/707949edc30f245a68145bef619f6f02b85e39ab but right now it only disables moduleinfo generation, afaics. You probably already noticed that you can compile stuff without druntime support just fine (compile with -nophoboslib), as long as you only use c functions: ----------------------------- import core.stdc.stdio; extern(C) in main(int argc, const char* argv[]) { printf("Hello World!\n".ptr); return 0; } ----------------------------- As soon as a feature requires runtime support you'll get linker errors.

What an awful name for a flag... (I suppose I better use -ffreestanding / -fhosted to map to that then). -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 21 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Saturday, 20 October 2012 at 15:27:34 UTC, Timo Sintonen wrote:

 STM32F0 may be too small.

Yeah probably. Are there any patches required to build a cross-gdc?
Oct 23 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 23 October 2012 17:37, Martin Nowak <dawg dawgfoto.de> wrote:
 On Saturday, 20 October 2012 at 15:27:34 UTC, Timo Sintonen wrote:

 STM32F0 may be too small.

Yeah probably. Are there any patches required to build a cross-gdc?

Nope - building a cross-compiler should be available in the gcc make infrastructure. The issue most people get with them is that the toolchain/environment for the cross-compiler is broken somewhere.... -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 23 2012
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Tuesday, 23 October 2012 at 16:37:11 UTC, Martin Nowak wrote:
  Are there any patches required to build a
 cross-gdc?

Before compiling gcc-package there should be binutils and libc for the target installed. Binutils is the gnu binutils package and as libc I have used newlib, which is a lighter version than gnu libc. Both are easy to compile with: configure --target=arm-eabi (or whatever the target is) for gcc I use this: ../gcc/configure --disable-bootstrap \ --enable-languages=c,c++,d --disable-nls --target=arm-eabi \ --without-headers --with-newlib --without-isl --without-cloog ( i have gcc sources in /usr/local/src/gcc and this script is in /usr/local/src/build-gcc) You should first compile and install only c compiler (enable-langugages=c). If this works, then add c++ and if this works, then add d. If you want to make it for Cortex, one small patch is needed in gcc/config/arm/t-arm-elf to get a working libgcc.a for thumb code. You do not necessary need this for simple programs. The d compilation fails currently to make the d runtime library and I am working on this. As suggested, we could start a wiki page for gdc cross compilers. So for the wiki maintainer: please create the page and add link to the front page
Oct 23 2012
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
I have started to make a minimum libdruntime. First I compiled 
object and now I am adding files one by one when needed.
The compiler generates lots of library calls. So far I have found 
these flags to get the code smaller and to reduce library calls: 
-fno-assert -fno-invariants and -fno-bouns-check.
Is there any other options that would make the executable more 
simple?
Nov 03 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 3 November 2012 12:44, Timo Sintonen <t.sintonen luukku.com> wrote:
 I have started to make a minimum libdruntime. First I compiled object and
 now I am adding files one by one when needed.
 The compiler generates lots of library calls. So far I have found these
 flags to get the code smaller and to reduce library calls: -fno-assert
 -fno-invariants and -fno-bouns-check.
 Is there any other options that would make the executable more simple?

Release/no bounds check would probably generate the least amount of library calls: -frelease -fno-bounds-check -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 03 2012
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
I have been able to make a minimum library, link it with my test 
program and run the program in my arm cortex-m4 controller board. 
Some features are disabled and many features are still untested. 
The library does not yet have threads and memory management is 
done with gcstub. My test program succesfully access static class 
data, generates two instances of a cloass and succesfully 
manipulates instance data.
All this was done with reasonable amount of work. No extra code 
needed so far, except system dependent malloc/realloc/free. So I 
think it is possible to make this library for other targets too.
Nov 11 2012
prev sibling next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
Why is so much built in to druntime? creating classes, AA's,....
Is it normal? does c++ do the same thing?

Why wasn't opted for making opIndex overloadable with other objects so
AA's could be moved out of druntime and in phobos?

I have no experience with language design but wouldn't it be great if
druntime was more modular to make porting (and stripping) of features
for for example embedded platforms more easy?

And is somewhere documented which functions need to be implemented in druntime?
Nov 17 2012
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Saturday, 17 November 2012 at 23:08:04 UTC, maarten van damme 
wrote:
 Why is so much built in to druntime? creating classes, AA's,....
 Is it normal? does c++ do the same thing?

 Why wasn't opted for making opIndex overloadable with other 
 objects so
 AA's could be moved out of druntime and in phobos?

 I have no experience with language design but wouldn't it be 
 great if
 druntime was more modular to make porting (and stripping) of 
 features
 for for example embedded platforms more easy?

 And is somewhere documented which functions need to be 
 implemented in druntime?

Druntime is a mixture of functions that the application may call, functions that the generated code calls and internal library functions. As pointed out earlier in this thread, there is no more documentation than those generated from the source files. They tell how to use the functions but does not tell when and why we need it. I started with my test class and object.d and added files one by one and commented out some features until all references were solved in that particular case. Nearly every file in the library is related to some d construction or keyword. If I use a construction in my application, I need a file from the library. Unfortunately, the whole file is included from the library even if I need a single funtion from it. The library has lots of version dependencies. First it has been made for win/mac/linux, then it has been ported to gdc. The next challenge is to add support for all mobile platforms and embedded systems with no os at all. In my opinion the version system will not work any more when we have 10 different systems to support. We should have abstract classes an put the real implementation to os specific directory. Then we make that directory as import directory. It might also be good to have a minimum implementation in configure. That would include only the necessary files and define version=minimum. This option would leave out as much as possible from the code. To make it work with all possible configuration may not be an easy task. All these takes lots of time and work. If the library is only for gdc, it would be simpler. To have a library that is totally different from the dmd version might not be a good idea. A library with different features and bugs may reduce the amount of possible users and it is harder to get people to maintain it.
Nov 18 2012
prev sibling next sibling parent reply "Freddie Chopin" <freddie_chopin op.pl> writes:
Hi!

Any progress on making D an usable alternative for C/C++ for ARM
MCUs? This would be VERY interesting thing! A wiki page was
mentioned several times, but I guess that it didn't happen, so
the only source of knowledge is this thread...

Anyway - do you think that D's threads could actually replace a
RTOS on an embedded system? This would be quite interesting too (;

Maybe a separate repo on github for embedded development would be
a good idea - more people would be able to help then (me
included!)...

4\/3!!
Jan 08 2013
parent reply Matthew Caron <matt.caron redlion.net> writes:
On 01/08/2013 09:22 AM, Freddie Chopin wrote:> Hi!
 Any progress on making D an usable alternative for C/C++ for ARM
 MCUs?

I had a cross compiler working based on an older version of this: http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG Bear in mind that my embedded system is an ARM CPU with at least 16MB of RAM, so it runs Linux and is basically just a small footprint Linux distro. If you mean "bare metal", I haven't done that.
 Anyway - do you think that D's threads could actually replace a
 RTOS on an embedded system? This would be quite interesting too (;

An RTOS does a lot more than manage threads. ;-) -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Jan 08 2013
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
08-Jan-2013 20:58, Freddie Chopin пишет:
 On Tuesday, 8 January 2013 at 16:52:05 UTC, Freddie Chopin wrote:
 Yes, we're talking about real bare-metal here (; I think D with it's
 safety fits really nicely in the embedded niche... I think that if D
 could be used on a system with 128kB of flash and 8kB of RAM that
 would be great. If it would require the chip to have more RAM it
 wouldn't be so great, but a 16kB or 32kB is still quite OK... This
 would probably require D's lib (phobos) to NOT depend on garbage
 collector (or maybe use it only in some high-level stuff that would be
 to big for such embedded system anyway).


I'd bet that the most of Phobos is out. Then it needs custom run-time w.r.t. threads and memory management (this could be built on top of whatever C-runtime is there), no GC and cutdown other features like RTTI (TypeInfo etc.) and/or class hierarchy with Object. Then, of course, to be practical it needs memory access to I/O ports/registers (this also could warp some C interface).
 To be even more specific - I'm talking about microCONTROLLERS (not
 micro-processors), ARM Cortex-M3 or Cortex-M4, STM32, LPC17xx, maybe
 even Cortex-M0 if the footprint is low enough... So no MMU, sometimes
 MPU (rarely), ROM in "hundreds of kilobytes", RAM in "tens of kilobytes"
 (sometimes less, rarely over 100kB - only for really big chips).

I'll get to use Cortex-M3/M4 rather soon (looking forward about half a year into future). So I'd love to know how to fit D in there.
 PC programmers have so many options to choose from, while on the MCUs
 it's basically only C (really about 99.666%), C++ sometimes, sometimes
 assembly - there are also things not worth mentioning like BASIC for
 some AVR chips and that's about all...

 4\/3!!

-- Dmitry Olshansky
Jan 08 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-08 17:52, Freddie Chopin wrote:

 Yes, we're talking about real bare-metal here (; I think D with it's
 safety fits really nicely in the embedded niche... I think that if D
 could be used on a system with 128kB of flash and 8kB of RAM that would
 be great. If it would require the chip to have more RAM it wouldn't be
 so great, but a 16kB or 32kB is still quite OK... This would probably
 require D's lib (phobos) to NOT depend on garbage collector (or maybe
 use it only in some high-level stuff that would be to big for such
 embedded system anyway).

This guy has created a GC free version of druntime and Phobos: http://3d.benjamin-thaut.de/?p=20 -- /Jacob Carlborg
Jan 08 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
09-Jan-2013 00:42, Freddie Chopin пишет:
 On Tuesday, 8 January 2013 at 20:13:54 UTC, Timo Sintonen wrote:
 Next I think I will make a list of required changes and then I will
 make a simple makefile to compile the library. If anybody is
 interested, please send an email to me and I will send those files
 back to you.

You should definetely post that to github or somewhere (dropbox, ...)! I'd be really interested to see the files (and maybe some details about strange things you need to do to get whole toolchain compiled), but I cannot see your e-mail with webinterface of this list... BTW - on GitHub you could just fork phobos and do your changes as normal commits and that would be clearly visible to anyone (;

+1 for placing the work as a fork on github. It would also make sure the project is more visible and allow others to contribute easily. Plus you can scratch up the build instructions in a wiki page there (to avoid repeating it over personal emails and/or making a mail-list). Just compare the current DMD/Phobos to the era prior to placing it on GitHub :) -- Dmitry Olshansky
Jan 08 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 8 January 2013 at 15:45:18 UTC, Matthew Caron wrote:
 On 01/08/2013 09:22 AM, Freddie Chopin wrote:> Hi!
 Any progress on making D an usable alternative for C/C++ for

 MCUs?

I had a cross compiler working based on an older version of this: http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG Bear in mind that my embedded system is an ARM CPU with at least 16MB of RAM, so it runs Linux and is basically just a small footprint Linux distro. If you mean "bare metal", I haven't done that.

Yes, we're talking about real bare-metal here (; I think D with it's safety fits really nicely in the embedded niche... I think that if D could be used on a system with 128kB of flash and 8kB of RAM that would be great. If it would require the chip to have more RAM it wouldn't be so great, but a 16kB or 32kB is still quite OK... This would probably require D's lib (phobos) to NOT depend on garbage collector (or maybe use it only in some high-level stuff that would be to big for such embedded system anyway).
 Anyway - do you think that D's threads could actually replace

 RTOS on an embedded system? This would be quite interesting

An RTOS does a lot more than manage threads. ;-)

Well, RTOSes ("schedulers") like FreeRTOS don't do that much - you have threads, mutexes/semaphores, message queue and software timers - all of them but the last one is covered by D APIs, but now I thought that D probably just uses some OS services for that (like POSIX pthread.h), wrapping it up a little... Anyway - I think these functions of D would nicely replace simple RTOSes that have a scheduler and nothing more... 4\/3!!
Jan 08 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 8 January 2013 at 16:52:05 UTC, Freddie Chopin wrote:
 Yes, we're talking about real bare-metal here (; I think D with 
 it's safety fits really nicely in the embedded niche... I think 
 that if D could be used on a system with 128kB of flash and 8kB 
 of RAM that would be great. If it would require the chip to 
 have more RAM it wouldn't be so great, but a 16kB or 32kB is 
 still quite OK... This would probably require D's lib (phobos) 
 to NOT depend on garbage collector (or maybe use it only in 
 some high-level stuff that would be to big for such embedded 
 system anyway).

To be even more specific - I'm talking about microCONTROLLERS (not micro-processors), ARM Cortex-M3 or Cortex-M4, STM32, LPC17xx, maybe even Cortex-M0 if the footprint is low enough... So no MMU, sometimes MPU (rarely), ROM in "hundreds of kilobytes", RAM in "tens of kilobytes" (sometimes less, rarely over 100kB - only for really big chips). PC programmers have so many options to choose from, while on the MCUs it's basically only C (really about 99.666%), C++ sometimes, sometimes assembly - there are also things not worth mentioning like BASIC for some AVR chips and that's about all... 4\/3!!
Jan 08 2013
prev sibling next sibling parent Matthew Caron <Matt.Caron redlion.net> writes:
On 01/08/2013 11:58 AM, Freddie Chopin wrote:
 To be even more specific - I'm talking about microCONTROLLERS (not
 micro-processors), ARM Cortex-M3 or Cortex-M4, STM32, LPC17xx, maybe
 even Cortex-M0 if the footprint is low enough... So no MMU, sometimes
 MPU (rarely), ROM in "hundreds of kilobytes", RAM in "tens of kilobytes"
 (sometimes less, rarely over 100kB - only for really big chips).

That makes sense. Our "smart" systems are, at a minimum, an ARM9 core (like an Atmel AT91), and we're drooling over the latest TI offerings (Cortex-A9 type stuff, like what's on the BeagleBone). -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Jan 08 2013
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
There are hundreds of ARM processors from several vendors from 
megahertz to gigahertz and from kilobytes to gigabytes. When we 
talk about ARMs it should be good to mention what kind of ARM we 
are using.

My interest is stm32f4 but everything I have done should be 
useful in the whole cortex-m series.

A minimum library has been working for a while and I think that D 
really is my choice. There have been a little silence when I have 
investigated linker problems and I am not able to use all my time 
for this anyway. When we now have so many interested people, I 
think I should go on.

My library is done with minimum set of files with minimum changes 
to them. There are about 20 changes required to get it compiled. 
This version can be run with 64 kb rom and 16 kb ram. It would be 
possible to get the library smaller by commenting out all 
unnecessary functions from all files. At this moment I want to 
keep the library as close to the original as possible.

This library does not yet have threads, but I have planned a 
minimun thread library which is somewhere between fiber and 
thread. Garbage collector is the gcstub version, which just calls 
directly malloc and free. The library does not require libc but 
there should be a proper libgcc. (a libgcc for cortex-m3 and -m4 
is not built by default when compiling gcc) The only functions 
needed outside are malloc, free, calloc and realloc and 
__aeabi_read_tp which returns the tls pointer.

Next I think I will make a list of required changes and then I 
will make a simple makefile to compile the library. If anybody is 
interested, please send an email to me and I will send those 
files back to you.
Jan 08 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 8 January 2013 at 20:13:54 UTC, Timo Sintonen wrote:
 Next I think I will make a list of required changes and then I 
 will make a simple makefile to compile the library. If anybody 
 is interested, please send an email to me and I will send those 
 files back to you.

You should definetely post that to github or somewhere (dropbox, ...)! I'd be really interested to see the files (and maybe some details about strange things you need to do to get whole toolchain compiled), but I cannot see your e-mail with webinterface of this list... BTW - on GitHub you could just fork phobos and do your changes as normal commits and that would be clearly visible to anyone (; 4\/3!!
Jan 08 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 8 January 2013 at 16:52:05 UTC, Freddie Chopin wrote:
 Well, RTOSes ("schedulers") like FreeRTOS don't do that much - 
 you have threads, mutexes/semaphores, message queue and 
 software timers - all of them but the last one is covered by D 
 APIs, but now I thought that D probably just uses some OS 
 services for that (like POSIX pthread.h), wrapping it up a 
 little...

That seems true - internally D just wraps POSIX (pthread.h especially) or whichever threading mechanism exists on the OS. Fortunately I have a rally nice and universal solution going around my head, which would make most of D runtime available for small embedded targets like Cortex-M3 (; If I could just stretch the day a bit, to - say - 96h... 4\/3!!
Jan 08 2013
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Tuesday, 8 January 2013 at 20:42:07 UTC, Freddie Chopin wrote:

 You should definetely post that to github or somewhere 
 (dropbox, ...)! I'd be really interested to see the files (and 
 maybe some details about strange things you need to do to get 
 whole toolchain compiled), but I cannot see your e-mail with 
 webinterface of this list...

The address is in the text in several places in this thread, but here it is: t.sintonen (at) luukku.com
 BTW - on GitHub you could just fork phobos and do your changes 
 as normal commits and that would be clearly visible to anyone (;

Of course this is the way to go. This just came so quickly. I should first write a makefile that works outside of my application and a list of changes. Because I have been messing around the files, I will also take a clean version of the original sources and write the changes again. Meanwhile I am asking you, have you read the instructions on http://gdcproject.org/wiki/Cross%20Compiler and have you been able to make the toolchain?
Jan 08 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Wednesday, 9 January 2013 at 07:15:33 UTC, Timo Sintonen wrote:
 Meanwhile I am asking you, have you read the instructions on 
 http://gdcproject.org/wiki/Cross%20Compiler and have you been 
 able to make the toolchain?

I've read this article, but actually I was hoping I could "drop" GDC into a linaro distribution of ARM bare-metal toolchain - https://launchpad.net/gcc-arm-embedded - it's a 4.7.x version, I don't know how big problem that is... So I haven't yet tried compiling the toolchain, but I guess that without your files it would not work anyway, right? (; 4\/3!!
Jan 09 2013
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Wednesday, 9 January 2013 at 08:31:01 UTC, Freddie Chopin 
wrote:

 but actually I was hoping I could "drop" GDC into a linaro  
 distribution of ARM bare-metal toolchain - 
 launchpad.net/gcc-arm-embedded - it's a 4.7.x version, I don't 
 know how big problem that is... So I haven't yet tried 
 compiling the toolchain, but I guess that without your files it 
 would not work anyway, right? (;

without library. It is possible to compile programs with gdc without the library as long as only c style functions are used. A working linker script is needed to make the executable and a proper startup file is needed to make the executable work in the target platform. A suitable bootloader is needed to transfer the executable to the target processor. When all these are working, the runtime library is needed. The toolchain in https://launchpad.net/gcc-arm-embedded seems to be a good starting point for arm cortex processors. It has all the tools and also suitable linker scripts and startup files. But it is not aware of D. As mentioned earlier in this thread, nobody has made this yet. So there is not an easy way to go. As long as gdc is not part of the gcc package, some extra work is always needed. If the toolchain works, it is worth of try to replace gcc in there with the newest gcc with d patches. Some modifications are needed in the build script to enable d and disable libphobos.
Jan 09 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
After browsing the forums a bit I've stumbled across a discussion 
about C-style "volatile" and lack of something like that in D (I 
did not get too deep in the details yet), so I'd like to ask if 
there is something that can be used for the purpose of forcing 
memory accesses to happen ALWAYS, disregarding what sense such 
operations make to the compiler/optimizer?

In MCUs it's for example common for one peripheral register 
(memory address) to perform two distinct functions, depending on 
whether you read or write:

SPI->DR = data_to_send[0];
SPI->DR = data_to_send[1];
SPI->DR = data_to_send[2];
data_received[0] = SPI->DR;
data_received[1] = SPI->DR;
data_received[2] = SPI->DR;

This cannot be mixed, this cannot be skipped, this cannot be 
concatenated, as each read/write has to take place exactly in the 
order specified.

In C this is handled by making the memory address pointed 
"volatile":

typedef struct SPI_s
{
volatile uint32_t DR;
volatile uint32_t REG1;
volatile uint32_t REG2;
} SPI_t;

#define SPI ((SPI_t*)0x12345678)

How would you handle things like that in D? Is that possible? 
That's a crucial thing for system-programming (;

4\/3!!
Jan 15 2013
prev sibling next sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
By request I have put my minimum library work visible at 
bitbucket.org/timosi/minlibd. It contains now the library. I hope 
it will contain other things for program development too, like 
makefiles and linker scripts and of course, documentation.
Jan 22 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 22 January 2013 at 16:25:02 UTC, Timo Sintonen wrote:
 By request I have put my minimum library work visible at 
 bitbucket.org/timosi/minlibd. It contains now the library. I 
 hope it will contain other things for program development too, 
 like makefiles and linker scripts and of course, documentation.

Great! (; Any chance for adding any example that could be used to verify that everything works correctly? It does not matter for which microcontroller it would be, just anything for a start (; One more request - maybe you could share a compiled toolchain with the lib in a binary form (Windows)? Compiling that is probably not the easiest thing to do (; Thx again! 4\/3!!
Jan 22 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--20cf307f34128b2fd204d3e3bfe2
Content-Type: text/plain; charset=ISO-8859-1

On 22 January 2013 17:02, Freddie Chopin <freddie_chopin op.pl> wrote:

 On Tuesday, 22 January 2013 at 16:25:02 UTC, Timo Sintonen wrote:

 By request I have put my minimum library work visible at
 bitbucket.org/timosi/minlibd. It contains now the library. I hope it
 will contain other things for program development too, like makefiles and
 linker scripts and of course, documentation.

Great! (;

Why are you upside-down. :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --20cf307f34128b2fd204d3e3bfe2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= On 22 January 2013 17:02, Freddie Chopin <span dir=3D"ltr">&lt;<a href=3D"m= ailto:freddie_chopin op.pl" target=3D"_blank">freddie_chopin op.pl</a>&gt;<= /span> 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 16:25:02 UTC, Timo Sintonen wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> By request I have put my minimum library work visible at <a href=3D"http://= bitbucket.org/timosi/minlibd" target=3D"_blank">bitbucket.org/timosi/minlib= d</a>. It contains now the library.=A0I hope it will contain other things f= or program development too, like makefiles and linker scripts and of course= , documentation.<br> </blockquote> <br></div> Great! (;</blockquote></div><br></div><div class=3D"gmail_extra">Why are yo= u upside-down. :)<br></div><div class=3D"gmail_extra"><br clear=3D"all"><br=
-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;=

</div></div> --20cf307f34128b2fd204d3e3bfe2--
Jan 22 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Tuesday, 22 January 2013 at 17:17:20 UTC, Iain Buclaw wrote:
 Great! (;

Why are you upside-down. :)

Against mainstream! <; 4\/3!!
Jan 22 2013
prev sibling parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Tuesday, 22 January 2013 at 17:02:58 UTC, Freddie Chopin wrote:

 Any chance for adding any example that could be used to verify 
 that everything works correctly? It does not matter for which 
 microcontroller it would be, just anything for a start (;

I will add something when I have time. I have a simple malloc and a main program that sends one byte to uart.
 One more request - maybe you could share a compiled toolchain 
 with the lib in a binary form (Windows)? Compiling that is 
 probably not the easiest thing to do (;

first linux... The best place to ask for a toolchain might be those who have made the native Windows toolchain. It should not be a big job to change it to a different target. If I had time, I might also look at it. But this brings out an interesting question: If I have the same cross toolchain in Linux and Windows, and I compile same files with same settings, are the object files equal? If I compile some files in Windows and some in Linux, can I link them together and have a working executable? I think this should work in theory but does anybody have any real experience of cross compiling programs in both win and linux?
Jan 22 2013