www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [ABI] 128bit integers and other vendor types

reply "Iain Buclaw" <ibuclaw gdcproject.org> writes:
Hi,

Just formulating some ideas that may well go into a DIP.

=== A ===

I raised this back in early 2013 [1], and so I might as well be 
the necromancer and raise it again.

The cent and ucent keywords have been reserved since... well... 
certainly before the first D1 (as opposed to D0.xx) release [2].  
But that's all they have ever seemed to be.  Just reserved 
keywords that give odd errors when you try to use them.

It was only until 2.061 that any valid semantic meaning (and 
errors) were actually given to them. [3]

Now we have DDMD approaching fast round the corner, with it comes 
the prospect of leveraging the many library types in D for use in 
the compiler frontend; BigInt, CustomFloat, HalfFloat; and 
preferring the deterministic accuracy of them over native types 
that:
1) May produce different results on each host platform (true for 
floating-point).
2) Restricts readily-supported backends to a precision that only 
the host can do (true for all types).

BigInt is certainly on the cards for making native 128-bit 
support possible, but it still needs to be set apart from global 
and function symbols.  For that, it needs to finally be given a 
mangled identifier.

Now, since last writing, 'N' has been used up by wild(T) types, 
leaving only 'z' and 'Q' left.  Now, I feel that it is very 
wasteful at this point to give away these last remaining digits 
to cent/ucent, so it has *got* to be a two-digit mangle 
identifier.  For instance zi/zk for cent/ucent respectively.

Grammar is simple enough and doesn't cause conflicts in 
demangling.

TypeCent:
	zi

TypeUcent:
	zk

However the thought does strike me that this might be wasteful 
too, and we've now only got the single letter left before we'd be 
forced to start breaking ABI to refactor things round and make 
new room for potential future additions.  Afterall, we have no 
idea what may add in the future.

I'd also like to be quite favourable towards supporting native 
types for non-x86 processors, these themselves would need a 
reserved space to fall into, which leads me onto the second topic 
in this subject, vendor types support in D.

[1] 
http://forum.dlang.org/post/gnxgxasvacgblwqjnjeg forum.dlang.org
[2] http://forum.dlang.org/post/cftnob$1e11$1 digitaldaemon.com
[3] 
https://github.com/D-Programming-Language/dmd/commit/2e70bcac262e879769f3236a05ce9bc46483a429

=== B ===

Now, I realise that I may be misquoting Walter here, and on 
re-reading the discussion in which I will *QUOTE* from *OUT OF 
CONTEXT* [4], it certainly seems that when he refers to the word 
'native', he actually means 'x87'.  But if he wants to use that 
argument to defend native x87, I'll use the same argument to 
fight for native non-x87.

**BEGIN QUOTE TAKEN OUT OF CONTEXT**
D is a systems programming language, and ought to give access to 
the native data types supported by the CPU.
**END QUOTE TAKEN OUT OF CONTEXT** [5]

Alright, so my train of thought goes as follows:
- We have D support on ARM.
- ARM supports natively the half-float type, and what with D 
being a systems programming language, it ought to give access to 
this native data type.
- We can't use it in extern(D) code unless it is given an 
appropriate mangle code that doesn't cause conflicts with other 
types.

So here's where TypeVendor or TypeExtended comes in.

 From a grammar point of view, there are two choices:

TypeVendor:
	Q Alpha

So we could define halffloat as being 'Qh', this gives us the 
ability to add up to 52 additional types (which is ok).

or

TypeVendor:
	Q Number Name

So we could define halffloat as being 'Q1h' or 'Q2hf', this gives 
us the ability to add an arbituary number of types into the 
system (which is better).


So what support would be beneficial from allowing compilers to 
extend the native type-system?  Other use-cases that come into 
mind:

- float80: For those who *strictly* want to use an 80-bit type on 
x86 (on GDC for instance, real can vary in size).
- float128: For those who *strictly* want to use an 128-bit type 
on x86 (on GDC, you can use -mlong-double-128bit, at the risk of 
breaking ABI).
- PowerPC has 'vector bool' and 'vector pixel' types that don't 
quite fit into D's existing vector support.
- Haven't looked into ARM Neon/Poly vector types enough to see if 
they warrant any specific distinction from normal D vectors, I 
suspect no.
- 24-bit float, though maybe not...

[4] 
https://github.com/D-Programming-Language/druntime/pull/863#issuecomment-49096430
[5] There, I hope I have my back covered with all the BIG WARNING 
TEXT. ;)


That pretty much ends my Sunday rambling, destroy.

