On Monday, 6 January 2014 at 17:52:44 UTC, Sean Kelly wrote:
> 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 case.

A wiki post desribing exactly this would be most helpful.

On Monday, 6 January 2014 at 20:23:23 UTC, Dwhatever wrote:
> 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 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
> }

For LDC with an ARM backend, you only need to compile with -march= and/or -mcpu= if you wish to compile for bare-metal.

The version strings are listed here (http://dlang.org/version.html).  So if I understand your objective, you would only need...

else version(ARM_Thumb) // or version(ARM) if targeting Cortex-A and the like
{
   ...
}

And it may actually need to look more like...
version(X86)
{
    version(Windows)
    { }
    else version(Linux)
    { }
    else
    { }
}
else version(ARM_Thumb)
{
    ...
}

of course the hard part is filling in the (...).

What CPU/MCU are you targeting?  Are you building for bare-metal?

On 1/6/14 4:22 AM, Mike 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. 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)
[snip]

Sounds like a good topic for a DConf talk. You may want to consider submitting one.

Andrei

I haven't really been following this thread, but I did a minimal D for x86 too

http://arsdnet.net/dcode/minimal.zip

you can compile it on linux or for bare metal. I got a fair chunk of the language working with my custom object.d, or you can back off and use less of the lang:

http://arsdnet.net/dcode/minimal.d


It might not work on the newest dmd, I did this some months ago. But it wasn't really too hard and much of it should be usable on arm too.

On Tuesday, 7 January 2014 at 03:02:51 UTC, Adam D. Ruppe wrote:
> I haven't really been following this thread, but I did a minimal D for x86 too
>
> http://arsdnet.net/dcode/minimal.zip
>
> you can compile it on linux or for bare metal. I got a fair chunk of the language working with my custom object.d, or you can back off and use less of the lang:
>
> http://arsdnet.net/dcode/minimal.d
>
>
> It might not work on the newest dmd, I did this some months ago. But it wasn't really too hard and much of it should be usable on arm too.

Those wikis exist (albeit somewhat outdated) but I think they're still on Dsource. Is the site still online?

On 2014-01-07 05:03, Sean Kelly wrote:

> Those wikis exist (albeit somewhat outdated) but I think they're still
> on Dsource. Is the site still online?

Yes, Dsource is still online.

-- 
/Jacob Carlborg

On Monday, 6 January 2014 at 16:25:08 UTC, David Nadlinger wrote:
> 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.

I think it's OK to emit code that is not used, as long as the linker can safely strip it out if it can't find a path to it.  I'm still a novice with the GNU toolchain, but I believe ld does this this with --gc-sections in collusion with GCC's -ffunction-sections and -fdata-sections.

A recent experiment with GDC showed that if unused symbols are stripped out by the linker, some of the used symbols get dislocated (at least that's what I think is happening).  Discussion here (http://forum.dlang.org/post/wrekpqefiswstqhhrhoh@forum.dlang.org).

My experiments with LDC last month seemed require a huge amount snowballing implementations just to compile, when they were all just going to get stripped out by the linker with --gc-sections anyway.

Again, I would like to submit enhancement/bug reports for these things, but I need to learn more about what's actually going on, and what's actually needed by D, so I my report is meaningful and actionable.

> 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

I actually wasn't aware of these features. These will be quite helpful when implemented.  Thank you.

On 2014-01-07 09:20, Mike wrote:

> I think it's OK to emit code that is not used, as long as the linker can
> safely strip it out if it can't find a path to it.

With the ModuleInfo and ClassInfo you can do some form of runtime reflection:

auto foo = Object.create("bar.Foo");

How would the compiler know that bar.Foo is actually used anywhere in the code?

-- 
/Jacob Carlborg

> For LDC with an ARM backend, you only need to compile with -march= and/or -mcpu= if you wish to compile for bare-metal.
>
> The version strings are listed here (http://dlang.org/version.html).  So if I understand your objective, you would only need...
>
> else version(ARM_Thumb) // or version(ARM) if targeting Cortex-A and the like
> {
>    ...
> }
>
> And it may actually need to look more like...
> version(X86)
> {
>     version(Windows)
>     { }
>     else version(Linux)
>     { }
>     else
>     { }
> }
> else version(ARM_Thumb)
> {
>     ...
> }
>
> of course the hard part is filling in the (...).
>
> What CPU/MCU are you targeting?  Are you building for bare-metal?

Yes, for bare metal, no OS, nothing.

I think I have to specify my target architecture and CPU otherwise the compiler cannot know that I'm cross compiling for ARM. -march= -mcpu= will not work for me.

I'm trying to compile a simple stand alone object file.

class TestClass
{
    ubyte member;

    this(ubyte m) { member = m; }
    ubyte Get() { return member; }
};


extern(C) void main()
{
    // stack class
   scope test = new TestClass(0);

   // simple inline asm test
   __asm("mov r0,#1;
          mov r1,#2", "~{r0,r1}");
}

This test should be simple enough I thought but it turned out that to compile and link this, D requires almost everything from the runtime.

So the challenge is, compile and link the simple code above targeting ARM using LDC, no OS allowed.

On Tuesday, 7 January 2014 at 21:52:54 UTC, Dwhatever wrote:
> So the challenge is, compile and link the simple code above targeting ARM using LDC, no OS allowed.

My minimal.zip is x86 but should be able to compile that and might not be hard to port to arm.
http://arsdnet.net/dcode/minimal.zip