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?

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';

> What OS are you working on?

Linux

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';

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

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?)

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

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';

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

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