On Sunday, 5 January 2014 at 17:07:10 UTC, Joakim wrote:
> What new platform are you porting druntime to?  I'm guessing linux/ARM Cortex-M based on your previous posts.  Hopefully, I can reuse some of your work when I try ARM out.

I'm porting to an STM32F4 (http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577) MCU, simply because that's the only hardware I have, and I'm familiar with it, but I hope it will be portable to any ARM Cortex-M MCU with little or no modification.  I'm doing a bare-metal port (no OS) so Linux way out of scope for me.

My goal to make something like the Arduino.  So the end product would be end up with the following:
* The hardware (I/O board).  Think Arduino DUE (http://store.arduino.cc/index.php?main_page=product_info&cPath=11&products_id=243)
* A compiler specific to the hardware (LCD with ARM Thumb backend, or GDC cross-compiled for arm-none-eabi
* A port of the D runtime.  Definitely not a complete port. Just enough to work the I/O and make use D programming constructs (classes, structs, exceptions, thread local storage, etc...)
* A library, or set of libraries, to make programming the IO convenient.  See the Arduino reference to get a an idea (http://arduino.cc/en/Reference/HomePage)
* Possibly an IDE specific to microcontroller development.

I'd like to eventually create a very tiny real-time OS like FreeRTOS(http://www.freertos.org/) and the like, but that is a very long-term goal.

Other goals are:
* Assist the LDC and GDC folks with supporting this platform, as this adventure truly stands on their shoulders and we're not going to get anywhere without them.
* Show that the D language can replace C/C++ in the 32-bit MCU realm.

Timo Sintonen is also well on his way to an ARM Cortex-M port (https://bitbucket.org/timosi/minlibd), but he's taking quite a different approach than I.  I'm taking more of a bottom up approach and hope to discard the peripheral library, the C library, and anything else C/C++ and do everything in D.

I've created a simple "hello world" tutorial here (http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22) so people interested in this or similar endeavors can have a convenient place to start.

At the moment, I don't have any source code to publish, as everything I've built so far is simply for academic purposes (I have a lot to learn).  But, I'd be happy to share what I have and what I've learned, and I hope in the coming months I'll have a repository with something useful.

Mike

On Monday, 6 January 2014 at 01:32:09 UTC, Mike wrote:
> On Sunday, 5 January 2014 at 17:07:10 UTC, Joakim wrote:
>> What new platform are you porting druntime to?  I'm guessing linux/ARM Cortex-M based on your previous posts.  Hopefully, I can reuse some of your work when I try ARM out.
>
> I'm porting to an STM32F4 (http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577) MCU, simply because that's the only hardware I have, and I'm familiar with it, but I hope it will be portable to any ARM Cortex-M MCU with little or no modification.  I'm doing a bare-metal port (no OS) so Linux way out of scope for me.
>
> My goal to make something like the Arduino.  So the end product would be end up with the following:
> * The hardware (I/O board).  Think Arduino DUE (http://store.arduino.cc/index.php?main_page=product_info&cPath=11&products_id=243)
> * A compiler specific to the hardware (LCD with ARM Thumb backend, or GDC cross-compiled for arm-none-eabi
> * A port of the D runtime.  Definitely not a complete port. Just enough to work the I/O and make use D programming constructs (classes, structs, exceptions, thread local storage, etc...)
> * A library, or set of libraries, to make programming the IO convenient.  See the Arduino reference to get a an idea (http://arduino.cc/en/Reference/HomePage)
> * Possibly an IDE specific to microcontroller development.
>
> I'd like to eventually create a very tiny real-time OS like FreeRTOS(http://www.freertos.org/) and the like, but that is a very long-term goal.
>
> Other goals are:
> * Assist the LDC and GDC folks with supporting this platform, as this adventure truly stands on their shoulders and we're not going to get anywhere without them.
> * Show that the D language can replace C/C++ in the 32-bit MCU realm.
>
> Timo Sintonen is also well on his way to an ARM Cortex-M port (https://bitbucket.org/timosi/minlibd), but he's taking quite a different approach than I.  I'm taking more of a bottom up approach and hope to discard the peripheral library, the C library, and anything else C/C++ and do everything in D.
>
> I've created a simple "hello world" tutorial here (http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22) so people interested in this or similar endeavors can have a convenient place to start.
>
> At the moment, I don't have any source code to publish, as everything I've built so far is simply for academic purposes (I have a lot to learn).  But, I'd be happy to share what I have and what I've learned, and I hope in the coming months I'll have a repository with something useful.
>
> Mike

Great, nice to hear about a pure D approach to embedded. :) Keep us updated on your progress.  I suggest that you publish your work-in-progress patches to a public repo somewhere, as I've been doing with my Android/x86 port, so that those interested can follow your work.

I'm trying to do the same, trying to compile OS free code but I haven't so far been successful because D requires the runtime and then also Phobos. Compared to C/C++ where you can create pretty advanced stand alone code without even include any standard libraries, this because much of C++ is part of the compiler.

With D this is not the case. I don't really have a good picture what is part of the compiler or the runtime. Even creating a simple sample class and create a stack object requires that I include *everything*, that hairy runtime phobos nest. The runtime also has dependencies into Phobos which I find to be very inconvenient and I don't think it is a good idea. The runtime should be stand alone and Phobos should depended on the runtime and not vice versa.

Also, I am not too happy about the change "scope for allocating classes on the stack", http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack.

This change requires you to include std.typecons from Phobos, which means you have include a library for a simple operation like stack allocation. C++ does not require this as it is a part of the language.

Compared to C/C++, D is very hard to get to work in the embedded/OS less environment because of this.

On Monday, 6 January 2014 at 11:47:57 UTC, Dwhatever wrote:
> I'm trying to do the same, trying to compile OS free code but I haven't so far been successful because D requires the runtime and then also Phobos. Compared to C/C++ where you can create pretty advanced stand alone code without even include any standard libraries, this because much of C++ is part of the compiler.

I created a bare-metal freestanding (OS Free) hello world program and wrote a wiki about it here (http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22)

The problem is that there's not really much D in that D program, but it is a working foundation on which to build.  If you plan on writing D code for embedded systems, you probably don't want all of the runtime anyway (at least I don't).

Using GDC compiled for arm-none-eabi, I created a malloc/free implementation in D and am now able to create classes that are allocated on the heap with "new" and deallocated using "destroy".  I also created a reference counted implementation too that automatically deallocates when the reference count reaches 0.  But, I'm still struggling with the memory management as a whole.

Unfortunately once I started creating structs and classes I had to implement a bunch of "TypeInfo.." stuff in object.d even though it appears none of it gets used.  My object.d is now only about 140 lines.

This was only possible with a recent change to GDC (http://forum.dlang.org/post/mailman.3.1387377012.2938.d.gnu@puremagic.com) and the -fno-emit-moduleinfo switch.  I tried with LDC too, but LDC requires the world, so I gave up for now.

If any compiler implementers are reading this, please try to generate only code that is used by the program being compiled.  I need to get this sorted out and submit some bug/enhancement requests to the compiler writers, but I first need to understand things better so I can articulate it well.

> With D this is not the case. I don't really have a good picture what is part of the compiler or the runtime. Even creating a simple sample class and create a stack object requires that I include *everything*, that hairy runtime phobos nest. The runtime also has dependencies into Phobos which I find to be very inconvenient and I don't think it is a good idea. The runtime should be stand alone and Phobos should depended on the runtime and not vice versa.

I sympathize and agree.  I can't see the abstraction in the phobos/runtime hairball.  That's why I'm throwing the baby out with the bathwater and making a new baby.

I also wish the runtime wasn't so coupled to the garbage collector.  The garbage collector is just one of several ways to manage memory, and I don't think the runtime should be so dependent on it, but that's probably easier said than done.

> Compared to C/C++, D is very hard to get to work in the embedded/OS less environment because of this.

I agree, but it won't get any better until you and I step up and do something about it.

On Monday, 6 January 2014 at 12:22:37 UTC, Mike wrote:
> If any compiler implementers are reading this, please try to generate only code that is used by the program being compiled.  I need to get this sorted out and submit some bug/enhancement requests to the compiler writers, but I first need to understand things better so I can articulate it well.

The issue with ModuleInfo is that you can actually query the list of all loaded D modules at runtime (ModuleInfo.opApply(), mainly for things like running static constructors, unit tests, Object.factory, …). So, even if your module is not using static constructors or unit tests, you can't just not emit the ModuleInfo in general.

In theory, LDC allows you to selectively disable ModuleInfo generation for some modules (http://wiki.dlang.org/LDC-specific_language_changes), but it looks like the pragmas actually don't have any effect in current LDC2 builds (https://github.com/ldc-developers/ldc/issues/571).

David

On Monday, 9 April 2012 at 10:19:47 UTC, Iain Buclaw wrote:
>
> Personally I feel that people porting to specific architectures should maintain their differences in separate files under a /ports directory structure - lets say core.stdc.stdio as a cod example. The version for bionic would be under /ports/bionic/core/stdc/stdio.d, and that is the module that gets compiled into the library when building for bionic. When installing, the build process generates a header file of the bionic version of core.stdc.stdio and puts the file in the correct /include/core/stdc/stdio.di location.

This would really be fine.  I'd even say just put them in core.sys.bionic or whatever, except that this location is for platform-specific imports and so core.sys.bionic.stdio could contain nonstandard extensions, while anything exposed by core.stdc should not.  For all of these issues, bugzilla tickets and/or pull requests are much appreciated.  I know that the design I chose for my own ease of maintenance may not scale past the handful of platforms DMD targets.

On Monday, 6 January 2014 at 11:47:57 UTC, Dwhatever wrote:
> I'm trying to do the same, trying to compile OS free code but I haven't so far been successful because D requires the runtime and then also Phobos.

D doesn't require Phobos.  The compiler implicitly links against
libphobos.a, but that isn't the same thing.  All a D app actually
needs is Druntime.  And you can replace the GC in Druntime with
gcstub (backed by malloc) and stub out the thread API if these
aren't appropriate for your target.  This still means using a
custom Druntime, but making the changes should really be pretty
straightforward in most cases.  The most complicated aspect of
porting will be how you handle core.stdc, since Druntime still
relies on C library calls for various things.

On 6 Jan 2014 17:55, "Sean Kelly" <sean@invisibleduck.org> wrote:
>
> On Monday, 6 January 2014 at 11:47:57 UTC, Dwhatever wrote:
>>
>> I'm trying to do the same, trying to compile OS free code but I haven't
so far been successful because D requires the runtime and then also Phobos.
>
>
> D doesn't require Phobos.  The compiler implicitly links against libphobos.a, but that isn't the same thing.  All a D app actually needs is Druntime.  And you can replace the GC in Druntime with gcstub (backed by malloc) and stub out the thread API if these aren't appropriate for your target.

GDC provides a configure flag to compile in gcstub instead of the standard GC.

There's also a pthread inspired thread API (gcc.gthreads) that provides a common interface to the platform-specific implementation - not all gcc supported thread models have been ported in yet (only posix and win32) though on bare metal you may just want to compile with thread model=single.

On Monday, 6 January 2014 at 17:52:44 UTC, Sean Kelly wrote:
> On Monday, 6 January 2014 at 11:47:57 UTC, Dwhatever wrote:
>> I'm trying to do the same, trying to compile OS free code but I haven't so far been successful because D requires the runtime and then also Phobos.
>
> D doesn't require Phobos.  The compiler implicitly links against
> libphobos.a, but that isn't the same thing.  All a D app actually
> needs is Druntime.  And you can replace the GC in Druntime with
> gcstub (backed by malloc) and stub out the thread API if these
> aren't appropriate for your target.  This still means using a
> custom Druntime, but making the changes should really be pretty
> straightforward in most cases.  The most complicated aspect of
> porting will be how you handle core.stdc, since Druntime still
> relies on C library calls for various things.

I'm using LDC and unfortunately the -mtriple=arm-eabi isn't supported so I have to use -mtriple=arm-linux which automatically sets the "Posix" version string. I can always try to stub all the Posix calls in the library but what I think would work is that you have a stubbed version when there isn't any system name like Windows or Posix. For example.

version (Windows)
{
  ...
}
else version (Posix)
{
  ...
}
else
{
  //Stubbed interface
}

However, it isn't really obvious what is missing when stubbing all the interfaces. Perhaps some stubbed interfaces should have a reference to some function so that the programmer understands that this must be implemented. For example malloc and free would be obvious.

On Monday, 6 January 2014 at 17:04:57 UTC, Sean Kelly wrote:
> On Monday, 9 April 2012 at 10:19:47 UTC, Iain Buclaw wrote:
>>
>> Personally I feel that people porting to specific architectures should maintain their differences in separate files under a /ports directory structure - lets say core.stdc.stdio as a cod example. The version for bionic would be under /ports/bionic/core/stdc/stdio.d, and that is the module that gets compiled into the library when building for bionic. When installing, the build process generates a header file of the bionic version of core.stdc.stdio and puts the file in the correct /include/core/stdc/stdio.di location.
>
> This would really be fine.  I'd even say just put them in core.sys.bionic or whatever, except that this location is for platform-specific imports and so core.sys.bionic.stdio could contain nonstandard extensions, while anything exposed by core.stdc should not.  For all of these issues, bugzilla tickets and/or pull requests are much appreciated.  I know that the design I chose for my own ease of maintenance may not scale past the handful of platforms DMD targets.

I would submit tickets requests for these things, but in order to create a meaningful ticket that can be acted upon, one must know precisely what should be done, and articulate that in the ticket.  But in order to understand what must be done, one must understand the current organization of the runtime.  But in order to understand the current organization of the runtime, one needs to be able to see the abstraction. But the crux of this problem is that one can't see the abstraction because of the way the runtime is organized (catch 22).

The same goes for pull requests.

Those already familiar with the runtime could accelerate contribution from others by 1) documenting the current abstraction on the wiki or 2) following up on https://d.puremagic.com/issues/show_bug.cgi?id=11666 so one can see the abstraction.  Finally the original runtime authors and porters could both begin writing a porting guide.