Am Thu, 07 May 2015 16:29:50 +0000
schrieb "Jens Bauer" <doctor@who.no>:

> 
> {snip}
> > Every port is in its own branch
> 
> In this case, the files must share the same parent directory, in order to be updated by a merge with master; correct ?

IIRC it's not always necessary. Git can detect if you moved files or you can tell git by using git mv. It'll then merge changes into the moved files as well*. But I wouldn't really want to rely on this 'feature'.


* (in GDC it always tries to merge gcc-4.10.diff
changes into gcc-4.9.diff which never works...)

On Thursday, 7 May 2015 at 09:55:11 UTC, Kagamin wrote:
> On Tuesday, 5 May 2015 at 02:26:28 UTC, Mike wrote:
>> Porting to a New Platform
>> ******************************
>> The platform-agnostic code in "d" delgates implementation details to the platform-specific code using `extern(C) extern _d_sys_name` "system calls" (for lack of a better term).
>
> You plan to have a sizable API without type safety? Why PAL is not good?

The "ports" folder in this experiment is essentially the platform abstraction layer.  However, it's resolved at link-time.  What do you suggest:  A reserved module/package implementing a standard interface that is imported at compile-time?  I could do that.

Mike

On Friday, 8 May 2015 at 02:25:48 UTC, Mike wrote:
> What do you suggest:  A reserved module/package implementing a standard interface that is imported at compile-time?  I could do that.

You just import the right PAL (maybe renamed private import) and everything is typechecked.

On Friday, 8 May 2015 at 02:25:48 UTC, Mike wrote:
>
> The "ports" folder in this experiment is essentially the platform abstraction layer.  However, it's resolved at link-time.  What do you suggest:  A reserved module/package implementing a standard interface that is imported at compile-time?  I could do that.

I'd like to help out (where I can).

As far as I remember, you have a STM32F4xx, correct ?

If we all have the same model STM32F4xx and we all have one or more different MCUs, we could probably do some initial drafts.
-Because I'm sure there are obstacles we do not think about in advance.
Testing some drafts on several MCUs in the beginning, will help us avoid a lot of trouble later on.

I have STM32F407, STM32F427, STM32F429 (I use these regularly).
On the shelf, I have LPC812, LPC1114, LPC1342 (seems to be dead though), LPC1549 (I don't have any libraries for this one yet), LPC1751, LPC1768, LPC1788 and LPC4337.
Though I have a few from Freescale, I am not able to flash-program them, as I have no driver for them in OpenOCD.

On Thursday, 7 May 2015 at 14:48:08 UTC, Jens Bauer wrote:
>
> I already have supplied those options in my toolchain.
> But does anyone know if this is advisable when using FreeRTOS (or any other RTOS for that matter) ?
> -I'm asking, because I'm not using any RTOS myself, but there are loads of people who do.

In order to make the full stack in D, I think we eventually will need to make 2 toolchains: a bare-metal kernel toolchain, and an application programming toolchain.

The bare-metal kernel toolchain would not have some of the high-level features of D, like threading and synchronization, as that has yet to be built.  However, once a D RTOS is created with all necessary features for theading and synchronization, then the application programming toolchain can be made with a druntime ported the D RTOS's API.

I've also considered another interesting approach.  It seems possible to port all features of D right to the metal, essentially embedding the RTOS directly into the runtime.  Then D is your RTOS :-)

Mike

On Sunday, 10 May 2015 at 01:55:53 UTC, Mike wrote:
> On Thursday, 7 May 2015 at 14:48:08 UTC, Jens Bauer wrote:
>>
>> I already have supplied those options in my toolchain.
>> But does anyone know if this is advisable when using FreeRTOS (or any other RTOS for that matter) ?
>> -I'm asking, because I'm not using any RTOS myself, but there are loads of people who do.
>
> In order to make the full stack in D, I think we eventually will need to make 2 toolchains: a bare-metal kernel toolchain, and an application programming toolchain.

That does not sound too appealing, because as far as I know, you have your bare-metal arm-none-eabi toolchain with C and C++, which can build RTOS. Then you'll need another arm-rtos-eabi, which can build RTOS, but cannot build bare-metal. I think people will not like this, because they don't want to switch toolchains when they work on different projects.
The arm-linux-eabi toolchain will be a third toolchain, because RTOS is not Linux, though Linux may be some kind of RTOS. ;)

