digitalmars.D.bugs - [Issue 14100] New: Remove barriers to D being a systems programming
- via Digitalmars-d-bugs (46/46) Feb 01 2015 https://issues.dlang.org/show_bug.cgi?id=14100
https://issues.dlang.org/show_bug.cgi?id=14100 Issue ID: 14100 Summary: Remove barriers to D being a systems programming language Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nobody puremagic.com Reporter: bugzilla digitalmars.com From: https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md •DMD emits references to C-language compiler instrinsics (__umoddi3, __udivdi3, etc.). Any new druntime will have to provide these. It would be best if D had its own D-language compiler intrinsics instead, which could also take advantage of D features like pure. •The druntime itself has many hard dependencies on libc/Win32. It should be split into a compiler-facing "libd" part that provide the extern (D) linkage funtions, and one or more libc-facing parts that build upon "libd". "libd" itself only needs to call realloc() (to achieve the functions of malloc, realloc, and free) which could be provided by a kernel or libc. •druntime and phobos are in the end just thin wrappers around libc/Win32. A native-D-system cannot create something like a new file abstraction API, because in the end it must always wrap a FILE *, file descriptor, or HANDLE. Same for sockets. To get a new abstraction, druntime needs to be able to make syscalls. •DMD has lost its ability to create fully-statically-linked executables. There appears to be no momentum on getting this back. Kernels obviously are not shared libraries. •DMD behaves differently based on what operating system it is running on, i.e. it is not a cross-(OS/ABI)compiler. The D language spec itself is OS and arch-independent, with fixed sizes for all primitive types, so it should actually be easier to make D a cross-compiler than C. This is a problem when one wants a slightly different ABI than the host C-based OS has. DMD's current backend license restrictions forces one to move to a different compiler. •D has worked very hard to be a good citizen in the C/C++ space. This is a great strength when one wants to incorporate C code into D applications. However, it has painted D into a corner: despite having a very cool syntax that could stand on its own for bare-metal programming, all D compilers are hamstrung by the pre-defined C ABIs, the externally-imposed momentum regarding shared libraries, and the C/C++ mechanisms for language features like TLS and exception handling. --
Feb 01 2015