[ABI] 128bit integers and other vendor types

[H. S. Teoh via Digitalmars-d]

On Tue, Jul 29, 2014 at 05:02:26AM +1000, Daniel Murphy via Digitalmars-d wrote:
> "H. S. Teoh via Digitalmars-d"  wrote in message
> news:mailman.124.1406572776.16021.digitalmars-d at puremagic.com...
> 
> >I see this as a good thing, actually. Not that I think it's good to
> >increase compile time and binary bloat, but that when this happens,
> >we will have very strong incentives to do something about it, that
> >will drive us to do whatever it takes for Phobos to *not* get in the
> >way of fast compile times and to *not* introduce tons of template
> >bloat. The end result will be a far better quality Phobos than we
> >might ever achieve otherwise, since external D codebases wouldn't be
> >as strong an incentive as the compiler itself would.
> 
> I do not see it that way.  Once phobos quality is acceptable, then we
> can think about using it in dmd.  As much as I want phobos to be as
> good as possible, this cannot in any way come at the expense of the
> compiler's quality.

It depends on how we do the transition. If we replace dmd with ddmd
first, then we'll run into problems with Phobos adoption, because we may
discover that using Phobos causes (d)dmd to be unacceptably slow /
bloated / etc., which means it becomes a disincentive to use Phobos in
ddmd.

But another way to approach it, is to do Phobos integration first, while
we still have the current C++ code. We may discover that ddmd becomes
unacceptably slow -- but since all of us want to make D self-hosted,
this is great incentive for improving Phobos so that ddmd is *not* slow.
While we work on fixing Phobos, we still have the current C++ dmd to
serve user needs. Then when Phobos is finally no longer slow/bloated in
ddmd, we can transition to ddmd and have a compiler on par or even
better than the C++ dmd.


> >Perhaps the solution is to get more people involved in this review?
> >Y'know, increase the bus factor and everything.
> 
> Do you mean dmd contributors should be reviewing phobos pulls instead
> of working on dmd?

Well, I don't think anyone is going to *force* you to do that, this
being a volunteer project and everything. :-) What about recruiting new
contributors who can help out?


> >Would it be too unrealistic to set things up so that ddmd bootstraps
> >itself with a *previous* release of Phobos, and then compile itself
> >again with the latest Phobos git HEAD? (And by this I mean that `make
> >-f posix.mak` will actually run through this bootstrap process, so
> >that if something breaks, it will be very obvious in the autotester
> >and we wouldn't pull whatever PR it is that caused the breakage.)
> >This would ensure that whatever we do, ddmd won't become uncompilable
> >with a previous release of itself, but will be effectively written in
> >a prior version of D (or ideally, in the common subset of D between
> >the two releases, or N releases if we decide to do that).
> 
> Yes, this one can be solved somewhat by improving test infrastructure.
> But it will tie the parts of phobos that dmd uses to dmd's release
> cycle.
> 
> eg if we add a new built-in attribute, it can't be used in phobos
> until the last compiler that doesn't support it is no longer supported
> for building dmd.  Same for every compiler patch.

Not necessarily. If the compiler doesn't use the parts of Phobos that
has the new attribute, then it's not a problem.

Another solution (albeit uglier) is to use version(...) in Phobos to
suppress certain new features if the current compiler is known not to
support it:

	static if (__VERSION__ <= 2099L)
	{
		// This is the old version compatible with 2.099 or
		// earlier.
		auto myPhobosFunc(R)(R range) /* don't use @newAttribute */
		{
			...
		}
	}
	else
	{
		// This is the new version that requires 2.100 or
		// higher.
		auto myPhobosFunc(R)(R range) @newAttribute
		{
			...
		}
	}

The first stage of bootstrapping will use myPhobosFunc without
@newAttribute, but when compiling the second stage (final) compiler, it
will use myPhobosFunc with @newAttribute, because the first stage
compiler now understands what it is.


> It would also be nice to keep compatibility further back than a single
> dmd release.  This would make things harder.

I think this should be possible using static if (__VERSION__ ...).


T

-- 
This sentence is false.