Re: Battle-plan for CTFE

On 10/30/2016 11:19 PM, Stefan Koch wrote: > Oh shoot! > I did not enable the new call system :( > This computed by the old interpreter. > > The new engine fails :( Stefan, would you mind creating a dedicated topic in main D newsgroup to report your development progress? Bumping the thread in

Re: Battle-plan for CTFE

On Sunday, 30 October 2016 at 21:09:19 UTC, Stefan Koch wrote: On Sunday, 30 October 2016 at 03:07:13 UTC, Stefan Koch wrote: I just made progress on another fundamental feature, function call support. It's does not [fully] work yet, but it shows promise. The following just compiled : int

Re: Battle-plan for CTFE

On Sunday, 30 October 2016 at 03:07:13 UTC, Stefan Koch wrote: I just made progress on another fundamental feature, function call support. It's does not [fully] work yet, but it shows promise. The following just compiled : int fn(int a) { return a + fn2(2); } int fn2(int a) { return

Re: Battle-plan for CTFE

On Friday, 28 October 2016 at 16:52:46 UTC, Stefan Koch wrote: Another update on CTFE. I have found a few errors in my handling of switch-statments. An efficient solution for this is still pending, Futhermore I have begun to work on ctfe handling refernces. These are a little bit harder to do

Re: Battle-plan for CTFE

Another update on CTFE. I have found a few errors in my handling of switch-statments. An efficient solution for this is still pending, Futhermore I have begun to work on ctfe handling refernces. These are a little bit harder to do in bytecode and do pessimise performance if overused. I hope

Re: Battle-plan for CTFE

On Wednesday, 26 October 2016 at 16:24:49 UTC, MakersF wrote: On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote: Who can guess what this code does ? char[] obfuscatedFn(string a, string b, uint aLength = 0, uint bLength = 0, uint cLength = 0, uint pos = 0, uint bPos = 0,

Re: Battle-plan for CTFE

On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote: Who can guess what this code does ? char[] obfuscatedFn(string a, string b, uint aLength = 0, uint bLength = 0, uint cLength = 0, uint pos = 0, uint bPos = 0, char[] result = []) { aLength = cast(uint)a.length;

Re: Battle-plan for CTFE

On Wednesday, 26 October 2016 at 15:38:30 UTC, Kagamin wrote: On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote: bLength = cast(uint)a.length; Reads past the end of b if b is shorter than a. you are right. Thanks for spotting it :)

Re: Battle-plan for CTFE

On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote: bLength = cast(uint)a.length; Reads past the end of b if b is shorter than a.

Re: Battle-plan for CTFE

Who can guess what this code does ? char[] obfuscatedFn(string a, string b, uint aLength = 0, uint bLength = 0, uint cLength = 0, uint pos = 0, uint bPos = 0, char[] result = []) { aLength = cast(uint)a.length; bLength = cast(uint)a.length; cLength = aLength + bLength;

Re: Battle-plan for CTFE

On Wednesday, 26 October 2016 at 08:19:46 UTC, Andrea Fontana wrote: On Wednesday, 26 October 2016 at 03:58:05 UTC, Stefam Koch wrote: On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg wrote: Very impressive :) Thanks. I just got the following code to compile and execute

Re: Battle-plan for CTFE

On Wednesday, 26 October 2016 at 03:58:05 UTC, Stefam Koch wrote: On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg wrote: Very impressive :) Thanks. I just got the following code to compile and execute correctly. bool strEq(string a, string b) { if (a.length != b.length)

Re: Battle-plan for CTFE

On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg wrote: Very impressive :) Thanks. I just got the following code to compile and execute correctly. bool strEq(string a, string b) { if (a.length != b.length) { return false; } uint length = cast(uint)

Re: Battle-plan for CTFE

On 2016-10-25 14:36, Stefam Koch wrote: First perf data is in The is measured with time src/dmd -c -ctfe-bc old interpreter (without -ctfe-bc) : real0m6.839s user0m6.423s sys0m0.407s new interpreter (-ctfe-bc) real0m0.549s user0m0.547s sys0m0.000s LLVM Backend

Re: Battle-plan for CTFE

On Tuesday, 25 October 2016 at 15:57:33 UTC, Wyatt wrote: On Tuesday, 25 October 2016 at 12:36:56 UTC, Stefam Koch wrote: LLVM Backend (-ctfe-bc -version=UseLLVMBackend) : real0m0.039s user0m0.027s sys 0m0.010s I think 20,000% is a pretty good speedup! ;) Great stuff. Now that

Re: Battle-plan for CTFE

On Tuesday, 25 October 2016 at 12:36:56 UTC, Stefam Koch wrote: LLVM Backend (-ctfe-bc -version=UseLLVMBackend) : real0m0.039s user0m0.027s sys 0m0.010s I think 20,000% is a pretty good speedup! ;) Great stuff. Now that JIT works, are you returning to focusing on feature

Re: Battle-plan for CTFE

On Tuesday, 25 October 2016 at 09:36:12 UTC, Stefam Koch wrote: On Monday, 24 October 2016 at 06:37:12 UTC, Rory McGuire wrote: Cool, thanks for the feedback. I have take care of the blocker for now. I turns out my tests contained wrong code that reused a register for multiple purposes.

Re: Battle-plan for CTFE

On Monday, 24 October 2016 at 06:37:12 UTC, Rory McGuire wrote: Cool, thanks for the feedback. I have take care of the blocker for now. I turns out my tests contained wrong code that reused a register for multiple purposes. LLVM does not like that. So it assumed the wrong things while

Re: Battle-plan for CTFE

On Mon, Oct 24, 2016 at 8:17 AM, Stefam Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Monday, 24 October 2016 at 05:57:42 UTC, Stefam Koch wrote: > >> On Sunday, 16 October 2016 at 00:27:50 UTC, Uplink_Coder wrote: >> >>> >>> Little update here: >>> The LLVM

Re: Battle-plan for CTFE

On Monday, 24 October 2016 at 05:57:42 UTC, Stefam Koch wrote: On Sunday, 16 October 2016 at 00:27:50 UTC, Uplink_Coder wrote: Little update here: The LLVM backend is almost on feature parity. Meaning that that soon the new CTFE engine is a real jit. In the process I discoverd quite a few

Re: Battle-plan for CTFE

On Sunday, 16 October 2016 at 00:27:50 UTC, Uplink_Coder wrote: Little update here: The LLVM backend is almost on feature parity. Meaning that that soon the new CTFE engine is a real jit. In the process I discoverd quite a few horrible bugs and inconsistency in the API. I am quite astonished

Re: Battle-plan for CTFE

On 19 Oct 2016 17:46, "Stefan Koch via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote: >> >> On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote: >>> >>> If all goes well there will be a separate

Re: Battle-plan for CTFE

On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote: On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote: If all goes well there will be a separate nightly release build from the newCTFE branch, sometime in October. I hope to get alpha bug reports that way. Have you

Re: Battle-plan for CTFE

On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote: If all goes well there will be a separate nightly release build from the newCTFE branch, sometime in October. I hope to get alpha bug reports that way. Have you benchmarked CTFE-heavy projects like Pegged?

Re: Battle-plan for CTFE

On Monday, 17 October 2016 at 15:50:37 UTC, Uplink_Coder wrote: The time llvm takes to build it's IR and execute the JITed code is absolutely too much! multiple milliseconds! I will write a very simple x86 codegenerator tomorrow. Great work.

Re: Battle-plan for CTFE

On Monday, 17 October 2016 at 00:56:01 UTC, Uplink_Coder wrote: If anyone want to take a look the lastest llvm_backend development is happening here : https://github.com/UplinkCoder/dmd/blob/_ctfe/src/bc_llvm_backend.d The time llvm takes to build it's IR and execute the JITed code is

Re: Battle-plan for CTFE

On Sunday, 16 October 2016 at 13:51:55 UTC, Uplink_Coder wrote: On Sunday, 16 October 2016 at 10:58:57 UTC, Dmitry Olshansky wrote: That LLVM thing is surely nice to have but I highly doubt it will be allowed as dependency for DMD. --- Dmitry Olshansky LLVM is purely optional. A pure D

Re: Battle-plan for CTFE

On 10/16/16 2:27 AM, Uplink_Coder wrote: On Wednesday, 5 October 2016 at 08:34:06 UTC, Rory McGuire wrote: No worries, I've been watching this space for over a decade. I really believe you are working on one of the most important parts of IT for the next decade. I am planning/making a library

Re: Battle-plan for CTFE

On Wednesday, 5 October 2016 at 08:34:06 UTC, Rory McGuire wrote: No worries, I've been watching this space for over a decade. I really believe you are working on one of the most important parts of IT for the next decade. I am planning/making a library that uses CTFE extensively and feel

Re: Battle-plan for CTFE

On Sunday, 16 October 2016 at 10:58:57 UTC, Dmitry Olshansky wrote: That LLVM thing is surely nice to have but I highly doubt it will be allowed as dependency for DMD. --- Dmitry Olshansky LLVM is purely optional. A pure D interpreter exists. LLVM optimises most ctfe btw and returns

Re: Battle-plan for CTFE

On Sun, Sep 25, 2016 at 10:47 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Sunday, 25 September 2016 at 18:21:27 UTC, Rory McGuire wrote: > >> >> :D congrats! >> > > I appreciate it. > If all goes well there will be a separate nightly release

Re: Battle-plan for CTFE

On Sunday, 25 September 2016 at 18:21:27 UTC, Rory McGuire wrote: :D congrats! I appreciate it. If all goes well there will be a separate nightly release build from the newCTFE branch, sometime in October. I hope to get alpha bug reports that way. Also I am now starting experimentation

Re: Battle-plan for CTFE

On Sun, Sep 25, 2016 at 4:47 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Tuesday, 20 September 2016 at 05:06:57 UTC, Nordlöw wrote: > >> On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote: >> >>> Compiling all of phobos does not

Re: Battle-plan for CTFE

On Tuesday, 20 September 2016 at 05:06:57 UTC, Nordlöw wrote: On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote: Compiling all of phobos does not crash my engine anymore! Great work! Keep up still! I am proud to announce, (and slightly embarssed because it took to long) that

Re: Battle-plan for CTFE

On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote: Compiling all of phobos does not crash my engine anymore! Great work! Keep up still!

Re: Battle-plan for CTFE

On Monday, 19 September 2016 at 18:05:34 UTC, Lurker wrote: Good news anyway! Do you have any preliminary results or goals and expectations that you are going to achieve with your rework? Is it mostly perf/memory improvements, are there any new features that this rework will unlock? Thanks

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 18:54:52 UTC, Stefan Koch wrote: On Thursday, 8 September 2016 at 13:11:23 UTC, Stefan Koch wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 13:11:23 UTC, Stefan Koch wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :) I think I have taken care of the incorrect

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 14:48:25 UTC, Rory McGuire wrote: On Thu, Sep 8, 2016 at 3:11 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no