> The bare-metal kernel toolchain would not have some of the high-level features of D, like threading and synchronization, as that has yet to be built.  However, once a D RTOS is created with all necessary features for theading and synchronization, then the application programming toolchain can be made with a druntime ported the D RTOS's API.

Another (annoying) input: If I decide to write a context-switcher in assembly language, I suddenly have threads, which I'd of course like to be able to use with my bare-metal toolchain.

> I've also considered another interesting approach.  It seems possible to port all features of D right to the metal, essentially embedding the RTOS directly into the runtime.  Then D is your RTOS :-)

I do like this approach better, and that resembles the way I've been thinking until now.
Yes, it might require more work, but strongly I think it's worth it.
I believe this would also give the user the most convenient D-compiler (and toolchain).

I somehow missed this topic earlier but I played a bit with
embedded runtime last month so I'll share some thoughts.

On Sunday, 10 May 2015 at 06:55:07 UTC, Jens Bauer wrote:
> On Sunday, 10 May 2015 at 01:55:53 UTC, Mike wrote:
>> I've also considered another interesting approach.  It seems possible to port all features of D right to the metal, essentially embedding the RTOS directly into the runtime.  Then D is your RTOS :-)
>
> I do like this approach better, and that resembles the way I've been thinking until now.
> Yes, it might require more work, but strongly I think it's worth it.
> I believe this would also give the user the most convenient D-compiler (and toolchain).

I'm also strongly in favor of integrating an RTOS with the
runtime, especially if we publish it under a liberal license,
just as the D runtime is distributed now.
Since most of existing RTOSes are distributed under either
proprietary license or  GPL, having a ready-to-use RTOS without
legal restrictions could work towards the adoption of D in the
embedded market. I would start with evaluating the existing
concurrency APIs in terms of their applicability in such RTOS.

Generally, if we stick to the pay-as-you-go approach most
features of D runtime (even exceptions and RTTI) can be ported.
They will not imply any costs when not used, but will be ready to
use out-of-the-box when they're needed. We could advertise it
using e.g. automatically generated charts showing the cost of
each feature. Also, there are already compiler switches to show
GC allocations and TLS variables, so a similar approach could be
used for other potentially costly features.

As for TLS, I think we should not change D semantics by
implicitly making all globals __gshared, but instead follow Dan's
suggestion to create a specific TLS model which statically
resolves thread-local variables to regular globals in
single-threaded builds.