Regards
Iain
Jul 27 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Iain Buclaw:

 BigInt is certainly on the cards for making native 128-bit 
 support possible, but it still needs to be set apart from 
 global and function symbols.  For that, it needs to finally be 
 given a mangled identifier.
Is a mangled identifier also useful for partially library defined checked integrals (currently 4 types)? Bye, bearophile
Jul 27 2014
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 27 July 2014 14:35, bearophile via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Iain Buclaw:


 BigInt is certainly on the cards for making native 128-bit support
 possible, but it still needs to be set apart from global and function
 symbols.  For that, it needs to finally be given a mangled identifier.
Is a mangled identifier also useful for partially library defined checked integrals (currently 4 types)?
I think not, and my reason for saying that is the mess of mangling C++ namespace std has on ABI. Library types shouldn't be given special mangling treatment IMO. Regards Iain
Jul 27 2014
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
 Now we have DDMD approaching fast round the corner, with it 
 comes the prospect of leveraging the many library types in D 
 for use in the compiler frontend; BigInt, CustomFloat, 
 HalfFloat;
I would point out that every time I've seen compiler devs discuss using Phobos in dmd, there has been a large reluctance to do so (if not outright a desire to avoid it entirely) in order to avoid the circular dependencies that would ensue (Daniel Murphy in particular really doesn't seem to like the idea). It's much easier to control what's going on with dmd if it doesn't rely on Phobos. So, while it may very well be that ddmd eventually uses Phobos, I suspect that you have an uphill battle in trying to make it happen. It's more likely that ddmd would end up with some simplified copies of the necessary functionality from Phobos within its own source code in order to avoid any such dependencies. - Jonathan M Davis
Jul 27 2014
next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28 July 2014 07:08, Jonathan M Davis via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
 Now we have DDMD approaching fast round the corner, with it comes the
 prospect of leveraging the many library types in D for use in the compiler
 frontend; BigInt, CustomFloat, HalfFloat;
I would point out that every time I've seen compiler devs discuss using Phobos in dmd, there has been a large reluctance to do so (if not outright a desire to avoid it entirely) in order to avoid the circular dependencies that would ensue (Daniel Murphy in particular really doesn't seem to like the idea). It's much easier to control what's going on with dmd if it doesn't rely on Phobos. So, while it may very well be that ddmd eventually uses Phobos, I suspect that you have an uphill battle in trying to make it happen. It's more likely that ddmd would end up with some simplified copies of the necessary functionality from Phobos within its own source code in order to avoid any such dependencies.
I was fairly reluctant initially given Phobos' track-record. However someone did point out that if we don't use Phobos in DDMD, we might as well apply the brakes now to the project before its allowed to set sail. Iain.
Jul 27 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Iain Buclaw via Digitalmars-d"  wrote in message 
news:mailman.95.1406528707.16021.digitalmars-d puremagic.com...

 I was fairly reluctant initially given Phobos' track-record.  However
 someone did point out that if we don't use Phobos in DDMD, we might as
 well apply the brakes now to the project before its allowed to set
 sail.
There are a huge number of nice things in D that you don't need phobos for.
Jul 28 2014
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28 July 2014 07:24, Iain Buclaw <ibuclaw gdcproject.org> wrote:
 On 28 July 2014 07:08, Jonathan M Davis via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
 Now we have DDMD approaching fast round the corner, with it comes the
 prospect of leveraging the many library types in D for use in the compiler
 frontend; BigInt, CustomFloat, HalfFloat;
I would point out that every time I've seen compiler devs discuss using Phobos in dmd, there has been a large reluctance to do so (if not outright a desire to avoid it entirely) in order to avoid the circular dependencies that would ensue (Daniel Murphy in particular really doesn't seem to like the idea). It's much easier to control what's going on with dmd if it doesn't rely on Phobos. So, while it may very well be that ddmd eventually uses Phobos, I suspect that you have an uphill battle in trying to make it happen. It's more likely that ddmd would end up with some simplified copies of the necessary functionality from Phobos within its own source code in order to avoid any such dependencies.
I was fairly reluctant initially given Phobos' track-record. However someone did point out that if we don't use Phobos in DDMD, we might as well apply the brakes now to the project before its allowed to set sail.
And I can say (as of writing): - Me and Daniel did discuss using a library-defined float-point type in DDMD at DConf 2014 - Daniel is considering the use of BigInt for integer operations in DDMD. Both will need work for support. But it is not something that is being ignored. Iain
Jul 27 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Iain Buclaw via Digitalmars-d"  wrote in message 
news:mailman.96.1406529001.16021.digitalmars-d puremagic.com...

 And I can say (as of writing):

 - Me and Daniel did discuss using a library-defined float-point type
 in DDMD at DConf 2014
 - Daniel is considering the use of BigInt for integer operations in DDMD.

 Both will need work for support.  But it is not something that is being 
 ignored.
