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 reply "Timo Sintonen" <t.sintonen luukku.com> writes:
 What OS are you working on?


Linux
Oct 18 2012
parent reply 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
parent reply "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
parent reply 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
next sibling parent reply "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
parent reply 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
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 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 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 reply "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.


Object is a parent for all classes so nothing can be compiled 
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
next sibling parent reply 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.


 Object is a parent for all classes so nothing can be compiled 
 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
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 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.


 Object is a parent for all classes so nothing can be compiled
 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 parent reply "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
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 parent reply "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
parent reply "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
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 parent reply "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
parent reply 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
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 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 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
parent reply "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


 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.


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


 a

 RTOS on an embedded system? This would be quite interesting


 too (;

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


You can and in this case you should make the toolchain first 
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 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 "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 parent reply "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
parent reply "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
parent reply "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
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Jan 22 2013
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 (;


I have tried to avoid Windows since 1996 when I installed my 
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