09-Jan-2015 05:07, Mike пишет:
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.
These are good. I expect more customization points to come as bare-metal
stuff moves along.
high-impact - I'm not sure I follow? Nobody would notice much except
those messing with the compiler and custom run-times. The change itself
might be a couple dozen of lines worth.
I could understand horror that tweaking something in a compiler may
instill but D's compiler is rapidly evolving. I see nothing fundamental
in how it depends on run-time and vise-versa, everything is tweakable
and we break binary compatibility (and not only that) with every release.
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
This issue mostly affects embedded targets that run full-fledged OS.
Somehow I see it as a minor issue. No matter how we pile up
platform-specific headers - somebody got to put it somewhere. A couple
of conventions were discussed with various drawbacks. Many C projects do
this in ad-hoc fashion and survive just fine. There is no inherent
design problem or something unfixable - we just need more ports.
Also I'm thinking that bare-metal stuff would simply have its own
run-time complying with some _spec_ of what compiler expects. Working
out that spec and importantly language feature sets would be awesome.
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.
We can just ask for them again and see. It's important to voice concerns
because there is so much of stuff going on that some important issues
may easily slip under radar.
What usually works best in prioritizing stuff is highlighting that some
actual project is having a problem with issue X, Y and Z.
Due to the fact that they only benefit a
few bare-metal folks, but impact the full language
Again I'm not sure how? In fact nobody would notice a damn thing. Layout
of internals of D run-time are just that.
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.
Great. This helps me understand what is the main impediment at the
moment. With that in mind I think we can formulate our GSOC plan better.
As far as I can tell it can focus on 2 paths:
a) Get embedded-savy student to work on MCU support and stuff while
delegating most compiler tweaks to mentor(s) and core team.
b) Get a student interested in compilers to deliver on getting robust
cross-compiler with minimal run-time. Getting actual boards to work is
then delegated to mentors.
I am in favor of a).
- 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