Re: Battle-plan for CTFE

On Thu, Sep 8, 2016 at 3:11 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: > >> compiling parts of phobos does no longer crash the new engine. >> However it still produces incorrect

Re: Battle-plan for CTFE

On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote: compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :) I think I have taken care of the incorrect bytecode. It was not an issue with the engine itself but rather with the

Re: Battle-plan for CTFE

compiling parts of phobos does no longer crash the new engine. However it still produces incorrect byte-code :)

Re: Battle-plan for CTFE

On Mon, Sep 5, 2016 at 1:39 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > FunctionCall support is done. (with a lot of room for improvement) > you can already return strings. > now I just have to finish string-comparison and string-concat support to >

Re: Battle-plan for CTFE

FunctionCall support is done. (with a lot of room for improvement) you can already return strings. now I just have to finish string-comparison and string-concat support to make it usable. And of course the correct translation of logical-expressions...

Re: Battle-plan for CTFE

On 09/01/2016 11:51 PM, Rory McGuire via Digitalmars-d-announce wrote: Yeah, I'm using an enum to force the evaluation during CT, I had missed that detail. Still, the error seems to be independent of any CTFE that's going on. [...] Here is another example: void main() { enum ret =

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 21:48:41 UTC, Rory McGuire wrote: I was hoping that the error was coming from the CTFE engine as it ran the code, but it comes up before ctfe execution I guess. As a general comment, there is no such thing as a CTFE phase. It is performed in-line with other

Re: Battle-plan for CTFE

On Thu, Sep 01, 2016 at 08:43:16PM +, David Nadlinger via Digitalmars-d-announce wrote: > On Thursday, 1 September 2016 at 19:38:13 UTC, Stefan Koch wrote: > > I have something that will help with that a little bit. > > https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln when you apply > >

Re: Battle-plan for CTFE

On Thu, Sep 1, 2016 at 11:26 PM, ag0aep6g via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On 09/01/2016 11:01 PM, Rory McGuire via Digitalmars-d-announce wrote: > >> I'm actually asking why we can't catch the ctfe error. >> > > There is no CTFE error in your example.

Re: Battle-plan for CTFE

On Thu, Sep 1, 2016 at 11:05 PM, David Nadlinger via Digitalmars-d-announce wrote: > On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote: > >> I'm actually asking why we can't catch the ctfe error. >> > > You can, by using __traits(compiles,

Re: Battle-plan for CTFE

On 09/01/2016 11:01 PM, Rory McGuire via Digitalmars-d-announce wrote: I'm actually asking why we can't catch the ctfe error. There is no CTFE error in your example. It doesn't compile in the first place, even without attempting any CTFE. [...] Surely the ctfe engine could be changed to

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 20:43:16 UTC, David Nadlinger wrote: See also: https://github.com/dlang/dmd/pull/692 – it's about time we finally got __ctfeWrite() merged. — David Oh yeah. Let me get this into PR shape.

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote: I'm actually asking why we can't catch the ctfe error. You can, by using __traits(compiles, …). Surely the ctfe engine could be changed to catch unsupported code errors. (Not invalid, just unsupported at CT). It already

Re: Battle-plan for CTFE

On 01 Sep 2016 21:36, "David Nadlinger via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote: >> >> So why can't we even catch the Error during CTFE, that would at least help somewhat. > > > You are mixing

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 19:38:13 UTC, Stefan Koch wrote: I have something that will help with that a little bit. https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln when you apply this patch __ctfeWriteln() will output every compiletime avilable string to the console. More

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote: At the moment I just have a verbose logging mode with pragma(msg) for my CTFE stuff. I have something that will help with that a little bit. https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln when you apply this patch

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote: So why can't we even catch the Error during CTFE, that would at least help somewhat. You are mixing up runtime exceptions ("throw …") with compiler errors (missing a semicolon). dm.D.learn should be able to help clear that

Re: Battle-plan for CTFE

On Thu, Sep 1, 2016 at 9:09 PM, David Nadlinger via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote: > >> is that in one of the "semantic" passes the compiler has? >> > > For reference, I've laid out the

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote: is that in one of the "semantic" passes the compiler has? For reference, I've laid out the reasons why this proposal couldn't work to Stefan here: https://github.com/dlang/dmd/pull/6098#issuecomment-243375543 The real

Re: Battle-plan for CTFE

On Thu, Sep 1, 2016 at 6:29 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote: > >> the _checkCTFE() function is just a function that does something we're not >> allowed to do at CTFE, but

Re: Battle-plan for CTFE

On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote: the _checkCTFE() function is just a function that does something we're not allowed to do at CTFE, but current implementation does not respect __traits(compiles, ); As far as I can tell that is a bug. Thoughts? It is

Re: Battle-plan for CTFE

On Wed, Aug 31, 2016 at 10:43 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Tuesday, 30 August 2016 at 22:01:45 UTC, tsbockman wrote: > >> On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote: >> >>> I just came up with a nifty little patch

Re: Battle-plan for CTFE

On Tuesday, 30 August 2016 at 22:01:45 UTC, tsbockman wrote: On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote: I just came up with a nifty little patch that makes it possible to ensure that a function is _only_ used at ctfe. Or the opposite. static assert(__ctfe, "This function is

Re: Battle-plan for CTFE

On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote: I just came up with a nifty little patch that makes it possible to ensure that a function is _only_ used at ctfe. Or the opposite. static assert(__ctfe, "This function is not supposed to be called outside of ctfe"); and static

Re: Battle-plan for CTFE

On Tuesday, 30 August 2016 at 17:29:19 UTC, deadalnix wrote: worth trying to get it into master ? I would say maybe, but let's keep separate things separate. This is a language change. I would not include it in the same series of patch that change CTFE behavior. Yes. It would be confusing.

Re: Battle-plan for CTFE

On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote: On Monday, 29 August 2016 at 08:05:10 UTC, Rory McGuire wrote: On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via The work you are doing is just awesome! Many thanks. +1 your work is key for our success as a

Re: Battle-plan for CTFE

Am Tue, 30 Aug 2016 12:42:35 +0200 schrieb Johannes Pfau : > @nogc is only meaningful at runtime. So this could work: > > module foo; > @nogc: > [...] > > string ctfeOnly(string name) > { > static assert(!__ctfe); This should be static assert(__ctfe); of course.

Re: Battle-plan for CTFE

Am Tue, 30 Aug 2016 08:35:20 + schrieb Stefan Koch : > I do not see how this could affect @nogc. @nogc is only meaningful at runtime. So this could work: module foo; @nogc: [...] string ctfeOnly(string name) { static assert(!__ctfe); // error: cannot

Re: Battle-plan for CTFE

On Tue, Aug 30, 2016 at 10:35 AM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > [snip] > But yes you can circumvent the code-generation and pulling in the druntime > dependency using a static if. > That will be awesome!

Re: Battle-plan for CTFE

On Tuesday, 30 August 2016 at 08:18:47 UTC, Johannes Pfau wrote: There are some nice use cases for this: * Do not enforce @nogc for CTFE only functions, so you can mark a complete module nogc: and CTFE only functions will get ignored * Do not emit code for CTFE only functions. This is

Re: Battle-plan for CTFE

Am Tue, 30 Aug 2016 08:57:25 +0200 schrieb Jacob Carlborg : > On 2016-08-29 10:39, Stefan Koch wrote: > > > Thanks guys. > > > > I just came up with a nifty little patch that makes it possible to > > ensure that a function is _only_ used at ctfe. > > Or the opposite. > > > > static

Re: Battle-plan for CTFE

On 2016-08-29 10:39, Stefan Koch wrote: Thanks guys. I just came up with a nifty little patch that makes it possible to ensure that a function is _only_ used at ctfe. Or the opposite. static assert(__ctfe, "This function is not supposed to be called outside of ctfe"); and static

Re: Battle-plan for CTFE

On Monday, 29 August 2016 at 00:24:01 UTC, Stefan Koch wrote: I feel that this can have a positive I am happy for all comments or suggestions. Incredible work! Keep up!

Re: Battle-plan for CTFE

On Monday, 29 August 2016 at 08:05:10 UTC, Rory McGuire wrote: On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via The work you are doing is just awesome! Many thanks. +1 your work is key for our success as a community. R Thanks guys. I just came up with a nifty little patch

Re: Battle-plan for CTFE

On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via Digitalmars-d-announce wrote: > On Monday, 29 August 2016 at 00:24:01 UTC, Stefan Koch wrote: > >> I feel that this can have a positive impact on the whole of dmd, since >> that will allow better

Re: Battle-plan for CTFE

On Monday, 29 August 2016 at 00:24:01 UTC, Stefan Koch wrote: I feel that this can have a positive impact on the whole of dmd, since that will allow better frontend-optimisations. I am happy for all comments or suggestions. The work you are doing is just awesome! Many thanks.

Re: Battle-plan for CTFE

Hi Guys, First of all, parsers will not make it before September. I am sorry about that. Currently I am fixing issues with the design, that for example prevent slices of slices to work. Also I am writing analysis and debugging code to (such as generating a call-graph and primitive DFA) that

Re: Battle-plan for CTFE

On Wednesday, 17 August 2016 at 18:24:37 UTC, Rory McGuire wrote: On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: Just a small update today. if(__ctfe) and if(!__ctfe) now get special treatment. Also working on getting

Re: Battle-plan for CTFE

On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > Just a small update today. > if(__ctfe) and if(!__ctfe) > now get special treatment. > Also working on getting compiletime-parsers to run. > Nice tease with the "compile time parsers

Re: Battle-plan for CTFE

Just a small update today. if(__ctfe) and if(!__ctfe) now get special treatment. Also working on getting compiletime-parsers to run.

Re: Battle-plan for CTFE

On Sun, Aug 14, 2016 at 5:21 AM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > Hi, > > I took a break from work on string operations and focused instead of > improving the robustness of the engine. > I.E. for it not to halt the compiler on unsupported

Re: Battle-plan for CTFE

Hi, I took a break from work on string operations and focused instead of improving the robustness of the engine. I.E. for it not to halt the compiler on unsupported expressions. right now, I can compile druntime without failures. Phobos should be working by the end of next week. Have a nice

Re: Battle-plan for CTFE

I have just committed the changes necessary for (ascii) string indexing and (ascii) string-foreach. Currently working on UTF8 => UTF32 auto-re-encoding and StringConcat and Slice-Support. Completion of Slice support will also fix the interplay between structs and arrays. Cheers, Stefan

Re: Battle-plan for CTFE

On Tuesday, 9 August 2016 at 12:30:18 UTC, Kagamin wrote: 1. You said CTFE engine can be ctfeable itself? But it uses unions in BCValue - it's not going to work in CTFE, is it? Just wondering myself what's the way to have polymorphism at compile time. 2. The byte code generator interface has

Re: Battle-plan for CTFE

1. You said CTFE engine can be ctfeable itself? But it uses unions in BCValue - it's not going to work in CTFE, is it? Just wondering myself what's the way to have polymorphism at compile time. 2. The byte code generator interface has no mean to declare functions? In case of LLVM jit one would

Re: Battle-plan for CTFE

On Monday, 8 August 2016 at 09:51:03 UTC, Johan Engelen wrote: On Sunday, 7 August 2016 at 16:52:28 UTC, Stefan Koch wrote: On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote: No, not now, but very soon. I want to have _basic_ utf8 support before I am comfortable with enabling

Re: Battle-plan for CTFE

On Sunday, 7 August 2016 at 16:52:28 UTC, Stefan Koch wrote: On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote: No, not now, but very soon. I want to have _basic_ utf8 support before I am comfortable with enabling string operations. Tomorrow this is going to work. Hi Stefan,

Re: Battle-plan for CTFE

On Saturday, 6 August 2016 at 14:26:00 UTC, Stefan Koch wrote: I added a switch to my version of dmd which allows to toggle the ctfe engine. So now I can compare apples to apples when posting perf data. That's indeed very useful, also for testing purposes.

Re: Battle-plan for CTFE

On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote: On Saturday, 6 August 2016 at 19:07:10 UTC, Rory McGuire wrote: Hi Stefan, Are you saying we can play around with ascii string slicing/appending already? No, not now, but very soon. I want to have _basic_ utf8 support before I

Re: Battle-plan for CTFE

On Saturday, 6 August 2016 at 19:07:10 UTC, Rory McGuire wrote: Hi Stefan, Are you saying we can play around with ascii string slicing/appending already? No, not now, but very soon. I want to have _basic_ utf8 support before I am comfortable with enabling string operations. The gist with

Re: Battle-plan for CTFE

On 06 Aug 2016 16:30, "Stefan Koch via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > Time for an update. > (ASCII)-Strings work reasonably well. > > I am now working on supporting general Sliceing and Appending. > The effort on function calls is also still ongoing. > >

Re: Battle-plan for CTFE

Time for an update. (ASCII)-Strings work reasonably well. I am now working on supporting general Sliceing and Appending. The effort on function calls is also still ongoing. I added a switch to my version of dmd which allows to toggle the ctfe engine. So now I can compare apples to apples when

Re: Battle-plan for CTFE

I am very happy to announce that calls are almost working now. And the code-gen-interface[1] is near finalization. It should be very easy to provide different back-ends such as LLVM or libJIT now. The missing pieces well be added during next week. I invite everyone to comment on the interface

Re: Battle-plan for CTFE

On Friday, 29 July 2016 at 14:28:03 UTC, Stefan Koch wrote: if ((a && b) || (a && c)) {//bla} This is now solved although quite naively at the cost of inserting twice the number of instructions for thoose cases. Then agian we are still much faster then the old interpreter. And I can still

Re: Battle-plan for CTFE

On Friday, 29 July 2016 at 12:47:55 UTC, Robert burner Schadek wrote: On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote: please share your thoughts. When is this moving into dmd master? As soon as it passes the test-suite. And can execute diet-ng on the fast-path. Currently I have

Re: Battle-plan for CTFE

On Friday, 29 July 2016 at 13:07:12 UTC, Edwin van Leeuwen wrote: On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote: I have fresh performance statistics: Is there any improvement in memory usage? Yes! There memory usage is the same as run-time execution. plus about 16k for the

Re: Battle-plan for CTFE

On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote: I have fresh performance statistics: Is there any improvement in memory usage?

Re: Battle-plan for CTFE

On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote: please share your thoughts. When is this moving into dmd master?

Re: Battle-plan for CTFE

Hi, I have fresh performance statistics: The test[1] involved running an empty while loop. Machine 1 Linux : DMD release : Interpreted : 3400 ms || Pseudo-Jited 230 || 50ms Native DMD Debug : Interpreted 4560 || Pseudo-Jited 260ms || Native 230 ms LDC release : Interpreted 2400 ms ||

Re: Battle-plan for CTFE

On Sunday, 17 July 2016 at 16:43:18 UTC, Rory McGuire wrote: Nice, so I'll be able to see separate improvements in my CTFE stuff vs the pegged template stuff once structs, classes, etc.. are handled in your new ctfe. Yes. Btw while working on printing template-instantiations I discovered

Re: Battle-plan for CTFE

On Sun, Jul 17, 2016 at 6:08 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Sunday, 17 July 2016 at 15:57:28 UTC, Rory McGuire wrote: > >> >> Thanks that would be great, however I think its a while off before it can >> work on your ctfe

  1   2   3   >