I did some experiments with porting small parts of Phobos and
druntime.
Initial tests show that e.g. semihosted writefln costs about 4KB
of flash initially + about 0.5KB per each new argument type list
(GDC, -Os, Cortex-M3). Sure, it may seem a lot if your uC has
16KB or less, but in such case you probably wouldn't use
formatted output much in C either. You don't pay for it when you
don't call it, and when you need it - it's there and it's fully
functional and type safe (unlike C's printf). And of course
there're probably ways to optimize it.

Also I think exceptions could be possible to implement without
large costs. I've already got scope(exit) and scope(success)
working, and IMHO this is already a huge advantage over manual
cleanup. I started working on unwinding using the libgcc support
but other duties stopped me from finishing it. I'll try to push
this work on github later this week.

I've run the above on LM3S6965 (qemu) and STM32F103
(Nucleo-F103RB).

On Wednesday, 10 June 2015 at 10:06:19 UTC, Adrian Matoga wrote:

> Generally, if we stick to the pay-as-you-go approach most
> features of D runtime (even exceptions and RTTI) can be ported.
> They will not imply any costs when not used, but will be ready to
> use out-of-the-box when they're needed.

I haven't had a pay-as-you-go experience with RTTI.  In fact TypeInfo has become my mortal enemy [1].  I submitted a bug report for now [2].

[1] TypeInfo not garbage collected (discussion) - http://forum.dlang.org/post/quemhwpgijwmqtpxukiv@forum.dlang.org
[2] TypeInfo not garbage collected (bug report) - http://bugzilla.gdcproject.org/show_bug.cgi?id=184

There is an implementation of an -fno-rtti switch [3], but unfortunately, I have found it compromises on a few things (slicing, postblit, and maybe others).  I think
the best way forward is to move TypeInfo to the runtime as described in [4].  I'm currently working on an initial pull request for it, but I have to admit that I don't know much about what I'm doing in the compiler and am struggling with it.  But I'm afraid if I don't do it, it won't happen.  I can't even continue with my work without it.

[3] -fno-rtti implementation - https://github.com/D-Programming-GDC/GDC/pull/100
[4] Move TypeInfo to the D Runtime - https://issues.dlang.org/show_bug.cgi?id=12270

> I'll try to push this work on github later this week.

I look forward to seeing it.  It's encouraging to see more interest in using D for this Domain.

Mike

On Thursday, 11 June 2015 at 00:26:39 UTC, Mike wrote:
> On Wednesday, 10 June 2015 at 10:06:19 UTC, Adrian Matoga wrote:
>
>> Generally, if we stick to the pay-as-you-go approach most
>> features of D runtime (even exceptions and RTTI) can be ported.
>> They will not imply any costs when not used, but will be ready to
>> use out-of-the-box when they're needed.
>
> I haven't had a pay-as-you-go experience with RTTI.  In fact TypeInfo has become my mortal enemy [1].  I submitted a bug report for now [2].
>
> [1] TypeInfo not garbage collected (discussion) - http://forum.dlang.org/post/quemhwpgijwmqtpxukiv@forum.dlang.org
> [2] TypeInfo not garbage collected (bug report) - http://bugzilla.gdcproject.org/show_bug.cgi?id=184
>
> There is an implementation of an -fno-rtti switch [3], but unfortunately, I have found it compromises on a few things (slicing, postblit, and maybe others).  I think
> the best way forward is to move TypeInfo to the runtime as described in [4].  I'm currently working on an initial pull request for it, but I have to admit that I don't know much about what I'm doing in the compiler and am struggling with it.
>  But I'm afraid if I don't do it, it won't happen.  I can't even continue with my work without it.
>
> [3] -fno-rtti implementation - https://github.com/D-Programming-GDC/GDC/pull/100
> [4] Move TypeInfo to the D Runtime - https://issues.dlang.org/show_bug.cgi?id=12270

If there's anything I can help with, let me know. My experience with GDC is close to non-existent (I managed to make some one-line hacks to make it compile for AVR or to show the sizes of TypeInfos, but that was pretty easy), and I didn't even bother to build LDC, but I want to write stuff for STMs in D so I'm motivated to learn by doing.

>> I'll try to push this work on github later this week.
>
> I look forward to seeing it.  It's encouraging to see more interest in using D for this Domain.

Here it is: https://github.com/epi/dirt
It's just a playground where I try adding different features by trial and error, so it's very far from being as clean and organized as your projects.
I wouldn't even start without your and Adam Ruppe's work, so thank you for that.

Apart from first steps towards formatted print and exception support I mentioned earlier, there's a try on running static constructors (which is most likely broken anyway) in the correct order. The machinery used to make it work wastes some text and data memory to do it in run time, but since we're linking everything statically in the end, I wonder if the linker could be forced to put it all together instead.

On Sunday, 14 June 2015 at 19:44:48 UTC, Adrian Matoga wrote:
> On Thursday, 11 June 2015 at 00:26:39 UTC, Mike wrote:
>> On Wednesday, 10 June 2015 at 10:06:19 UTC, Adrian Matoga wrote:
>
> If there's anything I can help with, let me know. My experience with GDC is close to non-existent (I managed to make some one-line hacks to make it compile for AVR or to show the sizes of TypeInfos, but that was pretty easy), and I didn't even bother to build LDC, but I want to write stuff for STMs in D so I'm motivated to learn by doing.

Today I'll start using launchpad's GCC with GDC, because it has support for the Cortex-M7, plus that it's the official ARM toolchain, and it seems to be slightly ahead of the official GCC releases.

> Here it is: https://github.com/epi/dirt

I like small; I like simple - so I like it. :)

Feel free to grab the startup-files here:
https://github.com/jens-gpio/MCU

(see http://d.gpio.dk/ for more info and how to contact me if you need to).