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