digitalmars.D - [ABI] 128bit integers and other vendor types
- Iain Buclaw (101/101) Jul 27 2014 Hi,
- bearophile (5/9) Jul 27 2014 Is a mangled identifier also useful for partially library defined
- Iain Buclaw via Digitalmars-d (7/13) Jul 27 2014 I think not, and my reason for saying that is the mess of mangling C++
- Jonathan M Davis (14/18) Jul 27 2014 I would point out that every time I've seen compiler devs discuss
- Iain Buclaw via Digitalmars-d (7/22) Jul 27 2014 I was fairly reluctant initially given Phobos' track-record. However
- Daniel Murphy (3/7) Jul 28 2014 There are a huge number of nice things in D that you don't need phobos f...
- Iain Buclaw via Digitalmars-d (7/31) Jul 27 2014 And I can say (as of writing):
- Daniel Murphy (6/12) Jul 28 2014 I am considering using BigInt, but my position on using phobos has not
- Daniel Murphy (8/13) Jul 28 2014 Yes, and I'm still against it. It's not about the circular dependency (...
- Andrei Alexandrescu (3/16) Jul 28 2014 There'd also be the argument that using phobos inside ddmd would make
- H. S. Teoh via Digitalmars-d (12/31) Jul 28 2014 FWIW, I'm for dogfooding. I think using Phobos in ddmd will (indirectly)
- Andrei Alexandrescu (13/42) Jul 28 2014 According to Simon Peyton Jones, it has greatly worked for ghc (the
- Daniel Murphy (5/9) Jul 28 2014 This doesn't make any sense. Somehow D is a worse choice than C++ if we...
- Andrei Alexandrescu (3/8) Jul 28 2014 Well, if quoted without the surrounding context...
- Daniel Murphy (13/15) Jul 28 2014 This is true, but my main concern is the quality of the compiler source.
- H. S. Teoh via Digitalmars-d (25/42) Jul 28 2014 I see this as a good thing, actually. Not that I think it's good to
- Daniel Murphy (15/35) Jul 28 2014 I do not see it that way. Once phobos quality is acceptable, then we ca...
- H. S. Teoh via Digitalmars-d (48/89) Jul 28 2014 It depends on how we do the transition. If we replace dmd with ddmd
- Jonathan M Davis (10/12) Jul 28 2014 I would point out that the way that ddmd is being done is to
- Daniel Murphy (10/32) Jul 29 2014 There is no if, this is exactly how it is going to happen. Phobos will ...
- Andrei Alexandrescu (2/23) Jul 28 2014 YES! I wrote my reply before reading this!! -- Andrei
- Andrei Alexandrescu (7/22) Jul 28 2014 The way I see some of these liabilities is as dogfooding. For example if...
- Daniel Murphy (6/10) Jul 28 2014 Hopefully the desire to see phobos used in ddmd will provide the needed
- Iain Buclaw via Digitalmars-d (5/28) Jul 28 2014 Indeed, before this topic gets derailed any further. Do you have any
- Andrei Alexandrescu (2/4) Jul 28 2014 I don't understand the question. -- Andrei
- Iain Buclaw via Digitalmars-d (3/8) Jul 29 2014 I didn't start this thread to talk about ddmd. :o)
- Dominikus Dittes Scherkl (6/10) Jul 28 2014 Yes, I truly wish those would be supported - not only to use them
- ponce (4/17) Jul 28 2014 https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint....
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
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
On 27 July 2014 14:35, bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:Iain Buclaw: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 IainBigInt 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)?
Jul 27 2014
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
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: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.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.
Jul 27 2014
"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
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: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. IainOn Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote: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.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.
Jul 27 2014
"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
"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
On 7/28/14, 4:54 AM, Daniel Murphy wrote:"Jonathan M Davis" wrote in message news:lfhsrrkauworheqmedhm forum.dlang.org...There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- AndreiI 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
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: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."Jonathan M Davis" wrote in message news:lfhsrrkauworheqmedhm forum.dlang.org...There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- AndreiI 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
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: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.On 7/28/14, 4:54 AM, Daniel Murphy wrote:FWIW, I'm for dogfooding. I think using Phobos in ddmd will (indirectly) improve the quality of Phobos."Jonathan M Davis" wrote in message news:lfhsrrkauworheqmedhm forum.dlang.org...There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- AndreiI 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).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
"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
On 7/28/14, 12:13 PM, Daniel Murphy wrote:"Andrei Alexandrescu" wrote in message news:lr64ah$1akc$1 digitalmars.com...Well, if quoted without the surrounding context... AndreiAgreed. 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.
Jul 28 2014
"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. -- AndreiThis 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
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...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.There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- AndreiThis 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 tooPerhaps 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
"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
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...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.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.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?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?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.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.I think this should be possible using static if (__VERSION__ ...). T -- This sentence is false.
Jul 28 2014
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
"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
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:YES! I wrote my reply before reading this!! -- Andrei"Andrei Alexandrescu" wrote in message news:lr6395$19r7$1 digitalmars.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.There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- AndreiThis is true, but my main concern is the quality of the compiler source. My main concerns are: (not in order) - Compile time - Binary bloat
Jul 28 2014
On 7/28/14, 11:24 AM, Daniel Murphy wrote:"Andrei Alexandrescu" wrote in message news:lr6395$19r7$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.There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- AndreiThis 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.That's the spirit! Andrei
Jul 28 2014
"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
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:Indeed, before this topic gets derailed any further. Do you have any thoughts on the initial post? Iain."Andrei Alexandrescu" wrote in message news:lr6395$19r7$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.There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- AndreiThis 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.
Jul 28 2014
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
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:I didn't start this thread to talk about ddmd. :o)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 29 2014
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
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:https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint.d FWIWThe 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