Should LLVM become the default D-lang platform?
This might have been brought up before but I couldn't find any thread about this. As things has progressed I wonder if Digital Mars DMD should move over to use LLVM instead of its own code generation and compiler framework. As I see it with the small amount of contributors D-language has, DMD will never support anything beyond x86 as there are no resources for this. Also, why spend time on recreating the the code generation which has already been done with LLVM? This enables this community to focus on the language which is the most important part as well as supporting more and future processor targets.
Re: Should LLVM become the default D-lang platform?
On Friday, 10 January 2014 at 20:59:35 UTC, Iain Buclaw wrote: On 10 January 2014 20:54, John Colvin john.loughran.col...@gmail.com wrote: On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote: This might have been brought up before but I couldn't find any thread about this. As things has progressed I wonder if Digital Mars DMD should move over to use LLVM instead of its own code generation and compiler framework. As I see it with the small amount of contributors D-language has, DMD will never support anything beyond x86 as there are no resources for this. Also, why spend time on recreating the the code generation which has already been done with LLVM? This enables this community to focus on the language which is the most important part as well as supporting more and future processor targets. This comes up regularly. It's already been done. Ldc *is* dmd with llvm backend. Gdc is the same idea but with the gcc framework. Indeed. But naturally I'd suggest they move to GCC. ;-) I see LLVM as a better choice because the license is less intrusive.
Re: Should LLVM become the default D-lang platform?
On Friday, 10 January 2014 at 20:54:06 UTC, John Colvin wrote: On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote: This might have been brought up before but I couldn't find any thread about this. As things has progressed I wonder if Digital Mars DMD should move over to use LLVM instead of its own code generation and compiler framework. As I see it with the small amount of contributors D-language has, DMD will never support anything beyond x86 as there are no resources for this. Also, why spend time on recreating the the code generation which has already been done with LLVM? This enables this community to focus on the language which is the most important part as well as supporting more and future processor targets. This comes up regularly. It's already been done. Ldc *is* dmd with llvm backend. Gdc is the same idea but with the gcc framework. Picking LLVM as the default development platform also means that it will tested in this environment instead of porting it all the time which introduce new bugs. The support is also different among the different backends, picking one would harmonize this and make it more complete.
Re: Hitchikers Guide to Porting Phobos / D Runtime to other architectures
My question is what do all these TypeInfo and ModuleInfo have to do with operating systems? Assuming that TypeInfo and ModuleInfo has really nothing to do with the OS, I see no problem with it. Sure it is nice to be able to remove it for certain embedded system where size is critical but for many embedded systems this is not necessary. Why remove key parts of the language when it is the OS dependency that is the problem? My view is that there is no clear distinction what is independent of the operating system and what is operating system dependent in the runtime. What is part of the langauge and what is not?
Re: Microsoft working on new systems language
On Wednesday, 8 January 2014 at 22:55:24 UTC, bioinfornatics wrote: On Saturday, 28 December 2013 at 11:13:55 UTC, Barry L. wrote: Hello everyone, first post... Just saw this: http://joeduffyblog.com/2013/12/27/csharp-for-systems-programming/ D (and Rust) get a mention with this quote: There are other candidates early in their lives, too, most notably Rust and D. But hey, my team works at Microsoft, where there is ample C# talent and community just an arm’s length away. They are any conclusion about this ? they are 10 page and most part talk about D gc… Thank you. Microsoft might put together a great language for system programming but if it is going to be used outside the Microsoft world, then LLVM will be essential. GCC has previously been used by processor vendors in order to support languages like C/C++. LLVM is now gradually taking over that part and I expect LLVM to become the compiler framework of choice. The same is really valid for the D language, without LLVM the D language will not live on. I don't really know the plan from Microsoft here but I doubt that they will release the source and support LLVM so I guess the wide acceptance of this new language will be limited to Microsoft development only. Then we might have people who will make an LLVM implementation of M# by themselves, we'll see
Re: Hitchikers Guide to Porting Phobos / D Runtime to other architectures
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.
Re: Hitchikers Guide to Porting Phobos / D Runtime to other architectures
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.
Re: Hitchikers Guide to Porting Phobos / D Runtime to other architectures
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.
