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

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

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.

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

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

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

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?

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

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.

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