Bug 14100 – Remove barriers to D being a systems programming language

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2015-02-01T08:23:29Z
Last change time
2024-12-13T18:39:43Z
Keywords
bare-metal
Assigned to
No Owner
Creator
Walter Bright
Moved to GitHub: dmd#18940 →

Comments

Comment #0 by bugzilla — 2015-02-01T08:23:29Z
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.
Comment #1 by robert.schadek — 2024-12-13T18:39:43Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18940 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB