Re: Battle-plan for CTFE

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 implementation. It uses Pegged, so getting the Pegged JSON parser or pegged.peg working would be a first step. pegged uses templates.

Re: Battle-plan for CTFE

On Sun, Jul 17, 2016 at 3:28 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Sunday, 17 July 2016 at 13:04:33 UTC, Rory McGuire wrote: > >> On Sun, Jul 17, 2016 at 2:41 PM, Stefan Koch via Digitalmars-d-announce < >>

Re: Battle-plan for CTFE

On Sunday, 17 July 2016 at 13:04:33 UTC, Rory McGuire wrote: On Sun, Jul 17, 2016 at 2:41 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: [...] A commit does pretty much the same thing. Tags/Branches just make UIs show a "menu" for selecting a

Re: Battle-plan for CTFE

On Sun, Jul 17, 2016 at 2:41 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Sunday, 17 July 2016 at 12:12:17 UTC, Rory McGuire wrote: > >> Nice! how are you keeping track of changes? Are you tagging / branching >> each time you get something new

Re: Battle-plan for CTFE

On Sunday, 17 July 2016 at 12:12:17 UTC, Rory McGuire wrote: Nice! how are you keeping track of changes? Are you tagging / branching each time you get something new working? I just push a new commit. And add code to the gist. Why would I branch ? It all goes towards the same goal.

Re: Battle-plan for CTFE

Nice! how are you keeping track of changes? Are you tagging / branching each time you get something new working? On Sun, Jul 17, 2016 at 12:12 PM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Friday, 15 July 2016 at 20:36:46 UTC, Stefan Koch wrote: >

Re: Battle-plan for CTFE

On Friday, 15 July 2016 at 20:36:46 UTC, Stefan Koch wrote: I decided to keep a gist updated to represent the current state the new engine can handle. https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e Internal changes to the bytecode engine make the manipulation of values

Re: Battle-plan for CTFE

On Thursday, 14 July 2016 at 00:45:53 UTC, Stefan Koch wrote: On Saturday, 9 July 2016 at 20:09:14 UTC, Stefan Koch wrote: I decided to keep a gist updated to represent the current state the new engine can handle. https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e This is

Re: Battle-plan for CTFE

On Saturday, 9 July 2016 at 20:09:14 UTC, Stefan Koch wrote: I decided to keep a gist updated to represent the current state the new engine can handle. https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e This is the currentState after approx. 50 hours of work First

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. [ ] I will post more details as soon as I dive deeper into the code. I decided to keep a gist updated to represent the current state the new engine

Re: Battle-plan for CTFE

p.s. it is, btw, completely possible to add at least something like "ctfe tracer" (something like old basic "trace on" command), or even some kind of gdb-like debugger to ctfe engine. it won't, of course, find it's way into mainline, but may still be a fun project to do.

Re: Battle-plan for CTFE

On Friday, 8 July 2016 at 23:31:38 UTC, Stefan Koch wrote: and mine is segfaulting in some bizarre ways (i failed my basic ++ and -- math, and so the stack ;-). still, it is almost working, with support for both compiled and interpreted function calls, almost full range of integer math and

Re: Battle-plan for CTFE

On Friday, 8 July 2016 at 12:17:29 UTC, Rene Zwanenburg wrote: On Friday, 8 July 2016 at 11:32:10 UTC, Stefan Koch wrote: I forgot to mention I posted a short article about the CTFE design on my blog. https://codesoldier.blogspot.com Feel free to comment or give suggestions. Thanks! Posts

Re: Battle-plan for CTFE

On Friday, 8 July 2016 at 11:32:10 UTC, Stefan Koch wrote: I forgot to mention I posted a short article about the CTFE design on my blog. https://codesoldier.blogspot.com Feel free to comment or give suggestions. Thanks! Posts like these are always interesting to read. I noticed a few

Re: Battle-plan for CTFE

On Thursday, 7 July 2016 at 17:47:28 UTC, Stefan Koch wrote: On Thursday, 7 July 2016 at 13:55:44 UTC, Stefan Koch wrote: I just made a PR to fix it for ctfe. It's a hack but then again ... The whole handling of PowExp is a hack. Clarification now it works on Literals. It is still not

