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

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.

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?

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.

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

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

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

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

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

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