I am considering using BigInt, but my position on using phobos has not changed. Being (mostly) self-contained is one of the nicest things about dmd's codebase, and I don't want to lose that.
Jul 28 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jonathan M Davis"  wrote in message 
news:lfhsrrkauworheqmedhm forum.dlang.org...

 I would point out that every time I've seen compiler devs discuss using 
 Phobos in dmd, there has been a large reluctance to do so (if not outright 
 a desire to avoid it entirely) in order to avoid the circular dependencies 
 that would ensue (Daniel Murphy in particular really doesn't seem to like 
 the idea).
Yes, and I'm still against it. It's not about the circular dependency (that already exists with druntime and is manageable) it's that including phobos effectively massively increases the size of the dmd codebase. Phobos is also tied to the release cycles in a different way than it looks like ddmd will be. Druntime is much smaller and much less worrying (and impossible to avoid).
Jul 28 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/14, 4:54 AM, Daniel Murphy wrote:
 "Jonathan M Davis"  wrote in message
 news:lfhsrrkauworheqmedhm forum.dlang.org...

 I would point out that every time I've seen compiler devs discuss
 using Phobos in dmd, there has been a large reluctance to do so (if
 not outright a desire to avoid it entirely) in order to avoid the
 circular dependencies that would ensue (Daniel Murphy in particular
 really doesn't seem to like the idea).
Yes, and I'm still against it. It's not about the circular dependency (that already exists with druntime and is manageable) it's that including phobos effectively massively increases the size of the dmd codebase. Phobos is also tied to the release cycles in a different way than it looks like ddmd will be. Druntime is much smaller and much less worrying (and impossible to avoid).
There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- Andrei
Jul 28 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jul 28, 2014 at 11:03:22AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 7/28/14, 4:54 AM, Daniel Murphy wrote:
"Jonathan M Davis"  wrote in message
news:lfhsrrkauworheqmedhm forum.dlang.org...

I would point out that every time I've seen compiler devs discuss
using Phobos in dmd, there has been a large reluctance to do so (if
not outright a desire to avoid it entirely) in order to avoid the
circular dependencies that would ensue (Daniel Murphy in particular
really doesn't seem to like the idea).
Yes, and I'm still against it. It's not about the circular dependency (that already exists with druntime and is manageable) it's that including phobos effectively massively increases the size of the dmd codebase. Phobos is also tied to the release cycles in a different way than it looks like ddmd will be. Druntime is much smaller and much less worrying (and impossible to avoid).
There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- Andrei
FWIW, I'm for dogfooding. I think using Phobos in ddmd will (indirectly) improve the quality of Phobos. I still have this lurking suspicion that large swaths of Phobos have only barely been used, and therefore there are probably many bugs, design issues, and inefficiencies that we're unaware of. Or only unknown user code out there uses some of these things, but we don't know about it so we're not conscious of issues that may arise. Using Phobos in ddmd will give us very strong incentives to polish Phobos to a far higher quality than it currently is, IMO. T -- Frank disagreement binds closer than feigned agreement.
Jul 28 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/14, 11:12 AM, H. S. Teoh via Digitalmars-d wrote:
 On Mon, Jul 28, 2014 at 11:03:22AM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 7/28/14, 4:54 AM, Daniel Murphy wrote:
 "Jonathan M Davis"  wrote in message
 news:lfhsrrkauworheqmedhm forum.dlang.org...

 I would point out that every time I've seen compiler devs discuss
 using Phobos in dmd, there has been a large reluctance to do so (if
 not outright a desire to avoid it entirely) in order to avoid the
 circular dependencies that would ensue (Daniel Murphy in particular
 really doesn't seem to like the idea).
Yes, and I'm still against it. It's not about the circular dependency (that already exists with druntime and is manageable) it's that including phobos effectively massively increases the size of the dmd codebase. Phobos is also tied to the release cycles in a different way than it looks like ddmd will be. Druntime is much smaller and much less worrying (and impossible to avoid).
There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- Andrei
FWIW, I'm for dogfooding. I think using Phobos in ddmd will (indirectly) improve the quality of Phobos.
According to Simon Peyton Jones, it has greatly worked for ghc (the reference Haskell compiler). Essentially ghc is one of the largest and most complex codebases of ghc itself. I assume they use Haskell's own standard library in the compiler.
 I still have this lurking suspicion that
 large swaths of Phobos have only barely been used, and therefore there
 are probably many bugs, design issues, and inefficiencies that we're
 unaware of. Or only unknown user code out there uses some of these
 things, but we don't know about it so we're not conscious of issues that
 may arise. Using Phobos in ddmd will give us very strong incentives to
 polish Phobos to a far higher quality than it currently is, IMO.
Agreed. Conversely we'd be hamstringing ourselves by essentially making D a poorer choice for implementing dmd than any other languages. The standard library of a language is a good part of any language's power, and that's true especially for D; static introspection has moved a bunch of stuff usually confined to builtins into the standard library. I'm not among the compiler development regulars but it seems to me converting to ddmd would be a mistake if we don't plan for using Phobos. Andrei
Jul 28 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:lr64ah$1akc$1 digitalmars.com...

 Agreed. Conversely we'd be hamstringing ourselves by essentially making D 
 a poorer choice for implementing dmd than any other languages.
This doesn't make any sense. Somehow D is a worse choice than C++ if we don't use phobos?
 I'm not among the compiler development regulars but it seems to me 
 converting to ddmd would be a mistake if we don't plan for using Phobos.
You are severely underestimating the benefits of D as a language.
Jul 28 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/14, 12:13 PM, Daniel Murphy wrote:
 "Andrei Alexandrescu"  wrote in message
 news:lr64ah$1akc$1 digitalmars.com...

 Agreed. Conversely we'd be hamstringing ourselves by essentially
 making D a poorer choice for implementing dmd than any other languages.
This doesn't make any sense.
Well, if quoted without the surrounding context... Andrei
Jul 28 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:lr6395$19r7$1 digitalmars.com...

 There'd also be the argument that using phobos inside ddmd would make the 
 latter a better test for itself and phobos. -- Andrei
This is true, but my main concern is the quality of the compiler source. My main concerns are: (not in order) - Compile time - Binary bloat - Reduced scrutiny of code that is used in the compiler - I review every single compiler patch, but I do not have time to do that for phobos too - The compiler must build with the last release, and with HEAD. HEAD phobos only needs to build with HEAD. - Some other things. Anyway, there is no rush. We will have plenty of time to talk about this after ddmd becomes dmd.
Jul 28 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jul 29, 2014 at 04:24:27AM +1000, Daniel Murphy via Digitalmars-d wrote:
 "Andrei Alexandrescu"  wrote in message
 news:lr6395$19r7$1 digitalmars.com...
 
There'd also be the argument that using phobos inside ddmd would make
the latter a better test for itself and phobos. -- Andrei
This is true, but my main concern is the quality of the compiler source. My main concerns are: (not in order) - Compile time - Binary bloat
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.
 - Reduced scrutiny of code that is used in the compiler - I review
   every single compiler patch, but I do not have time to do that for
   phobos too
Perhaps the solution is to get more people involved in this review? Y'know, increase the bus factor and everything.
 - The compiler must build with the last release, and with HEAD.  HEAD
   phobos only needs to build with HEAD.
[...] 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). T -- What is Matter, what is Mind? Never Mind, it doesn't Matter.
Jul 28 2014
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.124.1406572776.16021.digitalmars-d 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.
 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?
 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. It would also be nice to keep compatibility further back than a single dmd release. This would make things harder.
Jul 28 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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 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.
Jul 28 2014
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, 28 July 2014 at 22:45:51 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 But another way to approach it, is to do Phobos integration 
 first, while we still have the current C++ code.
I would point out that the way that ddmd is being done is to automatically translate dmd from C++ to D, so everything has to be done on the C++ end until we've actually switched it over to D permanently. That means that we can't take advantage of any of D's features (be they in the language or the standard library) until we've actually fully switched the compiler to D. So, Phobos integration _can't_ come first. - Jonathan M Davis
Jul 28 2014
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.130.1406587551.16021.digitalmars-d puremagic.com...

 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.
There is no if, this is exactly how it is going to happen. Phobos will not be used in ddmd until after the transition.
 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.
No. If you want to improve phobos, make phobos quality a blocker for your own projects, don't screw over ddmd.
 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?
Again, let's not make a phobos problem a dmd problem.
 Not necessarily. If the compiler doesn't use the parts of Phobos that
 has the new attribute, then it's not a problem.
Maybe, but I'm not so sure it will be that easy.
 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:
That's somewhere between horrific and unacceptable. It's just not worth it.
 I think this should be possible using static if (__VERSION__ ...).
Possible but not worthwhile.
Jul 29 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/14, 11:37 AM, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Jul 29, 2014 at 04:24:27AM +1000, Daniel Murphy via Digitalmars-d
wrote:
 "Andrei Alexandrescu"  wrote in message
 news:lr6395$19r7$1 digitalmars.com...

 There'd also be the argument that using phobos inside ddmd would make
 the latter a better test for itself and phobos. -- Andrei
This is true, but my main concern is the quality of the compiler source. My main concerns are: (not in order) - Compile time - Binary bloat
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.
YES! I wrote my reply before reading this!! -- Andrei
Jul 28 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/14, 11:24 AM, Daniel Murphy wrote:
 "Andrei Alexandrescu"  wrote in message
 news:lr6395$19r7$1 digitalmars.com...

 There'd also be the argument that using phobos inside ddmd would make
 the latter a better test for itself and phobos. -- Andrei
This is true, but my main concern is the quality of the compiler source. My main concerns are: (not in order) - Compile time - Binary bloat - Reduced scrutiny of code that is used in the compiler - I review every single compiler patch, but I do not have time to do that for phobos too - The compiler must build with the last release, and with HEAD. HEAD phobos only needs to build with HEAD. - Some other things.
The way I see some of these liabilities is as dogfooding. For example if slow compile times and code bloat become a problem with ddmd they are also a problem with other large D programs, and it's good to have an extra incentive to fix them.
 Anyway, there is no rush.  We will have plenty of time to talk about
 this after ddmd becomes dmd.
That's the spirit! Andrei
Jul 28 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:lr6c5j$1h13$1 digitalmars.com...

 The way I see some of these liabilities is as dogfooding. For example if 
 slow compile times and code bloat become a problem with ddmd they are also 
 a problem with other large D programs, and it's good to have an extra 
 incentive to fix them.
Hopefully the desire to see phobos used in ddmd will provide the needed motivation to fix these issue so it's suitable for use. I'm quite happy with our dog food but I'm not so sure about the dog house, dog toys and dog shampoo. Puppy steps.
Jul 28 2014
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28 July 2014 21:34, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 7/28/14, 11:24 AM, Daniel Murphy wrote:
 "Andrei Alexandrescu"  wrote in message
 news:lr6395$19r7$1 digitalmars.com...

 There'd also be the argument that using phobos inside ddmd would make
 the latter a better test for itself and phobos. -- Andrei
This is true, but my main concern is the quality of the compiler source. My main concerns are: (not in order) - Compile time - Binary bloat - Reduced scrutiny of code that is used in the compiler - I review every single compiler patch, but I do not have time to do that for phobos too - The compiler must build with the last release, and with HEAD. HEAD phobos only needs to build with HEAD. - Some other things.
The way I see some of these liabilities is as dogfooding. For example if slow compile times and code bloat become a problem with ddmd they are also a problem with other large D programs, and it's good to have an extra incentive to fix them.
Indeed, before this topic gets derailed any further. Do you have any thoughts on the initial post? Iain.
Jul 28 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/14, 11:23 PM, Iain Buclaw via Digitalmars-d wrote:
 Indeed, before this topic gets derailed any further. Do you have any
 thoughts on the initial post?
I don't understand the question. -- Andrei
Jul 28 2014
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29 July 2014 07:28, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 7/28/14, 11:23 PM, Iain Buclaw via Digitalmars-d wrote:
 Indeed, before this topic gets derailed any further. Do you have any
 thoughts on the initial post?
I don't understand the question. -- Andrei
I didn't start this thread to talk about ddmd. :o)
Jul 29 2014
prev sibling parent reply "Dominikus Dittes Scherkl" writes:
On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
 The cent and ucent keywords have been reserved since... well... 
 certainly before the first D1 (as opposed to D0.xx) release 
 [2].  But that's all they have ever seemed to be.  Just 
 reserved keywords that give odd errors when you try to use them.
Yes, I truly wish those would be supported - not only to use them directly, but at least as fallback for e.g. safe multiplication (cent x = long * long; if(x > long.max) throw exception;) From the language reference I had strongly expected that cent and ucent are supported - a look into phobos destroyed that hope :-/
Jul 28 2014
parent "ponce" <contact gam3sfrommars.fr> writes:
On Monday, 28 July 2014 at 12:43:03 UTC, Dominikus Dittes Scherkl 
wrote:
 On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
 The cent and ucent keywords have been reserved since... 
 well... certainly before the first D1 (as opposed to D0.xx) 
 release [2].  But that's all they have ever seemed to be.  
 Just reserved keywords that give odd errors when you try to 
 use them.
Yes, I truly wish those would be supported - not only to use them directly, but at least as fallback for e.g. safe multiplication (cent x = long * long; if(x > long.max) throw exception;) From the language reference I had strongly expected that cent and ucent are supported - a look into phobos destroyed that hope :-/
https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint.d FWIW
Jul 28 2014