Re: Battle-plan for CTFE

On Thursday, 7 July 2016 at 13:55:44 UTC, Stefan Koch wrote: I just made a PR to fix it for ctfe. It's a hack but then again ... The whole handling of PowExp is a hack. Clarification now it works on Literals. It is still not available at ctfe and the full non-hackish fix will take a while.

Re: Battle-plan for CTFE

On Tuesday, 10 May 2016 at 00:36:21 UTC, Walter Bright wrote: On 5/9/2016 2:32 PM, Andrej Mitrovic via Digitalmars-d-announce wrote: On 5/9/16, Stefan Koch via Digitalmars-d-announce wrote: I was shocked to discover that the PowExpression actually depends

Re: Battle-plan for CTFE

yay. ackemann(3, 7) in 70 milliseconds! and it does TCO. default interpreter is unable to execute that -- recursion is too deep.

Re: Battle-plan for CTFE

just... can't... stop... some current statistics: druntime total interpreted calls: 27,146 total complied calls : 1,330 phobos total interpreted calls: 6,492,826 total complied calls : 19,975 i can't do function calls from compiled code yet, so number of compiled calls is low, and no

Re: Battle-plan for CTFE

On Wednesday, 6 July 2016 at 08:16:32 UTC, Rory McGuire wrote: Thought as much, wondered if the ideas about how they work were being shared; often one idea sparks another. sure, some ideas flows; mostly very high-level. for example, proper fallback to the original interpreter was invented by

Re: Battle-plan for CTFE

