On Wednesday, 7 January 2015 at 14:10:49 UTC, Dmitry Olshansky
wrote:
Truth be told none of listed in this thread feel fundamental to
me. It looks more like a set of patches to each specific
problem in the compiler or run-time. Yeah, run-time would
better be more customizable, but it's just our *current*
run-time it's not the language.
Perhaps "high-impact" would be a better word than "fundamental".
I think moving runtime hooks out of the compiler to .di files and
Adam Ruppe's proposal to move TypeInfo to the runtime are great
ideas.
Enhancement 11666 [1] is another. That really highlighted a
design problem in the runtime for me. If the runtime had better
separation of language, platform (OS and architecture) and
library, the ports would simply have their own folder in the
runtime rather than their own repository. The controversy that
followed the pull requests in an attempt address 11666 clearly
shows the problems that high coupling to the platform can cause.
If the platform were encapsulated and decoupled from the language
implementation, we'd already be well on our way.
[1] - https://issues.dlang.org/show_bug.cgi?id=11666
But I've been watching how such changes are perceived here, and
I'm skeptical they would be accepted because so much in the
language is potentially affected by them. Due to the fact that
they only benefit a few bare-metal folks, but impact the full
language, I'm quite confident they would be shunned, and that's
been very discouraging.
Thus I do not believe that immediate upstreaming of everything
bare-metal is even a good thing in principle. In my opinion a
Bare-Metal D project can live its life along the upstream D by
providing bare-metal versions of each successive version. In
fact, we do not have all that many embedded guys in core team.
All generally useful patches should find their way in upstream,
of course, but it takes time and should *not* be a prerequisite.
Sure the bare-metal stuff can exist along-side the upstream
repository. That's actually what I alluded to in my previous
posts, that bare-metal programming in D will likely need to fork.
In fact, due to the lack of support, I don't see it happening
any other way.
A toolkit will need to provide e.g build/fetch with a bootstrap
script:
- a ready to-go D cross-compiler(s) might be with some patches
to disable language features for better experience etc.
That's more-or-less what I've suggested in this thread. If that
happened, I could get behind the items you listed below. But I
don't know how to proceed with the compiler, that's not my
interest nor within my current ability. Johannes has been
exploring this territory, however, which is encouraging.
- a stripped run-time instead of Phobos (come on C/C++ folks
use something much unlike standard library either)
- linker scripts for a (growing) set of MCUs
- I/O library and register definitions for MCUs (preferably a
tool to auto-generate such)
- a modified driver that passes all kinds of right options for
a given MCU
That's a minimum for other Bare Metal D projects to even start
to take off. Ideally other tools include debugger, high-level
libraries for peripherals (HAL), ports or bindings to C FAT,
IP, ... libraries and so on.
Let me add that I think the -betterC switch, or similar, is too
blunt an instrument. I'd like to have the flexibility to fine
tune the language features (even on individual types) for the
platform and/or application I'm building. And while compiler
switches and attributes may help, I think delegating features
from the compiler to the runtime is a better investment.
Mike
