D for embedded system

[Johannes Pfau]

Am Thu, 18 Oct 2012 17:51:46 +0200
schrieb "Timo Sintonen" <t.sintonen at 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?)