On Wed, Jul 6, 2016 at 8:09 AM, ketmar via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Wednesday, 6 July 2016 at 05:54:48 UTC, Rory McGuire wrote: > >> Are you sharing this code >> > > yes. we are chatting with Stefan in IRC, and the repository is public (i > mean,

Re: Battle-plan for CTFE

On Tuesday, 5 July 2016 at 21:11:39 UTC, deadalnix wrote: On Monday, 4 July 2016 at 07:29:49 UTC, ZombineDev wrote: Nice work! Any chance that you could also improve AliasSeq algorithms, like those in std.meta to compile faster and use less memory during compilation? Or is that too different

Re: Battle-plan for CTFE

On Wednesday, 6 July 2016 at 05:54:48 UTC, Rory McGuire wrote: Are you sharing this code i mean "my code is publicly available, but we aren't sharing any code between our projects".

Re: Battle-plan for CTFE

On Wednesday, 6 July 2016 at 05:54:48 UTC, Rory McGuire wrote: Are you sharing this code yes. we are chatting with Stefan in IRC, and the repository is public (i mean, the link was there ;-). yet it won't compile with "vanilla" dmd anyway -- i require my dmd fork ("aliced"). and i don't

Re: Battle-plan for CTFE

On Tue, Jul 5, 2016 at 11:54 PM, ketmar via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > and just to make sure that my approach is working: bytecode compiler now > compiles simple free functions without args and returning int (yep, there > are some in phobos! ;-), while

Re: Battle-plan for CTFE

and just to make sure that my approach is working: bytecode compiler now compiles simple free functions without args and returning int (yep, there are some in phobos! ;-), while passing everything other to old interpreter. it works, and all phobos unittests are passed (and some functions were

Re: Battle-plan for CTFE

On Monday, 4 July 2016 at 07:29:49 UTC, ZombineDev wrote: Nice work! Any chance that you could also improve AliasSeq algorithms, like those in std.meta to compile faster and use less memory during compilation? Or is that too different from CTFE? Not that I opposes this, but please keep it

Re: Battle-plan for CTFE

On Tue, Jul 05, 2016 at 05:44:14PM +, Ola Fosheim Grøstad via Digitalmars-d-announce wrote: > On Tuesday, 5 July 2016 at 16:40:05 UTC, ketmar wrote: > > so, we played a little game with Stefan: i wrote a simple > > stack-based VM implementation for our beloved bug6498, and got > > What is

Re: Battle-plan for CTFE

On Tuesday, 5 July 2016 at 16:40:05 UTC, ketmar wrote: so, we played a little game with Stefan: i wrote a simple stack-based VM implementation for our beloved bug6498, and got What is «bug6498»?

Re: Battle-plan for CTFE

On Monday, 4 July 2016 at 07:33:48 UTC, ZombineDev wrote: BTW, do you plan to handle stuff like exceptions, virtual calls and associative arrays and if so how? Sounds quite challenging. on the lower level, it's all just arrays and jumps. ;-)

Re: Battle-plan for CTFE

so, we played a little game with Stefan: i wrote a simple stack-based VM implementation for our beloved bug6498, and got 270 msecs with debug build, 140 msecs with release build. can be made even faster with some simple peephole optimizer (it has two hacks to get fair times on 6498, but this

Re: Battle-plan for CTFE

On Monday, 4 July 2016 at 07:33:48 UTC, ZombineDev wrote: On Monday, 4 July 2016 at 07:29:49 UTC, ZombineDev wrote: Nice work! Any chance that you could also improve AliasSeq algorithms, like those in std.meta to compile faster and use less memory during compilation? Or is that too different

Re: Battle-plan for CTFE

On Monday, 4 July 2016 at 07:29:49 UTC, ZombineDev wrote: On Monday, 4 July 2016 at 01:54:29 UTC, Stefan Koch wrote: On Thursday, 30 June 2016 at 14:26:29 UTC, Stefan Koch wrote: On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote: Sorry, I had missed this. I see you were able to

Re: Battle-plan for CTFE

On Monday, 4 July 2016 at 01:54:29 UTC, Stefan Koch wrote: On Thursday, 30 June 2016 at 14:26:29 UTC, Stefan Koch wrote: On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote: Sorry, I had missed this. I see you were able to make progress. It's fine. Honestly the hardest thing was to

Re: Battle-plan for CTFE

On Thursday, 30 June 2016 at 14:26:29 UTC, Stefan Koch wrote: On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote: Sorry, I had missed this. I see you were able to make progress. It's fine. Honestly the hardest thing was to actually get started. Once I see something working the

Re: Battle-plan for CTFE

On Thursday, 30 June 2016 at 14:17:30 UTC, Timon Gehr wrote: Sorry, I had missed this. I see you were able to make progress. It's fine. Honestly the hardest thing was to actually get started. Once I see something working the excitement carries me forward :) I would appreciate a critical

Re: Battle-plan for CTFE

On 08.06.2016 03:20, Stefan Koch wrote: On Friday, 3 June 2016 at 15:46:27 UTC, Stefan Koch wrote: On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: I will post more details as soon as I dive deeper into the code. Okay I briefly evaluated the current IR dmd uses for backend

Re: Battle-plan for CTFE

On Thursday, 30 June 2016 at 07:15:30 UTC, Nordlöw wrote: On Thursday, 30 June 2016 at 03:17:38 UTC, Stefan Koch wrote: Until then you can see my progress at https://github.com/UplinkCoder/dmd/tree/newCTFE I will try to always keep the branch in a healthy state. I can't wait to see the

Re: Battle-plan for CTFE

On 06/30/2016 05:17 AM, Stefan Koch wrote: > Both. Actually I could not imagine fixing the memory problem without > doing IR interpretation. > I will tackle compiling more difficult code later today. > As soon as I can run my compiletime brainfuck I will open a PR. > > Until then you can see my

Re: Battle-plan for CTFE

On Thursday, 30 June 2016 at 01:32:47 UTC, Martin Nowak wrote: On Thursday, 30 June 2016 at 01:20:08 UTC, Stefan Koch wrote: First small code example compiles! int bug6498(int x) { int n = 0; while (n < x) { n++; } return n; } evaluation of bug6498(100_000_00) took 226 msecs.

Re: Battle-plan for CTFE

On Thursday, 30 June 2016 at 01:20:08 UTC, Stefan Koch wrote: First small code example compiles! int bug6498(int x) { int n = 0; while (n < x) { n++; } return n; } evaluation of bug6498(100_000_00) took 226 msecs. evaluation of bug6498(100_000_000) took 2228 msecs. The memory

Re: Battle-plan for CTFE

First small code example compiles! int bug6498(int x) { int n = 0; while (n < x) { n++; } return n; } evaluation of bug6498(100_000_00) took 226 msecs. evaluation of bug6498(100_000_000) took 2228 msecs. The memory allocated by the Evaluator is exactly 12 bytes.

Re: Battle-plan for CTFE

On Friday, 3 June 2016 at 15:46:27 UTC, Stefan Koch wrote: On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: I will post more details as soon as I dive deeper into the code. Okay I briefly evaluated the current IR dmd uses for backend communication, and it seems usable for the

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: I will post more details as soon as I dive deeper into the code. Okay I briefly evaluated the current IR dmd uses for backend communication, and it seems usable for the purposes of a CTFE-Interpreter/JIT. The Memory-Management

Re: Battle-plan for CTFE

On Saturday, 28 May 2016 at 12:27:26 UTC, Stefan Koch wrote: On Friday, 27 May 2016 at 23:31:24 UTC, Stefan Koch wrote: On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. I will post more details as soon

Re: Battle-plan for CTFE

On Friday, 27 May 2016 at 23:31:24 UTC, Stefan Koch wrote: On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. I will post more details as soon as I dive deeper into the code. Update : int bug6498(int x)

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. I will post more details as soon as I dive deeper into the code. Update : int bug6498(int x) { int n = 0; while (n < x) ++n; return

Re: Battle-plan for CTFE

On Saturday, 21 May 2016 at 21:20:54 UTC, Martin Nowak wrote: On 05/21/2016 11:18 PM, Martin Nowak wrote: The debugging metaphor would be comparing a program that only uses pointer arithmetic against one that is memory safe, the former can randomly write everywhere from anywhere, the latter

Re: Battle-plan for CTFE

On 05/21/2016 11:18 PM, Martin Nowak wrote: > The debugging metaphor would be comparing a program that only uses > pointer arithmetic against one that is memory safe, the former can > randomly write everywhere from anywhere, the latter could use the wrong > reference. It's also similar to

Re: Battle-plan for CTFE

On 05/18/2016 04:59 PM, Daniel Murphy wrote: > The bytecode generator and bytecode interpreter can be debugged (and > tested!) independently. So the total amount of code will increase but > the components themselves will be better isolated and easier to work with. It's simpler to debug an AST

Re: Battle-plan for CTFE

On 05/18/2016 07:50 PM, Stefan Koch wrote: > Indeed. > > I am currently designing an IR to feed into the CTFE Evaluator. > I am aware that this could potentially make it harder to get things > merged since DMD already has the glue-layer. As a compat layer between different interpreters or as a

Re: Battle-plan for CTFE

On 19/05/2016 3:50 AM, Stefan Koch wrote: I am currently designing an IR to feed into the CTFE Evaluator. I am aware that this could potentially make it harder to get things merged since DMD already has the glue-layer. It's always more difficult to justify merging more complexity. But if

Re: Battle-plan for CTFE

On 18/05/2016 9:01 AM, Martin Nowak wrote: Yes, this https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/dinterpret.d#L3418 is really ugly and complex, but you won't get rid of this inherent complexity. The e2ir code for AssingExp looks almost the same

Re: Battle-plan for CTFE

On 05/17/2016 12:42 PM, Don Clugston wrote: > There's no need for grandiose plans, as if there is some > almost-insurmountable problem to be solved. THIS IS NOT DIFFICULT. With > the interface cleaned up, it is the well-studied problem of creating an > interpreter. Everyone knows how to do this,

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 10:29:21 UTC, Martin Nowak wrote: On 05/10/2016 08:45 AM, Jacob Carlborg wrote: I was listening to a discussion Don and Daniel had about the current implementation of CTFE. They talked about using a byte code interpreter. Even implementing a really crappy byte code

Re: Battle-plan for CTFE

On Tuesday, 17 May 2016 at 10:42:30 UTC, Don Clugston wrote: TL;DR: CTFE is actually a backend, so don't be afraid of creating a glue layer for it. My point exactly. The AST is not something I want to handle while inside the interpreter. It introduces too much complexity. There needs to

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 12:17:30 UTC, Daniel Murphy wrote: On 15/05/2016 9:57 PM, Martin Nowak wrote: On 05/15/2016 01:58 PM, Daniel Murphy wrote: The biggest advantage of bytecode is not the interpreter speed, it's that by lowering you can substitute VarExps etc with actual references to

Re: Battle-plan for CTFE

On Monday, 16 May 2016 at 12:13:14 UTC, Martin Nowak wrote: Last time people forced me to spend several hours on reimplementing and debugging a BitArray implementation Ouch. src/tk/vec.(h|c) already contained an implementation.

Re: Battle-plan for CTFE

On Tuesday, 10 May 2016 at 11:31:33 UTC, Stefan Koch wrote: Yes I do know the llvm jit, it is slow as a three legged dog. But I do plan for a way of plugging it in. This is not a main priority however. What about libjit?

Re: Battle-plan for CTFE

On 16/05/2016 9:20 PM, Martin Nowak wrote: On Monday, 16 May 2016 at 10:01:47 UTC, Kagamin wrote: Wasn't it possible to enable GC for entire compiler? There can be hybrid approach: 1) first allocate from bump heap 2) when it reaches, say, 200MB, switch to GC. Well, I wouldn't use D's GC for

Re: Battle-plan for CTFE

On 05/16/2016 03:03 PM, Martin Nowak wrote: > ~this() > { > if (impl.onHeap && --impl.heap.refCount == 0) > heapAllocator.free(impl.heap); > } Of course missing the increment for copies. this(this) { if (impl.onHeap) ++impl.heap.refCount; }

Re: Battle-plan for CTFE

On 05/16/2016 01:36 PM, Andrei Alexandrescu wrote: > > A reap would be great there! std.experimental.allocator offers that and > a variety of others. -- Andrei Yes indeed, a malloc backed Region Allocator w/ a FreeList or a BitmappedBlock would be a good starting point. That might finally be a

Re: Battle-plan for CTFE

On 5/16/16 7:20 AM, Martin Nowak wrote: On Monday, 16 May 2016 at 10:01:47 UTC, Kagamin wrote: Wasn't it possible to enable GC for entire compiler? There can be hybrid approach: 1) first allocate from bump heap 2) when it reaches, say, 200MB, switch to GC. Well, I wouldn't use D's GC for that

Re: Battle-plan for CTFE

On Monday, 16 May 2016 at 10:01:47 UTC, Kagamin wrote: Wasn't it possible to enable GC for entire compiler? There can be hybrid approach: 1) first allocate from bump heap 2) when it reaches, say, 200MB, switch to GC. Well, I wouldn't use D's GC for that dedicated heap. Allocation of CTFE

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 13:25:42 UTC, Martin Nowak wrote: So we do need a GC or RC for arrays, structs, classes (anything heapish). Values for those could be allocated by a simple bump/region allocator or a dedicated allocator that support individual freeing (via RC or GC). Wasn't it

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 15:09:17 UTC, Stefan Koch wrote: You want it ? Write it. I don't «want» anything.

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 14:56:02 UTC, Ola Fosheim Grøstad wrote: Well, this looks really bad. But a solver would get you much more than an interpreter. E.g. proving that asserts always hold etc. You want it ? Write it.

Re: Battle-plan for CTFE

On 05/15/2016 04:00 PM, Daniel Murphy wrote: > The problem is, if index refers to a single variable on the stack, then > it's insufficient to refer to a variable inside an aggregate on the > stack. Then you need to start building constructs for member of struct > in array of struct pointers and

Re: Battle-plan for CTFE

On 05/15/2016 02:54 PM, Daniel Murphy wrote: > > We really should have discussed this last week! I talked about it w/ Stefan, and asked him to volunteer for an implementation, that's why we have this thread ;). In any case I'm convinced that the simple-first strategy has a much higher chance to

Re: Battle-plan for CTFE

On 15/05/2016 11:25 PM, Martin Nowak wrote: On 05/15/2016 02:17 PM, Daniel Murphy wrote: For simple types that's true. For more complicated reference types... Variable indexes are not enough, you also need heap memory, but slices and pointers (and references) can refer to values either on

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 12:54:33 UTC, Daniel Murphy wrote: We really should have discussed this last week! I agree. Maybe we can have a skype conference or something in the next days. About the whole to BC or not to BC discussion. As Daniel already outlined, the main purpose it not

Re: Battle-plan for CTFE

On 05/15/2016 02:13 PM, Ola Fosheim Grøstad wrote: > > Well, you can, but it won't bring improvements to the language down the > line. Maybe you don't know the actual problem of the current interpreter? I leaks memory like hell b/c it allocates new AST nodes for almost every expression

Re: Battle-plan for CTFE

On 05/15/2016 02:17 PM, Daniel Murphy wrote: > > For simple types that's true. For more complicated reference types... > > Variable indexes are not enough, you also need heap memory, but slices > and pointers (and references) can refer to values either on the heap or > the stack, and you can

Re: Battle-plan for CTFE

On 15/05/2016 9:57 PM, Martin Nowak wrote: On 05/15/2016 01:58 PM, Daniel Murphy wrote: The biggest advantage of bytecode is not the interpreter speed, it's that by lowering you can substitute VarExps etc with actual references to memory without modifying the AST. By working with something

Re: Battle-plan for CTFE

On 15/05/2016 9:57 PM, Martin Nowak wrote: On 05/15/2016 01:58 PM, Daniel Murphy wrote: The biggest advantage of bytecode is not the interpreter speed, it's that by lowering you can substitute VarExps etc with actual references to memory without modifying the AST. By working with something

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 12:00:43 UTC, Martin Nowak wrote: On 05/15/2016 01:55 PM, Ola Fosheim Grøstad wrote: If you are going to have fast evaluation of loops/recursion then you need to use a solver. And well, doing worse than O(log N) at compile time is a very bad idea. Why not start with

Re: Battle-plan for CTFE

On 05/15/2016 02:02 PM, Stefan Koch wrote: > > Correct. A ByteCode Interpreter will add even more implementation > overhead, and the benefit is only realizable if the ByteCode is a > standard format that can be read other backends such as a jit. This indeed would be an interesting proposal,

Re: Battle-plan for CTFE

On 05/15/2016 01:55 PM, Ola Fosheim Grøstad wrote: > If you are going to have fast evaluation of loops/recursion then you > need to use a solver. And well, doing worse than O(log N) at compile > time is a very bad idea. > > Why not start with the most difficult case first? Then the simple cases >

Re: Battle-plan for CTFE

On 05/15/2016 01:58 PM, Daniel Murphy wrote: > The biggest advantage of bytecode is not the interpreter speed, it's > that by lowering you can substitute VarExps etc with actual references > to memory without modifying the AST. > > By working with something lower level than the AST, you should

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 10:29:21 UTC, Martin Nowak wrote: On 05/10/2016 08:45 AM, Jacob Carlborg wrote: I was listening to a discussion Don and Daniel had about the current implementation of CTFE. They talked about using a byte code interpreter. Even implementing a really crappy byte code

Re: Battle-plan for CTFE

On 15/05/2016 8:29 PM, Martin Nowak wrote: No need for a byte-code interpreter, it mostly just adds overhead and complexity over an AST interpreter. If you want to go really fast you need some sort of JIT anyhow, but a proper interpreter will be orders of mangnitude faster than the current

Re: Battle-plan for CTFE

On 05/09/2016 06:57 PM, Stefan Koch wrote: > I was shocked to discover that the PowExpression actually depends on > phobos! (depending on the exact codePath it may or may not compile...) > which let to me prematurely stating that it worked at ctfe >

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 10:29:21 UTC, Martin Nowak wrote: On 05/10/2016 08:45 AM, Jacob Carlborg wrote: overhead and complexity over an AST interpreter. If you want to go really fast you need some sort of JIT anyhow, but a proper interpreter will be orders of mangnitude faster than the

Re: Battle-plan for CTFE

On 05/13/2016 06:32 PM, Stefan Koch wrote: > I would like to work on a solution that does scale. The Problem is > not making a byteCode-interpreter. That part is relatively easy. > Currently I am trying to get a detailed understanding of dmd and > it's data-structures. (mainly it's AST.) > >

Re: Battle-plan for CTFE

On 05/10/2016 08:45 AM, Jacob Carlborg wrote: > > I was listening to a discussion Don and Daniel had about the current > implementation of CTFE. They talked about using a byte code interpreter. > Even implementing a really crappy byte code interpreter would be a huge > improvement. No need for a

Re: Battle-plan for CTFE

On Wednesday, May 11, 2016 07:06:59 maik klein via Digitalmars-d-announce wrote: > What is the current problem with ctfe? The biggest problem is that it uses up a _lot_ of memory and is generally slow. For instance, as I understand it, every time it mutates a variable, it actually allocates a

Re: Battle-plan for CTFE

On Friday, 13 May 2016 at 13:59:57 UTC, Don Clugston wrote: I think I need to explain the history of CTFE. Originally, we had constant-folding. Then constant-folding was extended to do things like slicing a string at compile time. Constant folding leaks memory like the Exxon Valdez leaks oil,

Re: Battle-plan for CTFE

On 13.05.2016 15:59, Don Clugston wrote: All that's needed is a very simple bytecode interpreter. Here is the one I have hacked together: https://github.com/tgehr/d-compiler/blob/master/interpret.d This file does both constant folding and byte-code interpretation for most of the language. I

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. Unfortunately It is a pretty big mess to untangle. Code responsible for CTFE is in at least 3 files. [dinterpret.d, ctfeexpr.d, constfold.d] I was shocked

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. Unfortunately It is a pretty big mess to untangle. Code responsible for CTFE is in at least 3 files. [dinterpret.d, ctfeexpr.d, constfold.d] I was shocked

Re: Battle-plan for CTFE

On Mon, May 09, 2016 at 05:36:21PM -0700, Walter Bright via Digitalmars-d-announce wrote: > On 5/9/2016 2:32 PM, Andrej Mitrovic via Digitalmars-d-announce wrote: > >On 5/9/16, Stefan Koch via Digitalmars-d-announce > > wrote: > >>I was shocked to discover

Re: Battle-plan for CTFE

On Tuesday, 10 May 2016 at 07:44:54 UTC, Rory McGuire wrote: On Tue, May 10, 2016 at 8:45 AM, Jacob Carlborg via Digitalmars-d-announce wrote: I was listening to a discussion Don and Daniel had about the current implementation of CTFE. They talked about

Re: Battle-plan for CTFE

On Tue, May 10, 2016 at 8:45 AM, Jacob Carlborg via Digitalmars-d-announce wrote: > > I was listening to a discussion Don and Daniel had about the current > implementation of CTFE. They talked about using a byte code interpreter. > Even implementing a really

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 18:20:46 UTC, Robert burner Schadek wrote: awesome news :-) thanks you I very much agree.

Re: Battle-plan for CTFE

On 2016-05-09 18:57, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. Unfortunately It is a pretty big mess to untangle. Code responsible for CTFE is in at least 3 files. [dinterpret.d, ctfeexpr.d, constfold.d] I was shocked to discover that the

Re: Battle-plan for CTFE

On 5/9/16 7:57 PM, Stefan Koch wrote: Hi Guys, I have been looking into the DMD now to see what I can do about CTFE. Unfortunately It is a pretty big mess to untangle. Code responsible for CTFE is in at least 3 files. [dinterpret.d, ctfeexpr.d, constfold.d] I was shocked to discover that the

Re: Battle-plan for CTFE

On 5/9/2016 2:32 PM, Andrej Mitrovic via Digitalmars-d-announce wrote: On 5/9/16, Stefan Koch via Digitalmars-d-announce wrote: I was shocked to discover that the PowExpression actually depends on phobos! I seem to remember having to implement

Re: Battle-plan for CTFE

On Monday, May 09, 2016 13:24:56 Walter Bright via Digitalmars-d-announce wrote: > On 5/9/2016 9:57 AM, Stefan Koch wrote: > >[...] > > The memory consumption problem, at least, can be resolved by using stack > temporaries instead of allocating new nodes. This was already done in > constfold.d,

Re: Battle-plan for CTFE

On Monday, 9 May 2016 at 20:24:56 UTC, Walter Bright wrote: On 5/9/2016 9:57 AM, Stefan Koch wrote: [...] The memory consumption problem, at least, can be resolved by using stack temporaries instead of allocating new nodes. This was already done in constfold.d, but not in the rest of the

Re: Battle-plan for CTFE

On 5/9/16, Stefan Koch via Digitalmars-d-announce wrote: > I was shocked to discover that the PowExpression actually depends > on phobos! I seem to remember having to implement diagnostics in DMD asking for the user to import std.math. I'm fairly confident

<    1   2   3   >