D for embedded system

[Timo Sintonen]

>
> 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.