On 21 October 2015 at 10:26, Jonathan M Davis via Digitalmars-d < [email protected]> wrote:
> On Wednesday, 21 October 2015 at 08:06:34 UTC, Johannes Pfau wrote: > >> It might make sense to reconsider upstreaming our inline ASM code. I >> think the main reason we didn't do that yet was that the druntime >> developers think of druntime as a compiler specific library anyway. And >> then there's no use in having GDC specific ASM in a DMD specific druntime. >> > > Even if gdc-specific stuff doesn't go into druntime, I would think that it > would make sense to update druntime where appropriate to segregate the > stuff that's compiler-specific so that it's easy for the gdc and ldc teams > to replace the parts that they need to replace. That being said, I would > think that using version blocks to separate compiler-specific stuff would > have been appropriate and that ideally the gdc and ldc teams wouldn't have > their own versions of druntime or Phobos, but even then, modularizing that > stuff is likely to be more maintainable than having it scattered throughout > the code. > > - Jonathan M Davis > In a way, druntime has three parts to it. core.stdc: Exposes enough platform bindings to interact with system C library. core, gc: D runtime library. Everything should be compiler agnostic within reason. rt: Per-compiler runtime internals. EH, Vector operations, Runtime calls, etc... The first two are the concern of upstream to maintain.
